기술 · 실용 가이드
Linux의 “Connection reset by peer” — 재시도 전에 RST 경계를 찾는 법
실패 한 건을 보존하고 정확한 소켓에 연결한 뒤 TCP 스트림과 수락된 RST 방향을 확인하고서 타임아웃, keepalive 또는 방화벽을 바꾸세요.
“Connection reset by peer”는 현재 소켓이 끝났다는 뜻이지만 서버 애플리케이션이 직접 닫았다는 증거는 아닙니다. 상대 프로세스, 커널, 프록시, 로드밸런서, 방화벽 또는 오래된 연결 상태가 RST를 만들 수 있습니다.
타임스탬프가 있는 실패 한 건과 정확한 4-튜플에서 시작하세요. 재시도 전 최초 오류, 요청 ID와 실패 바이트 경계를 보존해야 합니다. 두 번째 성공은 첫 실패를 설명하지 않습니다.
1. 재시도 전에 실패 한 건을 고정하세요
UTC 시간, 명령, 요청/작업 ID, 양쪽 주소와 포트, 프로토콜 단계, 최초 실패 바이트를 기록하세요. 여러 재시도를 하나의 사건으로 섞지 마세요.
재설정 전에 작업이 커밋됐을 가능성을 판단하세요. 읽기는 재실행 가능할 수 있지만 쓰기, 업로드, 결제, 작업 제출은 위험합니다. 상태나 멱등 키를 먼저 확인하세요.
2. 메시지를 소켓 하나에 연결하세요
`ss -tanp` 또는 런타임으로 4-튜플과 PID를 기록하세요. 컨테이너나 네트워크 네임스페이스에서는 연결을 소유한 공간에서 관찰하고 경계를 남기세요.
연결 시 거부와 연결 후 재설정을 구분하고 응답 전, 전송 중, 성공처럼 보인 출력 후 중 어느 단계인지 기록하세요.
3. TCP 스트림에서 RST 방향을 찾으세요
허가와 최소 권한 아래 좁은 시간·엔드포인트 필터로 `tcpdump`를 저장하세요. 인터페이스, 시계와 드롭 수를 남기고 불완전한 캡처의 부재를 증거로 삼지 마세요.
정확한 스트림에서 RST의 출발지, 목적지, 포트, 시퀀스와 직전 애플리케이션 사건을 기록하세요. 가능하면 양쪽에서 캡처해 경로 장비의 주입이나 변환을 구분하세요.
4. 엔드포인트와 중간 장비 증거를 맞추세요
겉보기 송신지에서 4-튜플을 프로세스에 연결하고 같은 UTC 구간의 서비스, 커널, 프록시, 로드밸런서 로그를 확인하세요. 재시작, 충돌, 타임아웃, 정책, 풀 재사용, 자원 제한을 찾으세요.
출발지 IP를 곧바로 애플리케이션 책임으로 단정하지 마세요. NAT, 사이드카, 역방향 프록시와 미들박스가 재설정을 만들거나 전달할 수 있습니다. 관찰·증명·미확인을 나누세요.
5. 증명된 분기 하나만 고치고 종료하세요
증거가 가리키는 소유자만 고치세요. 여러 설정을 동시에 바꾸면 원인 귀속을 잃습니다. 원본 로그와 캡처는 변경하지 말고 보존하세요.
안전할 때 같은 부하를 재현하세요. 기대 결과, 중복 부작용 없음, 동일 RST 없음, 양쪽 로그 정상 상태를 수용 기준으로 삼으세요. 재시도 성공만으로는 근본 원인이 증명되지 않습니다.
