Requêtes Squid lentes avec un réécrivain d'URL qui plante

Si Squid accepte les connexions mais met longtemps à transmettre les requêtes, inspectez tout réécrivain d'URL sur ce chemin. Dans Squid 5–7, url_rewrite_program désigne un programme externe consulté après les vérifications d'accès initiales. Il peut retarder la requête avant que la destination ne la reçoive.

1. Lisez la commande effective du réécrivain, y compris l'enveloppe et les arguments.
2. Rapprochez la transaction concernée des diagnostics de l'auxiliaire. Des sorties répétées de processus enfants, des réponses malformées et une file qui grossit sont des pistes distinctes.
3. Vérifiez si un motif d'URL déclenche la panne. Conservez un exemple expurgé de cette entrée plutôt que de modifier des réglages de résolveur sans rapport.

L'auxiliaire suit un contrat requête/réponse ligne par ligne. Un texte de progression de l'enveloppe sur la sortie standard peut le casser. Exécuter le script avec succès en tant qu'administrateur ne reproduit pas non plus le flux d'entrée, l'environnement ni les permissions de Squid. Ce chemin est distinct de la vérification du mot de passe.

Ne le traitez comme un problème de capacité qu'une fois l'échange fonctionnel. url_rewrite_children contrôle les processus et le comportement de la file associée, mais davantage d'enfants ne peuvent pas réparer les plantages déclenchés par l'entrée. Son option de concurrence introduit des identifiants de canal et exige un auxiliaire qui implémente cette conversation.

Une comparaison autorisée sans le réécrivain permet d'isoler sa contribution. Le laisser contourné en surcharge peut modifier le routage ou le filtrage qu'il applique, c'est donc un choix de politique. Comparez l'attente observée de l'auxiliaire aux preuves DNS et de connexion ultérieure avant d'attribuer tout le délai à la latence réseau.