Why Firefox Still Proxies an Intranet Host in Your Bypass Subnet
A bypass range for literal IP addresses does not necessarily exempt a hostname that resolves into that range.
You put 192.168.0.0/16 into Firefox's “No proxy for” list. Opening http://192.168.1.20/ goes directly, but http://wiki.office.example/ still reaches the proxy. Both URLs can refer to the same server.
The important difference is the destination string Firefox is matching. An IP-range exception and a hostname exception are not interchangeable. Do not assume the manual bypass list resolves every hostname before deciding whether an address-range rule applies.
| URL entered | Information available to matching |
|---|---|
| http://192.168.1.20/ | A literal IP address |
| http://wiki.office.example/ | A hostname |
If the intranet has a dedicated domain, use the appropriate hostname or domain exceptions rather than guessing the addresses the names may resolve to. Keep unrelated public services outside that exception. A domain can contain both internal and externally hosted applications.
Mozilla's original explanation explicitly distinguishes literal IP matching from names resolving to those IPs. That document is historical, so check the current client's behavior and policy interface before copying every syntax example from it.
When the policy needs DNS
A PAC file offers a separate, explicit place for DNS-aware decisions. It also introduces script distribution, execution, and resolution failure modes. Use it because the routing requirement needs that logic, not merely to make a long bypass list look shorter.
In a managed installation, inspect Firefox's effective policy as well. A locked Proxy policy can explain why a local edit does not determine the route.
For troubleshooting, record the literal URL you entered, not just the server's eventual IP. Comparing a hostname URL with a literal-address URL changes the information available to the bypass decision, which is exactly why the two requests can take different paths.