Azure Firewall’s explicit proxy mode reached general availability this month. For anyone who has fought with user-defined routes to steer outbound traffic through a firewall, this is a meaningful change. Instead of relying on transparent, route-based interception, you can now point applications and browsers directly at the firewall as a proxy.
Explicit proxy versus the old approach
The traditional way to force traffic through Azure Firewall was route-based. You put the firewall in the path with user-defined routes and let it intercept traffic transparently. That works, but it brings friction: UDR management, forced tunneling considerations, and the occasional surprise when something does not traverse the path you expected.
Explicit proxy flips the model. You configure the application or browser with a proxy setting, typically the firewall’s private IP, and it sends HTTP and HTTPS traffic directly to the firewall. Traffic egresses from the firewall to the destination without needing a UDR to pull it off its natural path. For workloads where you cannot easily redirect the route, or where you want per-application control over what goes through the firewall, this is much cleaner.
How the configuration works
One thing worth noting is where the settings live. Explicit proxy is configured at the Azure Firewall Policy level, not on the firewall resource itself. That tracks with how modern Azure Firewall is managed and makes sense if you are centralizing policy across many firewalls.
Automating proxy configuration is handled through a PAC file. You host the PAC file in Azure Storage, generate a SAS URL, and point the policy at it. Retrieval uses a user-assigned managed identity, so there is no manual credential distribution across endpoints. There are a few specifics to plan around: the PAC file is capped at 256 KB, a single proxy port serves both HTTP and HTTPS, and Microsoft publishes a migration guide because the post-GA behavior differs from the preview in these details.
Why this matters for security and ops teams
The biggest practical win is control and auditability. With route-based interception, everything on the subnet passes through the firewall whether it needed to or not. Explicit proxy lets you decide, application by application, what gets sent through it. That granularity makes policy enforcement clearer and the audit trail more meaningful, because you know exactly which clients are using the proxy.
For hybrid environments, there is a strong use case around Azure Arc. Arc-enabled servers in hybrid setups can route their outbound traffic through Azure Firewall as a forward proxy, which keeps those environments centrally secured without exposing them directly to the internet. That was a driver during preview and remains a headline use case at GA. The preview itself was well exercised, deployed across more than 300 subscriptions with around 40 S500 customers, which is a decent signal that the feature held up at enterprise scale before this release.
What to check before you adopt it
If you are planning to move to explicit proxy, a short checklist will save you trouble. Audit your current route-based setup and decide which workloads actually need the firewall, rather than enabling the proxy tenant-wide out of habit. Set up a user-assigned managed identity with the right roles on the storage account holding your PAC file. Validate the PAC file serves the endpoints your clients need and stays under the size limit. Then roll it out to a pilot subnet before expanding.
It is also worth looking at whether you want to enforce the configuration at scale. Azure Policy definitions can require explicit proxy settings across all firewall policies, which is how you keep a growing environment consistent instead of relying on manual setup.
Where explicit proxy saves real effort
The clearest wins show up in environments that are hard to steer with routes. PaaS services that resolve to platform endpoints, third-party SaaS connectors, and appliances that ignore route tables are classic trouble spots because you cannot always force them onto a transparent path. With explicit proxy, those workloads simply inherit the proxy setting and follow it, which removes a whole category of “why is this not going through the firewall” debugging. The same applies to clients outside the virtual network boundary, where a UDR has no meaning but a proxy endpoint still works.
There is also an operational angle. Route-based designs tend to accumulate complexity over time: multiple route tables, next-hop exceptions, and forced tunneling carve-outs that nobody fully remembers. Explicit proxy centralizes the decision point at the firewall policy, so the answer to “what goes through the firewall” becomes a configuration you can read, not a web of routes to reverse-engineer. For teams that value observability and clear ownership, that alone can justify the switch.
The takeaway
Explicit proxy does not replace route-based inspection entirely, and there will always be cases where transparent interception is the right call. What it adds is a legitimate alternative for the situations where transparency is the problem. Better control over which clients use the firewall, simpler egress for apps you cannot easily redirect, and a cleaner path to secure Arc-connected hybrids. For networking teams that have been wedging everything into UDRs, it is worth a serious look now that it is GA.