Clash 초보자 자주 묻는 질문: 구독 가져오기·노드 선택·연결 오류 10가지

Subscription

구독 및 구성 가져오기

1. 구독 링크를 노드처럼 바로 사용할 수 없는 이유는 무엇인가요?

구독 링크는 원격 구성에 접근하기 위한 주소이며, 특정 프록시 노드 자체를 의미하지 않습니다. 클라이언트가 해당 주소에 접속하면 노드 목록, 정책 그룹, 규칙, 규칙 제공자, DNS 등의 구성 정보를 가져옵니다. 가져오기가 완료되면 구성 화면에서 해당 구성을 확인할 수 있어야 하며, 프록시 화면에서는 선택 가능한 정책 그룹과 노드가 표시되어야 합니다.

일반적으로 서비스 제공자가 안내한 Clash 또는 Mihomo 구독 주소를 복사한 뒤, 클라이언트의 구독 또는 구성 화면에 붙여 넣고 다운로드합니다. 일반 웹페이지 주소, 계정 관리 페이지 주소, 다른 클라이언트 전용 구독 형식은 현재 코어에서 해석하지 못할 수 있습니다. 가져온 뒤 형식 오류가 표시되면 포트를 바꾸거나 TUN을 켜기 전에 먼저 링크 유형을 확인하세요.

2. 구독을 가져온 뒤 노드가 보이지 않는 이유는 무엇인가요?

먼저 새 구성이 다운로드되었고 현재 구성으로 지정되었는지 확인하세요. 일부 클라이언트는 여러 구성을 동시에 저장할 수 있으므로, 구독이 성공적으로 추가되었다고 해서 자동으로 해당 구성으로 전환되는 것은 아닙니다. 다음으로 프록시 화면에 정책 그룹 이름만 표시되는지 확인하세요. 노드는 ‘노드 선택’, ‘수동 선택’ 또는 서비스 제공자가 지정한 이름의 정책 그룹 안에 있을 수 있으며, 첫 화면에 바로 표시되지 않을 수 있습니다.

구성이 활성화되었는데도 노드 수가 0이라면 클라이언트 로그나 구성 오류 메시지를 확인하세요. 흔한 원인으로는 만료된 구독, 일시적으로 접근할 수 없는 원격 서버, 빈 응답, 코어와 호환되지 않는 구독 형식, YAML 들여쓰기 또는 필드 구조 오류가 있습니다. 수동 구성은 최소한 노드, 정책 그룹, 규칙 사이에 유효한 참조 관계를 만들어야 합니다. 예를 들어 정책 그룹이 참조하는 노드 이름은 노드 정의와 완전히 일치해야 합니다:

proxies:
  - name: "예시 노드"
    type: socks5
    server: 127.0.0.1
    port: 1080

proxy-groups:
  - name: "노드 선택"
    type: select
    proxies:
      - "예시 노드"
      - DIRECT

rules:
  - MATCH,노드 선택

이 내용은 참조 구조를 설명하기 위한 예시일 뿐, 외부 네트워크에 바로 연결할 수 있는 완전한 구성은 아닙니다. 실제 노드 매개변수는 신뢰할 수 있는 구성 출처에서 가져와야 합니다.

3. 구독을 업데이트하면 기존에 선택한 항목이 덮어써지나요?

구독을 업데이트하면 일반적으로 원격 구성을 다시 가져옵니다. 노드 추가·삭제, 정책 그룹 구조, 규칙과 DNS 설정의 변경 여부는 서버에서 반환하는 새 내용에 따라 달라집니다. 정책 그룹 선택을 기억하는 방식은 클라이언트마다 다릅니다. 정책 그룹 이름과 노드 이름이 그대로라면 이전 선택이 유지될 수 있지만, 노드가 삭제되거나 이름이 바뀌면 다시 선택해야 합니다.

구독에서 다운로드한 YAML을 직접 편집할 때도 주의해야 합니다. 다음 업데이트에서 원격 버전이 로컬 내용을 덮어써 수동 수정 사항이 사라질 수 있습니다. 사용자 지정 규칙을 장기간 관리해야 한다면 클라이언트가 지원하는 오버라이드, 구성 병합 또는 스크립트 기능을 사용하고 별도의 백업을 보관하는 편이 좋습니다. 업데이트 후에는 현재 구성, 주요 정책 그룹과 규칙 모드를 확인해야 하며, ‘업데이트 성공’ 메시지만으로 연결 상태를 판단해서는 안 됩니다.

Selection

노드·정책 그룹·프록시 모드

4. 지연 시간이 가장 짧은 노드가 실제 속도도 항상 가장 빠른가요?

지연 시간 테스트는 클라이언트와 테스트 대상 사이에서 한 번 또는 여러 번 이루어진 짧은 연결의 소요 시간만 보여 줄 뿐, 지속적인 다운로드, 동영상 재생 또는 해외 서비스 접속 성능을 완전히 나타내지는 않습니다. 노드 속도는 회선 혼잡, 출구 대역폭, 패킷 손실률, 대상 웹사이트의 위치, 전송 프로토콜, 로컬 네트워크 품질의 영향도 받습니다. 지연 시간이 조금 더 길더라도 패킷 손실이 적은 노드가 지연 시간은 짧지만 혼잡한 노드보다 실제 사용에서 안정적일 수 있습니다.

노드를 선택할 때는 먼저 지연 시간을 측정한 다음 실제 대상에 접속해 확인하세요. 웹페이지는 첫 응답과 연속해서 안정적으로 열리는지를 보고, 동영상은 일정 시간 동안 버퍼링이 계속되는지를 확인하며, 다운로드는 순간 최고 속도보다 안정적인 전송 속도를 봐야 합니다. 여러 노드가 모두 시간 초과라면 먼저 구독, 네트워크와 코어 상태를 점검하세요. 하나의 노드만 시간 초과라면 해당 노드가 일시적으로 사용할 수 없는 상태일 가능성이 큽니다.

5. 규칙·전역·직접 연결 모드 중 무엇을 선택해야 하나요?

규칙 모드는 구성에 정의된 규칙을 위에서부터 순서대로 적용합니다. 도메인, IP, 프로세스 또는 규칙 집합이 일치하면 연결은 지정된 정책 그룹, DIRECT 또는 REJECT로 전달됩니다. 일상적인 사용에 적합하며, 로컬 서비스와 자주 사용하는 한국 국내 사이트는 직접 연결하고 특정 대상만 프록시를 사용하도록 나눌 수 있습니다.

전역 모드는 일반적으로 코어로 들어온 연결을 모두 전역 정책 그룹에 전달합니다. 프록시 노드가 작동하는지 짧게 확인하거나 규칙에 포함되지 않은 대상을 비교 테스트할 때 유용합니다. 전역 모드라고 해서 모든 기기와 모든 프로세스가 자동으로 Clash를 거치는 것은 아닙니다. 실제로 트래픽을 가로챌지는 시스템 프록시, TUN 또는 애플리케이션 자체의 프록시 설정에 따라 달라집니다.

직접 연결 모드는 가로챈 트래픽을 프록시 노드 없이 대상에 직접 연결합니다. 문제가 프록시 경로와 관련 있는지 판단할 때 사용할 수 있습니다. 일상적인 사용은 규칙 모드로 시작하고, 진단이 필요할 때만 전역 또는 직접 연결 모드로 잠시 전환해 비교하는 것을 권장합니다.

6. 노드를 선택했는데도 트래픽이 프록시를 거치지 않는 이유는 무엇인가요?

노드를 선택하는 것은 특정 정책 그룹의 출구를 정할 뿐이며, 애플리케이션 트래픽이 자동으로 Clash에 들어가게 하지는 않습니다. 시스템 프록시를 켜거나, TUN 모드를 활성화하거나, 특정 애플리케이션에 Clash의 HTTP 또는 SOCKS 리스닝 주소를 직접 입력하는 등 최소 한 가지 트래픽 가로채기 방식이 필요합니다.

또한 규칙이 실제로 방금 조작한 정책 그룹을 사용하는지 확인해야 합니다. 구성에는 ‘노드 선택’, ‘자동 선택’, ‘미디어 서비스’, ‘기타 트래픽’ 등 여러 그룹이 동시에 존재할 수 있습니다. ‘노드 선택’에서 노드를 바꿔도 특정 규칙이 다른 정책 그룹을 가리킬 수 있습니다. 이 경우 연결 기록이나 로그를 열어 대상 도메인에 적용된 규칙, 정책 그룹과 최종 노드를 확인하세요.

Traffic Capture

시스템 프록시 및 TUN 모드

7. 시스템 프록시를 켰는데도 일부 애플리케이션이 직접 연결되는 이유는 무엇인가요?

시스템 프록시는 주로 운영체제의 프록시 설정을 읽는 애플리케이션에 영향을 줍니다. 대부분의 브라우저와 일부 데스크톱 프로그램이 여기에 해당합니다. 일부 게임, 명령줄 도구, 독립 업데이트 프로그램 또는 자체 네트워크 스택을 사용하는 프로그램은 시스템 프록시를 무시할 수 있으므로 Clash를 거치지 않습니다. 애플리케이션 자체 설정에서 ‘직접 연결’이나 별도의 프록시를 지정해 시스템 설정을 덮어쓸 수도 있습니다.

먼저 브라우저로 대상에 접속하면서 연결 기록을 확인하세요. 브라우저 트래픽은 기록되는데 특정 애플리케이션에는 아무 기록도 없다면, 해당 애플리케이션이 시스템 프록시를 따르는지 여부가 원인일 가능성이 큽니다. 애플리케이션 자체의 프록시 옵션을 확인하거나, 필요한 경우 TUN 모드를 사용할 수 있습니다. 모든 애플리케이션에 기록이 없다면 클라이언트 코어가 실행 중인지, 시스템 프록시가 정상적으로 적용되었는지, 리스닝 포트를 다른 프로그램이 사용 중인지 점검하세요.

8. TUN 모드는 언제 켜야 하나요?

TUN 모드는 가상 네트워크 인터페이스를 통해 더 넓은 범위의 IP 트래픽을 가로챕니다. 시스템 프록시를 읽지 않는 프로그램에 적합하며, 애플리케이션마다 프록시를 설정해야 하는 번거로움도 줄여 줍니다. 하지만 설치 직후 반드시 켜야 하는 기능은 아닙니다. 브라우저와 자주 사용하는 프로그램이 시스템 프록시로 정상 작동한다면, 이해와 문제 해결이 더 쉬운 간단한 시스템 프록시 방식을 유지하는 편이 좋습니다.

TUN을 활성화하려면 시스템 권한이 필요한 경우가 많으며, 다른 VPN, 가상 네트워크 어댑터, 보안 프로그램 또는 기업용 네트워크 클라이언트와 라우팅 충돌이 발생할 수 있습니다. 인터넷에 연결되지 않으면 TUN이 정상적으로 시작되었는지, 기본 경로가 올바른지, DNS를 사용할 수 있는지, 시스템에서 다른 네트워크 가로채기 도구가 동시에 실행 중인지 확인하세요. 다른 네트워크 가로채기 프로그램을 종료한 뒤 다시 테스트하면 충돌 원인을 찾는 데 도움이 됩니다.

TUN은 트래픽을 코어로 보내는 역할을 하며, 최종적으로 프록시를 사용할지는 현재 모드와 규칙이 결정합니다. 따라서 TUN을 켠 뒤 일부 연결이 DIRECT로 표시되더라도 반드시 오류인 것은 아닙니다. 해당 연결이 직접 연결 규칙과 일치했을 수 있습니다. 진단할 때는 TUN 스위치 상태만 보지 말고 연결 상세 정보의 규칙 이름과 최종 경로를 함께 확인하세요.

Troubleshooting

연결 오류 기본 점검

9. 노드 테스트는 정상인데 웹페이지가 열리지 않으면 무엇을 확인해야 하나요?

노드 지연 시간 측정에 성공했다는 것은 특정 테스트 요청이 응답을 받았다는 뜻일 뿐, 대상 웹페이지의 전체 접속 경로가 정상이라는 의미는 아닙니다. 다음 순서로 확인해 보세요:

1. 트래픽이 코어로 들어가는지 확인하세요. 연결 화면이나 실시간 로그를 열고 대상 웹사이트에 접속합니다. 새 기록이 없다면 시스템 프록시, TUN 또는 애플리케이션 프록시 설정을 먼저 확인하세요.
2. 적용된 규칙 결과를 확인하세요. 대상 도메인이 최종적으로 DIRECT, PROXY 또는 REJECT 중 어디로 처리되었는지 확인하고, 해당 정책 그룹에 사용 가능한 노드가 선택되어 있는지 점검하세요.
3. 노드를 바꿔 비교하세요. 같은 정책 그룹 안의 노드만 변경하고 DNS, 모드와 구성은 동시에 바꾸지 마세요. 다른 노드가 정상이라면 원래 노드 또는 해당 출구 회선을 우선 의심할 수 있습니다.
4. 규칙 모드와 전역 모드를 비교하세요. 전역 모드는 정상인데 규칙 모드에서만 문제가 발생한다면 규칙 매칭, 정책 그룹 참조 또는 규칙 집합 업데이트를 점검해야 할 가능성이 큽니다.
5. DNS를 확인하세요. 도메인 확인 실패, 잘못된 주소 반환 또는 프록시 규칙과 맞지 않는 DNS 경로가 모두 웹페이지 접속 실패로 나타날 수 있습니다. 도메인 접속과 알고 있는 IP 접속의 차이를 비교할 수 있지만, 임시 IP를 장기적인 해결책으로 사용해서는 안 됩니다.
6. 대상 서비스 상태를 확인하세요. 한 웹사이트에서만 문제가 발생한다면 대상 사이트의 점검, 지역 제한, 계정 상태 또는 대상 서비스가 출구 IP를 거부하는 상황일 수도 있습니다.

로그에 시간 초과가 표시되면 프록시 서버 연결 시간 초과인지, DNS 조회 시간 초과인지, 프록시 서버에서 대상에 연결하는 과정의 시간 초과인지 구분해야 합니다. 세 경우는 서로 다른 단계에서 발생하므로 해결 방향도 다릅니다. 브라우저에 마지막으로 표시된 오류 페이지만으로는 원인을 판단하기 어려운 경우가 많습니다.

10. 재부팅 후 연결되지 않을 때 빠르게 복구하려면 어떻게 해야 하나요?

먼저 창이 열려 있는지만 확인하지 말고 클라이언트 코어가 실행 중인지 점검하세요. 그런 다음 현재 구성이 남아 있고 활성화되어 있는지, 구독이 빈 구성으로 바뀌지 않았는지, 주요 정책 그룹에 사용 가능한 노드가 있는지 확인합니다. 시스템을 재부팅하면 시스템 프록시가 자동으로 다시 켜지지 않을 수 있습니다. TUN을 사용한다면 권한 요청, 서비스 구성 요소와 가상 네트워크 어댑터 상태도 정상인지 확인해야 합니다.

‘변수 최소화’ 방식으로 복구할 수 있습니다. TUN을 잠시 끄고 시스템 프록시만 활성화한 뒤, 최근에 정상 작동을 확인한 구성 하나를 선택하세요. 규칙 모드를 사용하고 주요 정책 그룹에서 사용 가능한 노드 하나를 수동으로 선택한 다음, 브라우저로 테스트하면서 연결 기록을 확인합니다. 이 조합이 정상적으로 작동한 뒤 자동 선택, TUN, 사용자 지정 DNS 또는 오버라이드 구성을 하나씩 다시 적용하세요.

클라이언트가 코어를 시작하지 못한다면 오류 로그에서 포트 사용 중, 구성 해석 실패 또는 권한 부족 메시지가 있는지 확인하세요. 포트가 사용 중일 때는 여러 리스닝 포트를 무작정 반복해서 바꾸지 말고, 다른 프록시 프로그램을 종료한 뒤 다시 시작해 보세요. 구성 해석에 실패했다면 정상적으로 작동하는 구성으로 전환하거나 최근 오버라이드 수정을 취소하세요. 권한 문제는 운영체제 안내에 따라 TUN 서비스 또는 네트워크 확장 기능의 권한을 허용해야 합니다.

Checklist

첫 사용 점검 목록

설치와 구독 가져오기를 완료한 뒤 아래 순서대로 확인하세요. 앞 단계가 통과되지 않았다면 복잡한 DNS나 라우팅 설정으로 바로 넘어가지 마세요:

1. 클라이언트 코어가 실행 중이며 구성 해석 오류가 없습니다.
2. 구독이 다운로드되었고 해당 구성이 현재 구성으로 지정되어 있습니다.
3. 프록시 화면에 정책 그룹이 표시되고, 정책 그룹 안에 노드가 있습니다.
4. 지연 시간 테스트 또는 실제 연결을 완료할 수 있는 노드를 하나 이상 선택합니다.
5. 일상적인 사용은 먼저 규칙 모드로 설정하고 주요 정책 그룹의 선택을 확인합니다.
6. 시스템 프록시를 켜고 브라우저로 첫 연결 테스트를 진행합니다.
7. 연결 기록에서 대상 도메인, 적용된 규칙과 최종 출구를 확인합니다.
8. 애플리케이션이 시스템 프록시를 무시할 때만 TUN 활성화를 검토합니다.
9. 구독을 업데이트한 뒤 정책 그룹을 다시 확인하여 노드 이름 변경으로 선택이 무효화되지 않았는지 점검합니다.
10. 문제가 발생하면 주요 로그를 저장하고 트래픽 가로채기, 규칙, 노드, DNS, 대상 서비스 순서로 원인을 찾습니다.

이러한 계층을 이해하면 ‘노드는 선택했지만 효과가 없음’, ‘브라우저는 정상인데 게임은 연결되지 않음’, ‘전역 모드는 되지만 규칙 모드는 실패함’과 같은 문제를 검증 가능한 단계로 나눌 수 있습니다. Clash의 핵심은 하나의 스위치가 아니라 구성 출처, 트래픽 진입점, 규칙 매칭과 출구 노드로 이어지는 처리 체인입니다. 연결 기록을 관찰하며 각 계층을 차례로 확인하는 것이 클라이언트를 반복해서 재설치하는 것보다 실제 원인을 찾기 쉽습니다.