Squid cache_peer : ne marquez pas un parent de transfert comme originserver
Supprimez l'hypothèse du serveur d'origine lorsque le saut suivant de Squid est un proxy de transfert ordinaire et non le site qui sert la ressource.
Une ligne cache_peer peut nommer un parent et pourtant demander à Squid de lui parler comme s'il était le site d'origine.
Le commutateur responsable est originserver. Squid le documente pour les montages d'accélérateur où le pair est un serveur web. Ce n'est pas un indicateur générique signifiant « envoyez la requête d'origine via ce parent ».
Si le saut suivant est un proxy de transfert HTTP ordinaire, vérifiez si cet indicateur y a sa place. Une déclaration de parent de base a plutôt cette forme :
cache_peer parent.example parent 8080 0 no-query name=upstreamLe parent peut être votre propre service ; pour un test autorisé de parent public sans identifiants de proxy parent configurés, prenez un candidat HTTP dans la liste de proxys HTTP. Conservez l'autorisation client prévue, l'éligibilité du pair, l'authentification et la politique de repli direct. Cet extrait ne fait qu'identifier le rôle du pair.
proxy-only, parfois copié à côté de originserver, concerne le stockage des objets récupérés auprès de ce pair. Retirer les deux indicateurs à la fois ne prouve pas que les deux ont causé l'échec du protocole.
Regardez ce qu'attend le service suivant : une requête de site web, une requête de proxy de transfert ou un échange d'établissement de tunnel. Un nom d'hôte valide et un port joignable ne rendent pas ces contrats interchangeables. Corriger le rôle du pair est plus précis que de changer sans cesse les certificats TLS sur une connexion dont la sémantique de requête était erronée.