​

Decide Where Traffic Is Intercepted

The interception point determines what SafeSquid can enforce. Choose it before sizing, before firewall changes, and before any client is touched — the choice drives client configuration effort, coverage gaps, and how easily a user can route around the control. SafeSquid cannot enforce policy on traffic that bypasses the proxy. Every mode below is a different answer to how you stop that from happening.

​

Match the mode to the constraint

Start with forward proxy for a pilot even when transparent is the production target. Explicit configuration makes it obvious which client is being tested and easy to roll back.

​

Understand what each mode enforces

Forward proxy requires explicit client configuration through browser settings, a PAC file, or system-level proxy settings. It gives the most granular control over which clients are proxied, and the clearest rollback — remove the setting. It also means an endpoint that misses the rollout is silently unprotected. Transparent proxy intercepts traffic through network-level redirection, with no client configuration. Coverage is comprehensive for everything on the redirected path, including devices you cannot configure. The cost moves to the network team, and a routing change made without coordination can take the control offline for everyone at once. TCP proxy operates at the TCP layer for non-HTTP protocols that still need inspection and control. Use it where an application will not honour an HTTP proxy but its traffic must still be governed. Reverse proxy protects internal web servers from direct internet access, terminating TLS and applying authentication in front of them. This is the inbound case — it does not replace an outbound egress control. Proxy chain places SafeSquid in a multi-tier architecture, forwarding to or receiving from another proxy. Use it where an existing upstream proxy cannot be removed, and confirm which tier owns policy before splitting enforcement across both.

​

Design the network placement

Once the mode is chosen, document where it sits:

• Explicit proxy for pilot clients and controlled validation.
• PAC file or managed OS proxy for browser rollout.
• Firewall or routing policy only when the network team can enforce bypass controls safely.
• Cloud egress placement for workloads or remote sites that already route through a cloud network.

Record source networks, proxy listener ports, DNS servers, NTP sources, upstream gateways, and firewall rules. Name an owner for every routing or firewall policy that forwards traffic toward SafeSquid — an unowned redirect is the one nobody restores after an outage.

​

Capture the architecture decision

Store these artifacts with the deployment record:

• The chosen mode and the constraint that drove it.
• A network placement diagram showing the interception point.
• Source networks and listener ports, with the firewall change record.
• The named owner of any routing, WCCP, or redirect policy.
• The rollback path for the interception change, and its owner.

​

Troubleshoot architecture choices

​

Next steps

• Forward Proxy - configure the explicit path used for most pilots.
• Transparent Proxy - intercept without touching clients.
• Resource Planning - size the node once placement is decided.