Azure Firewall Explicit Proxy Reaches General Availability

Aug 10

6 min read

Microsoft published an Azure Update on August 5, 2026 announcing that explicit proxy in Azure Firewall is generally available. Applications and browsers can send HTTP and HTTPS traffic directly to the firewall by using proxy settings, providing an alternative to steering those flows through user-defined routes.

The GA release turns a familiar enterprise egress pattern into a supported Azure Firewall capability. It also carries several important changes from preview: one proxy endpoint can serve both HTTP and HTTPS destinations, PAC file retrieval can use managed identity, and the portal configuration experience has been improved.

What Changed?

Azure Firewall normally operates as a transparent proxy. Routes place the firewall inline, and applications do not need to know that it is there. Explicit proxy changes that relationship. A configured application connects to the firewall's private IP address as its proxy, and the firewall establishes the outbound connection on the application's behalf.

Explicit proxy is now generally available for HTTP and HTTPS outbound traffic.
HTTP and HTTPS destinations can be served through a single HTTP proxy endpoint.
Applications can use a manually configured proxy address or a proxy auto-configuration file.
Managed identity-based PAC file retrieval improves how the firewall accesses customer-managed configuration.
The Azure portal now offers an improved configuration workflow.
Azure Arc onboarding in hybrid environments is a highlighted use case.

Microsoft reports that the preview was enabled in more than 300 Azure subscriptions and used by roughly 40 S500 customers. That validation is useful, but GA should still trigger a controlled production rollout. Proxy behavior sits in the path of application access, update services, package repositories, identity endpoints, and management traffic; small mistakes can have a wide blast radius.

Explicit Proxy Is Different from Route-Based Inspection

With transparent forwarding, a user-defined route sends traffic through Azure Firewall. With explicit proxy, the sending application is configured to contact the firewall directly. That can simplify selected web-egress scenarios because those application flows do not depend on a UDR to discover the firewall.

The distinction matters operationally. Only proxy-aware and correctly configured applications use the explicit path. A browser with the PAC file may be governed while another process on the same host follows the normal route table. Explicit proxy is therefore an application-level steering mechanism, not automatic proof that every outbound connection is inspected.

Traffic must be allowed with Azure Firewall application rules. Microsoft's configuration guidance explicitly notes that a network rule is not sufficient for explicit-proxy traffic. Build and test the required FQDN, URL, protocol, and port policy before moving clients to the new endpoint.

The PAC File Becomes Production Configuration

A PAC file decides when a client uses the proxy, which proxy endpoint it selects, and when it connects directly. That makes the file executable routing policy for web traffic, not a harmless browser preference. Store it in a controlled Azure Storage location, review changes, version it, and require the same change discipline used for firewall policy.

The GA model supports managed identity-based retrieval from customer-managed storage. Microsoft's migration guidance pairs the PAC file URL with a user-assigned managed identity and the required storage role assignments. This is a better operational boundary than anonymous access or long-lived credentials, but the identity still needs least-privilege scope, monitoring, and a tested recovery path.

Keep the PAC file within the documented size limit and validate its JavaScript syntax.
Use a stable deployment and versioning process so a bad PAC change can be rolled back quickly.
Restrict the storage account and role assignments to the identities that need them.
Test what happens when the PAC file cannot be retrieved or a client uses a cached copy.
Monitor both firewall policy changes and PAC file changes as one egress-control system.

Preview Deployments Need a Migration Review

Customers moving from preview should inventory old dual-port configurations and PAC distribution methods. The GA direction supports HTTP and HTTPS destinations through one HTTP proxy port and introduces the managed-identity retrieval model. Update the Firewall Policy, PAC content, client configuration, automation, documentation, and monitoring together.

Do not switch every client at once. Start with a canary group that exercises browsers, operating-system services, package managers, agents, and business applications. Validate authentication, redirects, large downloads, long-lived connections, certificate behavior, and exception handling. Expand only after logs and user experience show that the policy is complete.

If HTTPS inspection is part of the design, review the Azure Firewall SKU, TLS inspection configuration, certificate trust, and application compatibility separately. Sending HTTPS through an explicit proxy does not by itself guarantee that encrypted content is decrypted or inspected.

Why Azure Arc Is a Strong Use Case

Hybrid servers need outbound connectivity to Azure control-plane services during onboarding and ongoing management. Microsoft highlights Azure Arc as a key explicit-proxy scenario because organizations can point Arc-enabled servers at Azure Firewall as a forward proxy while retaining centralized outbound controls.

This can be attractive in regulated or tightly restricted networks, but the allow-list and failure model still matter. Required Microsoft endpoints change over time, agents may have different proxy capabilities, and the proxy path must be available when servers need to authenticate, update, send telemetry, or receive management instructions. Validate the complete Arc lifecycle rather than stopping after a successful first connection.

Security and Operations Considerations

A proxy is only a control when bypass paths are understood. Review default routes, direct internet access, alternative NAT paths, local proxy overrides, and applications that ignore system proxy settings. If policy requires all outbound web traffic to be inspected, combine explicit proxy with network controls that prevent unauthorized direct egress.

Send Azure Firewall application-rule and relevant diagnostic logs to the approved monitoring workspace.
Alert on unexpected denies, unusual destinations, policy changes, PAC retrieval failures, and identity changes.
Test firewall and client behavior during zonal, regional, DNS, storage, and identity disruptions.
Document how emergency bypass works, who can authorize it, how long it may remain, and how it is removed.
Measure proxy latency, connection success, throughput, and application errors before and after rollout.

High availability also extends beyond the managed firewall. Client proxy configuration, DNS, the PAC file's storage location, managed identity permissions, and the applications themselves all participate in the path. A healthy firewall does not help a client that cannot discover or reach its configured proxy.

Who Should Care?

Network security teams should care because explicit proxy adds application-aware egress steering to Azure Firewall. Platform teams should care because Firewall Policy, managed identity, storage, and client configuration belong in repeatable automation. Hybrid operations teams should care because Azure Arc onboarding is a primary use case. Application owners should care because proxy compatibility and destination allow-lists can directly affect service availability. Compliance teams should care because centralized web-egress control is only defensible when bypass prevention, logging, and change evidence are included.

Practical Cloud Engineer Takeaway

Create a non-production Firewall Policy and enable explicit proxy with the GA single-endpoint model. Place a small, reviewed PAC file in customer-managed storage, configure managed identity access, and add narrowly scoped application rules for a representative test workload.

Test both HTTP and HTTPS destinations through the same proxy endpoint.
Verify that allowed traffic is logged and denied traffic fails in the expected way.
Exercise a browser, an automated service, and an Azure Arc-enabled server if Arc is in scope.
Block or detect direct egress so the test can reveal proxy bypass.
Change the PAC file, confirm the update process, and practice rollback.
Capture latency, failures, log coverage, ownership, and operational runbooks before production rollout.

The goal is not merely to see traffic pass. The goal is to prove that intended applications use the proxy, unintended destinations are blocked, bypass paths are controlled, logs are actionable, and the service recovers cleanly when a dependency fails.

Bottom Line

Azure Firewall explicit proxy reaching general availability gives organizations a managed forward-proxy option for HTTP and HTTPS traffic, including one proxy endpoint for both destination types, managed identity-based PAC retrieval, and a clearer portal workflow. It is particularly relevant for controlled hybrid egress and Azure Arc onboarding.

The right next step is a canary migration that treats Firewall Policy, PAC content, identity, storage, client settings, bypass prevention, and monitoring as one system. Used with that discipline, explicit proxy can simplify application-level traffic steering while strengthening centralized outbound governance.