1 왜 노드만 바꿔선 안 되나
프록시 품질 문제도 있지만, 증상이 특정 사이트만 깨지거나 같은 사이트가 시간마다 다른 노드색으로 찍히면, 우선 확인할 것은 어떤 정책이 적용됐는지와 이름 해석이 코어 안에서 어떻게 되었는지입니다. connection 로그는 새 연결이 들어올 때 도메인·목적지·선택된 정책(프록시 그룹·노드) 한 줄로 요약해 주는 경우가 많아, 사용자가 GUI에서 규칙 순서만 눈으로 훑기보다 판정 결과를 문자로 확인하기에 좋습니다. 반대로 이름이 안 풀리면 브라우저에는 «연결 끊김»처럼만 보이므로 DNS와 routing을 동시에 의심해야 합니다.
log-level 설정은 같은 축입니다. 패널별로 «로그」탭 이름만 다르게 보일 수 있습니다.
2 connection 로그가 말해 주는 것
일반적으로 커넥션 한 건에는 프로토콜·호스트 이름 또는 IP·최종 정책(어느 proxy/DIRECT로 나갔는지) 정보가 포함됩니다. 이름이 빠져 있거나 IP만 있으면, TLS 이전 단계거나 스니퍼가 아직 이름을 복원하지 못한 흐름일 수 있습니다. 이때 규칙이 기대와 다르게 매칭됐는지 보려면 같은 순간의 매칭된 규칙 유형(IP·도메인·GEOIP 등)을 로그 레벨을 올려서 확인하는 방법이 많습니다.
즉 단순히 «느린 노드를 바꾼다»가 아니라, 로그에 실제 매칭이 RULE-SET, DOMAIN-SUFFIX, GEOIP 중 무엇이었는지 찍히는지를 보면, 규칙 순서 문제인지 데이터베이스·목록 신선도 문제인지 갈립니다. Mihomo에서 GeoIP 목록 낡음은 별도로 GeoIP 수동 갱신 글과 맞물립니다.
3 로그 레벨: 언제 info, 언제 debug인가
설정 파일의 전역 로그 레벨(예: YAML의 log-level:)은 과도하게 낮추면 로그 디스크·CPU 부담이 늘고, 너무 높이면 라우팅 판단 중간 과정을 못 봅니다. 실무적으로는 문제 재현 시간대에만 임시로 레벨을 조정합니다. 흔한 단계를 요약하면 다음과 같습니다.
error: 코어 시작 실패·인증 거절처럼 치명적인 한 줄만 필요할 때.warning: 구독 갱신 경고나 일부 기능 비권장 사용 통지처럼 이상 신호 요약을 원할 때.info: 정상 이용 중 연결별 판단·프록시 선택 결과를 보기 시작하는 기본 디버깅 구간입니다. 대부분의 «어느 정책으로 나갔지?»는 여기부터 보입니다.debug: DNS 재귀 과정·캐시 히트·상세 라우팅 트레이스가 필요하고, 짧은 시간만 켭니다.
# Mihomo-style global log level — adjust briefly while reproducing an issue
log-level: info
profile:
store-selected: true4 DNS 실패 쪽 패턴은 로그에서 어떻게 보이나
DNS 실패는 접속이 시작되기도 전에 끝나는 계열이라, 증상이 즉시 실패·타임아웃 앞쪽에 몰립니다. Fake‑IP 모드를 쓰면 앱에는 가짜 대역으로 보였다가, 코어 안에서 진짜 IP로 교체하기 전후의 체인이 꼬이면 «간헐 접속 불가»처럼 느껴집니다. DoH 설정·upstream 순서는 Meta DNS·FakeIP 유출 방지 글과 직결됩니다.
로그에서는 (1) resolver 이름, (2) i/o timeout·no such host·NXDOMAIN 같은 키워드, (3) fake-ip 매핑 또는 캐시 관련 줄이 같은 타임스탬프에 붙었는지를 봅니다. 브라우저/OS가 Private DNS(DoT)나 보안 DNS를 켜두면 클라이언트가 Mihomo 스텁을 무시하여, 코어 로그에는 기대만큼 이름이 안 잡히는 현상과 겹칩니다. 브라우저 쪽은 Chrome·Edge 보안 DNS 안내와 함께 점검하는 편이 정확합니다.
5 규칙 미스매치·오분류 쪽 패턴
DNS는 성공했는데 속도만 이상하거나 다른 리전 페이지가 뜨는 경우에는, 해당 연결 줄에서 선택된 정책이 무엇인지가 핵심입니다. 규칙 리스트 상단의 넓은 IP/도메인 묶음에 먼저 걸리면 원하는 «전용 줄»까지 도달하지 못합니다. 로그에는 그 판단이 한 번에 표시되는 경우가 있어, 사용자는 GUI 규칙 편집기에서 스크롤만 하지 말고 해당 접속 한 건 기준 문자열을 붙여 보관하는 편이 이후 수정에 유리합니다.
HTTPS의 SNI 기반 이름 복구가 필요한 경우, 스니퍼가 없거나 과도하게 제외되어 있으면 IP 기반 GEOIP 규칙만 적용되어 출구 위치가 흔들릴 수 있습니다. 이때 원리 참고용으로 앞에서 인용한 HTTPS 스니퍼 글을 읽고, 규칙만 손보지 말고 스니퍼를 쓸 범위를 함께 맞춥니다.
6 «FakeIP·규칙 안 먹음»처럼 보일 때
Fake‑IP는 설계 상 애플리케이션이 받은 IP 주소 공간과, 코어가 실제 라우팅에 쓰는 해석 순서가 다른 레이어일 수 있습니다. 그래서 «규칙이 깨졌다»보다 먼저 DNS 체인이 동일 타임라인으로 맞는지 로그와 대조하는 것이 중요합니다. RULE‑SET 재갱신 다음날이라도 GEOIP 버전 불일치로 경계 근처 IP만 다르게 매칭되는 일이 나올 수 있으므로, 한 번이라도 증명용으로 로그 줄을 저장해 두면 나중에 mmdb·목록 교체 후 비교하기 좋습니다.
또한 같은 기기 안에서 여러 레이어마다 DNS를 지정하면(예: OS, 브라우저, 회사 에이전트, VPN Overlay) Mihomo 로그에는 일부 이름만 표시되고 다른 요청은 옆 채널로 빠지는 것처럼 불완전해질 수 있습니다. Tailscale과 병행하는 환경은 별도 라우팅 우선순위를 먼저 정리해야 오진이 줄어듭니다.
7 실전 워크플로: 재현 → 레벨 → 한 줄 근거 확보 → 수정
- 재현 순서 줄이기: 브라우저 한 종류·프로필 하나·가능하면 시크릿 모드처럼 변수를 고정합니다.
log-level을info로 두고 해당 시각 전후 로그만 필터링합니다.- 같은 타임라인에서 DNS 관련 줄이 먼저인지 connection 정책 줄이 먼저인지 보면, DNS 축 문제인지 규칙 축 문제인지 1차 분기가 됩니다.
- 판단 근거가 부족할 때만
debug를 짧게, 재현 후 곧 원래 레벨로 되돌립니다. - 수정 후에는 같은 시나리오에서 정책 이름·히트 위치가 바뀌었는지 다시 문자로 확인합니다.
8 정리
Clash Meta·Mihomo 사용자가 겪는 «잘못된 노드·FakeIP·규칙 미스매치·간헐 실패»는 많은 경우 노드 품질 이전에 DNS와 규칙 판정이 얽혀 있습니다. connection 로그와 적절한 로그 레벨로 원인축을 갈라 보면, 노드 교체뿐 아니라 MATCH 위쪽 줄 재배치, resolver 스플릿, Private DNS 차단 등 근본 수정으로 이어질 수 있습니다. 서버 응용과 달리 가정에서는 정답 패키지가 하나가 아니므로, 같은 증상 한 번이라도 로그 한 줄이라도 증표로 남기는 습관이 유지보수 비용을 가장 줄여 줍니다. 무분별하게 debug를 상시 유지하지 말고, 문제 조사 구간만 올린 뒤 복귀하는 것이 디스크·프라이버시 모두에 안전합니다.
설치 패키지는 일관된 출처를 쓰는 편이 로그 패턴도 비슷하게 맞춰 해석하기 좋으며, 허브의 Clash 무료 다운로드에서 OS별 설치물을 선택해 보실 수 있습니다. 오픈소스 레포와 릴리스 노트는 소스 신뢰 확인용으로 두면 충분하고, 패키지 획득 메인 경로는 사이트 다운로드 페이지를 사용하는 편을 권장합니다.
