O proxy auto-config é anterior a quase tudo o mais na infraestrutura web, e ainda é como uma grande parte do tráfego corporativo é direcionada. Um arquivo PAC é uma única função JavaScript que o navegador avalia a cada requisição. Entendê-la é a diferença entre confiar em uma configuração de direcionamento e adivinhá-la. Este texto explica o modelo que a ferramenta correspondente lê.

Uma função, chamada a cada requisição

Um arquivo PAC define exatamente um ponto de entrada:

function FindProxyForURL(url, host) {
  // ... retorna uma string de proxy
}

O navegador a chama com a url completa e o host extraído, e espera de volta uma string dizendo para onde enviar a requisição. Todo o resto no arquivo existe para ajudar essa função a decidir. O arquivo é servido com o tipo MIME application/x-ns-proxy-autoconfig, normalmente a partir de uma URL configurada no navegador ou descoberta por WPAD.

Há uma sutileza moderna que vale saber de antemão: muitos navegadores baseados em Chromium agora removem o caminho e a query de URLs https:// antes de chamar a função, passando apenas o esquema, o host e a porta. Uma lógica que tenta casar pelo caminho de uma URL HTTPS não o verá. Casar pelo host ainda funciona.

A gramática da string de retorno

A string que FindProxyForURL retorna é uma ou mais diretivas separadas por ponto e vírgula. O navegador as tenta da esquerda para a direita e usa a primeira que funcionar, o que faz do ponto e vírgula um mecanismo de failover.

As diretivas são DIRECT (conectar direto ao destino, sem proxy), PROXY host:porta (usar aquele proxy HTTP) e SOCKS host:porta (usar aquele servidor SOCKS). Navegadores mais novos também aceitam HTTP host:porta, HTTPS host:porta (uma conexão TLS ao proxy) e as formas explícitas SOCKS4 e SOCKS5. Então PROXY primario:8080; PROXY reserva:8080; DIRECT significa "tente o proxy primário, depois o reserva, e se nenhum responder, vá direto". Esse DIRECT no final é uma rede de segurança comum e deliberada: sem ele, um proxy inacessível pode deixar o tráfego sem para onde ir.

As funções auxiliares, e as que custam uma consulta DNS

Arquivos PAC decidem usando uma biblioteca fixa de funções auxiliares. A maioria delas são operações puras de string e não custam nada: isPlainHostName (verdadeiro para um nome de rótulo único sem qualificação, o jeito clássico de mandar nomes curtos de intranet direto), dnsDomainIs (o host termina em um sufixo de domínio), shExpMatch (uma correspondência shell-glob), dnsDomainLevels, weekdayRange, dateRange e timeRange.

Três auxiliares são diferentes, e a distinção importa para o desempenho: isInNet, isResolvable e dnsResolve todas consultam DNS. A MDN aponta isso explicitamente, porque uma consulta DNS a cada requisição pode bloquear e deixar a navegação lenta. A regra prática é ordenar suas verificações de modo que as comparações baratas de string decidam primeiro, e o DNS só seja consultado quando nada mais decidiu. Um arquivo que recorre a isInNet no topo da função paga esse custo em cada requisição.

Mais duas arestas valem ser internalizadas. shExpMatch usa curingas de shell-glob (* e ?), não expressões regulares, então um padrão escrito em sintaxe de regex silenciosamente não casa. E myIpAddress é não confiável em máquinas com várias interfaces e pode cair em um endereço de loopback como 127.0.0.1, então uma lógica que ramifica com base nele pode se comportar de forma diferente do esperado em máquinas com VPN ou múltiplas interfaces. Há também um conjunto de extensões IPv6 da Microsoft com sufixo Ex (dnsResolveEx, isInNetEx, myIpAddressEx e outras) suportadas pelo Chromium, mas não pelo Firefox.

Como a Netskope usa um PAC

Um Secure Web Gateway precisa de uma forma de fazer o navegador enviar tráfego para ele, e uma das formas padrão é um arquivo PAC. O Cloud Explicit Proxy da Netskope é direcionado exatamente assim. Um PAC da Netskope retorna PROXY eproxy-<tenant>.goskope.com:8081 para o tráfego web que deve inspecionar, com o nome do tenant preenchido, e retorna DIRECT para o que deve contornar o proxy: hostnames simples e os hosts de provedor de identidade dos quais o fluxo de login depende. A porta 8081 é a porta do proxy explícito. Como o proxy faz inspeção TLS, a CA raiz da Netskope precisa ser confiável no cliente, e a Netskope usa surrogates de cookie para carregar a identidade do usuário pelo caminho do proxy explícito. Ler um PAC da Netskope, então, é principalmente uma questão de separar os desvios DIRECT da única linha PROXY que envia todo o resto ao host de proxy explícito do tenant.

De onde isto vem

A mecânica do PAC aqui vem da referência Proxy Auto-Configuration da MDN e do artigo de proxy auto-config da Wikipedia (para as extensões IPv6 da Microsoft); as especificidades da Netskope vêm da documentação do Cloud Explicit Proxy da Netskope. A ferramenta correspondente lê um arquivo PAC colado de forma lexical e o explica; nunca avalia o arquivo nem contata um proxy.