Prove Traffic Reaches the Proxy
A healthy proxy that clients cannot reach passes every check run on the server. The failure only appears from the client side — and by then users are already escalating, and the fastest workaround an impatient administrator reaches for is removing the proxy setting entirely. Run this check from a pilot client, not from the SafeSquid host.Validate prerequisites
Confirm:- Service Health passes on the SafeSquid node.
- At least one pilot client is configured to use SafeSquid as its proxy. Use Connect Your Client for the routing path.
- You have shell access to the SafeSquid server to read the access log.
- The test window is approved in the change record.
Request an HTTP site through the proxy
From the pilot client:200, 301, or 302.
Confirm the request was logged
The client response alone does not prove the request went through SafeSquid — a bypassed client reaches the site just as successfully. The access log is the proof. On the SafeSquid server:Client-side checklist
Client-side checklist
Run this from a client workstation, not from the SafeSquid host. It catches the failures that server-side checks cannot see — a healthy proxy that clients cannot reach still passes every check on the server.Network connectivity
-
ping <PROXY-IP>succeeds from the client. -
The proxy port accepts connections. On Windows, PuTTY in raw mode serves the same purpose as
telnet:
- Browser proxy points at
<PROXY-IP>:8080. - OS-level proxy is configured, where all applications must be covered.
-
http://safesquid.cfg/loads when the proxy is configured. - The activation key has been uploaded through the interface.
- Support → Activation Details shows an active state.
- An SSH client is available on the administrator workstation.
- Public keys are installed on the SafeSquid host if key-based authentication is required.
-
ssh <admin-user>@<PROXY-IP>succeeds from the approved management network.
Capture connectivity evidence
Store these artifacts with the deployment record:- The
curlcommand and its response headers. - The matching access-log line from
/var/log/safesquid/access/extended.log, showing source, destination, timestamp, and action. - The pilot client’s proxy configuration.
- The completed client-side checklist, with the tester named.
Troubleshoot client routing
Next steps
- HTTPS Inspection Validation - prove encrypted traffic is inspected, not tunnelled.
- Logging and Reporting - confirm evidence is retained and reportable.
- Explicit Browser Proxy - re-check the client routing method.