As enterprises continue to adopt SASE, ZTNA and browser-based app delivery in 2026, controlling where browser traffic flows has become a critical control point. Per-site split tunneling — routing only selected domains through a corporate gateway while sending the rest directly to the Internet — reduces latency, cuts egress costs, and limits attack surface if implemented correctly. Managed browsers give security and IT teams a precise enforcement layer without requiring system-wide VPNs or complex endpoint network hooks.

Who should read this and why

This guide targets architects, browser platform engineers and endpoint teams who operate managed browsers (Chrome, Edge, Firefox in enterprise-managed mode, or vendor-managed enterprise browsers). It assumes familiarity with basic browser management (enterprise policies) and with your organization’s SASE or proxy infrastructure. You’ll get a decision framework, concrete examples (including PAC logic and sample enterprise policy snippets), testing guidance, and operational best practices.

When per-site split tunneling is the right tool

  • Performance-sensitive SaaS: SaaS apps with global CDNs often benefit from direct Internet paths to reduce latency and bandwidth through the corporate gateway.
  • Cost and egress control: Routing only high-risk or internal-hosted services through corporate gateways lowers egress and inspection costs with cloud providers.
  • Least privilege for external contractors: Allow contractors direct access to external services while keeping internal resources behind ZTNA.
  • Compliance and segmentation: Enforce that sensitive systems (internal HR, financial systems) always traverse corporate controls while public browsing does not.

High-level design: inventory, policy and enforcement point

Start with an application-domain inventory. Collect hostnames, subdomains and IP ranges for internal apps, SaaS integrations, telemetry endpoints and third-party CDNs. Then map traffic classes to routes:

  • Internal-private (always via corporate proxy/SASE)
  • Sensitive external (inspection required)
  • Public Internet (direct)

Decide the enforcement point: browser-level split tunneling gives per-application control and is appropriate for managed browsers. Alternatives include system-level VPNs (broader coverage) or network edge controls (less granular per-device control). Browser-level rules are preferable when you need per-user, per-profile or per-tenant granularity and when you cannot or do not want to alter host networking stacks.

Technical options available in modern managed browsers (2026)

Common options to implement per-site split tunneling in managed browsers:

  • PAC (Proxy Auto-Config) files using FindProxyForURL(). Supported by Chrome, Edge, Firefox and most enterprise browsers.
  • Browser enterprise proxy policies. Many management consoles let you set explicit proxy modes: fixed proxy, PAC script URL, or auto-detect.
  • Vendor-specific connectors. Some SASE vendors provide browser connectors or browser policies that route specified hosts to the vendor tunnel automatically.
  • DNS steering: using enterprise DoH/DoT policies so that DNS resolution and routing are aligned with proxy decisions.

PAC files remain the most flexible cross-browser mechanism. Below are concrete patterns and considerations for PAC scripts in managed environments.

Example PAC logic (compact)

Use a concise PAC that classifies internal hosts by domain and IP-range and sends them to the corporate proxy; otherwise use a DIRECT connection:

function FindProxyForURL(url, host) { if (shExpMatch(host, "*.corp.example.com") || shExpMatch(host, "intranet.example.local")) return "PROXY proxy.corp.example.com:8080"; if (isInNet(resolve(host), "10.0.0.0", "255.0.0.0") || isPlainHostName(host)) return "PROXY proxy.corp.example.com:8080"; return "DIRECT"; }

Key points:

  • Use shExpMatch for wildcard host patterns where appropriate.
  • Resolve hostnames (resolve()) and isInNet checks for private IP ranges to catch hosts referenced by IP or non‑qualified names.
  • A fallback of DIRECT prevents accidental full-proxying if your proxy is down — but choose fallback behavior based on risk tolerance.

Browser policy examples (how to push PAC to managed browsers)

Here are representative approaches to apply a PAC or proxy policy from common management layers.

Chrome / Chromium-based browsers (JSON policy or ADMX)

Set ProxyMode to "pac_script" and specify the PAC URL. Example JSON policy fragment for enterprise management (Chrome Browser Cloud Management or analogous MDM):

{"ProxyMode": "pac_script", "ProxyPacUrl": "https://config.corp.example.com/pac/proxy.pac"}

Firefox (policies.json)

Use the policies.json enterprise configuration to set automatic configuration:

{"Policies": {"Proxy": {"Mode": "auto_config", "AutoConfigURL": "https://config.corp.example.com/pac/proxy.pac"}}}

Edge (Group Policy or Intune)

Edge supports the same PAC-based model as Chromium; use ADMX/Intune to configure "ProxyMode" and "ProxyPacUrl".

DoH and DNS implications

DNS-over-HTTPS (DoH) complicates PAC logic because PAC functions that call resolve() may use the browser's DNS stack, which could be configured to use a public DoH resolver. In 2026 most enterprise-managed browsers allow policy control over DoH:

  • Configure enterprise DoH appliances or resolver policies so resolve() uses an internal DNS for enterprise hostnames.
  • Alternatively, avoid relying solely on resolve()/isInNet in PAC files; instead use hostname patterns and a maintained list of subdomains for key internal apps.
  • Test PAC behavior with your chosen DoH configuration — subtle differences exist between browser engines.

Integrating with SASE / ZTNA

Two common integration patterns:

  • PAC directs internal and sensitive hostnames to the corporate proxy or to a SASE browser connector endpoint. The SASE gateway then enforces inspection, logging, and ZTNA checks.
  • For private apps behind ZTNA connectors, point the browser to a vendor tunnel (via PAC or connector client) for the specific hostnames; public traffic remains DIRECT.

Coordinate with your SASE/ZTNA team on session handling and cookie scopes. Some vendors provide browser extensions or connectors that automatically register private app domains — prefer those when available to avoid fragile hand-maintained PAC lists.

Testing and rollout

  1. Stage: Start with a pilot group of users and a limited set of critical internal hostnames.
  2. Synthetic tests: Use targeted curl/wget tests from a managed profile to ensure requests to internal hosts traverse the proxy and that public sites go direct. Browser DevTools > Network can show the proxy headers and timing.
  3. PAC validation: Many browsers log PAC evaluation errors to the console. Monitor and fix syntax or runtime exceptions.
  4. Telemetry and logs: Collect proxy access logs, SASE logs and browser telemetry to verify expected routing and to identify overbroad patterns (e.g., major SaaS providers inadvertently routed through the proxy).
  5. Rollout in phases: Expand domains and user groups; maintain a rollback plan (repointing Policy to a safe PAC or fixed proxy).

Common pitfalls and mitigations

  • Wildcard overmatching: Broad patterns like "*.example.com" may unintentionally capture third-party CDN hosts. Be specific.
  • CDN and third-party domains: Many SaaS providers use dynamic domains; coordinate with app owners and rely on vendor-supplied domain lists where possible.
  • Service workers and cached resources: Service workers can serve cached assets that fetch via routes inconsistent with current PAC decisions. Evict or version service workers during rollout for critical apps.
  • WebSocket and long-lived connections: Ensure your proxy or SASE connector supports WebSocket upgrades and long-lived connections routed via the intended path.
  • Proxy authentication: NTLM and Kerberos flows may require proper host headers and SPN configuration; browser identity delegation settings may need to be enabled by policy for corporate hosts.
  • PAC caching and propagation: Browsers cache PAC files; changes will not always be instantaneous. Use policy-controlled cache TTLs where supported and communicate expected propagation times.

Operational recommendations

  • Version-control your PAC files and store them in a secure, highly-available host (HTTPS, signed distribution if possible).
  • Automate domain list updates from application owners and SRE teams via a service that publishes curated JSON feeds consumed by your PAC generator.
  • Monitor for traffic anomalies shortly after policy changes — automated alerts help catch misroutes quickly.
  • Document change-control: approvals for adding domains to the “corporate tunnel” list should include risk and performance justification.
  • Train service desks: users will report access gaps; equip support staff with quick tests to identify whether a routing policy is to blame.

Checklist before production rollout

  1. Complete domain inventory and classification (internal, inspected, direct).
  2. Create initial PAC and validate in a lab environment for Chrome, Edge and Firefox.
  3. Coordinate DoH configuration so resolve() behavior aligns with PAC expectations.
  4. Verify SASE/ZTNA connector behavior for private apps and WebSocket support.
  5. Pilot with a limited user group for 2–4 weeks with active monitoring.
  6. Publish runbook for incident response and rollback procedure.

Conclusion

Per-site split tunneling implemented at the managed-browser layer is an effective tool to balance performance, cost and security. In 2026 the challenge is less about whether it can be done and more about doing it reliably across browsers, DoH configurations and SASE connectors. Use PAC-based logic as the flexible core, control DoH and identity delegation via enterprise policies, and integrate with SASE/ZTNA connectors where vendors provide automation. With careful inventorying, staged rollout and robust telemetry, browser-level split tunneling delivers the granularity modern enterprises need without the complexity of host-level networking changes.