수신은 되는데 발신만 실패했습니다
마블로에서 텔레그램 메시지는 들어오는데, 보내는 쪽은 ETIMEDOUT으로
실패하는 문제가 있었습니다. 수신이 된다는 사실만으로 텔레그램 연결 전체가
정상이라고 판단하기 어려운 상황입니다.
이런 증상을 만나면 수신과 발신을 나누어 확인해야 합니다. 메시지가 들어오는지와 나가는지를 따로 살펴야 실패하는 쪽으로 진단 범위를 좁힐 수 있습니다.
이번 문제에서는 주소군별 연결 상태와 실제 연결 지연을 비교하는 것이 실마리였습니다. IPv6 경로는 응답 없이 막혀 있었고, IPv4 연결에는 약 0.24~0.28초가 걸렸습니다.
연결 지연을 시도 제한과 나란히 봅니다
IPv4 연결 시간을 밀리초로 바꾸면 약 240~280ms입니다. 여기에 Node의 주소군 자동 선택이 각 연결 시도를 얼마나 기다리는지 함께 놓고 봐야 합니다.
Node 22 공식 문서는
autoSelectFamilyAttemptTimeout의 초기 기본값을 250ms로 설명합니다.
연결 옵션 문서에
따르면 자동 선택 중 마지막 주소를 제외한 각 시도에 이 제한을 적용하고,
시간이 지나면 다음 주소를 시도합니다.
이번에 측정한 IPv4 연결 시간은 그 제한에 걸쳐 있습니다. 따라서 제한이 적용되는 IPv4 시도는 연결을 마치기 전에 끊길 수 있습니다. 연결 가능한 경로가 있어도 시도에 주어진 시간이 부족할 수 있습니다.
진단할 때는 사용하는 Node 버전의 문서와 실제 설정값을 함께 확인하세요. 연결 지연과 시도 제한을 같은 단위로 비교하면, 어느 구간에서 기다림이 끝나는지 살펴보기 쉽습니다.
IPv4 우선만으로는 해결되지 않았습니다
DNS 결과를 IPv4 우선으로 바꾸는 조치만으로는 발신이 정상화되지 않았습니다.
DNS 결과 순서 설정은 이름 조회 결과의 정렬을 다룹니다. 연결 시도에 허용하는 시간과는 별개입니다. 주소 순서를 바꿨다면 연결 시도 제한도 이어서 확인해야 합니다.
이번에는 주소군별 연결 시도 시간을 2초로 늘려 해결했습니다.
이후 텔레그램 발신이 정상으로 돌아왔습니다.
Node는 이 기본값을 조정하는 공개 API로
net.setDefaultAutoSelectFamilyAttemptTimeout()을
제공합니다.
다른 환경에 적용할 때도 먼저 연결 지연을 재고, 시도 제한과 비교하세요. 이번의 2초는 이 환경에서 발신 정상화를 확인한 값입니다.
재시도 전에 전달 여부를 생각합니다
메시지 발신 실패를 다룰 때는 재시도 정책도 함께 살펴야 합니다. 전달 여부가 불확실한 메시지를 다시 보내면 중복으로 도착할 위험이 있습니다. 실패 표시만 보고 재전송하기 전에 전달을 확인할 수 있는지 검토하세요.
빌더가 비슷한 증상을 진단할 때는 다음 순서로 확인해 보세요.
- 수신과 발신을 분리합니다. 어느 쪽이 성공하고 어느 쪽이 실패하는지 확인합니다.
- 주소군별 경로와 연결 지연을 확인합니다. 응답 없는 경로와 연결에 시간이 걸리는 경로를 구분합니다.
- 타임아웃 기본값과 실제 설정을 비교합니다. DNS 순서를 조정한 뒤에도 연결 시도 시간을 확인합니다.
- 조치 뒤 발신을 다시 확인합니다. 수신 성공과 별도로 발신 정상화를 확인합니다.
- 재전송 전 중복 위험을 검토합니다. 전달 여부가 불확실할 때 어떻게 확인하고 다시 보낼지 정합니다.
같은 시리즈
마블로 빌드 노트 9: 텔레그램 오케 대화에서는 밖에서도 방향을 전하고 진행 상황을 받는 활용을 살펴봅니다. 그 대화를 운영할 때는 메시지가 들어오는 쪽과 나가는 쪽을 각각 확인하는 습관이 도움이 됩니다.
마치며
하이프마크 빌더 커뮤니티는 AI 에이전트를 만들고 운영하며 얻은 경험과 참고할 자료를 꾸준히 공유하려고 합니다. 빌더 여러분께 도움이 될 좋은 자료들을 계속 모아 나누겠습니다.