What is a PAC File?

A PAC (Proxy Auto-Configuration) file is a JavaScript file that automatically determines which proxy server to use for each web request. Instead of manually configuring proxy settings for every application, a single PAC file can dynamically route traffic based on the destination URL.

At its core, a PAC file defines one JavaScript function:

function FindProxyForURL(url, host) {
  // Return proxy configuration for this URL
}

When your browser or application accesses a URL, this function executes and returns instructions like "use proxy server X" or "connect directly."

Why PAC Files Matter

PAC files are commonly used in corporate and enterprise networks where:

• Different websites require different proxy servers
• Some internal sites should bypass the proxy entirely
• Internet access is restricted and must go through a proxy

Quick diagnostic: If you're on a network where you can browse the web but cannot ping external DNS records, you're likely using a proxy configuration (possibly via PAC).

How PAC Files Work

Here's the typical workflow:

1. Your system is configured with a PAC file URL (e.g., http://proxy.company.com/proxy.pac)
2. When you access a website, your browser downloads and executes the PAC file
3. The FindProxyForURL() function runs with the target URL as input
4. The function returns a proxy directive (e.g., "PROXY proxy.company.com:8080; DIRECT")
5. Your browser follows this directive to route the request

Example PAC File

function FindProxyForURL(url, host) {
  // Direct connection for local hosts
  if (isPlainHostName(host) || isInNet(host, "10.0.0.0", "255.0.0.0")) {
    return "DIRECT";
  }
 
  // Use proxy for everything else
  return "PROXY proxy.company.com:8080; DIRECT";
}

Netskope Traffic Steering with PAC Files

Netskope is a cloud security platform (SSE/CASB) that uses PAC files as one method to steer user traffic through its security cloud for inspection, data loss prevention (DLP), and threat protection.

How Netskope Uses PAC Files

When Netskope is deployed via PAC file, the steering logic typically works like this:

function FindProxyForURL(url, host) {
  // Bypass Netskope for internal/private networks
  if (isPlainHostName(host) ||
      isInNet(host, "10.0.0.0", "255.0.0.0") ||
      isInNet(host, "172.16.0.0", "255.240.0.0") ||
      isInNet(host, "192.168.0.0", "255.255.0.0")) {
    return "DIRECT";
  }
 
  // Steer specific cloud apps through Netskope PoP
  if (shExpMatch(host, "*.salesforce.com") ||
      shExpMatch(host, "*.office365.com") ||
      shExpMatch(host, "*.dropbox.com")) {
    return "PROXY tenant-name.goskope.com:443";
  }
 
  // All other traffic goes direct (or through Netskope depending on policy)
  return "DIRECT";
}

Traffic Steering Architecture

PoP (Point of Presence): Netskope operates global PoPs (data centers) that act as security inspection points. When traffic is steered via PAC file:

1. Client request: User attempts to access a cloud application (e.g., Office 365)
2. PAC evaluation: Browser executes the PAC file and determines the traffic should go to Netskope
3. PoP routing: Traffic is sent to the nearest Netskope PoP (e.g., tenant-name.goskope.com)
4. Inspection: The PoP performs:
   • DLP scanning: Checks for sensitive data (credit cards, SSNs, confidential documents)
   • Threat detection: Scans for malware, ransomware, phishing
   • Policy enforcement: Blocks/allows based on corporate policies
   • CASB controls: Monitors cloud app usage and enforces access policies
5. Forward: If allowed, traffic is forwarded to the actual destination
6. Return path: Response comes back through the same PoP for inspection

Steering Modes

Netskope supports different steering approaches via PAC:

Selective steering: Only specific apps/domains go through Netskope (lightweight, minimal latency impact)

// Only cloud apps to Netskope, everything else direct
if (shExpMatch(host, "*.cloud-app.com")) {
  return "PROXY tenant.goskope.com:443";
}
return "DIRECT";

Full steering: All web traffic goes through Netskope (comprehensive security, higher latency)

// Everything except internal goes through Netskope
if (isInNet(host, "10.0.0.0", "255.0.0.0")) {
  return "DIRECT";
}
return "PROXY tenant.goskope.com:443";

DLP and Real-Time Inspection

When traffic passes through Netskope PoPs:

• SSL/TLS decryption: Netskope terminates SSL to inspect encrypted traffic
• Content analysis: Files, emails, and web content are scanned in real-time
• Policy actions: Block, alert, quarantine, or allow based on DLP rules
• Cloud DLP: Specific inspection for SaaS apps (Salesforce, Office 365, Google Workspace)

PAC File Distribution

Organizations typically distribute Netskope PAC files via:

• DHCP Option 252: Automatically provides PAC URL to clients
• GPO (Group Policy): Centrally configures Windows machines
• MDM: Mobile Device Management for corporate devices
• Manual configuration: Users manually enter PAC URL in browser settings

Advantages of PAC-Based Steering

• No client installation: Works with any browser/app that supports PAC
• Flexible policies: Easy to update steering logic without touching endpoints
• Gradual rollout: Can start with selective steering and expand
• Cross-platform: Works on Windows, Mac, Linux, mobile devices

Limitations

• PAC-unaware apps: Some applications don't honor PAC files
• Client bypass: Tech-savvy users can disable PAC configuration
• Initial connection: First PAC file download requires direct internet access
• Latency: Additional hop through PoP adds latency (usually 10-50ms)

For environments requiring stronger enforcement, Netskope also offers:

• Client software (Netskope Client): Enforced steering, can't be bypassed
• IPsec tunnels: Branch offices can tunnel all traffic to Netskope
• Inline deployment: Hardware/virtual appliances for transparent steering

PAC vs WCCP

While PAC files handle client-side proxy configuration, WCCP (Web Cache Communication Protocol) operates at the network infrastructure level. WCCP allows routers to transparently redirect traffic to proxy servers without any client configuration. Both optimize web traffic but at different layers:

• PAC: Client-configured, flexible per-user rules
• WCCP: Network-configured, transparent to clients

Detecting PAC Configuration

On Windows

Use PowerShell to check your PAC file URL:

Get-ItemProperty -Path 'HKCU:\Software\Microsoft\Windows\CurrentVersion\Internet Settings' | Select-Object -Property AutoConfigURL

This reads the Windows Registry key where Internet Explorer and many Windows apps store their proxy auto-configuration URL.

On Linux/Unix

Many Linux applications respect these environment variables:

echo $HTTP_PROXY
echo $HTTPS_PROXY
echo $NO_PROXY

You can also check your browser's proxy settings:

• Firefox: Settings → Network Settings → Automatic proxy configuration URL
• Chrome/Chromium: Uses system proxy settings

Common PAC Use Cases

Split tunneling: Route corporate traffic through the proxy while allowing direct access to personal sites

Load balancing: Distribute requests across multiple proxy servers

Geo-routing: Use different proxies based on destination geography

Bypass lists: Allow direct connections to trusted or internal sites

Troubleshooting Tips

If you suspect PAC file issues:

1. Download and review the PAC file directly (it's just a text file)
2. Test the FindProxyForURL() function with specific URLs
3. Check if the PAC file URL is accessible from your network
4. Verify your system clock is correct (some PAC files use time-based rules)

Reference

• PAC File Examples and Documentation
• MDN: Proxy Auto-Configuration (PAC) file