O curl não lê o seu ficheiro PAC: passe o proxy em vez disso

O endereço do ficheiro PAC e o endpoint do proxy parecem intercambiáveis num ficheiro de configuração, e não são. Um é um programa de política que tem de ser avaliado para cada URL; o outro é um anfitrião e uma porta que aceitam ligações. O curl só entende o segundo. Passar um endereço PAC ao --proxy é um erro de categoria que falha de forma confusa, normalmente após um longo tempo limite CONNECT para um servidor web.

O que cada um é realmente

As perguntas frequentes do curl dizem-no claramente: o curl não fornece qualquer interpretação de JavaScript nem de PAC. Um invólucro em torno do curl que entenda PAC pode fazê-lo, mas o curl em si não, e nenhuma opção o transforma num navegador.

Porque é que o navegador funciona e o curl não

Um navegador integra-se na configuração de proxy do sistema, descarrega o ficheiro PAC e executa as suas regras contra o URL que abre. Essa avaliação é o serviço que o ficheiro PAC fornece, e acontece dentro do navegador, não dentro do seu terminal.

Descarregar o ficheiro PAC com o curl obtém apenas o texto. Não faz com que o curl execute a política, e lê-lo à mão para encontrar um proxy é uma versão manual da mesma avaliação, com a mesma probabilidade de escolher o ramo errado. Se o ler, leia a instrução return que corresponde ao seu anfitrião em vez do primeiro nome de proxy no ficheiro. A maioria dos ficheiros PAC contém vários, e só um ramo se aplica a si.

Para um proxy HTTP aprovado e um serviço HTTPS aprovado, um pedido ilustrativo é:

curl --proxy http://proxy.corp.example:8080 https://service.example.net/status

O primeiro endereço é o ouvinte do proxy, o segundo é o serviço que pretende. Estes são endpoints de exemplo e não um teste que alguém tenha feito, por isso substitua-os pelo esquema, pela porta e pelo fluxo de autenticação da sua organização.

Escolha o proxy para este destino

Pergunte ao administrador que proxy a política escolhe para o URL de que precisa, e não que proxy a organização possui. As regras PAC podem devolver resultados diferentes para serviços internos, sites públicos e condições de comutação por falha, e uma regra que hoje corresponde ao seu URL pode corresponder a outro depois de uma edição.

Se o fluxo de trabalho precisar de mais do que um pedido conhecido, use uma definição estática suportada pelo administrador ou uma integração aprovada que entenda PAC. Codificar um único endereço copiado funciona até ao dia em que a política muda e ninguém se lembra porque é que esse endereço foi escolhido.

Depois veja o que o curl herda. As variáveis de ambiente de proxy e o NO_PROXY podem substituir ou excluir o proxy que passou, e uma exclusão que corresponda ao seu destino envia o pedido diretamente sem avisar. Preserve a política pretendida em vez de apagar todas as exclusões ou forçar tudo através de um único endereço. Execute o pedido uma vez com -v e verifique a que endereço se ligou realmente.

Mantenha as duas identidades TLS separadas

Com um proxy HTTPS, há duas ligações TLS em jogo: a sua para o proxy e a do proxy para o destino. Cada uma tem a sua própria identidade a verificar, e desativar a verificação de qualquer uma delas não é uma correção PAC, é um segundo problema acrescentado ao primeiro.

Mantenha a verificação ativa e leia a falha que obtém. Um desafio de autenticação do proxy, um proxy inalcançável e uma recusa do site são três resultados diferentes, e só o primeiro diz respeito a credenciais. A VPN continua a ter de fornecer um caminho permitido para um proxy privado, incluindo a resolução de nomes para o próprio anfitrião do proxy, antes que algo disto funcione.

Anote o endpoint, o esquema, a porta, o método de autenticação, as exclusões e o caminho VPN até ao proxy. Esse registo é o que torna o próximo pedido reproduzível, e é a diferença entre conhecer o seu proxy e adivinhá-lo.