Pedidos lentos no Squid com um rewriter de URL a falhar
Investigue o auxiliar de reescrita de URL quando o proxy aceita ligações mas os pedidos ficam parados antes do encaminhamento.
Se o Squid aceita ligações mas demora muito a enviar os pedidos adiante, examine qualquer rewriter de URL nesse caminho. No Squid 5–7, url_rewrite_program indica um programa externo consultado depois das verificações iniciais de acesso. Ele pode atrasar o pedido antes de o destino o receber.
- Leia o comando de reescrita efetivo, incluindo o wrapper e os argumentos.
- Cruze a transação afetada com o diagnóstico do auxiliar. Saídas repetidas do processo filho, respostas malformadas e uma fila crescente são pistas distintas.
- Verifique se um padrão de URL dispara a falha. Preserve um exemplo redigido dessa entrada em vez de alterar definições de resolver não relacionadas.
O auxiliar tem um contrato de pedido/resposta orientado a linhas. Texto de progresso do wrapper na saída padrão pode quebrá-lo. Executar o script com sucesso como administrador também não reproduz o fluxo de entrada, o ambiente ou as permissões do Squid. Este caminho é separado da verificação de palavra-passe.
Só depois de a troca funcionar deve tratá-la como problema de capacidade. url_rewrite_children controla processos e o comportamento da fila associada, mas mais filhos não corrigem falhas provocadas pela entrada. A opção de concorrência introduz identificadores de canal e exige um auxiliar que implemente essa conversa.
Uma comparação autorizada sem o rewriter pode isolar o seu contributo. Deixá-lo contornado em sobrecarga pode alterar o encaminhamento ou a filtragem que aplica, pelo que isso é uma decisão de política. Compare a espera observada no auxiliar com provas de DNS e da ligação seguinte antes de atribuir todo o atraso à latência da rede.