Check That Your Proxy Is Not Open to Everyone
Verify the listener, rule order, credentials, and actual forwarding from both permitted and denied sources before exposing a forward proxy.
Test the access boundary before making a new forward proxy reachable from other networks. A successful request from the server itself proves very little about what an unrelated client can do. Use a controlled destination so you can tell whether a denied request was actually forwarded.
Check the effective listener and policy
Inspect the listening process and addresses, including IPv6 if enabled. Remove unintended extra listeners or older service instances. Keep the network firewall limited to the sources that should reach the service.
Then inspect the configuration the process actually loaded, including included files. In Squid 6, an earlier allow can make a later restriction irrelevant. In Tinyproxy 1.11.2, removing every Allow and Deny line permits all clients. Dante has separate client and SOCKS rules, so admitting the TCP connection is not the whole policy.
Use your installed version's documentation. Squid's version-8 directive changes are a reason to verify the version, not a reason to assume a familiar configuration was accepted with the same meaning.
Test both the allowed and denied cases
For a proxy intended to require an approved source and a login, run this matrix using systems you control:
| Source | Credentials | Required outcome |
|---|---|---|
| Allowed | Valid | The intended destination receives the request. |
| Allowed | Missing or wrong | The destination is not reached. |
| Not allowed | Valid or missing | The destination is not reached. |
Two devices behind one NAT can appear as the same source. Choose test locations with different source addresses at the proxy, and confirm those addresses in its logs. Do not use unrelated third-party machines or scan other people's services.
A firewall denial may produce no HTTP response at all. An application denial may return an error. In either case, verify that the controlled target did not receive the forbidden request; an error page alone can otherwise be confused with a destination response.
Exercise the forwarding modes you intend to permit
For a web proxy, test an ordinary HTTP request and the allowed HTTPS CONNECT path separately. If destination restrictions are part of the policy, test a permitted destination and a controlled one that should be rejected. Do not remove the controls just to make every test succeed.
Retest after changes to source ranges, credentials, listener addresses, included files, or service versions. Keep the test time, configuration version, and outcomes together so a later change can be checked against the same boundary.
This is an acceptance procedure, not a claim that a configuration parser or one request can prove every network path is closed.