Debug HTTP Checks Behind Nginx Without Falling Back to TCP

Reproduce the monitor request, not a convenient approximation

Write down the exact URL, method, accepted statuses, headers, authentication, timeout, and redirect policy. A browser may follow redirects and carry login cookies while the monitor sends an unauthenticated request. A command on the host may use a different resolver and route from the checking container.

Run the equivalent request from the same network namespace using an approved diagnostic image if the application container has no troubleshooting tools. Do not install an unreviewed package into a running production container merely to get a quick result. Record the destination address, certificate identity, response status, and request time.

Separate DNS from virtual-host behavior

Use the public hostname as the URL, even when comparing a known origin address. A request to a raw IP can select a default virtual host and present the wrong TLS identity. This curl example (opens in a new tab) pins the destination address for a direct connection; replace the documentation host and address with your own.

Run this example only from a location permitted to connect directly. The --noproxy '*' option prevents inherited proxy settings from changing the path. If an outbound proxy is mandatory, use an approved diagnostic location or inspect the proxy's upstream connection separately; --resolve alone does not control an HTTP CONNECT proxy's origin resolution.

umask 077
probe_dir="$(mktemp -d)"
curl --noproxy '*' --resolve app.example.com:443:192.0.2.10 \
  --connect-timeout 5 --max-time 15 \
  --dump-header "$probe_dir/headers.txt" \
  --output "$probe_dir/body.txt" \
  https://app.example.com/health

The private temporary directory can contain sensitive headers or response data; inspect it locally and remove it when the investigation is complete. Do not disable TLS verification to declare the monitor fixed. If the pinned request works but normal resolution fails, compare DNS answers and reachability for each address family.

Inspect each redirect and responding layer

Capture the initial response before following redirects. Check whether HTTP redirects to HTTPS, whether a canonical host changes, and whether an authentication gateway sends the client to a login page. Match the probe time and source address in Nginx access and error logs, then inspect upstream status and timing.

The Uptime Kuma reverse-proxy documentation (opens in a new tab) applies when Nginx fronts Kuma itself, including its connection requirements. Keep that separate from Nginx fronting the application being monitored; they are two different request paths and can fail independently.

Restore the application assertion

Once the path is understood, retain the expected status and a stable content or JSON assertion. For a private endpoint, use an explicitly scoped machine identity or a deliberately public minimal health endpoint. A 401 response may be correct for unauthenticated users while still requiring a different monitor design.

Test a real application failure behind the open proxy port. The HTTP monitor should fail while a TCP test can still succeed. Then verify a valid recovery and the notification received. Record the request contract with the monitor so a later authentication or rewrite change can be reviewed against a concrete expectation.