Solicitudes de Squid lentas con un reescritor de URL que falla
Investigue el auxiliar de reescritura de URL cuando el proxy acepta conexiones pero las solicitudes se atascan antes de reenviarse.
Si Squid acepta conexiones pero tarda mucho en enviar las solicitudes, revise cualquier reescritor de URL en esa ruta. En Squid 5–7, url_rewrite_program nombra un programa externo que se consulta después de las comprobaciones iniciales de acceso. Puede retrasar la solicitud antes de que el destino la reciba.
- Lea el comando efectivo del reescritor, incluidos el envoltorio y los argumentos.
- Relacione la transacción afectada con el diagnóstico del auxiliar. Las salidas repetidas de procesos hijos, las respuestas mal formadas y una cola creciente son pistas distintas.
- Compruebe si un patrón de URL provoca el fallo. Conserve un ejemplo redactado de esa entrada en lugar de cambiar ajustes del resolutor no relacionados.
El auxiliar tiene un contrato de solicitud/respuesta por líneas. El texto de progreso del envoltorio en la salida estándar puede romperlo. Ejecutar el script con éxito como administrador tampoco reproduce el flujo de entrada, el entorno ni los permisos de Squid. Esta ruta es independiente de la verificación de contraseña.
Solo cuando el intercambio funcione debería tratarlo como un problema de capacidad. url_rewrite_children controla los procesos y el comportamiento de la cola asociada, pero más hijos no pueden reparar caídas desencadenadas por la entrada. Su opción de concurrencia introduce identificadores de canal y exige un auxiliar que implemente esa conversación.
Una comparación autorizada sin el reescritor puede aislar su contribución. Dejarlo eludido en sobrecarga puede cambiar el enrutamiento o el filtrado que aplica, así que es una decisión de política. Compare la espera observada del auxiliar con las evidencias de DNS y de la conexión posterior antes de atribuir toda la demora a la latencia de red.