Clash 초보자 FAQ 10가지: 구독 가져오기, 규칙·전역 모드 차이, 연결됐는데 웹페이지가 열리지 않을 때

1. Clash 클라이언트, 코어, 구독은 각각 무엇인가요?

클라이언트는 조작 화면을 제공하고, 코어는 연결을 처리하며, 구독은 노드나 설정을 제공합니다. 클라이언트를 설치해도 실행 환경만 갖춰진 것이며, 사용할 수 있는 프록시 서비스까지 제공되는 것은 아닙니다. 먼저 이 세 가지를 구분해야 이후 문제를 정확히 파악할 수 있습니다.

GUI 클라이언트: Clash Verge Rev 같은 프로그램으로, 구독 관리, 프록시 그룹 선택, 로그 확인, 시스템 프록시 설정 등을 화면에서 조작할 수 있습니다.
코어: mihomo가 대표적이며 Clash Meta 코어라고도 합니다. 프로토콜 연결, 규칙 매칭, DNS, TUN 등의 실제 처리를 담당합니다.
구독: 이용 권한이 있는 서비스 제공자나 직접 운영하는 설정 서비스에서 받는 주소입니다. 반환되는 내용은 전체 YAML 설정일 수도 있고 노드 목록만 포함할 수도 있습니다.

Clash라는 이름이 붙은 클라이언트라도 지원하는 필드와 프로토콜은 서로 다를 수 있습니다. 설정을 해석하지 못하면 먼저 클라이언트 이름과 버전, 코어 이름과 버전을 확인한 뒤 설정 요구 사항을 살펴보세요. 이름에 Clash가 들어간다는 이유만으로 설정을 서로 바꿔 쓸 수 있다고 단정하면 안 됩니다.

2. 구독은 어디서 받으며, 링크를 다른 사람에게 보내도 되나요?

구독 주소는 이용 권한이 있는 서비스의 관리 페이지나 직접 운영하는 설정 서비스에서 받습니다. Clash 클라이언트는 구독을 제공하지 않습니다. 클라이언트 다운로드 페이지와 구독 관리 페이지도 서로 다른 곳입니다.

서비스 관리 페이지의 구독 메뉴에서 Clash, Clash Meta 또는 mihomo용으로 표시된 설정 항목을 찾으세요.
쿼리 매개변수를 포함해 구독 URL 전체를 복사하세요. 주소에 계정 식별용 토큰이 들어 있을 수 있습니다.
클라이언트에 가져오기 전에 요금제 상태, 만료일, 남은 데이터 용량을 확인하세요.

브라우저에서 구독을 열었을 때 긴 텍스트가 표시되어도 반드시 오류인 것은 아닙니다. 일부 링크는 설정을 그대로 반환합니다. 로그인 페이지나 CAPTCHA 화면, 401 Unauthorized, 403 Forbidden이 표시되면 로컬 포트를 계속 바꾸기보다 권한과 서버 측 제한을 확인하세요.

3. 구독은 어떻게 가져오며, 형식 오류가 표시되는 이유는 무엇인가요?

먼저 구독 형식을 확인한 다음 가져와 활성화하세요. Clash Verge Rev를 예로 들면 사이드바에서 「구독」으로 이동해 구독 링크 입력란에 주소를 붙여 넣고 가져온 다음, 해당 구독을 선택해 현재 설정으로 지정합니다. 버전에 따라 버튼 문구는 다를 수 있지만 ‘설정 다운로드’와 ‘설정 활성화’는 각각 확인해야 합니다.

처음 가져온 뒤 확인할 순서

가져온 뒤 업데이트 시간이나 성공 메시지를 확인하세요. 구독 카드가 생겼는지만 봐서는 안 됩니다.
「프록시」로 이동해 프록시 그룹과 노드 이름이 표시되는지 확인하세요.
사용 가능한 노드를 선택한 뒤 「시스템 프록시」를 켜고 브라우저에서 테스트하세요.
클라이언트에서 설정 오류가 표시되면 로그에서 문제가 된 필드와 줄 번호를 먼저 확인하세요.

전체 Clash YAML에는 보통 proxies, proxy-groups, rules가 포함됩니다. proxy-providers를 사용해 노드를 불러올 수도 있습니다. 단일 ss:// 또는 vmess:// 링크, Base64 인코딩 목록, 전체 설정은 서로 다른 형식입니다. 바로 가져올 수 있는지는 클라이언트의 가져오기 기능에 따라 달라집니다.

yaml: unmarshal errors가 표시되면 먼저 받은 내용이 웹페이지 HTML이 아닌지 확인한 다음 들여쓰기, 필드 유형, 코어 호환성을 살펴보세요. YAML 들여쓰기에는 공백을 사용하고 Tab은 섞지 마세요. 형식 변환이 필요하다면 구독 정보를 낯선 서비스에 제공하지 말고, 서비스 제공자가 지원하는 해당 형식 메뉴를 이용하세요.

4. 규칙 모드, 전역 모드, 직접 연결 모드는 어떻게 선택하나요?

평소에는 규칙 모드를 사용하고, 전역 모드는 목적이 분명한 테스트에만 쓰세요. 모든 문제를 해결하는 만능 스위치는 아닙니다. 모드는 코어에 들어온 연결의 출구를 선택합니다. 애플리케이션의 트래픽이 코어에 들어오는지 여부를 결정하지는 않습니다.

모드	처리 방식	사용 사례
`rule` 규칙	규칙을 위에서부터 차례로 적용해 해당 프록시 그룹으로 보냅니다	평소 트래픽 분기: 직접 연결과 프록시 트래픽을 구분해 처리
`global` 전역	코어에 들어온 연결을 대체로 GLOBAL 프록시 그룹에서 선택	규칙 선택이 문제의 원인인지 잠시 확인할 때
`direct` 직접 연결	코어에 들어온 연결을 프록시 없이 대상에 직접 연결	프록시 연결과 비교 테스트할 때

규칙은 보통 먼저 일치하는 항목이 적용되므로 최종 규칙인 MATCH는 맨 끝에 두어야 합니다. 아래는 규칙 일부일 뿐 단독으로 실행할 수 있는 전체 설정이 아닙니다. PROXY는 전체 설정에서 사용 가능한 프록시 그룹이나 프록시 이름으로 정의해야 합니다.

규칙 예시 · 전체 설정이 아님

mode: rule
rules:
  - DOMAIN-SUFFIX,example.com,DIRECT
  - GEOIP,CN,DIRECT
  - MATCH,PROXY

전역 모드에서는 웹사이트가 열리지만 규칙 모드에서는 열리지 않는다면 해당 연결에 적용된 규칙과 프록시 그룹을 확인하세요. 모든 규칙을 바로 삭제하거나 전역 모드가 “컴퓨터의 모든 프로그램을 프록시로 연결한다”고 생각하면 안 됩니다.

5. 시스템 프록시와 TUN 모드는 어떻게 다른가요?

시스템 프록시는 시스템 프록시 설정을 따르는 앱에 주로 적용됩니다. TUN은 가상 네트워크 인터페이스를 통해 라우팅 조건에 맞는 트래픽을 처리합니다. 초보자라면 먼저 시스템 프록시로 브라우저 연결을 확인한 뒤 TUN이 필요한지 판단하세요.

시스템 프록시: 보통 시스템의 HTTP/HTTPS 프록시를 로컬 수신 포트로 연결합니다. 브라우저는 대체로 이 설정을 따르지만 일부 게임, 명령줄 도구, 자체 네트워크 스택을 사용하는 앱은 따르지 않을 수 있습니다.
TUN: 관련 시스템 권한과 라우팅 설정이 필요하며, 시스템 프록시를 따르지 않는 연결도 더 폭넓게 처리할 수 있습니다. 하지만 TUN을 켠다고 모든 트래픽이 프록시를 거치는 것은 아닙니다.
모바일: Android 클라이언트는 보통 시스템 VPN 인터페이스를 통해 트래픽을 처리합니다. 데스크톱의 「시스템 프록시」와는 작동 방식이 다릅니다.

Clash Verge Rev에서는 먼저 「시스템 프록시」가 켜져 있는지 확인하고, 필요한 경우 「TUN 모드」를 활성화하세요. 서비스 설치나 권한 부여 안내가 표시되면 현재 버전의 요구 사항에 따라 진행하면 됩니다. 다른 VPN, 가상 네트워크 어댑터, 보안 프로그램이 라우팅이나 DNS 충돌을 일으킬 수 있으므로 테스트할 때는 트래픽 처리 방식을 하나씩만 활성화하세요.

TUN은 작동하지 않는 노드를 복구하거나 잘못된 구독을 유효한 설정으로 바꾸지 않습니다. TUN을 켠 뒤 오히려 인터넷이 끊기면 먼저 TUN을 끄고 시스템 프록시로 테스트한 다음 권한, 라우팅, DNS 로그를 확인하세요. 노드 변경, DNS 수정, TUN 활성화를 한꺼번에 하면 무엇이 결과를 바꿨는지 파악하기 어렵습니다.

6. 프록시 그룹은 어떻게 선택하며, 지연 시간이 짧은데도 연결되지 않는 이유는 무엇인가요?

먼저 프록시 그룹에서 실제로 선택된 항목을 확인한 다음 속도 테스트 결과를 살펴보세요. 수동 선택 그룹 select와 자동 속도 테스트 그룹 url-test는 작동 방식이 다릅니다. 전자는 사용자가 출구를 직접 선택하고, 후자는 설정된 테스트에 따라 자동으로 선택합니다.

다음 세 가지 상태를 확인하세요

현재 웹사이트에 적용된 프록시 그룹이 무엇인지, 지금 확인 중인 그룹과 일치하는지 살펴보세요.
해당 그룹에서 최종 선택된 항목이 노드인지, 다른 프록시 그룹인지, 아니면 DIRECT 또는 REJECT인지 확인하세요.
노드 속도 테스트 성공 여부와 실제 웹페이지 연결 성공 여부를 각각 기록하세요.

화면에 80 ms라고 표시되어도 해당 테스트 요청이 응답을 받았다는 뜻일 뿐, 모든 웹사이트에 접속할 수 있거나 다운로드 속도가 빠르다는 뜻은 아닙니다. 테스트 주소, 요청 시간 초과, 노드의 출구, 대상 웹사이트의 제한에 따라 사용 경험이 달라질 수 있습니다. timeout이 발생했다고 노드가 영구적으로 작동하지 않는다고 단정할 수도 없습니다. 로컬 네트워크와 테스트 주소 문제도 확인해야 합니다.

특정 웹사이트만 접속되지 않을 때는 모드를 그대로 두고 노드 하나만 바꿔 비교하세요. 모든 노드에서 실패하면 규칙과 DNS를 살펴보고, 특정 노드에서만 실패하면 우선 해당 노드나 출구를 확인하세요. 클라이언트를 먼저 다시 설치할 필요는 없습니다.

7. 연결됨으로 표시되는데 웹페이지가 열리지 않으면 어디부터 확인해야 하나요?

“코어가 실행 중”이라고 해서 “브라우저 요청이 정상적으로 연결됨”을 뜻하지는 않습니다. 트래픽 유입, 규칙, 노드, DNS 순서로 확인하는 편이 클라이언트를 계속 껐다 켜는 것보다 효과적입니다.

직접 연결과 비교: 시스템 프록시와 TUN을 끄고 일반 네트워크가 작동하는지 확인하세요. 직접 연결도 실패하면 먼저 Wi-Fi, 게이트웨이, 시스템 네트워크 문제를 해결하세요.
트래픽 유입 확인: 시스템 프록시를 다시 켜고 브라우저 하나로 테스트 페이지를 연 다음 「연결」 또는 「로그」를 확인하세요. 새 기록이 없다면 브라우저의 별도 프록시 설정, 프록시 확장 프로그램, 시스템 프록시 포트를 살펴보세요.
출구 확인: 연결 세부 정보에서 적용된 규칙, 프록시 그룹, 최종 노드를 확인하세요. 실수로 REJECT가 적용됐다면 DNS를 바꾸기보다 규칙을 수정해야 합니다.
노드 변경: 테스트 URL은 그대로 두고 노드 하나만 바꿔 결과가 달라지는지 확인하세요.
정확한 오류 확인: connection refused, i/o timeout, 이름 해석 실패가 발생한 대상 주소를 기록하세요. 단순히 “열리지 않음”이라고만 적지 마세요.

브라우저에서 인증서 오류가 표시되면 시스템 날짜, 시간, 시간대를 먼저 확인하세요. 인증서 검증을 끄면 안 됩니다. 회사 네트워크의 HTTPS 검사, 패킷 캡처 도구 인증서, 오류 메시지 해석 문제도 각각 확인해야 합니다. 더 많은 문제 해결 방법은 도움말 센터를 참고하세요.

8. DNS와 Fake-IP는 ‘일부 웹사이트가 열리지 않는’ 문제와 어떤 관련이 있나요?

DNS는 도메인 이름을 어떻게 해석할지 결정하고, 프록시 규칙은 연결이 어떤 경로로 갈지 정합니다. 둘은 서로 영향을 주지만 서로를 대신할 수는 없습니다. mihomo의 fake-ip 모드에서는 도메인에 가상 주소를 할당한 뒤 코어가 해당 연결을 원래 도메인과 연결합니다.

예를 들어 설정에서 198.18.0.1/16을 Fake-IP 주소 풀로 사용한다면 해당 범위의 주소가 표시되어도 반드시 오류는 아닙니다. 반대로 클라이언트를 종료한 뒤에도 프로그램이 캐시된 가상 주소를 사용하거나 트래픽이 처리 경로를 우회하면, DNS 조회는 성공했는데 연결은 실패할 수 있습니다.

로그에서 DNS resolve failed, no such host 등의 메시지를 찾아 문제가 발생한 도메인을 확인하세요.
브라우저의 「보안 DNS」나 앱 자체 DoH 설정을 확인하세요. 예상한 것과 다른 DNS 조회 경로를 사용할 수 있습니다.
다른 VPN, 시스템 암호화 DNS, 로컬 네트워크 DNS 설정의 영향을 확인하고 한 번에 한 가지만 변경하세요.
DNS를 변경한 뒤 앱에서 다시 시도하고, 필요한 경우 해당 캐시를 비우세요. Windows에서는 명령 프롬프트에서 ipconfig /flushdns를 실행할 수 있지만 브라우저 자체 캐시는 남아 있을 수 있습니다.

모든 DNS 문제를 Fake-IP 탓으로 돌리거나 출처를 알 수 없는 DNS 설정 전체를 그대로 복사하지 마세요. 먼저 구독에 설정된 dns 항목과 클라이언트에서 덮어쓴 내용을 확인한 뒤 고급 설정을 참고해 하나씩 조정하세요.

9. 7890, 7897 포트는 무엇이며 충돌이 발생하면 어떻게 해결하나요?

포트는 로컬 서비스에 접속하기 위한 번호이지, 노드 회선 번호가 아닙니다. 설정에 7890이나 7897이 사용될 수 있지만 모든 Clash 클라이언트가 같은 포트를 쓰는 것은 아닙니다. 현재 적용된 설정과 클라이언트에 표시된 값을 기준으로 확인하세요.

로컬 수신 설정 예시 · 전체 설정이 아님

mixed-port: 7890
allow-lan: false

mixed-port는 HTTP와 SOCKS가 함께 사용하는 수신 포트를 제공합니다. 위 예시는 해당 필드의 역할만 보여 주며 노드, 프록시 그룹, 규칙은 포함하지 않습니다. 다른 프로그램이 이미 7890을 사용 중이면 로그에 bind: address already in use가 표시될 수 있습니다. 해당 프로그램을 종료하거나 사용 중이지 않은 포트로 변경하고, 시스템 프록시와 앱의 프록시 설정도 함께 업데이트하세요.

정확한 로컬 프록시 주소로 테스트하세요

실제 HTTP 프록시 수신 주소가 127.0.0.1:7890이라고 가정하면 아래 명령으로 테스트할 수 있습니다. Windows에서는 일부 PowerShell 환경에서 curl이 다른 명령으로 해석되는 일을 피하기 위해 curl.exe를 사용하세요. macOS와 Linux에서는 curl을 사용하면 됩니다.

Windows 프록시 연결 테스트

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

로컬 포트 연결이 바로 실패하면 수신 상태와 포트 값을 먼저 확인하세요. 요청이 로그에 기록된 뒤 시간 초과가 발생한다면 이후 네트워크 경로를 살펴보세요. 로컬 브라우저 문제를 해결하려고 allow-lan: true를 바로 활성화하지 마세요. LAN 공유에는 수신 주소, 방화벽, 접근 제어, 인증을 별도로 설정해야 합니다.

10. 구독을 업데이트하면 수정 내용이 사라지나요? 종료 전에 해야 할 일은 무엇인가요?

구독에서 다운로드한 설정을 직접 수정하면 다음 업데이트 때 변경 내용이 사라질 수 있습니다. 규칙, DNS, 포트 변경을 계속 유지하려면 현재 클라이언트가 지원하는 덮어쓰기, 병합, 스크립트 기능을 사용하고 최종 생성된 설정을 확인하세요.

수정 전: 클라이언트와 코어 버전을 기록하고 로컬 규칙, 덮어쓰기 내용, 필요한 설정을 백업하세요. 백업 파일에도 구독 정보가 포함될 수 있으므로 안전하게 보관해야 합니다.
업데이트 후: 설정이 계속 선택되어 있는지, 프록시 그룹 선택이 유지됐는지, 새 규칙이 실제로 적용되는지 확인하세요. 구독 업데이트 시간만 확인해서는 안 됩니다.
클라이언트 변경 시: 포트, 시스템 프록시, TUN, DNS, 시작 프로그램 설정을 다시 확인하세요. 기존 프로그램의 데이터 폴더 전체를 그대로 복사하지 마세요.
종료할 때: 먼저 시스템 프록시를 끈 다음 정상적으로 종료하세요. TUN을 사용했다면 관련 트래픽 처리가 중지됐는지 확인하세요. 비정상 종료 후 브라우저 연결이 끊겼다면 로컬 주소를 가리키는 프록시 설정이 남아 있는지 살펴보세요.

Windows 11에서는 「설정」→「네트워크 및 인터넷」→「프록시」에서 수동 프록시 설정을 확인할 수 있습니다. macOS에서는 「시스템 설정」→「네트워크」→현재 네트워크 서비스의 「세부사항」→「프록시」를 확인하세요. 종료한 클라이언트가 남긴 설정임을 확인한 경우에만 해당 항목을 끄세요. 회사에서 관리하는 조직 프록시는 함부로 삭제하지 마세요.

처음 설정할 때는 먼저 한 가지 연결 경로만 확인하면 됩니다. 유효한 구독을 가져오고 설정을 활성화한 뒤 노드를 선택하고 시스템 프록시를 켜서 브라우저로 테스트하세요. 안정적으로 작동한 다음 TUN, 사용자 지정 규칙, DNS를 설정하세요. 자세한 방법은 구독 가져오기 및 기본 설정 안내를 참고하고, 필드 설명은 용어집에서 확인하세요.