Why some traffic can bypass a proxy: PAC, DIRECT, and WebRTC
A browser proxy setting is not always a device-wide rule. A PAC file can intentionally return DIRECT, another application may ignore the system proxy, and WebRTC uses ICE candidates with its own connection paths. This does not automatically mean a leak or failure, but the flows that matter to the authorized task must be tested explicitly.
Key points in one minute
- A proxy handles only traffic that the client sends to it according to a rule.
- A PAC file can select PROXY, SOCKS, or DIRECT for different destinations.
- A DIRECT fallback can improve availability while allowing a direct route.
- WebRTC can use host, server-reflexive, and relay ICE candidates.
- Disabling WebRTC is not a universal fix and can break calls.
An application proxy is not the whole device
A browser, command-line tool, messenger, and background service can read different settings. Some applications support only HTTP, others support SOCKS5, and some do not support proxies at all. A green result in one window therefore proves only that window's route and says nothing about a neighboring process.
PAC and explicit DIRECT routes
A PAC file's FindProxyForURL function decides whether each destination uses a proxy or a direct connection. A fallback such as PROXY ...; DIRECT means the browser may connect directly when the proxy is unavailable. That can be a valid availability policy, but it is unsuitable when direct routing is prohibited.
Exceptions for local names and corporate domains also commonly return DIRECT by design. Check the actual PAC result for the destination URL rather than merely confirming that a PAC URL is configured. After a change, clear configuration caches according to the client documentation and retest with a new connection.
Why WebRTC is different
WebRTC establishes media connectivity through ICE and gathers possible path candidates: local, STUN-derived, and TURN-relayed. Depending on browser and policy, some of these paths may differ from the ordinary HTTP proxy route. A different address in a WebRTC test therefore calls for candidate analysis, not an immediate conclusion that the proxy is broken.
Validate without exposing data
Use a clean profile without unrelated extensions, an authorized control service, and a predefined expected route. Compare a normal HTTPS request, DNS behavior, and WebRTC only when the application actually uses calls or media. Sanitize screenshots and logs to remove local addresses, device names, cookies, and proxy credentials.
Choose mitigation according to risk
When direct routing is prohibited, remove DIRECT from the relevant rule, enforce managed browser policy, or use a network tunnel with verifiable routes. If WebRTC is required, configuring acceptable ICE paths is preferable to disabling the technology entirely. Test every change with calls, normal websites, and failure recovery.
Practical checklist
- 1List the applications for which the proxy is mandatory.
- 2Check the PAC result for real destination URLs.
- 3Find DIRECT rules and document their purpose.
- 4Test WebRTC only in scenarios that actually use it.
- 5Do not disable features without testing application impact.
- 6Remove addresses and secrets from screenshots and logs.
Sources and documentation
This material is based on primary, official, and technical sources. The article is an original summary written for this knowledge base.