Tecnología · GUÍA PRÁCTICA
Linux muestra «Connection reset by peer»: localiza quién originó el RST antes de reintentar
Conserva un fallo, vincúlalo al socket exacto, captura el flujo TCP, identifica la dirección del RST aceptado y correlaciona ambos extremos antes de cambiar timeouts, keepalive o firewall.
«Connection reset by peer» indica que el socket actual terminó; no demuestra por sí solo que la aplicación del servidor eligió cerrarlo. Un proceso remoto, el kernel, un proxy, un balanceador, un firewall o un estado de conexión obsoleto pueden producir el RST aceptado.
Empieza con un único fallo fechado y una 4-tupla exacta. Guarda el primer error, el identificador de petición y el límite de bytes antes de reintentar: un segundo intento correcto puede borrar la ventana de evidencia sin explicar el primero.
1. Congela un fallo antes de reintentar
Registra hora UTC, comando, ID de petición o trabajo, direcciones y puertos, fase del protocolo y primer byte fallido. Conserva la cadena completa de errores y no mezcles varios reintentos.
Decide si la operación pudo confirmarse antes del reinicio. Las lecturas suelen repetirse; escrituras, cargas, pagos y trabajos quizá no. Comprueba el estado o una clave de idempotencia.
2. Vincula el mensaje a un solo socket
Usa `ss -tanp` o el runtime para guardar la 4-tupla y el PID propietario. En contenedores o namespaces, observa desde el espacio que posee la conexión y registra ese límite.
Separa un rechazo al conectar de un reinicio tras establecerse y anota si ocurrió antes de la respuesta, durante la transferencia o después de una salida aparentemente correcta.
3. Captura el flujo TCP y la dirección del RST
Con autorización y privilegio mínimo, guarda una captura con filtros estrechos. Registra interfaz, reloj y paquetes descartados; la ausencia en una captura incompleta no es prueba.
En el flujo exacto localiza `RST` y anota origen, destino, puertos, secuencia y último evento de aplicación. Captura en ambos extremos cuando sea posible para detectar inyección o traducción intermedia.
4. Correlaciona extremos e intermediarios
En el emisor aparente asigna la 4-tupla a un proceso y revisa registros de servicio, kernel, proxy y balanceador en la misma ventana UTC. Busca reinicios, caídas, timeouts, políticas, reutilización de pool y límites.
No conviertas una IP de origen en culpa automática de la aplicación. NAT, sidecars, proxies inversos y middleboxes pueden originar o retransmitir reinicios. Separa lo observado, probado y desconocido.
5. Repara una rama probada y cierra
Corrige solo el propietario respaldado por evidencia. Cambiar varios parámetros destruye la atribución. Mantén inmutables los registros y la captura originales.
Repite la misma carga solo si es seguro. Exige el resultado esperado, ningún efecto duplicado, ningún reinicio equivalente y registros sanos en ambos extremos. Un reintento exitoso no prueba la causa raíz.
