Clash 초보자 자주 묻는 질문: 구독, 모드와 연결 상태 10가지

시작 전: 네 가지 상태부터 구분하기

Clash 클라이언트는 일반적으로 그래픽 인터페이스, Clash 또는 mihomo 코어, 설정 파일, 시스템 네트워크 설정이 함께 작동합니다. 창이 열렸다는 것은 그래픽 인터페이스가 실행되었다는 뜻일 뿐이며, 설정을 성공적으로 가져왔다고 해서 트래픽이 이미 프록시를 통과하는 것은 아닙니다. 초기화가 완료되었는지 확인하려면 설정, 노드, 프록시 진입점, 실제 요청 순서로 점검해야 합니다.

1. 설정 상태: 현재 설정 파일을 코어가 불러올 수 있고, 인터페이스에 YAML 구문 오류나 필드 호환성 오류가 표시되지 않습니다.
2. 정책 상태: 프록시 정책 그룹에 사용할 수 있는 노드가 있고, 수동 선택이 필요한 정책 그룹이 비어 있지 않습니다.
3. 트래픽 인계 상태: 시스템 프록시 또는 TUN 모드 중 하나 이상이 활성화되어 애플리케이션 트래픽이 Clash 수신 포트로 들어갑니다.
4. 연결 상태: 연결 목록에 새 기록이 생성되고, 로그에 규칙 매칭 결과가 표시되며, 대상 요청이 정상적으로 응답합니다.

“실행 중” 표시나 트레이 아이콘만 확인하면 설정 문제, 노드 문제, 시스템 프록시 문제를 쉽게 혼동할 수 있습니다. 아래 10가지 질문은 실제 사용 순서에 따라 정리했으므로, 문제가 생겼을 때 해당 항목으로 바로 이동해도 됩니다.

구독 및 설정: 가져오기는 연결과 다릅니다

질문 1: 구독 주소를 가져온 뒤 노드가 보이지 않는 이유는 무엇인가요?

구독 주소는 원격 설정에 접근하기 위한 경로입니다. 클라이언트는 해당 주소에 접속해 응답 내용을 내려받은 뒤, 이를 프록시 노드·정책 그룹·규칙으로 파싱해야 합니다. 가져오기가 완료되었는데 목록이 비어 있다면 주소가 완전히 복사되지 않았거나, 구독이 만료되었거나, 현재 네트워크에서 구독 서버에 접속할 수 없거나, 서버가 설정 파일 대신 웹 페이지를 반환했거나, 클라이언트가 해당 형식을 지원하지 않는 경우가 흔합니다.

먼저 설정 또는 구독 관리 화면에서 수동 업데이트를 한 번 실행하고 업데이트 시간과 오류 메시지를 확인하세요. 시간 초과가 표시되면 현재 네트워크와 구독 서버 사이의 연결 상태를 점검해야 합니다. 파싱 실패가 표시되면 로그인 페이지, 콘솔 주소, QR 코드 이미지 링크가 아니라 실제 구독 주소를 가져왔는지 확인하세요. 일부 서비스는 범용 구독, Clash 설정, 단일 노드 링크를 별도로 제공합니다. 데스크톱 Clash 클라이언트에서는 일반적으로 Clash 또는 Clash 호환으로 명확히 표시된 설정 경로를 선택해야 합니다.

“노드가 없음”과 “정책 그룹이 선택되지 않음”도 구분해야 합니다. 설정 안에는 노드가 이미 있지만 홈 화면에는 정책 그룹만 표시될 수 있습니다. 프록시 또는 Proxies 페이지로 이동해 구체적인 정책 그룹을 펼친 다음 구성원을 확인하세요. 규칙 제공자가 정책 그룹을 동적으로 생성하는 경우에는 설정 다운로드와 파싱이 끝날 때까지 기다린 뒤 조작해야 합니다.

질문 2: 구독을 업데이트하면 수동으로 수정한 내용이 덮어써지나요?

대부분 그렇습니다. 원격 구독 업데이트는 설정을 새로 내려받는 작업과 같으므로, 구독에서 생성된 노드 이름·규칙·DNS 필드를 직접 수정하면 다음 업데이트 때 원격 내용으로 교체될 수 있습니다. 클라이언트마다 오버라이드, 설정 병합, 스크립트 처리, 설정 패치의 구현 방식은 다르지만 기본 원칙은 같습니다. 업데이트되는 내용은 원격 설정에 맡기고, 로컬 맞춤 설정은 클라이언트가 제공하는 오버라이드 계층에 추가해야 합니다.

초보자는 처음부터 YAML을 크게 편집하지 않는 것이 좋습니다. 먼저 원본 설정을 보존하고 기본 연결이 정상인지 확인한 다음, 클라이언트 기능에 맞춰 로컬 규칙을 추가하세요. 편집 후 실행에 실패하면 들여쓰기, 콜론 뒤의 공백, 목록 기호, 필드 계층을 우선 확인해야 합니다. YAML은 공백으로 계층을 표현하므로 탭, 전각 문장 부호, 잘못된 들여쓰기 때문에 파일 전체를 불러오지 못할 수 있습니다.

노드 및 지연 시간: 테스트 수치가 실제 속도와 같지는 않습니다

질문 3: 지연 시간이 가장 짧은 노드가 항상 가장 빠른가요?

그렇지는 않습니다. 지연 시간 테스트는 주로 클라이언트에서 테스트 대상까지 한 번의 연결 또는 요청을 완료하는 데 걸린 시간을 보여주며, 노드의 온라인 여부와 상호작용 응답성을 판단하는 데 유용합니다. 다운로드 속도는 노드의 출구 대역폭, 회선 혼잡, 망 간 라우팅, 대상 사이트의 속도 제한, 프로토콜 오버헤드, 로컬 네트워크 품질의 영향을 함께 받습니다. 지연 시간이 수십 밀리초인 혼잡한 노드가, 지연 시간은 조금 더 길지만 회선이 안정적인 노드보다 실제 처리량이 낮을 수도 있습니다.

노드를 선택할 때는 세 단계로 진행하면 됩니다. 먼저 시간 초과 노드를 제외하고, 지연 시간이 짧은 노드에서 실제 웹 페이지나 파일 요청을 수행한 다음, 일정 시간 동안 연결이 자주 끊기는지 확인하세요. 게임·원격 터미널·실시간 통화는 지연 시간과 지터를 더 중요하게 보고, 동영상과 대용량 파일 다운로드는 지속적인 처리량을 더 중요하게 봅니다. 일반 웹 서핑에서는 DNS, 핸드셰이크 속도, 안정성을 함께 고려해야 합니다.

클라이언트의 URL Test 정책 그룹은 지정된 주소를 주기적으로 테스트해 더 나은 결과의 노드를 선택할 수 있지만, 테스트 결과는 해당 테스트 대상과 테스트 시점에만 유효합니다. Fallback 정책은 장애 전환에 더 초점을 맞추고, 부하 분산 정책은 설정에 따라 여러 노드에 연결을 나눌 수 있습니다. 실제 동작은 설정된 정책 그룹 유형에 따라 달라지므로 모든 “자동 선택”을 단순히 지연 시간이 가장 짧은 노드를 고르는 기능으로 이해해서는 안 됩니다.

질문 4: 노드가 사용 가능으로 표시되는데 웹 페이지가 열리지 않는 이유는 무엇인가요?

노드 테스트 성공은 특정 테스트 요청이 해당 노드를 통과할 수 있다는 뜻일 뿐, 브라우저 요청도 반드시 같은 경로를 이용한다는 뜻은 아닙니다. 먼저 연결 목록에 브라우저가 요청한 도메인이 표시되는지 확인하세요. 기록이 전혀 없다면 문제는 대개 시스템 프록시, 브라우저의 독립 프록시 설정, TUN 인계 계층에 있습니다. 기록이 있다면 매칭된 규칙, 최종 정책, 오류 메시지를 계속 확인하세요.

테스트 주소는 접속되지만 대상 웹 사이트는 접속되지 않는 경우도 있습니다. 대상 도메인이 규칙에 따라 DIRECT로 할당되었거나, 정책 그룹에서 다른 노드를 선택했거나, DNS 해석 결과와 실제 연결 경로가 일치하지 않을 수 있습니다. 전역 모드로 전환하는 것은 짧은 시간 동안 원인을 좁히는 방법이 될 수 있습니다. 전역 모드에서는 작동하지만 규칙 모드에서는 작동하지 않는다면 규칙 매칭과 정책 그룹을 확인하고, 두 모드 모두 작동하지 않는다면 노드, DNS, 시스템 시간, 로컬 네트워크를 우선 점검하세요.

규칙 모드와 시스템 프록시: 트래픽이 들어오는 경로 확인하기

질문 5: Rule, Global, Direct 세 가지 모드는 어떻게 다른가요?

Rule(규칙) 모드는 설정의 규칙을 순서대로 적용해 요청을 판단합니다. 예를 들어 도메인, IP, 프로세스 또는 규칙 집합에 따라 직접 연결할지, 거부할지, 특정 정책 그룹으로 보낼지를 결정합니다. 일상적인 사용에서 가장 흔한 모드이며, 설정의 규칙과 정책 그룹이 완전하고 정상적으로 작동해야 합니다.

Global(전역) 모드는 일반적으로 Clash로 들어온 요청을 모두 전역 정책 그룹으로 전달하며, 노드가 작동하는지 임시로 확인할 때 적합합니다. 그렇다고 기기의 모든 트래픽이 자동으로 Clash에 들어오는 것은 아닙니다. 트래픽은 먼저 시스템 프록시, 애플리케이션 프록시 또는 TUN 인터페이스를 거쳐야 합니다.

Direct(직접 연결) 모드는 Clash에 들어온 요청을 프록시 노드 없이 대상에 직접 연결합니다. 프록시 노드가 문제의 원인인지 테스트하거나, 노드 전달만 중단한 채 Clash의 트래픽 인계 상태를 유지할 때 사용할 수 있습니다. Direct는 클라이언트를 완전히 종료하는 것과 다릅니다. DNS, 수신 포트, 연결 기록은 여전히 코어가 처리할 수 있습니다.

문제를 확인할 때는 간단한 비교가 도움이 됩니다. 규칙 모드에서는 실패하지만 전역 모드에서는 성공한다면 규칙을 중점적으로 확인하고, 전역 모드도 실패한다면 노드와 트래픽 인계 진입점을 확인하세요. Direct 모드도 실패한다면 로컬 네트워크, DNS 또는 대상 서비스 자체에 문제가 있을 수 있습니다. 테스트가 끝나면 원래의 규칙 모드로 복원해 예상한 트래픽 분배가 장기간 바뀌지 않도록 하세요.

질문 6: 시스템 프록시를 켰는데 일부 애플리케이션이 계속 직접 연결되는 이유는 무엇인가요?

시스템 프록시는 운영체제가 애플리케이션에 제공하는 프록시 설정 모음입니다. 브라우저와 많은 데스크톱 프로그램은 이 설정을 읽어 HTTP 또는 HTTPS 요청을 Clash의 혼합 포트나 해당 프록시 포트로 보냅니다. 하지만 모든 애플리케이션이 시스템 프록시를 따르는 것은 아닙니다. 일부 게임, 명령줄 도구, 가상 머신, 컨테이너 프로그램, 자체 네트워크 스택을 사용하는 소프트웨어는 직접 연결을 생성합니다.

먼저 시스템 프록시를 켠 뒤 운영체제의 프록시 주소가 로컬 호스트의 수신 주소를 가리키는지, 포트가 클라이언트의 현재 포트와 일치하는지 확인하세요. 다른 프로그램이 포트를 사용 중이거나, 코어가 실행되지 않았거나, 클라이언트가 설정을 전환한 뒤 수신에 실패하면 시스템 프록시는 켜져 있어도 연결이 들어오지 않습니다. 브라우저에 별도의 프록시 확장 프로그램을 설치했다면 시스템 설정을 덮어쓸 수 있으므로 잠시 비활성화한 뒤 다시 테스트하세요.

더 많은 TCP·UDP 트래픽이나 시스템 프록시를 읽지 않는 애플리케이션까지 처리해야 한다면 TUN 모드를 고려할 수 있습니다. TUN은 가상 네트워크 인터페이스를 만들고 시스템 라우팅을 통해 더 많은 트래픽을 코어로 전달하며, 일반적으로 관리자 권한이 필요합니다. 적용 범위는 더 넓지만 다른 VPN, 가상 네트워크 카드, 보안 소프트웨어, 사용자 지정 라우팅과 충돌하기도 쉽습니다. 초보자는 먼저 시스템 프록시 모드를 정상 작동시킨 뒤 실제 필요에 따라 TUN을 활성화해야 하며, 여러 네트워크 설정을 동시에 변경해서는 안 됩니다.

연결 실패: 진입점·규칙·노드·대상 순서로 점검하기

질문 7: 로그의 timeout, connection refused, DNS error는 각각 무엇을 의미하나요?

timeout은 네트워크의 특정 단계가 제한 시간 안에 완료되지 않았다는 뜻입니다. 구독에 접근할 때, 노드에 연결할 때, 대상 연결을 만들 때, 응답을 기다릴 때 발생할 수 있습니다. 일반적으로 회선 단절, 심각한 패킷 손실, 느린 대상 응답, 방화벽 차단을 의심할 수 있지만 timeout 하나만으로 장애 위치를 확정할 수는 없습니다. 로그의 대상 주소, 정책 이름, 연결 경로를 함께 확인해야 합니다.

connection refused는 대상 주소가 연결을 명확히 거부했다는 뜻입니다. 로컬 포트에서 거부되었다면 Clash 코어가 해당 포트를 수신하지 않고 있을 수 있습니다. 프록시 서버에서 거부되었다면 노드 서비스가 중지되었거나 포트 설정이 일치하지 않을 수 있고, 최종 대상에서 거부되었다면 대상 서비스가 해당 포트를 열어 두지 않았을 수 있습니다.

DNS 관련 오류는 도메인 이름을 해석하는 단계에서 유효한 결과를 얻지 못했다는 뜻입니다. 흔한 원인으로는 DNS 서버에 접근할 수 없거나, 향상된 모드 설정이 맞지 않거나, 네트워크가 DNS 요청을 가로채거나, 도메인 자체가 존재하지 않는 경우가 있습니다. 이런 오류가 발생했다고 노드만 계속 바꾸지 마세요. 먼저 일반 네트워크에서 도메인을 해석할 수 있는지 확인한 다음 설정의 DNS 활성화 여부, 수신 설정, nameserver, fallback 등의 필드를 점검하세요. DNS를 수정한 뒤에는 설정을 다시 불러오고 연결을 새로 시도해야 하며, 기존 연결에는 새 결과가 자동으로 적용되지 않습니다.

질문 8: 시스템 프록시가 켜져 있는데 연결 목록이 여전히 비어 있는 이유는 무엇인가요?

연결 목록이 비어 있다는 것은 현재 확인된 요청이 Clash로 들어오지 않았다는 뜻입니다. 브라우저가 캐시를 사용하지 않도록 한 번도 열지 않은 웹 페이지를 새로고침하세요. 그런 다음 클라이언트 코어가 실행 중인지, 시스템 프록시가 올바른 포트를 가리키는지, 운영체제 설정에 이전 클라이언트의 프록시 주소가 남아 있지 않은지 확인하세요.

브라우저가 개인정보 보호 프록시, 확장 프로그램 프록시 또는 기업 관리 정책을 사용하면 시스템 프록시를 우회할 수 있습니다. 명령줄 도구에도 HTTP 프록시와 HTTPS 프록시 변수처럼 별도의 환경 변수가 있는 경우가 많으며, 이러한 설정이 다른 포트를 가리킬 수 있습니다. TUN 모드에서 연결 목록이 비어 있다면 가상 네트워크 카드가 정상적으로 생성되었는지, 라우팅이 적용되었는지, 관리자 권한이 부여되었는지 확인하세요.

로컬 네트워크 기기에서 테스트하는 방식이 잘못되지 않았는지도 확인해야 합니다. Clash가 기본적으로 로컬 주소에서만 수신하도록 설정되어 있으면 다른 기기가 직접 연결할 수 없습니다. 클라이언트에서 LAN 접근을 허용하고, 수신 주소가 LAN 인터페이스를 포함하며, 운영체제 방화벽이 해당 포트를 허용해야 휴대폰이나 다른 컴퓨터가 이 기기를 프록시 서버로 사용할 수 있습니다. LAN 수신을 개방하기 전에 현재 네트워크를 신뢰할 수 있는지 확인하고 접근 범위를 제한하세요.

업데이트 및 유지 관리: 설정 상태가 조금씩 어긋나지 않도록 하기

질문 9: 클라이언트를 업데이트한 뒤 설정을 불러올 수 없으면 어떻게 해야 하나요?

그래픽 클라이언트, 코어, 설정 규격은 서로 같은 버전 개념이 아닙니다. 클라이언트를 업데이트하면서 코어가 함께 바뀔 수도 있고 기존 코어를 계속 사용할 수도 있습니다. 또한 구독 설정에 특정 코어에서만 지원하는 필드가 포함될 수 있습니다. 업데이트 후 불러오기에 실패했다면 먼저 전체 오류 행을 기록하고, 여러 필드를 연속해서 수정하지 마세요.

오류가 알 수 없는 필드나 정책 유형을 가리킨다면 현재 클라이언트가 Clash, Clash Meta, mihomo 중 어떤 코어를 사용하는지, 설정이 해당 코어를 대상으로 생성되었는지 확인하세요. mihomo는 Clash Meta의 기능을 계승하고 확장하지만, 구형 클라이언트에 내장된 코어가 최신 설정 항목을 지원하지 않을 수 있습니다. 오류가 YAML 행 번호를 가리킨다면 해당 행 주변의 들여쓰기, 따옴표, 목록 구조를 점검하세요. 실제 구조 오류는 표시된 행보다 앞에 있을 수도 있습니다.

처리 순서는 일정하게 유지하는 것이 좋습니다. 현재 파일을 백업하고, 정상 작동하는 기본 설정으로 전환한 다음, 코어가 실행되는지 확인하고 구독을 다시 업데이트하세요. 기본 설정은 작동하지만 구독 설정이 실패한다면 구독 내용이나 호환성에 문제가 집중된 것입니다. 모든 설정이 실패한다면 클라이언트 권한, 코어 파일, 수신 포트, 업그레이드 과정을 점검하세요. 이렇게 하면 설정 오류를 설치 오류로 잘못 판단하는 일을 줄일 수 있습니다.

질문 10: Clash가 제대로 작동하는지 어떻게 확인하나요?

웹 페이지 하나만으로 결론을 내리지 마세요. 완전한 검증은 로컬 상태, 프록시 경로, 트래픽 분배 결과의 세 가지 측면을 포함해야 합니다. 먼저 코어가 실행 중이고 설정에 오류가 없으며 정책 그룹에서 노드를 선택했는지 확인하세요. 다음으로 시스템 프록시 또는 TUN이 활성화되어 있는지 확인하고, 웹 페이지를 열었을 때 연결 목록에 새 기록이 나타나는지 살펴보세요. 마지막으로 각 요청이 예상한 규칙과 매칭되는지 확인하세요. 예를 들어 로컬 서비스는 DIRECT로 연결되고 프록시가 필요한 대상은 지정한 정책 그룹으로 들어가야 합니다.

아래 점검표를 따라 항목별로 확인할 수 있습니다.

• 설정 페이지에 최근 업데이트 시간이 표시되고, 수동 업데이트에서 다운로드 또는 파싱 오류가 반환되지 않습니다.
• 프록시 페이지에 사용 가능한 노드가 하나 이상 있고, 현재 정책 그룹이 비어 있거나 사용할 수 없는 노드를 가리키지 않습니다.
• 규칙 모드가 활성화되어 있고, 로그에 도메인·규칙·최종 정책이 표시됩니다.
• 새 웹 페이지를 열 때 연결 수가 변하고, 업로드 및 다운로드 트래픽이 계속 0으로 유지되지 않습니다.
• 시스템 프록시를 끄면 요청 경로가 예상대로 바뀌고, 다시 켜면 정상적으로 복구됩니다.
• 클라이언트를 재시작한 뒤에도 설정이 자동으로 불러와지고, 시스템 프록시 상태가 클라이언트 설정과 일치합니다.

위 항목이 모두 정상이라면 설치, 설정, 노드, 트래픽 진입점이 완전한 연결 경로를 구성한 것입니다. 이후에는 클라이언트를 계속 재설치하기보다 지연 시간, 규칙 세부 조정, DNS 최적화, TUN 호환성 문제를 처리하는 편이 더 효과적입니다.