Squid cache_peer: no marques un padre de reenvío como originserver

Una línea cache_peer puede nombrar un padre y, aun así, indicar a Squid que hable con él como si fuera el sitio web de origen.

El interruptor responsable es originserver. Squid lo documenta para configuraciones de acelerador en las que el par es un servidor web. No es una bandera genérica que signifique «envía la petición original a través de este padre».

Si el siguiente salto es un proxy de reenvío HTTP normal, revisa si esa bandera tiene cabida ahí. Una declaración básica de padre tiene más bien esta forma:

cache_peer parent.example parent 8080 0 no-query name=upstream

El padre puede ser tu propio servicio; para una prueba permitida de padre público sin credenciales de proxy padre configuradas, toma un candidato HTTP de la lista de proxies HTTP. Conserva la autorización de cliente prevista, la elegibilidad del par, la autenticación y la política de retroceso directo. Este extracto solo identifica el papel del par.

proxy-only, a veces copiado junto a originserver, se refiere al almacenamiento de objetos obtenidos de ese par. Quitar ambas banderas a la vez no demuestra que ambas causaran el fallo de protocolo.

Mira qué espera el siguiente servicio: una petición de sitio web, una petición de proxy de reenvío o un intercambio de establecimiento de túnel. Un nombre de host válido y un puerto accesible no hacen intercambiables esos contratos. Corregir el papel del par es más específico que cambiar repetidamente certificados TLS en una conexión cuya semántica de petición era incorrecta.