Clash를 처음 실행한 뒤 화면이 열렸다고 해서 프록시가 이미 네트워크를 제어하고 있다는 뜻은 아닙니다. 완전한 연결에는 최소 네 가지 독립적인 단계가 필요합니다. 설정이 정상적으로 로드되고, 프록시 그룹에서 노드가 선택되어 있으며, 운영 체제나 앱이 트래픽을 Clash로 전달하고, 대상 연결이 규칙에 따라 지정된 출구를 통해 이루어져야 합니다. 어느 한 단계라도 완료되지 않으면 “노드는 사용할 수 있어 보이지만 웹페이지는 여전히 직접 연결됨” 또는 “시스템 프록시는 켜졌지만 모든 요청이 시간 초과됨”과 같은 문제가 발생할 수 있습니다.

클라이언트마다 메뉴 이름은 조금씩 다를 수 있습니다. Clash Meta(mihomo) 코어 기반 클라이언트는 대체로 설정, 프록시, 연결, 로그, 시스템 프록시, TUN을 별도 페이지로 나눕니다. 구버전 Clash 클라이언트도 비슷한 구조를 따릅니다. 처음 사용할 때는 데이터 흐름 순서대로 진행하고 DNS, 규칙 모드, 포트, TUN 설정을 한꺼번에 변경하지 마세요. 먼저 확인 가능한 기본 연결을 만든 다음 특정 앱의 호환성 문제를 다루는 편이 좋습니다.

1. 연결 전 클라이언트 상태 확인

클라이언트를 실행한 뒤 먼저 코어가 정상적으로 작동하는지 확인하세요. 화면에는 Running, Started, Core Running 또는 “서비스 실행 중”과 같은 상태가 표시되는 경우가 많습니다. 페이지는 열리지만 코어 상태가 Stopped, Error이거나 계속 재시작된다면 이후 구독 가져오기와 노드 테스트 결과를 신뢰하기 어렵습니다. 이때는 먼저 로그를 열어 설정 파싱 실패, 수신 포트 충돌 또는 권한 부족이 있는지 확인하세요.

시스템 날짜, 시간, 시간대도 정확한지 확인해야 합니다. HTTPS 연결은 인증서 유효 기간을 기준으로 검증하므로 기기 시간이 크게 어긋나면 구독 업데이트와 노드 핸드셰이크가 모두 실패할 수 있습니다. 네트워크 자체가 구독 서비스에 접속할 수 있어야 합니다. 먼저 시스템 프록시를 잠시 끄고 브라우저에서 일반 웹사이트가 열리는지 확인하세요. 기본 네트워크가 연결되지 않은 상태에서는 Clash도 로컬 Wi-Fi, 유선 네트워크 또는 모바일 네트워크를 대신해 하위 연결을 만들 수 없습니다.

점검 항목 정상적인 상태 문제 발생 시 우선 조치
코어 상태 계속 실행되며 반복 종료되지 않음 시작 로그와 설정 오류 확인
로컬 네트워크 프록시를 끄면 일반 웹사이트에 접속 가능 게이트웨이, 인증 페이지 및 DNS 확인
시스템 시간 날짜, 시간, 시간대가 정확함 시스템 시간 동기화 활성화
수신 포트 HTTP, SOCKS 또는 mixed 포트가 정상적으로 열려 있음 포트를 점유한 이전 프로세스 종료

2. 구독 설정 가져오기 및 활성화

Clash는 YAML 설정으로 프록시 노드, 프록시 그룹, 규칙, DNS 및 실행 매개변수를 정의합니다. 구독 링크는 보통 설정 서비스가 제공하는 업데이트 주소이며, 클라이언트는 먼저 해당 주소에 요청을 보낸 뒤 응답 내용을 로컬 설정으로 저장합니다. 링크를 복사할 때는 전체 쿼리 매개변수를 유지하세요. 물음표 뒤의 token, 기기 매개변수 또는 인코딩된 내용을 임의로 삭제하지 말고, 구독 관리 웹페이지 주소를 구독 주소로 착각하지도 마세요.

  1. “설정”, “Profiles” 또는 “구독” 페이지로 이동합니다.
  2. URL에서 가져오기를 선택하고 전체 구독 주소를 입력란에 붙여 넣습니다.
  3. 다운로드 또는 가져오기를 실행하고 클라이언트에서 업데이트 완료를 알릴 때까지 기다립니다.
  4. 설정 목록에서 방금 가져온 항목을 선택해 현재 활성 설정으로 지정합니다.
  5. 프록시 페이지로 돌아가 프록시 그룹과 그룹 내 노드가 표시되는지 확인합니다.

“다운로드 성공”과 “설정 활성화”는 서로 다른 상태입니다. 일부 클라이언트는 구독을 업데이트한 뒤 파일만 목록에 추가하고 현재 설정으로 자동 전환하지 않습니다. 프록시 페이지에 이전 노드가 계속 표시된다면 설정 페이지에서 선택 표시, 활성 상태 또는 최근 업데이트 시간을 확인하세요. 설정을 활성화한 뒤 YAML 파싱 오류가 표시되면 구체적인 줄 번호와 필드를 기록하세요. 같은 오류 내용은 반복해서 다운로드한다고 자동으로 수정되지 않으므로 업데이트 버튼을 계속 누르지 마세요.

구독 응답이 비어 있거나 HTML 페이지 또는 지원되지 않는 형식으로 반환되면 invalid config, unexpected token, proxy group not found 또는 proxies 필드 누락과 같은 메시지가 표시될 수 있습니다. 이런 문제는 설정을 불러오는 단계에서 발생하며 노드 속도와는 관계가 없습니다. 브라우저에서 구독 주소를 열어 서비스 응답을 확인할 수 있지만, 접근 자격 증명이 포함된 구독 URL은 채팅방, 스크린샷 또는 공개 로그에 게시하지 마세요.

3. 프록시 그룹과 노드 선택

설정이 정상적으로 로드되면 “프록시”, “Proxies” 페이지로 이동하세요. 이곳은 단순한 노드 목록이 아니라 여러 프록시 그룹으로 구성된 경우가 많습니다. 대표적인 그룹 유형으로는 수동 선택 방식인 select, 자동 속도 측정 방식인 url-test, 장애 전환 방식인 fallback, 부하 분산 방식인 load-balance가 있습니다. 규칙은 프록시 그룹 이름을 참조하고, 프록시 그룹이 실제 사용할 노드를 결정합니다. 따라서 관계없는 그룹에서만 노드를 선택하면 실제 출구가 바뀌지 않을 수 있습니다.

먼저 주요 트래픽을 담당하는 그룹을 찾으세요. “노드 선택”, “프록시”, “PROXY” 또는 설정 제공업체가 정한 이름일 수 있습니다. 해당 그룹에 들어가 지역이 명확하고 테스트 가능한 상태의 노드를 선택하세요. 주 그룹에서 다른 프록시 그룹을 선택한 경우에는 최종 노드를 확인할 수 있도록 다음 단계로 더 들어가야 합니다. 그룹을 연쇄적으로 구성하는 방식은 정상적인 설정이지만, 최초 문제를 확인할 때는 최종적으로 어떤 프록시 항목에 연결되는지 알아야 합니다.

모드 선택도 결과에 영향을 줍니다.

  • 규칙 모드(Rule): 규칙을 위에서 아래로 매칭합니다. 도메인에 따라 프록시, 직접 연결 또는 거부 정책이 달라질 수 있어 일상적인 기본 모드로 적합합니다.
  • 전역 모드(Global): 대부분의 가로채인 연결을 전역 그룹으로 일괄 전달합니다. 임시로 노드 출구를 확인할 때 유용하지만 모든 시스템 트래픽이 반드시 가로채인다는 의미는 아닙니다.
  • 직접 연결 모드(Direct): Clash가 받은 트래픽을 프록시 노드 없이 대상에 직접 연결합니다. 원격 프록시 출구를 확인하는 용도로는 사용할 수 없습니다.

최초 확인에서는 먼저 규칙 모드를 사용하세요. 특정 테스트 사이트가 어떤 규칙에 매칭되었는지 판단하기 어렵다면 잠시 전역 모드로 전환해 결과를 비교할 수 있습니다. 테스트가 끝나면 규칙 모드로 되돌리세요. 모드는 Clash가 연결을 받은 뒤 처리하는 방식을 결정하고, 시스템 프록시 또는 TUN은 연결이 Clash에 도달할지를 결정합니다. 두 설정은 서로 대체할 수 없습니다.

4. 지연 시간 테스트 제대로 이해하기

노드 옆의 “속도 테스트”는 보통 HTTP 탐색을 수행합니다. 코어가 해당 노드를 통해 설정된 테스트 URL에 접속하고, 연결을 수립한 뒤 응답을 받기까지 걸린 시간을 기록합니다. 80ms, 200ms 또는 Timeout이라는 표시가 의미하는 것은 해당 탐색의 결과뿐입니다. 다운로드 대역폭과 같지 않으며 동영상 재생 안정성, 피크 시간대 혼잡, 패킷 손실률 또는 대상 웹사이트의 출구 주소 제한까지 완전히 보여 주지도 않습니다.

테스트할 때는 먼저 한 프록시 그룹의 모든 노드에 대해 지연 시간 테스트를 실행한 뒤, 같은 지역의 사용 가능한 노드 중 수치가 낮고 결과가 안정적인 항목을 선택하세요. 한 번 나온 최저 수치만으로 결정하지 마세요. 연속 테스트에서 90ms, 95ms, 100ms 부근으로 변동하는 노드가 40ms와 700ms 사이를 크게 오가는 노드보다 일반적으로 상호작용을 안정적으로 유지하기 쉽습니다. 지역 간 거리가 먼 노드는 기본 지연 시간이 늘어나는 것이 정상입니다.

Timeout은 테스트 시간 안에 예상한 응답을 받지 못했다는 뜻입니다. 노드 오프라인, 경로 차단, 테스트 주소 접속 불가, TLS 핸드셰이크 실패 또는 로컬 네트워크 변동이 원인일 수 있습니다. 모든 노드가 동시에 시간 초과되면 노드를 하나씩 고장으로 판단하기보다 로컬 네트워크, 구독 설정, 코어 상태 또는 테스트 URL부터 의심하세요. 특정 노드 하나만 계속 시간 초과된다면 같은 그룹의 다른 노드로 전환하는 편이 효과적입니다.

5. 시스템 프록시 또는 TUN 활성화

노드를 선택한 뒤에는 앱 트래픽이 Clash로 들어가도록 해야 합니다. 가장 일반적인 방법은 “시스템 프록시”를 켜는 것입니다. 클라이언트는 운영 체제의 HTTP 및 HTTPS 프록시를 로컬 수신 주소로 지정하며, 보통 127.0.0.1과 로컬 포트 조합으로 표시됩니다. 시스템 프록시 설정을 따르는 브라우저와 데스크톱 앱은 요청을 Clash로 보내고, 이후 규칙에 따라 직접 연결하거나 프록시를 사용합니다.

시스템 프록시가 모든 프로그램을 지원하는 것은 아닙니다. 일부 게임, 명령줄 도구, 백그라운드 서비스 또는 자체 네트워크 스택을 사용하는 앱은 운영 체제의 프록시를 무시할 수 있으며 UDP 트래픽도 일반 HTTP 프록시를 거치지 않을 수 있습니다. 이런 경우에는 TUN 모드를 고려할 수 있습니다. TUN은 가상 네트워크 인터페이스를 만들고 코어가 더 넓은 범위의 IP 트래픽을 수신하도록 합니다. 일반적으로 관리자 권한이 필요하며 방화벽, 백신, 다른 VPN 또는 가상 네트워크 어댑터의 영향을 받을 수 있습니다.

첫 연결에서는 경로가 단순하고 문제 지점이 적은 시스템 프록시부터 테스트하는 것이 좋습니다. 브라우저 프록시가 정상적으로 작동하는 것을 확인한 뒤 필요에 따라 TUN을 켜세요. 시스템 프록시나 라우팅 테이블을 변경하는 클라이언트를 여러 개 동시에 실행하지 마세요. 한 프로그램이 다른 프로그램의 설정을 덮어쓸 수 있습니다. 클라이언트를 바꾸기 전에는 기존 클라이언트의 시스템 프록시와 TUN을 끄고 백그라운드 프로세스도 종료하세요.

시스템 프록시를 사용할 때는 운영 체제의 프록시 주소가 클라이언트의 현재 포트와 일치하는지도 확인하세요. 설정의 mixed-port, port, socks-port는 용도가 서로 다릅니다. 직접 입력할 때 SOCKS 포트를 HTTP 포트로 사용하면 안 됩니다. 시스템 프록시는 클라이언트가 자동으로 관리하도록 하는 편이 안전하며, 포트가 바뀌어도 설정을 동기화할 수 있습니다.

6. 프록시가 실제로 적용되는지 확인

스위치 색상만 보고 적용 여부를 판단해서는 안 됩니다. 출구 결과, 연결 기록, 규칙 매칭을 함께 확인하세요. 먼저 확인된 노드를 선택한 상태로 유지하고 시스템 프록시를 켠 다음, 새 브라우저 시크릿 창에서 공인 출구 정보를 표시하는 서비스에 접속합니다. 현재 출구 지역 또는 주소를 기록한 뒤 시스템 프록시를 끄고 새로 고쳐 비교하세요. 두 결과가 예상대로 달라지면 브라우저 트래픽이 프록시 경로로 들어간 것입니다.

이어서 클라이언트의 “연결”, “Connections” 페이지를 열고 새 웹사이트에 접속하세요. 정상이라면 새로운 도메인, 대상 주소, 연결 유형, 업로드·다운로드량, 매칭된 규칙과 프록시 체인이 표시됩니다. 프록시 체인은 “대상 정책 그룹 → 선택한 노드”로 표시될 수도 있고 DIRECT로 표시될 수도 있습니다. DIRECT가 항상 오류인 것은 아닙니다. 규칙 모드에서는 로컬 네트워크, 특정 지역 웹사이트 또는 설정에서 지정한 도메인이 원래 직접 연결될 수 있습니다.

로그도 판단에 도움이 되지만 시간 순서대로 읽어야 합니다. 브라우저 요청 하나는 보통 DNS 조회, 규칙 매칭, TCP 또는 UDP 연결 수립, 노드 연결, 대상 접속 단계를 거칩니다. 로그에 match, proxy, DIRECT 또는 구체적인 그룹 이름이 나타나면 방금 접속한 도메인에 해당하는지 확인하세요. 이전 로그의 timeout만으로 현재 요청도 실패했다고 단정할 수 없습니다. 문제를 확인하기 전 로그를 비우거나 테스트 시작 시간을 기억해 두세요.

도메인 연결과 직접 IP 연결도 나누어 테스트해야 합니다. 웹페이지가 열리지 않는데 연결 기록에 새 항목이 전혀 없다면 트래픽이 Clash에 들어오지 않았을 가능성이 있습니다. 연결 항목은 있지만 DNS 실패로 표시된다면 DNS 모듈, 네트워크 접근성 및 모드 설정을 확인하세요. 올바른 노드에 연결된 뒤에도 시간 초과가 발생한다면 노드 경로 또는 대상 서비스 문제에 더 가깝습니다. 무작정 열 개가 넘는 노드를 바꾸기보다 단계별로 위치를 좁히는 편이 빠릅니다.

재현 가능한 확인 절차

  1. 지연 시간 테스트에 응답하는 노드를 선택합니다.
  2. 현재 모드가 직접 연결이 아닌 규칙 또는 전역인지 확인합니다.
  3. 시스템 프록시를 켜고 TUN은 잠시 끈 상태로 둡니다.
  4. 연결 기록과 로그를 비우거나 현재 시간을 기준으로 표시합니다.
  5. 브라우저의 새 창에서 출구 확인 페이지와 일반 HTTPS 웹사이트를 엽니다.
  6. 연결 기록에서 도메인, 규칙, 정책 그룹 및 최종 노드를 확인합니다.
  7. 시스템 프록시를 끈 뒤 다시 테스트해 출구와 연결 기록이 달라지는지 확인합니다.

7. 상태 메시지와 일반적인 문제 확인

Connected 또는 Running: 일반적으로 코어, 서비스 또는 특정 연결이 실행 중이라는 뜻일 뿐입니다. 대상 웹사이트에 접속할 수 있거나 현재 출구가 프록시를 거친다는 보장은 없습니다. 연결 기록과 함께 확인해야 합니다.

Timeout: 제한 시간 안에 탐색 또는 연결이 완료되지 않았다는 뜻입니다. 먼저 모든 노드에서 발생하는지 특정 노드에서만 발생하는지 확인한 다음 DNS, 노드 핸드셰이크, 대상 응답 단계로 나누어 살펴보세요. 모든 노드가 동시에 시간 초과되면 로컬 네트워크와 코어를 먼저 확인해야 합니다.

Connection refused: 대상 주소가 연결을 적극적으로 거부했다는 뜻입니다. 거부된 주소가 127.0.0.1의 로컬 포트라면 코어가 수신 대기 중이지 않거나 시스템 프록시 포트가 잘못 입력된 경우가 많습니다. 원격 노드에서 발생했다면 해당 포트에서 노드 서비스가 실행되지 않을 수 있습니다.

DNS lookup failed: 도메인 이름을 해석해 사용할 수 있는 결과를 얻지 못했다는 뜻입니다. 기기에 다른 DNS 도구가 있는지, TUN DNS 가로채기가 정상인지, 설정의 nameserver에 접근할 수 있는지 확인하세요. 기본 연결을 확인하기 전에는 여러 암호화 DNS와 사용자 지정 hosts 규칙을 동시에 추가하지 마세요.

TLS handshake failed: 기기 시간, 인증서 검증, SNI, 경로 중단 또는 원격 서비스 상태와 관련이 있을 수 있습니다. 먼저 시간을 보정한 뒤 같은 그룹의 다른 노드와 비교하세요. 모든 노드가 특정 대상 하나에 대해서만 실패한다면 전체 설정을 바로 수정하기보다 대상 서비스의 제한도 고려해야 합니다.

웹페이지는 열리지만 앱이 연결되지 않음: 브라우저는 대체로 시스템 프록시를 따르지만 대상 앱은 해당 설정을 무시하거나 UDP를 사용할 수 있습니다. 먼저 연결 페이지에서 앱 요청이 나타나는지 확인하세요. 기록이 전혀 없다면 TUN, 앱 내부 프록시 또는 프로세스 라우팅 설정을 검토하세요.

8. 최초 연결 점검 목록

  • 클라이언트 코어가 계속 실행되고 로그에 설정 파싱 실패가 없습니다.
  • 구독이 다운로드되었고 현재 활성 설정으로 지정되어 있습니다.
  • 프록시 페이지에 정책 그룹과 노드가 표시됩니다.
  • 주요 정책 그룹에서 사용할 수 없는 항목이 아닌 실제 노드가 선택되어 있습니다.
  • 노드 지연 시간 테스트에 응답이 있고 연속 결과에 이상 변동이 없습니다.
  • 현재 모드가 Direct가 아니며 규칙 모드에서 매칭된 정책을 확인할 수 있습니다.
  • 시스템 프록시가 켜져 있고 운영 체제의 프록시 포트가 클라이언트 수신 포트와 일치합니다.
  • 브라우저로 접속할 때 연결 페이지에 해당하는 새 기록이 나타납니다.
  • 기록에 예상한 규칙, 정책 그룹 및 최종 노드가 표시됩니다.
  • 출구 확인 결과가 시스템 프록시를 끈 상태와 예상대로 다릅니다.

위 항목을 모두 완료하면 최초 연결의 기본 경로가 구축된 것입니다. 이후 특정 프로그램만 인터넷에 연결되지 않는다면 해당 앱이 시스템 프록시를 따르는지, UDP를 사용하는지, TUN이 필요한지, 해당 도메인이 어떤 규칙에 매칭되었는지로 점검 범위를 좁히세요. 모든 앱이 동시에 작동하지 않으면 설정, 코어, 수신 포트, 로컬 네트워크라는 네 가지 기본 요소로 돌아가 다시 확인하세요.

안정적인 사용의 핵심은 최저 지연 시간을 계속 추구하는 것이 아니라 설정의 유효성, 노드 접근 가능성, 명확한 트래픽 진입 경로, 관찰 가능한 규칙 결과를 유지하는 데 있습니다. 연결 기록에서 “요청이 Clash에 들어왔는가, 어떤 규칙에 매칭되었는가, 최종적으로 어느 노드를 사용했는가”에 답할 수 있다면 대부분의 최초 연결 문제를 구체적인 단계까지 좁혀 해결할 수 있습니다.