Sol·licituds Squid lentes amb un reescriptor d'URL que peta
Investigueu l'auxiliar de reescriptura d'URL quan el proxy accepta connexions però les sol·licituds s'encallen abans de reenviar-se.
Si Squid accepta connexions però triga molt a enviar les sol·licituds, reviseu qualsevol reescriptor d'URL en aquest camí. A Squid 5–7, url_rewrite_program anomena un programa extern consultat després de les comprovacions d'accés inicials. Pot retardar la sol·licitud abans que la destinació la rebi.
- Llegiu l'ordre efectiva del reescriptor, incloent-hi l'embolcall i els arguments.
- Aparelleu la transacció afectada amb el diagnòstic de l'auxiliar. Sortides repetides de processos fills, respostes mal formades i una cua creixent són pistes diferents.
- Comproveu si un patró d'URL provoca la fallada. Conserveu un exemple redactat d'aquesta entrada en lloc de canviar paràmetres del resolutor no relacionats.
L'auxiliar té un contracte de sol·licitud/resposta per línies. El text de progrés de l'embolcall a la sortida estàndard el pot trencar. Executar l'script amb èxit com a administrador tampoc reprodueix el flux d'entrada, l'entorn ni els permisos de Squid. Aquest camí és independent de la verificació de contrasenya.
Només quan l'intercanvi funcioni l'heu de tractar com un problema de capacitat. url_rewrite_children controla els processos i el comportament de la cua, però més fills no poden reparar caigudes desencadenades per l'entrada. La seva opció de concurrència introdueix identificadors de canal i requereix un auxiliar que implementi aquesta conversa.
Una comparació autoritzada sense el reescriptor pot aïllar-ne la contribució. Deixar-lo eludit en sobrecàrrega pot canviar l'encaminament o el filtratge que aplica, així que és una decisió de política. Compareu l'espera observada de l'auxiliar amb les evidències de DNS i de la connexió posterior abans d'atribuir tota la demora a la latència de xarxa.