Forward Proxies: When a Server Proxies Outbound Traffic

A forward proxy sits in front of clients rather than servers. It takes connections from a group of clients — an office, a scraping fleet, a CI runner — and makes their outbound HTTP requests on their behalf. The internet sees the proxy's IP, not the client's. This is the shape of traffic yours truly flows through when you use a corporate proxy or a scraping pool, and it is a different engineering problem from the reverse proxies covered earlier in this series.

Forward versus reverse in one sentence

A reverse proxy stands between the internet and your servers, hiding the servers. A forward proxy stands between your clients and the internet, hiding the clients. If you want multiple endpoints under one IP that others connect to, you want a reverse proxy. If you want one controlled egress point that many of your own machines or tools pass through, you want a forward proxy.

When a forward proxy earns its place

• **One egress IP.** Every request leaves through the proxy's address, which is what allowlists at third-party APIs sometimes require.
• **Central filtering.** You can block malware domains or risky TLS versions in one file instead of on every workstation and runner.
• **Caching and deduplication.** Repeated fetches of the same artifact can be served from proxy cache instead of hitting the source again.
• **Auditing.** A corporate-flavored log of who fetched what becomes possible at the network edge.

The classic warning still applies: a forward proxy is a man-in-the-middle by design, and if the proxy itself is compromised, so is all the traffic that passes through it.

Run a minimal forward proxy with Squid

Squid is the boring, reliable choice, and the Ubuntu package is ready to go. Lock it down to the private networks that are allowed to use it before it ever sees traffic.

apt update && apt install -y squid
tee /etc/squid/squid.conf > /dev/null <<'EOS'
http_port 3128
acl allowed_net src 10.10.0.0/16
acl localhost_allowed src 127.0.0.0/8
http_access allow localhost_allowed
http_access allow allowed_net
http_access deny all
EOS
systemctl restart squid
systemctl enable --now squid

The ordering is deliberate: allow lists come first, and the final deny all catches everything else. An anonymous, open forward proxy on a public IP is a magnet for abuse within hours, so the same rules you use on reverse proxies apply here — least privilege, default deny.

Using it from the client side

On the machine that will route through the proxy, every tool with proxy support accepts the same environment variables.

export http_proxy=http://proxy.example.com:3128
export https_proxy=http://proxy.example.com:3128
export no_proxy=localhost,127.0.0.1,10.0.0.0/8
curl -v https://example.com/downloads/tool.deb

The curl verbose output is the fastest way to confirm the path: look for your proxy host in the Connected to line and the Via and X-Cache headers in the response. no_proxy prevents loopback and internal traffic from bouncing through the proxy, which keeps site-local API calls direct and fast.

Authentication-aware variants

Squid also supports per-user credentials for cases where the whole team should not share one password. The config grows a proxy_auth field backed by a basic auth file, and clients send credentials in their requests. Start with source-IP allowlisting as the default posture, and treat per-user auth as an upgrade once you actually have distinct humans to authorize.

Takeaway

Forward proxies make sense when the job is controlling outbound traffic, not inbound: one egress IP, central filtering, and an audit trail. Keep it locked behind allowlists and never expose an anonymous proxy to the public internet. Netbay hosts can be configured either way — pick a name and a datacenter, deploy Squid in a few commands, and you have a controlled egress point at netbayhosts.in.