Interpreting a Proxy Monitor’s Status and Exit Codes
Report command execution, HTTP outcome and certificate validation independently in a proxy-backed website check.
A wrapper cannot turn a zero downloader exit code into an observed “HTTP 200 OK.” Record what each layer actually reported:
| Field | Question answered |
|---|---|
| Tool or plugin exit | Did the check execute, and what failure class did it report? |
| Proxy negotiation | Was forwarding or the requested tunnel admitted? |
| Origin status and expected content | Did the application return the intended result? |
| TLS validation | Did the configured identity checks succeed? |
curl normally can return zero after an HTTP error response. Its fail options alter exit behavior, but a failure exit still does not uniquely identify the status. Wget exit values are categories too: authentication failure is not a dedicated HTTP 401 value, and a server-error category does not identify every response within it. A check expecting 401 must observe that response.
Keep the proxy endpoint and website name separate. The TCP peer of an HTTP-proxy check is the proxy; CONNECT names the destination, whose TLS session then runs inside the tunnel. For an HTTPS proxy, outer proxy trust is another certificate check.
Inspect the plugin's guarantee before treating an SSL flag as verification. Monitoring Plugins deprecates check_http in favor of check_curl. Its check_http documentation warns that selecting SSL alone does not verify hostname or issuer trust; check_curl's documented verify-peer option includes that verification.
Use the intended authenticated route too. A port probe can remain green while the operational account receives 407. Deliver its secret through the deployment's appropriate mechanism, and report the actual failed stage: a denied tunnel calls for a different repair from an unexpected website status.