무엇이 문제로 보이나: connection reset이 로그에 올 때
connection reset·connection refused·i/o timeout은 원인이 모두 같지는 않지만, 공통으로 “TCP·스트림이 중간에 끊겼다”는 신호에 가깝습니다. 상대가 RST를 보냈는지, 로컬 스택이 잘랐는지, 프록시·TLS 구간에서 끊겼는지는 브라우저 한 문장만으로는 갈리지 않고, 코어 로그에 남는 정책·체인과 함께 봐야 합니다. Clash Meta 계열은 가능한 경우 어느 규칙이 걸렸는지, 어느 노드로 나갔는지를 남깁니다. 감으로 노드만 갈기 전에 로그·규칙·시각이 먼저입니다.
이 글은 클라이언트에서 코어 로그를 info~debug 수준으로 켤 수 있다는 전제를 둡니다. GUI마다 뷰어 경로는 다르지만, 파일로 남기고 문제가 터진 시각에 앱에서 재현한 뒤 앞뒤 수십 줄을 잡는 방식이면 충분합니다. 로그가 너무 짧으면 도메인·SNAT·TLS 맥락이 잘리므로, 재현 절차(몇 번 클릭했는지)를 메모해 두는 것이 좋습니다.
connection reset이 가리킬 수 있는 층
첫째, 노드(업스트림)가 불안정해 세션이 중간에 끊기는 경우입니다. 지연이 튀거나 끊김이 특정 국가·이름에만 몰리면 이쪽이 유력합니다. 둘째, 규칙 때문에 직접 연결(DIRECT)이 나갔는데, 로컬 ISP·지역·대상 쪽에서 연결을 리셋하는 패턴입니다. 프록시 목록이 멀쩡해도 앱 트래픽이 DIRECT로만 나가면 같은 화면이 납니다. 셋째, DNS가 엉뚱한 IP로 붙다가, 그 끝에서 바로 끊기는 경우입니다. FakeIP·스플릿 DNS가 어긋면 규칙과 실제 다이얼이 동시에 꼬입니다.
UDP·QUIC만 특이하게 끊기는 경우는 TUN·Sniffer·REJECT·지역·앱 정책이 겹칠 수 있습니다. Discord 음성 전용 UDP·TUN 글이 따로 있고, 이 글은 TCP 중심의 로그 읽기에 초점을 둡니다. 마지막에 DNS 정렬 점검은 같은 체크리스트에 넣습니다.
1재현·시각 맞추기
로그를 볼 때 가장 먼저 할 일은 시스템 시각과 로그 타임스탬프의 기준(UTC·로컬)을 맞추는 것입니다. 몇 분만 어긋나도 엉뚱한 줄을 잡고 시간을 낭비하기 쉽습니다. 다음으로는 한 번에 바꿀 변수를 하나로 제한하세요. 노드·규칙·DNS를 동시에 손대면 로그에 이전과 이후가 섞여 원인이 흐려집니다. 에러 문자열만 검색해 스크롤하는 것보다, 문제가 난 직전에 시작된 연결 한 줄(도메인·정책)을 위에서부터 집어 잡는 편이 낫습니다.
2로그 한 줄에서 읽을 것: 규칙·정책·체인
Mihomo 계열 로그에는 보통 프로세스·도메인, 매칭된 규칙 종류, 정책 이름(프록시 그룹 등), 최종 업스트림에 대한 힌트가 함께 붙습니다. 클라이언트 빌드마다 용어는 조금씩 달라도, 핵심은 세 가지입니다. (1) 이 연결이 어느 rule에 걸렸는지 (2) 그 규칙이 가리킨 policy가 PROXY 쪽인지 DIRECT인지 (3) 실제로 나간 노드 이름. HTTPS에서 호스트가 잘 보이지 않을 때는 스니퍼·SNI 복원 이슈가 겹칠 수 있으니 Sniffer 가이드를 함께 보세요.
connection reset 문구가 뜬 직전·직후 줄에, 대상·규칙·정책·체인·시각이 한 덩어리로 이어지는지 확인합니다. 같은 사이트인데 이전엔 PROXY로 찍혔다가, 새로고침이나 재접속 뒤에는 DIRECT로 잡힌 줄이 섞이면 규칙 순서, 앱이 붙는 IP 변화, HTTP/3(QUIC) 경로를 의심할 만합니다.
알아두기: 로그에 REJECT·drop이 보이면 reset과 원인이 다를 수 있습니다. 필터·광고 차단·조직 정책 규칙에 막힌 경로인지 먼저 구분하세요.
3규칙 문제 vs 노드 문제 나누기
끊김은 비슷한데 로그에 찍힌 규칙이 늘 기대와 다르면 rules·분류 쪽을 우선 봅니다. 위에서 아래로 첫 매칭·GEOIP 줄의 위치·RULE-SET이 실제로 로드됐는지가 흔한 원인입니다. 반면 규칙과 정책은 맞는 것 같은데 특정 노드 이름에서만 끊기면 url-test·fallback·지연·업스트림 용량을 의심합니다. 이때는 url-test·fallback 글의 헬스체크·proxy-groups 설정이 짝이 됩니다.
“이 트래픽은 직접 연결이 맞다”는 설계인지, “프록시를 타야 한다”는 설계인지 메모해 두고, 로그의 policy가 그 메모와 맞는지 대조하면, 다음에 손댈 곳이 rules인지 proxy-groups인지 dns인지 한 번에 갈립니다. 같은 connection reset이어도 손댈 위치가 다르면 작업 내용이 완전히 달라집니다.
4DIRECT·DNS와 섞인 reset
로그에 DIRECT가 찍혔는데 지금 누른 서비스가 사실 해외/차단 풀 URL이면, 끊김은 로컬·ISP·대상 쪽에서 난 리셋일 수 있습니다. 이 경우 노드를 바꾸기 전에 해당 호스트를 PROXY 정책으로 보내는 규칙을 먼저 점검하는 편이 맞습니다. FakeIP·nameserver-policy·nameserver 순서가 어긋나면 “IP는 맞는 것 같은데 연결만 이상”한 착시가 나기도 합니다. fake-ip-filter와 Meta DNS 문서를 같은 세션에서 맞춰 읽는 것이 좋습니다.
DoH·DoT 조회 자체가 끊기면 해석이 실패하고, 그다음 TCP connect도 연쇄로 실패하는 패턴이 나옵니다. 로그에 DNS 조회 시각과 dial 시각이 같이 있으면, 먼저 앞단 해석이 안정적인지 확인하세요. 반대로 DNS는 성공인데 reset만 반복이면, 이미 분류·노드·대상 쪽으로 시선을 옮기면 됩니다. 캐리어·최말단의 장애는 이 문서의 범위를 넘을 수 있으며, 그때는 짧은 관측 로그를 남겨 지원·운영 팀에 넘기는 것이 효율적입니다.
5시간선으로 압축해 보기
한 번 재현이 되면, 메모에 다섯 칸을 적어 보는 습관이 큰 도움이 됩니다. (A) 사용자가 버튼을 누른 대략 시각 (B) 코어 로그에 첫 연결이 뜬 시각 (C) 매칭된 규칙·정책 이름 (D) 실제 선택된 노드 (E) 에러 문구(예: reset·timeout). (B)~(D)가 끊기기 직전까지 일관하는지, 배경에 다른 앱이 같은 초에 붙는 연결이 끼어 엉키지는 않는지 봅니다. 한 팝업에서 수십 개 도메인이 동시에 뜨는 앱이면, 한 줄만 보면 전체를 오해할 수 있습니다.
Yacd 같은 웹 UI에서 활성 연결을 병행하면 텍스트만 볼 때보다 누가 지금 쓰이는지 빨리 훑을 수 있습니다. 다만 끊긴 뒤에는 행이 사라져서, 분쟁이 남는 건 보통 텍스트 로그 쪽이므로 둘을 같이 두는 것이 안전합니다.
TUN·시스템 프록시와 로그의 관계(요약)
TUN 모드는 앱이 시스템 스택·가상 인터페이스를 거칠 때 흐름이 길어지고, 로그에 찍히는 홉도 늘 수 있습니다. 끊김이 “TUN 켰을 때만”·“시스템 프록시만 켰을 때만” 나온다면, 별도의 TUN·포트·(Windows의 경우) UWP 루프백 절차를 먼저 겹쳐 보는 편이 낫습니다. 핵심은 같은 connection reset이어도, 트래픽이 거치는 경로가 다르면 읽어야 할 로그·설정 층이 달라진다는 점입니다.
끊김 뒤에 손댈 설정 맵(요약)
로그가 가리킨 층에 맞춰 손댈 후보를 정리해 두면 이후에 헷갈리지 않습니다. 규칙이 잘못 잡혔다면 rules·RULE-SET 순서·MATCH 전 단계. 노드만 불안정이면 proxy-groups·헬스체크·url-test·fallback·다른 출구. DIRECT가 설계와 다르면 rules와 dns(FakeIP·nameserver-policy)를 같이. 구독·노드 목록이 비어 있거나 갱신이 실패면 구독 새로고침·403부터. 이 순서를 지키면 connection reset 한 줄에 매몰되지 않고, 노드·규칙·DNS 가운데 어디를 고칠지 바로 갈 수 있습니다.
주의: 서비스 약관·소속 기관 정책을 위반하는 우회는 하지 마세요. 이 글은 합법적 범위·자신의 장비에서 설정 진단을 가정합니다.
오픈소스와 설치 패키지
Mihomo·Clash Meta 코어 소스·이슈는 GitHub에서 확인할 수 있으나, 클라이언트 설치 패키지의 주 안내는 이 사이트 다운로드 페이지를 권장합니다. 릴리스 URL은 검증·투명성 용으로 두고, 독자 혼선을 줄이려면 문서·설정 허브와 함께 쓰는 편이 좋습니다.
맺음말
connection reset은 한 문장으로 끝나는 에러가 아닙니다. Clash Meta 로그에 남는 시간·규칙 이름·정책·노드·대상을 같은 시간선에 놓고 읽으면, 같은 끊김이어도 노드 교체인지 rule 재배치인지 DNS 정렬인지 빨리 갈라집니다. 한 번 흐름이 익으면 이후 트래픽 튜닝 시간이 줄어듭니다.
다른 도구에 비해 정책 이름과 로그 대응이 읽기 쉬운 편이라, 끊김을 재현 가능한 사실로 바꾸기에 유리합니다. 설치 경로를 통일하려면 릴리스 직링크보다 사이트 허브·다운로드 페이지를 쓰는 것이 독자에게 덜 헷갈립니다.
→ Clash를 무료로 다운로드하고, connection reset이 난 시각에 맞춰 Meta 로그·규칙·DNS를 한 번에 점검해 보세요