Request-path diagnostics
Last updated: · Applies to Roxy-WI 10.0 and later.
Diagnose DNS, listener, TCP, TLS/SNI, HTTP and candidate-backend connectivity for HAProxy, NGINX and Apache with saved evidence.
Diagnose a request
- Open a HAProxy, NGINX or Apache service page and choose Actions → Request diagnostics on the server card.
- Enter a domain or HTTP(S) URL. A domain alone uses HTTPS.
- Select Diagnose request path. If several frontends match, select the Discovered frontend and run again.
- Read the stage results and open Assessment history for previous runs.
The dialog uses that card's server and service. Changing the URL clears the frontend choice. Operators can start checks; readers with the relevant service/group access can inspect history. The Operations worker retains the job after the dialog closes. Reopening resumes polling; Retry status retries a failed status read without starting a new assessment.
Read the diagnostic stages
| Stage | Evidence |
|---|---|
| Configuration | Discovered frontend and candidate backends, source hash and completeness. |
| DNS | Answers from the controller and managed host, including differences. |
| Listener / VIP | DNS destinations matched to the selected frontend's bindings. |
| TCP | Connection result, address, port and connection time. |
| TLS / SNI | Requested hostname, trust, certificate identity/expiry and protocol. |
| HTTP | A HEAD response status without credentials, cookies, bodies or redirects. |
| Candidate backends | TCP checks from the configured proxy network context. |
For example, a reachable listener with a refused backend TCP connection identifies a useful next investigation. It does not prove which backend a complete dynamic request would select or whether the application is healthy.
Scope and limits
Targets come from the authorized proxy configuration. HAProxy startup files, NGINX configuration dumps and Apache includes are inspected. Dynamic ACLs/maps, scripts, conditional routes and unsupported destinations remain partial or unprobed. Disk configuration may differ from what the running process last loaded.
Only addresses matching the chosen frontend are probed. The checks pin resolved addresses, verify TLS and do not follow redirects. An untrusted certificate can be reported, but no HTTP request is sent through the unverified connection.
For adopted Docker/Podman services, probes use the saved engine, owner and verified container network namespace. Backend DNS comes from the managed host; custom container DNS rules and its CA store are not inferred. Checks are bounded, including 16 candidate backends per assessment, and omitted targets are reported.
Follow up and retry
Fix the reported DNS, listener, certificate or backend issue, then run a fresh assessment. If configuration changes during probing, the result is stale. Use certificate sources or the certificate catalog for deployment issues, and service logs for application behavior.
Reports are encrypted and tied to the original server registration. Recreating a server does not transfer its previous diagnostics. Reports and queued assessments without a verifiable registration identity cannot be reused; run a new check after upgrading Web and Operations together.