Service Unavailable or Port 8000 unbound, only for /healthz

Ok, /healthz is not special. I think what I was observing is that my /healthz was returning 500 and the reverse proxy substitutes its own Service Unavailable page? That might be intended behavior, but it makes debugging a lot harder because I can't see the body of the response with the error message.

However, I still don't understand why in the browser I was seeing "Port 8000 unbound." for /healthz while / was working and the CLI was showing "Service Unavailable".

Hmmmm. You had me scared for a moment re: healthz. :P (Tailscale uses healthz and I was afraid some wire had gotten crossed in a very bad way!)

I'm not sure I entirely understand why you saw what you saw. Sounds like maybe something was slow to respond, which yielded the "unbound" error. Let me poke around a bit and see what I can dig up.

If you're looking at this anyway, and have a clear reproducer, let me know.

(And I agree, we should pass through explicit 500s. I thought we did...)

We have some pretty aggressive timeouts to avoid the appearance of hanging for a long time when there's nothing listening on a port. I think you're intermittently hitting those timeouts. That's my best theory, anyway.

cc @bmizerany who last tuned these timeouts -- perhaps we should loosen them just a smidge?

That's not impossible, but I switched back and forth between / serving the right page, /healthz in the browser serving "Service Unavailable", and /healthz in the CLI serving "Service Unavailable" at least three times, so it would be a hell of a coincidence. There is also nothing that would make /healthz slower than /.

BTW, I put the 500 back up at https://geomys-atsite.exe.xyz/500 to try to reproduce it, and now I just see my custom error. Maybe you fixed something in the meantime? Or the proxy is haunted.

We have some pretty aggressive timeouts to avoid the appearance of hanging for a long time when there's nothing listening on a port. I think you're intermittently hitting those timeouts. That's my best theory, anyway.

cc @bmizerany who last tuned these timeouts -- perhaps we should loosen them just a smidge?

Sounds right. I loosed them and the change is now live. Sorry for those hiccups @FiloSottile. Please let us know if the issue persists. I'll close this assuming this fixes it, but please reopen if it comes back.