Clash 실행 로그 보는 법: 주요 오류 의미와 문제 해결 순서

LOG LAYERS

먼저 로그가 어느 계층에서 발생했는지 확인하기

Clash 클라이언트에서 “연결 실패”가 표시될 때 화면 메시지는 대개 최종 결과만 보여 주며, 실제 실패 단계는 실행 로그에 기록됩니다. 분석을 시작하기 전에 클라이언트 화면 계층, 프록시 코어 계층, 운영 체제 네트워크 계층을 구분해야 합니다. 클라이언트는 설정 관리, 트레이 메뉴, 시스템 프록시 전환을 담당합니다. Clash, Clash Meta 또는 현재 사용하는 mihomo 코어는 포트 수신, 규칙 파싱, 프록시 연결, DNS 처리를 담당합니다. 운영 체제는 네트워크 어댑터, 라우팅, 방화벽, 권한, 로컬 포트를 관리합니다. 세 계층 중 어느 한 곳에서든 문제가 발생하면 화면에는 모두 “연결할 수 없음”으로 표시될 수 있습니다.

클라이언트마다 같은 코어 로그를 표시하는 방식이 다를 수 있습니다. 어떤 클라이언트는 시간, 로그 수준, 모듈 이름을 유지하지만, 어떤 클라이언트는 메시지 본문만 보여 줍니다. mihomo가 업데이트되면 필드 이름과 표현도 달라질 수 있습니다. 따라서 오류 문장 전체를 그대로 검색하기보다 설정 파일 경로, 수신 주소, 포트 번호, 도메인, 노드 이름, 네트워크 유형, 시스템 오류처럼 변하지 않는 대상을 추려 확인하세요.

warning이나 error가 한 번 나타났다고 해서 모든 프록시 트래픽이 중단된 것은 아닙니다. 예를 들어 특정 노드의 연결 시간 초과는 해당 연결 또는 관련 전략 그룹에만 영향을 줄 수 있고, 보조 DNS 서버 하나가 실패해도 다른 서버가 조회를 처리할 수 있습니다. 영향을 판단할 때는 오류 대상, 발생 빈도, 이후 성공 기록이 나타났는지를 함께 확인해야 합니다.

REPRODUCE FIRST

시간 순서대로 문제 재현하기

효율적인 로그 분석에는 명확한 재현 과정이 필요합니다. 클라이언트를 몇 시간 동안 계속 실행한 뒤 설정 업데이트, 지연 시간 테스트, 백그라운드 프로그램 연결이 섞인 기록만 보고 원인을 추측하지 마세요. 현재 로그를 비우거나 시작 시간을 기록한 다음, 문제를 일으키는 동작 하나만 수행하는 편이 정확합니다. 이렇게 하면 사용자 동작과 로그 시간을 맞춰 볼 수 있습니다.

1. 현재 환경을 기록합니다. 클라이언트 이름, 코어 유형, 운영 체제, 현재 설정 파일, 프록시 모드, TUN 활성화 여부를 확인하세요. 클라이언트나 코어를 방금 업데이트했다면 업데이트 전후 상태도 기록합니다.
2. 관련 없는 테스트를 중지합니다. 자동 속도 측정, 설정 자동 업데이트, 지속적으로 연결을 생성하는 프로그램을 잠시 끄고 로그 잡음을 줄입니다.
3. 낮은 로그 수준부터 시작합니다. 먼저 info 수준으로 문제를 재현하고, 연결 실패 결과만 보이면 debug로 잠시 전환하세요. 문제를 찾은 뒤에는 평소 사용하는 수준으로 되돌려 로그가 빠르게 쌓이지 않게 합니다.
4. 동작 하나만 수행합니다. 예를 들어 구독을 한 번 업데이트하거나, 확실한 웹 페이지 하나를 열거나, 노드를 한 번 전환하거나, TUN만 따로 활성화합니다.
5. 최초의 이상 징후를 찾습니다. 동작을 수행한 시점부터 아래로 확인해 가장 이른 warning, error 또는 뚜렷한 시간 초과를 찾고, 그 앞의 설정과 라우팅 정보도 살펴봅니다.
6. 변수 하나만 바꾼 뒤 다시 시도합니다. 매번 노드, 포트, DNS, 실행 모드 중 하나만 변경해야 어떤 수정이 효과가 있었는지 확인할 수 있습니다.

로그의 시간 순서는 오류 개수보다 중요합니다. 먼저 설정 파싱 실패가 발생하고, 이어서 컨트롤 포트 연결 실패가 나타난 뒤, 마지막으로 화면에 코어가 실행 중이 아니라고 표시된다면 근본 원인은 마지막 컨트롤 포트 오류가 아니라 첫 번째 설정 오류일 가능성이 큽니다. TUN 초기화 실패 후에도 시스템 프록시로 애플리케이션이 네트워크에 접속된다면 프록시 코어는 정상이고 투명하게 트래픽을 가로채는 경로만 구성되지 않았을 수 있습니다.

클라이언트 시작
→ 설정 읽기
→ DNS 및 규칙 초기화
→ 로컬 프록시 포트 수신
→ TUN 초기화(활성화된 경우)
→ 애플리케이션 연결 수신
→ 규칙 매칭
→ 노드 선택
→ 원격 연결 수립

이 흐름을 점검 순서로 활용할 수 있습니다. 오류가 발생한 단계와 해당 단계가 의존하는 이전 단계부터 처리하고, 곧바로 노드를 바꾸거나 클라이언트를 재설치하지 마세요.

CONFIG PARSER

설정 파싱 및 코어 시작 오류

설정 오류는 대개 코어가 실제로 포트를 수신하기 전에 발생합니다. 자주 보이는 키워드는 parse, yaml, unmarshal, invalid config, field, duplicate, not found입니다. 이런 오류가 나타났다면 코어가 실행 가능한 설정을 아직 로드하지 못했을 수 있으므로 노드나 시스템 프록시를 계속 테스트해도 의미가 없습니다.

YAML 구조를 파싱할 수 없음

YAML은 들여쓰기로 계층을 표현합니다. Tab 사용, 목록 항목의 들여쓰기 불일치, 콜론 뒤 공백 누락, 닫히지 않은 따옴표 때문에 파싱이 중단될 수 있습니다. 로그에는 보통 행과 열 번호가 표시되지만 실제 문제는 안내된 줄보다 앞에 있을 수도 있습니다. 이전 줄의 문자열이 끝나지 않아 파서가 다음 줄에서야 잘못된 구조를 발견하는 경우입니다.

proxies:
  - name: Example
    type: ss
    server: example.test
    port: 443

proxy-groups:
  - name: SELECT
    type: select
    proxies:
      - Example

확인할 때는 먼저 모든 들여쓰기가 공백으로 되어 있는지 확인한 다음 오류 줄 앞뒤 몇 줄을 살펴보세요. 노드 이름에 콜론, 해시 또는 YAML 의미를 가진 문자가 포함되어 있다면 설정 제공자가 올바르게 인용해야 합니다. 설정을 직접 편집한 뒤 오류가 발생했다면 변경 사항을 되돌려 원본 설정이 로드되는지 먼저 확인하세요.

필드는 존재하지만 현재 코어가 지원하지 않음

Clash 설정은 모든 코어 버전에서 완전히 호환되지 않습니다. 일부 필드는 mihomo만 지원하므로 구형 코어에서 알 수 없는 필드, 유형 오류, 필수 매개변수 누락으로 보고될 수 있습니다. 반대로 클라이언트가 코어를 업데이트한 뒤 오래된 필드 때문에 경고가 발생할 수도 있습니다. 이때는 클라이언트 제품명만 보지 말고 실제로 호출되는 코어를 확인해야 합니다. 설정이 mihomo용이라면 해당 문법을 지원하는 클라이언트와 코어 버전을 사용하세요.

참조 대상이 존재하지 않음

전략 그룹이 존재하지 않는 노드를 참조하거나, 규칙이 정의되지 않은 전략 그룹을 가리키거나, 규칙 모음 경로를 읽지 못하면 로드 실패 또는 일부 기능 사용 불가가 발생할 수 있습니다. 오류에 표시된 대상 이름을 기준으로 대소문자, 공백, 전각 문자를 확인하세요. 이름은 정확히 일치해야 하며, 같아 보이는 앞뒤 공백도 참조 실패의 원인이 될 수 있습니다.

LISTENER STATUS

포트 충돌 및 시스템 프록시 오류

포트 오류에서 자주 보이는 키워드는 address already in use, bind, listen, permission denied, connection refused입니다. Clash 코어는 보통 HTTP, SOCKS, 혼합 포트 또는 외부 컨트롤 포트를 수신해야 합니다. 다른 코어 인스턴스, 이전 클라이언트 프로세스, 다른 네트워크 도구가 같은 주소를 이미 사용 중이면 새 프로세스가 수신을 완료하지 못합니다.

address already in use는 지정한 주소와 포트가 다른 프로세스에서 사용 중이라는 뜻입니다. 먼저 같은 종류의 클라이언트를 모두 종료한 다음 작업 관리자나 시스템 프로세스 목록에 코어 프로세스가 남아 있는지 확인하세요. 창만 닫으면 일부 클라이언트가 트레이에서 계속 실행될 수 있습니다. 잔류 프로세스가 없는 것을 확인한 뒤 다시 시작하고, 그래도 포트가 사용 중이면 사용하지 않는 포트로 변경한 뒤 해당 포트에 의존하는 브라우저나 애플리케이션 설정도 함께 수정합니다.

permission denied는 수신 위치와 함께 판단해야 합니다. 일반적인 로컬 고번호 포트에는 특별한 권한이 필요하지 않지만, 시스템 보안 정책, 방화벽 규칙, 제한된 실행 디렉터리가 작업을 막을 수 있습니다. 로그에 TUN, 라우팅, 서비스 등록이 언급된다면 시스템 권한 문제이므로 프록시 노드를 반복해서 바꿔도 해결되지 않습니다.

connection refused가 어느 방향의 연결에서 발생했는지도 중요합니다. 클라이언트 화면이 외부 컨트롤 포트에 연결하다 거부되었다면 코어가 시작되지 않았거나 컨트롤 주소가 다르거나 코어가 이미 종료되었을 가능성이 큽니다. 반면 프록시 코어가 원격 서버에 연결하다 거부되었다면 대상 주소에는 도달했지만 해당 원격 포트가 연결을 받아들이지 않는다는 뜻입니다. 표현은 같아도 문제 위치는 전혀 다르므로 로그의 출발지 주소, 대상 주소, 모듈 이름을 확인해야 합니다.

시스템 프록시 활성화 실패가 코어 포트가 작동하지 않는다는 뜻은 아닙니다. 먼저 로그에서 로컬 프록시 수신이 성공했는지 확인한 뒤 운영 체제의 프록시 설정이 해당 포트를 가리키는지 점검하세요. 브라우저를 수동으로 설정하면 연결되지만 일반 애플리케이션이 연결되지 않는다면 시스템 프록시 설정, 애플리케이션의 시스템 프록시 준수 여부, 애플리케이션 자체의 네트워크 설정을 의심할 수 있습니다.

DNS PIPELINE

DNS 조회 및 이름 해석 오류

DNS 문제는 웹 페이지에서 도메인을 찾지 못하거나, 일부 사이트만 접속되고 다른 사이트는 실패하거나, TUN을 켠 뒤 모든 도메인 연결이 시간 초과되거나, 로그에 lookup, resolve, no such host, timeout, SERVFAIL이 반복되는 형태로 나타납니다. 분석할 때는 먼저 “도메인에서 주소를 얻지 못한 것”과 “주소는 얻었지만 이후 연결에 실패한 것”을 구분하세요. 로그에 대상 IP가 이미 표시되고 연결 단계로 넘어갔다면 근본 원인은 최초의 도메인 해석이 아닐 가능성이 큽니다.

일반 DNS, DNS over HTTPS, DNS over TLS는 서로 다른 의존 관계를 가집니다. 암호화 DNS 서버 자체를 도메인으로 지정하면 코어가 bootstrap 또는 기본 해석기를 통해 먼저 서버 주소를 얻어야 할 수 있습니다. 이 선행 해석에 실패하면 이후 모든 조회를 보낼 수 없습니다. DNS 서버 도메인 조회가 로그에 반복되고 시간 초과된다면 단순히 프록시 노드만 바꾸지 말고 기본 해석기, 네트워크 연결 상태, 설정의 nameserver-policy를 확인하세요.

Fake IP 모드에서는 애플리케이션이 먼저 예약 주소를 받고, 코어가 내부 매핑을 기준으로 원래 도메인을 복원해 규칙을 매칭합니다. 예약 주소가 보인다고 해서 해석 오류는 아닙니다. 실제로 확인해야 할 것은 매핑이 존재하는지, 대상 도메인이 올바르게 가로채졌는지, Fake IP에 적합하지 않은 일부 로컬 네트워크 도메인이나 장치 검색 도메인을 필터링해야 하는지입니다. Redir Host 모드는 애플리케이션에 해석 결과를 직접 반환하므로 오류 로그의 형태가 달라질 수 있습니다.

DNS 시간 초과 점검 순서

1. 설정이 정상적으로 로드되고 DNS 모듈이 초기화되었는지 확인합니다.
2. 모든 서버가 실패했는지, 특정 보조 서버 하나만 실패했는지 확인합니다.
3. 조회가 직접 연결인지 프록시 경로인지, 관련 정책이 순환 의존을 이루는지 확인합니다.
4. DNS 서버의 주소와 프로토콜 형식이 현재 코어에서 지원되는지 확인합니다.
5. TUN을 끄고 시스템 프록시로 다시 시도해 문제가 가로채기 경로에만 있는지 판단합니다.
6. 도메인 해석 성공 후 TLS, 연결 시간 초과, 라우팅 실패가 계속 발생하는지 확인합니다.

TUN DEVICE

TUN 모드 시작 실패

TUN 모드는 가상 네트워크 어댑터와 시스템 라우팅을 통해 더 많은 애플리케이션 트래픽을 가로채며, 권한, 드라이버, 네트워크 인터페이스, 라우팅 테이블이 관련됩니다. 따라서 일반 시스템 프록시보다 오류 범위가 넓습니다. 자주 보이는 키워드는 tun, interface, route, adapter, device, service, operation not permitted입니다.

첫 단계는 “코어 전체가 실패했는지”와 “TUN 초기화만 실패했는지”를 구분하는 것입니다. 로컬 HTTP 또는 mixed 포트가 정상적으로 수신되고 TUN을 끈 뒤 시스템 프록시가 작동한다면 노드, 규칙, 기본 코어는 대체로 정상이며 가상 네트워크 어댑터 경로에 문제가 집중된 것입니다. 이때는 클라이언트가 요구하는 서비스 구성 요소, 실행 권한, 시스템의 다른 VPN·가상 머신·네트워크 필터 도구를 확인하세요.

인터페이스 생성 실패가 나타나면 가상 네트워크 어댑터를 만들 수 있는 다른 프로그램을 완전히 종료한 뒤 클라이언트를 다시 시작하세요. 라우팅 추가 실패가 나타나면 같은 네트워크 대역 충돌, 기존 라우팅 잔여 항목, 권한 부족을 확인합니다. 지정한 네트워크 인터페이스를 찾을 수 없다는 로그가 나오면 설정에 이미 변경된 인터페이스 이름이 고정되어 있을 수 있습니다. 노트북이 유선에서 무선으로 전환되거나 네트워크 장치를 재설치한 뒤에는 인터페이스 식별자가 달라질 수 있습니다.

macOS, Windows, Linux는 TUN 구현과 권한 모델이 서로 다르므로 다른 플랫폼의 처리 명령을 그대로 적용할 수 없습니다. 데스크톱 클라이언트에서 서비스 모드나 보조 서비스를 제공한다면 먼저 해당 구성 요소가 정상인지 확인하세요. Linux 환경에서는 TUN 장치와 네트워크 관리 권한도 확인해야 합니다. 어떤 플랫폼이든 먼저 클라이언트 자체의 시작·중지 기능으로 테스트하고, 여러 트래픽 가로채기 도구를 동시에 사용하지 마세요.

TUN을 켠 뒤 인터넷이 끊기지만 치명적인 로그가 없는 경우

기본 라우팅, DNS 가로채기, 규칙 결과를 확인해야 합니다. 로그에 연결이 DIRECT로 들어갔는데 직접 연결 트래픽이 올바른 인터페이스로 나가지 못한다면 출구 인터페이스 자동 식별에 실패했을 수 있습니다. 모든 도메인 조회가 시간 초과된다면 먼저 DNS 경로를 처리하세요. 로컬 네트워크 장치만 접근할 수 없다면 로컬 네트워크 대역이 잘못 가로채졌는지, 사설 주소 규칙이 예상대로 직접 연결되는지 확인합니다.

TUN을 점검할 때는 비교군을 하나 남겨 두는 것이 좋습니다. TUN을 끄고 시스템 프록시만 활성화한 뒤 같은 대상에 접속하세요. 시스템 프록시는 성공하고 TUN만 실패한다면 네트워크 어댑터와 라우팅을 계속 확인하고, 두 모드 모두 실패한다면 DNS, 노드, 원격 연결 계층으로 돌아가 분석합니다.

OUTBOUND CONNECTION

연결 실패, 시간 초과, TLS 오류

코어가 규칙 매칭을 마치면 선택한 아웃바운드 노드를 통해 대상에 연결합니다. 이 단계의 로그에는 보통 대상 도메인 또는 IP, 포트, 네트워크 유형, 전략 그룹, 노드 이름, 소요 시간이 포함됩니다. 핵심은 노드 서버에 연결하는지, 아니면 노드 연결이 성립한 뒤 대상 사이트에 연결하는지를 구분하는 것입니다. 로그 모듈과 주소를 보면 두 연결 구간을 나눠 확인할 수 있습니다.

i/o timeout 또는 context deadline exceeded

시간 초과는 제한 시간 안에 작업이 완료되지 않았다는 뜻일 뿐, 원인을 단독으로 알려 주지는 않습니다. 노드 서버에 접근할 수 없거나, 네트워크 패킷이 손실되거나, DNS 조회 결과가 늦게 나오거나, 대상 사이트가 응답하지 않아도 시간 초과가 발생할 수 있습니다. 먼저 시간 초과의 대상을 확인하세요. 노드 서버 주소라면 같은 구독의 다른 노드로 바꿔 비교하고, 여러 지역의 노드가 동시에 시간 초과되면 로컬 네트워크, DNS, 방화벽을 우선 점검합니다. 특정 대상만 실패한다면 규칙 결과와 대상의 접근 가능성을 확인하세요.

connection reset by peer

이 메시지는 연결이 수립된 뒤 상대방 또는 경로상의 장치가 연결을 재설정했다는 뜻입니다. 한 번 간헐적으로 발생했다면 네트워크 변동이나 서버의 정상적인 연결 종료일 수 있지만, 계속 발생한다면 노드 프로토콜, 포트, 전송 계층 매개변수, 서버 상태를 확인해야 합니다. reset만으로 클라이언트 문제라고 단정할 수 없습니다. 다른 노드로 같은 대상에 접속하거나 같은 노드로 다른 대상에 접속하면 범위를 빠르게 좁힐 수 있습니다.

TLS handshake timeout 및 인증서 오류

TLS 핸드셰이크 시간 초과는 네트워크 품질 저하, 대상 접근 불가, 프로토콜 매개변수 불일치에서 흔히 발생합니다. 인증서 오류가 있으면 시스템 날짜와 시간대도 확인해야 합니다. 시간이 잘못되면 유효한 인증서가 아직 유효하지 않거나 이미 만료된 것으로 판단될 수 있습니다. 노드 설정에 서버 이름과 전송 계층 보안 매개변수가 포함되어 있다면 구독에서 내려온 내용을 그대로 유지하고, 용도를 모르는 상태에서 직접 삭제하지 마세요.

network is unreachable 및 no route to host

이런 로그는 라우팅 계층을 가리킵니다. 현재 네트워크에 해당 IPv4 또는 IPv6 출구가 없거나, TUN 라우팅이 만들어지지 않았거나, 지정 인터페이스를 사용할 수 없거나, 대상 주소가 속한 네트워크에 도달할 수 없는 경우입니다. 로그에 IPv6 연결 시도가 표시되지만 로컬 네트워크에 안정적인 IPv6가 없다면 DNS 결과와 코어의 주소 선택을 확인하세요. IPv4와 IPv6가 모두 실패한다면 시스템 네트워크와 라우팅을 다시 점검합니다.

RULE MATCH

규칙 매칭 및 트래픽 경로

연결 자체에는 오류가 없지만 트래픽 경로가 예상과 다를 때가 있습니다. 예를 들어 프록시해야 할 도메인이 직접 연결되거나, 로컬 네트워크 주소가 노드로 전송되거나, 전략 그룹이 작동하지 않는 노드를 선택할 수 있습니다. 이런 문제는 error만 검색하지 말고 규칙 매칭 로그를 확인해야 합니다. debug 또는 상세 연결 로그에는 보통 대상, 적중한 규칙, 최종 정책이 표시됩니다.

Clash 규칙은 설정 순서대로 매칭되며, 일반적으로 하나가 적중되면 이후 검사를 중단합니다. 범위가 넓은 규칙을 앞에 배치하면 뒤의 정확한 도메인 규칙이 가려질 수 있습니다. 최종 MATCH 규칙은 앞에서 적중하지 않은 연결을 처리합니다. 로그에 잘못된 정책이 적중되었다면 설정에서 해당 규칙의 위치, 규칙 모음 내용, 전략 그룹의 현재 선택을 확인하세요.

전략 그룹 이름이 실제 노드를 의미하는 것은 아닙니다. 로그에는 연결이 먼저 “자동 선택”이라는 전략 그룹으로 전달된 뒤, 해당 그룹이 구체적인 노드를 선택하는 과정이 표시될 수 있습니다. 문제를 해결할 때는 규칙이 연결을 어느 그룹으로 보냈는지와 그 그룹이 당시 실제로 어떤 항목을 선택했는지를 모두 확인해야 합니다. 지연 시간 테스트 성공은 테스트 시점에 테스트 URL에 접근할 수 있었다는 뜻일 뿐, 모든 대상에 접속할 수 있거나 장시간 연결이 안정적이라는 보장은 아닙니다.

DIRECT도 명확한 아웃바운드 정책입니다. DIRECT에 적중한 연결이 실패하면 로컬 네트워크, DNS, 대상 사이트를 확인해야 하며 프록시 노드가 해결해 주기를 기대해서는 안 됩니다. REJECT는 규칙이 연결을 의도적으로 종료했다는 뜻이므로 로그의 거부는 설정상 예상된 결과일 수 있습니다. 애플리케이션이 REJECT된 도메인을 반복 요청하면 기록이 많이 남을 수 있지만, 이것이 코어 이상을 의미하지는 않습니다.

INCIDENT CHECKLIST

로그 수집 및 문제 해결 체크리스트

클라이언트 유지 관리자, 구독 제공자, 다른 기술 담당자에게 문의할 때는 로그에 충분한 맥락을 포함하되 민감한 정보는 제거해야 합니다. “연결 실패” 화면 한 장만으로는 충분하지 않으며, 몇 시간 분량의 전체 로그를 내보낼 필요도 없습니다. 재현 동작 전후 수십 초의 연속 로그를 남기는 편이 보통 문제를 찾기 쉽습니다.

함께 기록할 정보

• 운영 체제와 버전, 클라이언트 이름과 버전, 실제 코어 유형과 버전.
• 현재 사용하는 규칙 모드, 전체 모드 또는 직접 연결 모드와 시스템 프록시 및 TUN 활성화 여부.
• 문제가 발생하기 전에 수행한 동작(예: 설정 업데이트, 노드 전환, 절전 모드 해제, 클라이언트 업그레이드).
• 재현 가능한 조작 단계와 문제가 계속 발생하는지 간헐적인지 여부.
• 최초 이상 징후 전후의 연속 로그. 마지막 한 줄만 잘라내지 않습니다.
• TUN을 끄거나 노드를 전환하거나 네트워크를 바꾼 뒤의 비교 결과.

공유 전에 처리할 내용

로그와 설정에는 구독 주소, 인증 매개변수, 노드 서버 주소, 로컬 네트워크 장치 주소, 접속 도메인, 로컬 파일 경로가 포함될 수 있습니다. 공개하기 전에 이런 내용을 항목별로 확인하고 가리되 오류 유형, 포트 범위, 프로토콜 종류, 시간 순서는 남겨야 합니다. 모든 주소를 같은 값으로 바꾸면 “로컬 주소인지 원격 주소인지”, “같은 대상인지 여러 대상인지” 같은 중요한 관계가 사라집니다.

현상에서 근본 원인까지의 고정 순서

1. 운영 체제 자체가 인터넷에 연결되는지 확인합니다.
2. 설정 파싱이 완료되고 코어가 시작 단계에서 종료되지 않았는지 확인합니다.
3. 로컬 프록시 포트와 컨트롤 포트가 정상적으로 수신되는지 확인합니다.
4. DNS 조회가 결과를 반환하는지 확인합니다.
5. TUN을 활성화했다면 가상 네트워크 어댑터와 라우팅 초기화가 성공했는지 확인합니다.
6. 대상 연결이 예상한 규칙과 전략 그룹에 적중했는지 확인합니다.
7. 전략 그룹이 사용 가능한 노드를 선택했고 노드 서버에 연결할 수 있는지 확인합니다.
8. 마지막으로 대상 사이트, TLS 핸드셰이크, 애플리케이션 자체의 프록시 설정을 확인합니다.

이 순서의 핵심은 상위 의존성부터 처리하는 것입니다. 설정이 로드되지 않았을 때 포트를 테스트하지 말고, 포트가 수신되지 않을 때 애플리케이션 프록시를 점검하지 마세요. DNS가 완료되지 않았는데 대상 연결을 판단하지 말고, TUN이 구성되지 않았는데 모든 시간 초과를 노드 탓으로 돌리지 마세요. 매번 조건 하나만 바꾸고 변경 전후 로그를 비교하면 여러 설정을 반복해서 전환하는 것보다 근본 원인을 빠르게 찾을 수 있습니다.