Clash 초보자 FAQ 10가지: 구독 가져오기·프록시 모드·시스템 프록시 설정

1. Clash, 클라이언트, mihomo는 각각 무엇인가요?

먼저 세 가지를 구분해 보세요. 클라이언트는 조작 화면을 제공하고, 코어는 네트워크 연결을 처리하며, 구독은 노드나 설정을 제공합니다. 클라이언트를 설치했다고 바로 사용할 수 있는 프록시 노드가 생기는 것은 아닙니다. 구독을 가져온 뒤에도 설정을 활성화하고 정책을 선택한 다음 앱 트래픽을 연결해야 합니다.

기존 Clash 코어와 mihomo는 현재 함께 업데이트되는 동일 프로젝트가 아닙니다. mihomo는 Clash Meta에서 발전한 프로젝트로, Clash의 설정 방식 상당수를 유지하면서 지원 프로토콜과 설정 기능을 확장했습니다. 구형 코어는 mihomo용으로 작성된 설정을 읽지 못할 수 있으며, 파일 확장자가 모두 .yaml이라고 해서 호환되는 것은 아닙니다.

클라이언트 선택: 운영체제와 프로세서 아키텍처에 맞는 설치 파일을 고르고, 클라이언트 비교에서 코어 종류를 확인하세요.
설정 확인: 서비스 제공자에게 Clash 형식과 Clash Meta／mihomo 형식 중 어떤 설정을 사용해야 하는지 확인하세요.
오류 확인: “지원하지 않는 프록시 유형” 오류가 발생하면 같은 구독을 반복해서 다운로드하기보다 먼저 코어의 지원 기능을 확인하세요.

클라이언트마다 설정 메뉴 구성이 다릅니다. 아래에서는 공통 기능을 “구독”, “시스템 프록시”, “연결 기록”이라고 부르며, 운영체제별 절차는 경로를 명시합니다. 예시 포트는 7890입니다. 실제 사용 시에는 클라이언트에 표시된 현재 수신 대기 포트를 확인하세요.

2. 구독 링크는 어디에 입력하며, 가져오기는 어떻게 확인하나요?

구독 링크는 클라이언트의 원격 구독 가져오기 메뉴에 입력해야 합니다. 브라우저의 프록시 서버 주소란이나 노드 서버 주소 입력란에 넣는 것이 아닙니다. 원격 구독은 보통 YAML 설정을 반환하지만, 서비스에 따라 여러 출력 형식을 제공하므로 해당 클라이언트에 맞는 형식의 링크를 복사하세요.

서비스 제공자의 구독 페이지에서 링크 전체를 복사하세요. 쿼리 매개변수를 유지하고, 복사할 때 공백이나 줄바꿈이 섞이지 않도록 주의하세요.
클라이언트의 구독 관리 화면을 열고 원격 가져오기 기능으로 링크를 입력한 다음 다운로드하세요.
다운로드가 끝나면 해당 설정을 선택하거나 활성화하세요. 목록에 설정 카드가 나타나더라도 코어가 실제로 그 설정을 사용하고 있다는 뜻은 아닙니다.
프록시 또는 정책 그룹 화면에서 노드와 그룹이 표시되는지 확인하고, 로그에 설정 로드 오류가 있는지도 살펴보세요.

로컬 YAML 파일만 있다면 로컬 설정 가져오기 메뉴를 사용하세요. 가져온 뒤 노드가 보이지 않으면 다운로드한 내용이 로그인 페이지나 오류 메시지, 빈 파일은 아닌지 먼저 확인하세요. 브라우저에서 열리는 URL이라고 해서 모두 구독 링크인 것은 아닙니다.

3. Rule, Global, Direct 중 무엇을 선택해야 하나요?

일상적인 사용에는 보통 Rule을 선택합니다. 규칙에 따라 각 연결을 직접 연결하거나 프록시 그룹 등으로 보냅니다. Global은 프록시 연결 경로를 임시로 확인할 때 사용하고, Direct는 코어에 들어온 연결을 직접 연결합니다. 모드는 코어에 들어온 트래픽의 처리 방식만 정하며, 모든 앱의 트래픽을 자동으로 가져오지는 않습니다.

모드	처리 방식	사용 사례
Rule	rules를 위에서 아래로 확인하고, 처음 일치하는 규칙의 정책을 적용	도메인, IP 등의 조건에 따라 일상적인 트래픽 분기
Global	코어에 들어온 연결을 GLOBAL 정책 선택으로 전달	규칙이 접속에 영향을 주는지 임시로 확인
Direct	코어에 들어온 연결을 대상에 직접 연결	직접 연결 결과 비교 및 프록시 경로 점검

Global로 전환한 뒤에도 GLOBAL에서 어떤 항목을 선택했는지 확인해야 합니다. 다른 정책 그룹이나 DIRECT가 선택되어 있을 수 있으므로, 모드를 바꾼다고 반드시 원격 노드를 사용하게 되는 것은 아닙니다. 점검이 끝나면 Rule로 되돌려 원래 직접 연결되어야 할 트래픽이 계속 원격으로 전송되지 않도록 하세요.

아래는 규칙 일부이며 독립적으로 사용할 수 있는 설정이 아닙니다. Proxy는 예시 정책 그룹 이름입니다. 현재 설정에 실제로 존재하는 그룹 이름으로 바꾸거나 그룹을 먼저 정의해야 합니다.

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

MATCH는 기본 규칙이므로 보통 마지막에 둡니다. 앞쪽에 배치하면 이후 규칙은 일치 여부를 확인할 기회가 없습니다. GEOIP 규칙은 관련 지리 데이터 파일도 필요하므로 YAML 문법이 올바른지만 확인해서는 안 됩니다.

4. 시스템 프록시를 켰는데 앱이 프록시를 사용하지 않는 이유는 무엇인가요?

시스템 프록시는 시스템 프록시 설정을 따르는 앱에 연결 경로를 제공할 뿐, 모든 트래픽을 강제로 전달하지는 않습니다. 브라우저 자체 프록시 설정을 사용하는 경우도 있고, 일부 명령줄 프로그램은 환경 변수만 읽습니다. 게임이나 다른 앱은 연결을 직접 만들 수도 있습니다.

수신 대기 상태를 확인한 다음 시스템 설정을 점검하세요

코어가 실행 중인지 확인하고 HTTP 또는 mixed-port를 찾으세요. mixed-port는 하나의 포트에서 HTTP와 SOCKS 프록시 연결을 모두 받을 수 있습니다.
이 기기에서 실행되는 앱은 127.0.0.1과 실제 포트에 연결해야 합니다. 구독 도메인을 시스템 프록시 서버로 입력하지 마세요.
Windows 11에서는 「설정」→「네트워크 및 인터넷」→「프록시」→「수동 프록시 설정」에서 주소와 포트를 확인할 수 있습니다.
macOS에서는 「시스템 설정」→「네트워크」→ 현재 네트워크 서비스 →「세부사항」→「프록시」에서 HTTP 및 HTTPS 프록시 설정을 확인할 수 있습니다.

아래 명령처럼 프록시를 직접 지정하면 프로그램이 시스템 설정을 읽는지 여부와 관계없이 테스트할 수 있습니다. Windows PowerShell에서는 이전 환경의 동명 별칭과 충돌하지 않도록 curl.exe를 사용하세요. 다른 시스템에서는 보통 curl을 사용합니다.

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

로그에 127.0.0.1:7890에 연결할 수 없다고 표시되면 포트와 코어 프로세스를 먼저 확인하세요. 프록시 연결은 성립했지만 대상 요청이 실패한다면 노드, 규칙, DNS를 점검하세요. 웹 응답이 정상적으로 반환됐다는 사실만으로 최종 연결이 원격 노드를 사용했다고 단정할 수는 없습니다.

5. 시스템 프록시와 TUN 모드를 함께 켜야 하나요?

“더 완벽하게” 사용하려고 처음부터 둘 다 켤 필요는 없습니다. 시스템 프록시는 브라우저처럼 프록시 설정을 따르는 프로그램에 적합합니다. TUN은 가상 네트워크 인터페이스와 라우팅을 통해 트래픽을 연결하므로 시스템 프록시를 따르지 않는 앱에 유용하지만, 권한과 라우팅, DNS 등을 추가로 설정해야 합니다.

브라우저부터 확인: 먼저 시스템 프록시로 설정, 노드, 규칙이 정상인지 확인한 뒤 TUN이 필요한지 판단하세요.
프록시를 사용하지 않는 앱: 클라이언트가 TUN을 지원하는지 확인하고 안내에 따라 서비스를 설치하거나 필요한 권한을 부여하세요.
다른 VPN이 실행 중인 경우: 라우팅을 제어하는 다른 소프트웨어를 먼저 일시 중지하고 따로 테스트하세요. 기본 경로와 DNS 설정이 서로 간섭하는 일을 방지할 수 있습니다.

mihomo의 tun.enable은 TUN을 켜고 끄며, auto-route는 자동 라우팅과 관련되고, dns-hijack은 일치하는 DNS 트래픽을 가로채는 데 사용됩니다. 이 필드가 있다고 해서 “켜기만 하면 모든 트래픽을 반드시 처리한다”는 뜻은 아닙니다. 플랫폼, 권한, 제외 경로, 앱 자체의 암호화 DNS가 결과에 영향을 줍니다.

6. 노드에 지연 시간이 표시되는데 웹페이지가 열리지 않는 이유는 무엇인가요?

지연 시간 테스트는 보통 클라이언트가 노드를 통해 테스트 URL에 요청을 보내는 데 걸린 시간입니다. ICMP ping과는 다르며 모든 대상 사이트에 접속할 수 있다는 의미도 아닙니다. 테스트 주소에 접속할 수 있다고 해서 동영상, 로그인, 특정 지역 서비스까지 반드시 이용할 수 있는 것은 아닙니다.

연결 경로를 따라 하나씩 확인하세요

정책 선택 확인: 현재 어떤 그룹이 일치했나요? 수동 선택 그룹, 자동 지연 시간 측정 그룹, 장애 조치 그룹은 노드를 선택하는 방식이 서로 다릅니다.
새 요청 확인: 노드를 바꾼 뒤 다시 연결하세요. 기존 TCP 연결은 이전 경로를 계속 사용할 수 있고, 페이지 캐시도 판단을 방해할 수 있습니다.
대상별 차이 확인: 일반 HTTPS 페이지와 실제로 문제가 발생한 페이지를 각각 테스트해 노드 전체의 문제인지 대상 서비스의 제한인지 구분하세요.
로그 단계 확인: 도메인 해석 실패, 노드 연결 시간 초과, 대상 TLS 연결 실패는 서로 다른 문제입니다. 모두 “노드가 느리다”는 원인으로 돌리면 안 됩니다.

특정 사이트만 실패한다면 해당 요청에 실제로 적용된 규칙을 확인하세요. Rule 모드에서는 DIRECT로 분기되거나 다른 정책 그룹으로 들어갔을 수 있습니다. 노드 목록에서 현재 선택된 항목만 보지 말고, 해당 요청의 연결 기록을 확인하세요.

7. 구독 업데이트에 실패하면 먼저 DNS를 바꿔야 하나요?

오류 내용을 확인한 뒤 조치할 항목을 결정하세요. 업데이트는 도메인 해석, TCP 연결, TLS 핸드셰이크, HTTP 응답 또는 YAML 파싱 단계에서 실패할 수 있습니다. DNS 관련 오류만 DNS 문제를 직접 가리키며, 상태 코드 오류나 설정 문법 오류는 DNS를 바꿔도 해결되지 않습니다.

오류 증상	우선 확인할 항목
HTTP 401／403	구독 토큰, 계정 상태, 서비스 제공자의 접근 제한
HTTP 404	링크 전체가 복사됐는지, 구독 경로가 변경됐는지
구독 도메인 해석 실패	기기의 DNS 해석 상태와 업데이트 요청이 사용하는 네트워크 경로
연결 시간 초과	현재 네트워크, 구독 사이트 접속 가능 여부, 클라이언트의 업데이트 프록시 설정
YAML 파싱 실패	응답 내용, 들여쓰기, 형식 호환성, 코어 지원 여부

일부 클라이언트는 구독 업데이트에 프록시를 사용할지 선택할 수 있고, 다른 클라이언트는 별도의 다운로드 방식을 사용합니다. 웹페이지가 열린다고 업데이트 도구도 같은 경로를 사용한다는 뜻은 아닙니다. 클라이언트 설명에서 다운로드 방식을 확인하고, 시스템 프록시를 켜면 모든 백그라운드 업데이트에 적용된다고 가정하지 마세요.

업데이트를 시도하기 전에 마지막으로 정상 작동한 설정을 보관하세요. 구독에 접속할 수 없다고 유일하게 사용할 수 있는 설정을 먼저 삭제하지 말고, TLS 오류를 없애려고 인증서 검증을 끄지도 마세요. 인증서 시간 오류가 발생하면 시스템 날짜와 시간대, 네트워크 환경부터 확인하세요.

8. DNS, Fake-IP, ‘DNS 유출’은 어떻게 이해해야 하나요?

DNS는 도메인을 IP 주소로 변환합니다. mihomo의 Fake-IP 모드는 도메인에 매핑 주소를 할당한 뒤 내부 매핑 정보를 이용해 후속 연결을 처리합니다. 일반적인 설정에서는 198.18.0.0/16을 사용합니다. 이런 주소가 보인다고 해서 노드 장애나 도메인 해석 오류라고 단정하지 마세요.

DNS 유출은 DNS 조회가 예상하지 않은 경로를 통과하는지 확인하는 개념입니다. 검사 페이지에 표시된 DNS 리졸버의 위치가 브라우저 프록시 노드의 위치와 같다는 보장은 없습니다. 원격 DNS 서비스, 캐시, 서비스 제공자의 네트워크 출구에 따라 표시 결과가 달라집니다. 지역 표시 하나만으로 유출 여부나 보안 상태를 완전히 판단할 수는 없습니다.

먼저 시스템 DNS 요청이 코어로 들어가는지 확인한 다음 코어에서 사용하는 nameserver와 도메인별 nameserver-policy를 살펴보세요.
브라우저의 보안 DNS／DoH는 별도의 연결을 사용할 수 있습니다. 시스템 DNS만 바꾸지 말고 실제 라우팅 경로를 함께 확인하세요.
일부 로컬 네트워크 서비스나 앱은 Fake-IP에 적합하지 않을 수 있습니다. 필요한 경우 fake-ip-filter를 설정하되, 모든 도메인을 무작정 제외하지 마세요.

초보자는 먼저 출처가 명확하고 현재 코어와 호환되는 DNS 설정을 사용한 뒤, 구체적인 문제가 있을 때 수정하는 것이 좋습니다. DNS 필드는 서로 연관되어 있으므로 여러 가이드의 설정을 무작정 조합하면 상위 DNS 해석이 순환할 수 있습니다. 필드 설명은 고급 설정과 mihomo DNS 문서에서 확인하세요.

9. 특정 사이트에 실제로 어떤 규칙이 적용되는지 확인하려면 어떻게 하나요?

클라이언트의 연결 화면에서 대상 요청을 찾아 도메인, 적용된 규칙, 정책 경로를 확인하세요. 화면 이름은 클라이언트마다 다르지만 핵심은 “한 번의 요청”과 “한 가지 라우팅 결과”를 연결하는 것입니다. 외부 IP 확인 사이트만으로 모든 앱의 경로를 추측하지 마세요.

관련 없는 다운로드를 일시 중지해 백그라운드 연결로 인한 혼선을 줄이세요.
연결 기록을 연 다음 브라우저에서 대상 페이지를 다시 방문하세요.
도메인이나 프로세스로 필터링해 대상 연결에 적용된 규칙과 최종 정책을 확인하세요.
규칙을 수정한 뒤 설정을 다시 불러오고 새 연결로 테스트하세요.

도메인 규칙을 임시로 추가해야 한다면 먼저 일치할 수 있는 포괄적인 규칙보다 앞에 배치하세요. 아래 예시는 example.com과 하위 도메인을 직접 연결하는 문법 설명일 뿐입니다. 전체 설정이 아니며 관련 없는 도메인에는 영향을 주지 않습니다.

rules:
  - DOMAIN-SUFFIX,example.com,DIRECT
  - MATCH,Proxy

Proxy는 실제로 존재하는 정책 그룹 이름이어야 합니다. 원격 구독을 업데이트하면 직접 편집한 내용이 덮어써질 수 있습니다. 사용자 설정을 계속 유지하려면 클라이언트의 오버라이드, 병합 또는 스크립트 기능을 사용하고, 생성된 설정에 변경 사항이 반영됐는지 확인하세요. 클라이언트마다 병합 순서가 다르므로 편집기에 보이는 내용만으로 최종 규칙을 판단하지 마세요.

10. 클라이언트를 종료한 뒤 인터넷이 끊기면 어떻게 복구하나요?

로컬 프록시 프로세스는 중지됐지만 시스템이 여전히 해당 수신 주소를 가리키는 경우가 흔합니다. 이때 앱은 계속 127.0.0.1:7890에 연결하므로 응답을 받을 수 없습니다. 클라이언트를 바로 다시 설치하지 말고 먼저 네트워크 연결 설정을 복구하세요.

범위를 좁혀 가며 복구하세요

클라이언트를 열 수 있다면 시스템 프록시와 TUN을 먼저 끈 다음 정상적으로 종료하세요.
Windows 11에서는 「설정」→「네트워크 및 인터넷」→「프록시」로 이동해 더 이상 사용하지 않는 수동 프록시를 끄세요. 조직에서 관리하는 프록시 설정은 관리자에게 먼저 확인하세요.
macOS에서는 현재 네트워크 서비스의 「세부사항」→「프록시」로 이동해 더 이상 작동하지 않는 프록시 항목을 해제하세요.
터미널에서만 문제가 발생한다면 HTTP_PROXY, HTTPS_PROXY, ALL_PROXY 등의 환경 변수와 도구 자체의 프록시 설정을 확인하세요.
TUN이 비정상적으로 종료된 뒤에도 인터넷에 연결할 수 없다면 클라이언트를 다시 실행한 다음 TUN을 정상적으로 종료하세요. 필요한 경우 시스템을 재시작해 네트워크 인터페이스와 라우팅을 다시 구성하세요.

Linux 또는 macOS에서는 현재 셸의 프록시 환경 변수를 먼저 확인할 수 있습니다. 아래 명령은 값을 읽고 필터링만 하며 시스템 설정을 변경하지 않습니다. 변수에 계정 정보가 포함될 수 있으므로 결과를 공유하기 전에 민감한 내용을 가리세요.

env | grep -iE '^(http|https|all|no)_proxy='

처음부터 네트워크 초기화나 전체 방화벽 규칙 삭제를 실행하지 마세요. 다른 VPN, 가상 머신, 회사 네트워크에 영향을 줄 수 있습니다. 인터넷을 복구한 뒤 “설정 활성화 → 코어 수신 대기 → 앱 연결 → 규칙에 따른 경로 확인” 순서로 다시 점검하면 대개 문제 구간을 좁힐 수 있습니다.