Skip to main content

​
Prove Client Traffic Reaches SafeSquid

SafeSquid cannot enforce policy on traffic that bypasses the proxy. Client onboarding must prove that web requests traverse SafeSquid, appear in logs, and can later be tied to user identity. Start with a pilot client, then move to managed rollout.

​
Validate prerequisites

Confirm:
  • SafeSquid is installed and activated.
  • The proxy listener is reachable from the pilot network.
  • The pilot client can resolve DNS and reach the proxy IP.
  • The operator can inspect /var/log/safesquid/access/extended.log.
  • Rollback steps exist for the selected client setting.

​
Choose the routing method

1

Choose fastest pilot test

Fastest pilot test

Use explicit proxy settings on one browser or host.
Confirm one browser produces a SafeSquid access-log entry.If no log appears, retest with curl --proxy.
2

Choose managed browser routing

Managed browser routing

Use a PAC file for controlled browser routing and bypass logic.
Confirm PAC evaluation sends internet traffic to SafeSquid.If internal apps break, correct exact bypass logic.
3

Choose host-level OS proxy

Host-level OS proxy

Use system-wide settings when applications inherit operating-system proxy configuration.
Confirm OS-aware applications inherit the proxy setting.If applications bypass OS settings, use application-specific configuration.
4

Choose organization-wide rollout

Organization-wide rollout

Use GPO, MDM, Jamf, Ansible, Puppet, or other managed rollout tooling.
Confirm the rollout tool applies settings only to the pilot ring.If scope is too broad, roll back the profile or policy.
5

Choose application-specific routing

Applications that ignore OS settings

Configure Git, package managers, container runtimes, curl, wget, Outlook, Thunderbird, and other tools directly.
Confirm each application uses SafeSquid or has an approved exception.If a tool still bypasses the proxy, configure its native proxy setting.

​
Grant the matching Access restrictions right

Client routing only delivers traffic to SafeSquid — whether that traffic is actually allowed through still depends on the Access restrictions entry that matches the client, and specifically on which rights that entry grants. Configuring the client correctly but leaving the matching right ungranted looks identical to a routing failure: the client reaches SafeSquid, and SafeSquid still blocks it. These two rights are independent — a client can be granted one and denied the other — and both are independent of CONNECT requests, which separately gates HTTPS tunnels regardless of which delivery mode got the traffic there. Six rights exist on an Access restrictions entry, and none of them implies another:
  • Web interface — permits requests to SafeSquid’s own console. Block pages still display to a denied client rather than a broken connection.
  • Proxy requests — permits explicit proxy requests.
  • HTTP requests — permits plain HTTP traffic, independent of CONNECT requests.
  • Transparent proxying — permits traffic that reached SafeSquid through network-level redirection.
  • CONNECT requests — permits CONNECT tunnels (HTTPS and similar). A denied client fails HTTPS even when HTTP requests are allowed.
  • Allow bypassing — permits a temporary continue after an Access Profiles Deny, using a bypass cookie. An Access Profiles entry marked “do not bypass” still blocks regardless of this right. This is narrower than it sounds, and distinct from the per-entry Bypass checkboxes that skip individual filtering modules.
Find SafeSquid’s listen address and port in Network settings → Listen — port 8080 is common, but it is set per deployment; confirm it before assuming it. An ftp:// URL opened in a browser follows the same explicit-proxy or transparent path as HTTP. A standalone FTP client needs its own proxy configuration, if it supports one at all. Configure the matching entry in Access restrictions before troubleshooting client-side settings further.

​
Start with a pilot

1

Configure one client

Configure one browser or host to use SafeSquid as its proxy.Confirm the client has the approved SafeSquid IP, port, and bypass entries.If the setting does not persist, check endpoint management policy and local browser overrides.
2

Test external access

Browse to http://example.com and record whether the request is allowed or blocked as expected.Confirm the request produces the expected browser result.If browsing fails, confirm proxy reachability and the SafeSquid listener.
3

Test internal bypass

Browse to an internal site that should bypass the proxy, if a bypass is required.Confirm the internal destination follows the approved bypass behavior.If the internal app fails, add only an approved exact bypass entry.
4

Record the result

Record whether traffic is allowed, blocked, or bypassed as expected, then compare the result with SafeSquid access logs.Confirm /var/log/safesquid/access/extended.log records proxied traffic with source, destination, timestamp, and action.If no log appears, retest with curl --proxy and confirm the client is not bypassing SafeSquid.

​
Verify traffic evidence

From a client:
On the SafeSquid server:
Expected result: the log records the pilot request with source, destination, timestamp, and action.
The access log is the authoritative check, but it needs shell access to the SafeSquid host. When you are walking a pilot user through the change, or verifying an endpoint you cannot log into, check the egress address from the browser instead.Visit an address-reflection service such as whatismyip.com from the configured client.Expected result: the address shown is the SafeSquid host’s WAN address, not the client’s own public address. If the client’s own address appears, traffic is bypassing the proxy regardless of what the settings screen says.Pair this with the internal-bypass test: an internal destination should load and should not appear in the SafeSquid log.
Method choice tracks fleet size more than anything else:For production, the usual path is explicit proxy to prove the route, then enterprise deployment to enforce it.

​
Prevent bypass

After the pilot passes, restrict direct internet egress where the network design allows it. A browser proxy setting alone is not a control if endpoints can still reach the internet directly.

​
Capture onboarding evidence

Store:
  • Pilot client and user.
  • Proxy method and settings.
  • Access-log sample.
  • Internal bypass test result.
  • Rollback command or management profile.
  • Exception owner.

​
Troubleshoot client routing

| Access-denied entry in logs | The matching Access restrictions entry lacks the right for this request type | Confirm Proxy requests, HTTP requests, CONNECT requests, or Transparent proxying is granted on the matching entry |

​
Next steps