Clash 초보자를 위한 자주 묻는 질문 10가지: 구독 가져오기 실패·노드 시간 초과·시스템 프록시 오류

Clash 문제를 해결할 때는 먼저 어느 단계에서 문제가 생겼는지 확인하세요. 설정이 제대로 불러와졌는지, 노드에 연결되는지, 앱의 트래픽이 클라이언트로 전달되는지 순서대로 점검하면 모드를 바꾸거나 포트를 수정하고 재설치하는 것보다 원인을 찾기 쉽습니다.

01 / Clash, 클라이언트, mihomo는 어떤 관계인가요?

클라이언트는 조작 화면을 제공하고, 커널은 연결을 처리합니다. 구독 가져오기, 노드 선택, 시스템 프록시 활성화는 보통 클라이언트에서 합니다. 규칙을 읽고 서버에 연결하는 작업은 커널이 담당합니다. Clash Meta 프로젝트는 이후 mihomo로 이름이 바뀌었으므로, 온라인의 오래된 안내에서는 이전 이름을 볼 수 있습니다.

• 클라이언트: 데스크톱 창, 트레이 메뉴 또는 모바일 앱으로, 버튼과 설정의 배치를 결정합니다.
• 커널: 프록시 프로토콜, 규칙 매칭, DNS, 연결을 처리하며 설정 항목의 지원 여부를 결정합니다.
• 설정: 커널이 읽어들이는 옵션으로, 보통 들여쓰기로 계층을 표현하는 YAML 형식을 사용합니다.

‘지원하지 않는 프록시 유형’ 또는 ‘알 수 없는 필드’ 오류가 발생해도 앱 아이콘만 비교하지 마세요. 클라이언트의 ‘정보’ 또는 커널 정보 화면에서 이름과 버전을 확인한 다음, 구독 설정이 해당 커널과 호환되는지 살펴보세요. 이전 Clash와 현재 mihomo가 읽을 수 있는 설정은 완전히 같지 않습니다.

02 / 설치했는데 선택할 노드가 없는 이유는 무엇인가요?

클라이언트를 설치했다고 프록시 설정까지 갖춰지는 것은 아닙니다. 노드는 원격 서버에 연결하기 위한 정보이며, 보통 서비스 제공자가 구독으로 제공합니다. 구독 링크는 설정을 가져오고 업데이트하는 주소이지, 열기만 하면 바로 사용할 수 있는 일반 웹페이지가 아닙니다.

1. 신뢰할 수 있는 출처에서 현재 클라이언트 또는 커널에 맞는 구독 링크를 받으세요. 계정 관리 페이지 주소를 구독 링크로 사용하지 마세요.
2. 클라이언트의 ‘설정’ 페이지에서 원격 설정을 추가하거나 URL에서 가져오기를 선택한 뒤, 링크 전체를 붙여 넣으세요.
3. 가져오기가 완료되면 해당 설정을 선택해 현재 적용 중인 설정으로 지정하세요.
4. ‘프록시’ 페이지에서 규칙이 사용하는 정책 그룹을 펼친 다음 노드를 선택하세요. 정책 그룹은 규칙에서 사용할 수 있는 연결 옵션의 모음입니다.

설정 목록에 이름이 표시된다고 해서 커널이 해당 설정으로 전환된 것은 아닙니다. 프록시 페이지에 직접 연결 옵션만 보인다면 현재 설정이 선택되어 있는지 확인하고, 로그에 설정 불러오기 실패가 기록됐는지도 살펴보세요.

03 / 구독을 가져올 수 없을 때 링크와 네트워크 중 무엇부터 확인해야 하나요?

오류 메시지를 먼저 읽고 점검할 항목을 정하세요. 시간 초과, 권한 오류, 파싱 오류는 각각 원인이 다릅니다. 계속 업데이트 버튼을 눌러도 같은 오류만 반복될 수 있습니다.

세 단계로 원인 좁히기

1. 링크를 다시 복사하고 앞뒤 공백을 제거한 다음, 한글 문장 부호나 줄바꿈이 섞이지 않았는지 확인하세요.
2. 서비스 제공자가 제공하는 형식 옵션을 확인하고 현재 커널에 맞는 Clash 또는 mihomo 설정을 선택하세요.
3. 현재 프록시가 작동하지 않고 구독 업데이트가 프록시를 통해 이루어지도록 설정되어 있다면, 잠시 직접 연결로 업데이트해 보세요. 반대로 직접 연결로 구독 주소에 접속할 수 없다면, 사용할 수 있고 이용이 허용된 네트워크 경로가 필요합니다.

04 / 가져오기는 됐지만 설정 오류가 표시됩니다. 어디를 수정해야 하나요?

가져오기에 성공한 것과 설정을 불러오는 데 성공한 것은 다릅니다. 클라이언트가 파일을 다운로드했더라도 커널이 내용을 파싱하지 못할 수 있습니다. ‘로그’를 열어 이번 설정을 불러올 때 가장 먼저 나타난 오류를 확인하세요. 마지막에 표시된 시작 실패 메시지만 봐서는 안 됩니다.

• 들여쓰기 오류: YAML은 공백으로 계층을 표현하므로 Tab을 사용하지 마세요. 오류가 표시된 줄뿐 아니라 바로 앞 줄도 확인하세요.
• 참조 대상 없음: 규칙에서 참조하는 정책 그룹 이름은 그룹 정의와 정확히 일치해야 합니다. 공백 하나나 글자 하나만 달라도 문제가 생깁니다.
• 커널 비호환: 설정에 현재 커널이 인식하지 못하는 프로토콜이나 필드가 포함된 경우입니다. 오류가 난 줄을 단순히 삭제하지 말고, 호환되는 형식이나 커널을 사용하세요.

아래 두 줄은 규칙에서 그룹 이름을 참조하는 방법만 보여주는 예시이며, 완전한 설정은 아닙니다:

rules:
  - DOMAIN-SUFFIX,example.com,웹 프록시
  - MATCH,DIRECT

여기서 ‘웹 프록시’는 설정의 proxy-groups에 정의되어 있어야 합니다. MATCH는 나머지 트래픽과 일치한다는 뜻입니다. 수정하기 전에 원본 파일을 백업하세요. 원격 구독 설정은 다운로드한 복사본을 직접 수정해도 다음 업데이트 때 덮어써질 수 있습니다. 장기적으로 설정을 조정하려면 클라이언트에서 지원하는 오버라이드 또는 병합 기능을 사용하고, 변경 사항이 실제로 적용됐는지 확인하세요.

05 / 노드 속도 테스트가 모두 시간 초과됩니다. 노드가 전부 고장 난 건가요?

속도 테스트 시간 초과는 테스트 요청이 제한 시간 안에 완료되지 않았다는 뜻입니다. 노드에 연결할 수 없는 경우뿐 아니라 테스트 주소, DNS, 설정 선택에 문제가 있을 수도 있습니다. 표시되는 속도는 보통 지정된 테스트 주소의 응답을 기준으로 하며 다운로드 대역폭을 의미하지는 않습니다.

1. 먼저 기기에서 일반적인 직접 연결 웹사이트에 접속할 수 있는지 확인해 인터넷 연결이 끊겼거나 Wi-Fi 로그인 페이지가 표시되는 상황을 제외하세요.
2. 현재 설정이 정상적으로 불러와졌는지, 구독이 만료되지 않았는지, 사용량을 모두 소진하지 않았는지 확인하세요.
3. 노드를 하나 직접 선택하고 이용이 허용된 웹페이지에 접속한 뒤 연결 내역과 로그를 확인하세요.
4. 실제 접속은 되지만 속도 테스트만 시간 초과된다면 테스트 URL, 제한 시간, 테스트 방식을 확인하세요. 실제 접속도 실패한다면 다른 노드로 바꿔 비교하세요.

지연 시간만으로 판단하지 말고 비교 테스트를 하세요

예를 들어 한 노드가 80ms, 다른 노드가 180ms로 표시되더라도 이번 테스트에서 응답 시간이 달랐다는 의미일 뿐, 앞의 노드가 다운로드 속도도 반드시 더 빠르다는 뜻은 아닙니다. 집의 네트워크에서는 여러 노드가 실패하지만 휴대전화 핫스팟에서는 정상이라면, 클라이언트를 바로 재설치하기보다 먼저 로컬 네트워크 경로를 점검하세요.

로그의 connection refused는 보통 연결이 거부됐다는 뜻이고, timeout은 대기 시간이 제한을 초과했다는 의미입니다. no such host는 도메인 이름 확인 문제일 가능성이 높습니다. 대상과 발생 시간을 기록하면 로컬 연결 지점, 원격 노드, 대상 웹사이트 중 어디에 문제가 있는지 구분할 수 있습니다.

06 / 시스템 프록시를 켰는데 브라우저에 변화가 없는 이유는 무엇인가요?

시스템 프록시는 해당 설정을 따르는 앱에 로컬 프록시 포트로 요청을 보내도록 알리는 기능입니다. 모든 프로그램의 트래픽을 자동으로 가져오지는 않습니다. 먼저 시스템에 입력된 주소가 커널이 실제로 수신 대기 중인 주소와 일치하는지 확인하세요.

1. 클라이언트 설정이나 실행 중인 설정에서 HTTP 포트 또는 혼합 포트를 확인하세요. 혼합 포트는 HTTP와 SOCKS 프록시 요청을 모두 받을 수 있습니다.
2. 이 기기의 혼합 포트가 실제로 7890인 경우, 시스템 프록시는 127.0.0.1:7890을 가리켜야 합니다. 예시의 포트 번호가 모든 클라이언트의 기본값은 아닙니다.
3. Windows 11에서는 ‘설정’ → ‘네트워크 및 인터넷’ → ‘프록시’에서 수동 프록시 설정을 확인하세요. macOS에서는 ‘시스템 설정’ → ‘네트워크’ → 현재 연결 → ‘세부사항’ → ‘프록시’를 확인하세요.
4. 브라우저의 프록시 확장 프로그램, 개별 프록시 설정, 실행 중인 다른 네트워크 도구를 확인해 시스템 설정을 덮어쓰고 있지는 않은지 살펴보세요.

Windows PowerShell에서 아래 명령을 사용하면 로컬 HTTP 프록시 연결 지점을 직접 테스트할 수 있습니다. 먼저 포트를 실제 값으로 바꾸세요:

curl.exe --proxy http://127.0.0.1:7890 --connect-timeout 10 -I https://example.com

이 명령은 프록시를 명시적으로 지정하므로 브라우저가 시스템 프록시를 따르는지에 영향을 받지 않습니다. 테스트 사이트에 요청을 한 번 보낸 결과만 확인합니다. 127.0.0.1에 연결할 수 없다면 먼저 커널이 실행 중인지, 포트가 맞는지 확인하세요. 클라이언트에 요청이 들어왔는데도 접속에 실패하면 규칙과 노드를 점검하세요.

07 / 규칙 모드, 전역 모드, 직접 연결 모드 중 무엇을 선택해야 하나요?

평소에는 규칙 모드를 사용하고, 문제를 확인할 때만 잠시 모드를 전환하세요. 세 모드는 커널에 들어온 요청의 출구를 결정하며, 앱 트래픽이 클라이언트로 들어오는지 여부를 결정하지는 않습니다.

• 규칙 모드: 설정의 규칙을 순서대로 적용해 해당 정책 그룹, 직접 연결 또는 차단으로 트래픽을 보냅니다.
• 전역 모드: 보통 커널에 들어온 요청을 전역 정책에 따라 처리합니다. 전역 그룹에서 노드와 직접 연결 중 무엇을 선택했는지 확인해야 합니다.
• 직접 연결 모드: 커널에 들어온 요청을 직접 연결로 보냅니다. 시스템 프록시가 꺼지거나 커널이 중지되는 것은 아닙니다.

규칙은 일반적으로 위에서 아래 순서로 적용되며, 일치하는 규칙을 찾으면 해당 정책을 사용합니다. 따라서 같은 웹사이트가 규칙 모드에서는 직접 연결되고 전역 모드에서는 노드를 거칠 수 있습니다. 이는 클라이언트 오류가 아니라 규칙 적용 결과가 다른 것일 수 있습니다. ‘연결’에서 대상 도메인, 일치한 규칙, 실제 정책 경로를 확인하는 편이 페이지가 열리는지만 보는 것보다 유용합니다.

08 / TUN 모드는 언제 사용해야 하나요? 켠 뒤 인터넷이 끊기면 어떻게 하나요?

시스템 프록시를 따르지 않는 트래픽을 연결해야 할 때 TUN을 고려하세요. TUN은 시스템 라우팅을 통해 조건에 맞는 트래픽을 커널로 전달하는 가상 네트워크 인터페이스입니다. 관리자 권한이나 클라이언트 서비스 모드가 필요할 수 있으며, 지원 여부는 운영체제와 커널, 설정에 따라 다릅니다.

활성화하기 전에 기본 연결 경로를 확인하세요

1. 먼저 프록시를 명시적으로 지정한 요청이나 브라우저를 사용해 노드 하나 이상이 대상에 정상적으로 접속되는지 확인하세요.
2. 현재 시스템 프록시, DNS, 다른 VPN의 상태를 기록해 여러 항목을 동시에 변경하지 않도록 하세요.
3. 클라이언트가 요구하는 서비스를 설치하거나 네트워크 권한을 허용한 뒤 TUN을 켜세요. 인터페이스가 생성되는지, 라우팅 오류나 권한 오류가 나타나는지 확인하세요.

TUN을 켠 뒤 직접 연결 웹사이트도 열리지 않으면 TUN을 먼저 끄고 기존 네트워크가 복구되는지 확인한 다음 권한, 라우팅 충돌, DNS 설정을 점검하세요. DNS는 도메인 이름을 IP 주소로 변환하는 과정입니다. DNS 설정에 문제가 있으면 연결은 유지되지만 도메인 이름을 확인하지 못할 수 있습니다.

다른 안내에서 본 fake-ip, DNS 가로채기 또는 라우팅 설정을 통째로 현재 설정에 붙여 넣지 마세요. fake-ip는 도메인 매핑에 가상 주소를 사용하는 방식으로, 현재 DNS 및 라우팅 구성에 맞는지 확인해야 합니다. 기업 네트워크, 다른 VPN, 가상 머신 네트워크도 TUN과 충돌할 수 있습니다.

09 / 브라우저는 되는데 게임이나 스토어 앱은 안 되는 이유가 무엇인가요?

먼저 실패하는 앱의 연결이 클라이언트에 표시되는지 확인하세요. 브라우저가 정상 작동한다는 것은 브라우저의 연결 경로를 사용할 수 있다는 뜻일 뿐, 다른 앱도 같은 프록시 방식을 사용한다는 의미는 아닙니다.

• 연결 목록에 요청이 없음: 앱이 시스템 프록시를 무시하거나 자체 프록시 설정을 사용하고 있을 수 있습니다. 앱 설정을 먼저 확인하고, TUN으로 연결하는 것이 적절한지 검토하세요.
• 요청은 표시되지만 직접 연결됨: 일치한 규칙과 정책 그룹을 확인해 예상한 결과인지 살펴보세요. 노드만 바꾸지 마세요.
• 요청이 노드로 전달되지만 실패함: 대상 프로토콜, 서비스 제한, 노드의 전송 방식 지원 여부를 확인하세요. 일부 게임은 UDP를 사용하므로 HTTP 프록시가 작동한다고 UDP 경로도 작동하는 것은 아닙니다.
• 일부 Windows 스토어 앱에서 실패: UWP 네트워크 격리와 관련된 문제일 수 있습니다. UWP는 Windows 앱 플랫폼의 하나입니다. 이런 앱이 로컬 루프백 프록시에 접속하려면 앱별 루프백 예외가 필요할 수 있습니다.

루프백 예외는 특정 앱이 로컬 인터페이스에 접근할 때 발생하는 제한만 처리합니다. 만료된 구독을 복구하거나 지원하지 않는 프로토콜을 사용할 수 있게 해주지는 않습니다. 먼저 앱과 실패 경로를 확인한 뒤 신뢰할 수 있는 클라이언트에서 제공하는 해당 도구를 사용하세요. 테스트를 위해 모든 앱의 제한을 일괄 해제하지 마세요.

10 / 구독 업데이트 또는 클라이언트 종료 후 문제가 생겼을 때 안전하게 복구하는 방법

먼저 작동하던 연결 경로를 복구한 다음 장기적인 해결책을 찾으세요. 구독 업데이트로 노드 이름, 정책 그룹 구성원, 규칙이 바뀔 수 있습니다. 클라이언트를 종료한 뒤에도 시스템에 로컬 포트를 가리키는 프록시 설정이 남아 있을 수 있습니다. 두 문제는 따로 처리해야 합니다.

구독 업데이트 후 연결이 안 됨

1. 현재 어떤 설정이 활성화되어 있는지, 가장 최근 업데이트가 실제로 성공했는지 확인하세요.
2. 정책 그룹에서 선택된 항목을 다시 확인하세요. 직접 선택한 노드의 이름이 바뀌거나 삭제되면 그룹에서 선택된 결과가 달라질 수 있습니다.
3. 설정 불러오기 로그를 확인하세요. 정상 작동하는 로컬 백업을 알고 있다면 잠시 전환해 확인할 수 있습니다. 백업의 노드나 인증 정보도 만료됐을 수 있으니 유의하세요.
4. 복구한 다음 사용자 지정 규칙을 하나씩 옮기세요. 구조가 바뀐 새 설정에 기존 규칙을 그대로 덮어쓰지 마세요.

종료 후 인터넷에 연결할 수 없음

먼저 시스템 프록시가 여전히 127.0.0.1을 가리키는지 확인하세요. 클라이언트가 중지되어 수신 대기하지 않는 상태에서 이 프록시를 계속 사용하면 연결되지 않습니다. 남아 있는 프록시 설정을 끄고, TUN을 사용했다면 인터페이스와 라우팅도 복구됐는지 확인하세요. 이 점검을 대신해 설정 폴더 전체를 삭제하지 마세요.

더 알아보기: 문제에 맞는 문서 선택

처음 설치하고 설정을 가져오는 방법은 사용 설명서를 참고하세요. 설정 항목의 계층, 정책 그룹 참조, 규칙 순서를 확인하려면 YAML 설명서를 살펴보세요. 자주 묻는 사용 방법은 FAQ에서 확인할 수 있습니다. 문제를 해결할 때는 한 번에 한 항목만 바꾸고 변경 전후 결과를 기록하세요.