Clash 초보자 FAQ 10가지: 구독 가져오기·프록시 모드·노드 선택·자동 실행

01 · 클라이언트를 설치했는데 왜 연결되지 않나요?

클라이언트는 설정을 관리하고 프록시 코어를 실행하며, 노드는 원격 출구를 제공합니다. 설치를 마쳤다는 것은 로컬에서 실행할 환경이 갖춰졌다는 뜻일 뿐, 사용할 수 있는 노드를 확보했다는 의미는 아닙니다. 처음 사용할 때는 설정 가져오기, 설정 활성화, 출구 선택, 앱 트래픽을 프록시로 보내기까지 네 단계를 완료해야 합니다.

Clash는 규칙 기반 프록시 코어와 관련 클라이언트를 통칭할 때 흔히 쓰는 이름입니다. Clash Meta는 이후 mihomo라는 이름으로 개발을 이어가고 있습니다. mihomo를 사용하는 그래픽 클라이언트는 보통 더 다양한 프로토콜과 설정 항목을 지원합니다. 클라이언트 UI 버전과 코어 버전은 별도로 확인해야 하므로, 문제를 진단할 때 둘 다 기록하세요. 단순히 ‘최신 버전을 설치했다’고만 해서는 충분하지 않습니다.

클라이언트의 ‘정보’ 또는 코어 정보 화면에서 클라이언트 이름, 버전, 코어 이름을 확인해 기록하세요.
구독 제공업체가 Clash 또는 mihomo 설정을 명시적으로 지원하는지 확인하세요. 특히 노드 프로토콜 요구 사항을 살펴보세요.
먼저 규칙 모드와 시스템 프록시로 브라우저 연결을 확인한 뒤 TUN 사용 여부를 결정하세요.

02 · 구독 링크는 어디서 받나요? 공유해도 되나요?

구독 링크는 보통 노드 서비스를 제공하는 계정 관리 페이지에서 확인하거나, 직접 구축한 서비스에서 생성할 수 있습니다. 클라이언트가 원격 노드를 자동으로 제공하지는 않습니다. 링크를 받을 때는 Clash 또는 mihomo용 구독 형식을 선택하세요. 웹사이트 로그인 주소나 결제 페이지, 브라우저 주소창에 표시된 계정 페이지 주소를 복사하면 안 됩니다.

구독 주소에는 계정을 식별하는 토큰이 포함되는 경우가 많습니다. 주소 전체를 가진 사람은 노드 정보를 확인하거나 트래픽을 소모할 수 있고, 구독 응답에 계정 관련 정보가 포함되어 있다면 이를 볼 수도 있습니다. 따라서 자격 증명처럼 취급해야 하며, 공개 문의 게시판이나 스크린샷, 채팅방, 코드 저장소에 올리지 마세요.

가져오기 전에 도메인이 제공업체의 관리 페이지에 표시된 주소와 일치하는지 확인하고, 공식 HTTPS 주소를 사용하세요.
도움을 요청할 때는 사용자 이름만 가리지 말고 쿼리 매개변수와 민감한 경로 전체를 숨기세요.
유출된 경우 제공업체 관리 페이지에서 구독 링크를 재설정한 다음 클라이언트에 저장된 주소를 새 주소로 바꾸세요.
온라인 구독 변환 서비스를 사용하면 원본 주소를 해당 서비스에 전달하게 됩니다. 먼저 신뢰할 수 있는 서비스인지 검토하세요.

이 문서에서는 공개 노드나 구독 주소를 제공하지 않습니다. 직접 구축한 사용자는 YAML 설정을 관리할 수 있습니다. ss:// 또는 vmess:// 링크만 있다면 클라이언트가 단일 노드 가져오기를 지원하는지 확인해야 합니다. 이런 링크를 완전한 Clash 설정으로 간주하면 안 됩니다.

03 · Clash 구독은 어떻게 가져오나요? 가져오기에 실패하면 어디를 확인해야 하나요?

클라이언트마다 메뉴 이름은 조금씩 다릅니다. 일반적으로 ‘구독’ 또는 ‘설정’ 화면에서 원격 설정을 새로 만들고 주소를 붙여 넣어 다운로드한 다음, 해당 설정을 선택해 현재 사용 항목으로 지정합니다. 설정 카드가 보인다고 해서 반드시 활성화된 것은 아닙니다. 현재 설정 표시와 코어 로그를 확인하세요.

응답 결과에 따라 오류 원인 찾기

증상	먼저 확인할 항목	다음 단계
HTTP 401 또는 403	토큰, 계정 권한, 접속 위치 제한	계정 관리 페이지에서 구독 주소를 다시 복사하세요
HTTP 404	경로가 완전한지, 이전 링크가 만료되었는지	제공업체가 현재 안내하는 주소와 대조하세요
HTML 페이지가 반환됨	로그인 페이지를 복사했거나 웹 인증 페이지가 표시되었는지	구독 전용 내보내기 메뉴를 선택하세요
YAML 파싱 실패	들여쓰기, 콘텐츠 형식, 필드 구조	오류가 발생한 줄 번호를 기록하고 YAML이 반환되었는지 확인하세요
지원되지 않는 프록시 유형	코어 기능과 구독 프로토콜	mihomo 지원 여부를 확인하거나 호환되는 설정으로 바꾸세요

완전한 설정에는 보통 proxies, proxy-groups, rules가 포함되며, proxy-providers를 통해 노드를 불러올 수도 있습니다. Base64로 인코딩된 노드 목록만 제공하는 구독은 YAML 설정으로 바로 불러올 수 없는 경우가 있습니다. 형식이 맞지 않는다고 파일 확장자만 바꾸지는 마세요.

로그에 연결 시간 초과가 표시되면 먼저 컴퓨터 시간이 정확한지, 네트워크에서 구독 도메인에 접속할 수 있는지 확인하세요. 프록시를 통해 구독을 갱신해야 한다면 이미 작동하는 프록시 경로도 필요합니다. 설정이 비어 있으면 이 경로를 저절로 만들 수 없습니다.

04 · 규칙 모드, 전역 모드, 직접 연결 모드는 어떻게 다른가요?

프록시 모드는 코어에 들어온 연결이 어떤 출구를 사용할지 결정합니다. 모든 앱의 트래픽을 자동으로 코어에 보내는 기능은 아닙니다. 전역 모드로 바꾸더라도 시스템 프록시를 무시하고 TUN으로도 처리되지 않는 앱은 클라이언트를 완전히 우회할 수 있습니다.

규칙 모드: rules를 위에서부터 차례로 확인해 일치하는 규칙의 지정 정책을 사용합니다. 일반적으로 일상적인 사용은 이 모드로 시작하면 됩니다.
전역 모드: 연결을 전역 정책으로 보냅니다. 이때도 전역 정책에서 사용할 노드나 그룹을 선택해야 합니다. 트래픽 분기 문제를 일시적으로 진단할 때 유용합니다.
직접 연결 모드: 연결이 직접 연결 출구를 사용합니다. 클라이언트를 종료하거나 시스템 프록시를 끄는 것과는 다릅니다.

최소 규칙 예시

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

아래는 규칙 예시이며 그대로 가져올 수 있는 완전한 설정이 아닙니다. PROXY는 설정에 실제로 존재하는 노드 또는 정책 그룹 이름이어야 합니다. DOMAIN-SUFFIX,example.com,DIRECT는 해당 도메인과 하위 도메인에 적용됩니다. MATCH는 마지막에 두는 기본 규칙입니다. MATCH를 앞에 두면 그 뒤의 규칙은 적용되지 않습니다.

특정 사이트의 문제를 확인할 때는 잠시 전역 모드로 전환하고 같은 노드를 선택해 보세요. 전역 모드에서는 접속되지만 규칙 모드에서 안 된다면, 노드가 작동하지 않는다고 단정하기보다 적용된 규칙과 대상 정책을 먼저 확인하세요.

05 · 노드는 어떻게 고르나요? 지연 시간이 가장 짧으면 가장 좋은가요?

클라이언트에 표시되는 지연 시간은 대개 지정된 테스트 URL에 연결해 측정한 값입니다. 테스트 주소, 제한 시간, 네트워크 혼잡도, 코어의 테스트 방식에 따라 달라질 수 있으며, 모든 사이트의 접속 속도나 동영상 다운로드 속도를 나타내지는 않습니다. 지연 시간 테스트에 성공했다는 것은 해당 테스트가 완료되었다는 뜻일 뿐입니다.

노드 목록에서 테스트 버튼만 누르지 말고, 현재 사용하는 정책 그룹에서 노드를 선택하세요.
실제 접속하려는 사이트를 열어 연결 시간, 페이지 리소스 로드 여부, 반복 오류 발생 여부를 확인하세요.
조건 변화의 영향을 줄이려면 같은 네트워크와 같은 테스트 URL에서 후보 노드를 비교하세요.
연결 기록에서 실제 출구를 확인해 트래픽이 다른 정책 그룹으로 전달되지 않았는지 살펴보세요.

select 그룹에서는 사용자가 직접 선택하고, url-test 그룹은 테스트 결과에 따라 자동으로 노드를 선택합니다. fallback 그룹은 순서에 따라 사용 가능한 출구를 선택하는 방식입니다. 그룹이 다른 그룹을 참조할 수도 있으므로 화면에 표시된 그룹 이름이 실제 노드 이름과 다를 수 있습니다.

예를 들어 수동 선택 그룹에서 ‘자동 선택’ 그룹을 선택했다면 실제 출구는 테스트 결과에 따라 바뀔 수 있습니다. 문제를 같은 조건에서 재현하려면 임시로 특정 노드를 선택하고 테스트 시각, 대상 도메인, 오류 내용을 기록하세요. 노드와 DNS, 규칙을 한꺼번에 바꾸면 어떤 변경이 영향을 줬는지 파악하기 어렵습니다.

06 · 시스템 프록시를 켰는데도 브라우저가 연결되지 않는 이유는 무엇인가요?

시스템 프록시는 해당 방식을 지원하는 앱에 로컬 프록시 주소를 제공할 뿐, 트래픽을 강제로 가로채지는 않습니다. 먼저 클라이언트가 실제로 사용하는 수신 포트를 확인하고, 운영체제에 설정된 주소와 일치하는지 살펴보세요. 아래에서는 점검 예시로 127.0.0.1:7890을 사용합니다. 실제 값은 현재 클라이언트 설정을 기준으로 하세요.

Windows 점검 순서

‘설정’ → ‘네트워크 및 인터넷’ → ‘프록시’를 열고 클라이언트가 관리하는 프록시 주소와 포트를 확인하세요.
클라이언트 설정에서 HTTP 또는 mixed 수신 포트를 확인하세요. 제어 인터페이스 포트를 잘못 사용하지 않도록 주의하세요.
다른 프록시 도구를 일시 중지해 여러 프로그램이 시스템 프록시 설정을 반복해서 바꾸지 않도록 하세요.
브라우저 확장 프로그램에서 별도의 프록시를 지정했는지 확인하세요. 필요하다면 관련 확장 프로그램을 끄고 다시 시도하세요.

Test-NetConnection -ComputerName 127.0.0.1 -Port 7890
curl.exe -I --proxy http://127.0.0.1:7890 https://example.com/

첫 번째 명령은 PowerShell에서 로컬 포트에 연결할 수 있는지 확인합니다. TcpTestSucceeded : True는 해당 포트에 연결할 수 있다는 뜻일 뿐입니다. 두 번째 명령은 HTTP 프록시를 명시해 앱이 시스템 프록시 설정을 읽는지 여부를 확인하지 않고 요청합니다. HTTP 응답을 받았다면 해당 프록시 요청에 응답이 온 것입니다. 응답 코드가 예상한 결과인지는 대상 사이트를 함께 고려해야 합니다.

프록시를 명시한 요청은 성공하지만 브라우저에서 실패한다면 브라우저 설정, 확장 프로그램, 보안 DNS를 확인하세요. 프록시를 명시해도 실패한다면 로컬 포트, 노드, 인증 정보, 로그를 살펴보세요. 제어 인터페이스는 보통 클라이언트와 코어 간 통신에 사용합니다. 포트가 열려 있다고 해서 브라우저의 프록시 주소로 입력하면 안 됩니다.

07 · TUN 모드란 무엇인가요? 초보자도 켜야 하나요?

TUN은 가상 네트워크 인터페이스와 라우팅 설정을 사용해 IP 트래픽을 처리하며, 시스템 프록시를 따르지 않는 앱에 적합합니다. 시스템 프록시와는 트래픽을 전달하는 진입 방식이 다를 뿐, ‘한 단계 더 높은 프록시 모드’는 아닙니다. 규칙, 전역, 직접 연결 모드는 여전히 코어에 들어온 트래픽의 출구를 결정합니다.

먼저 시스템 프록시로 기본 동작을 확인하면 문제를 찾을 때 고려할 변수가 줄어듭니다. 브라우저는 정상적으로 연결되지만 특정 앱이 시스템 프록시를 사용하지 않는다면 TUN을 고려하세요. 활성화하기 전에 클라이언트에 관리자 권한, 서비스 모드, 추가 네트워크 권한이 필요한지 확인하세요. 요구 사항은 운영체제와 클라이언트 구현에 따라 다릅니다.

Windows: 클라이언트에서 요구하는 서비스나 권한이 준비되어 있는지 확인하고, 가상 네트워크 어댑터 또는 라우팅 생성 실패가 로그에 기록되었는지 살펴보세요.
Android: 보통 시스템 VPN 권한을 받아 트래픽을 처리합니다. 다른 VPN 앱을 켜면 현재 연결이 대체될 수 있습니다.
데스크톱에서 여러 VPN 사용: 기업 VPN, 가상 머신 네트워크, 다른 터널이 라우팅 우선순위를 바꿀 수 있으므로 하나씩 확인하세요.

‘TUN을 켜면 모든 UDP, IPv6, DNS가 반드시 예상대로 처리된다’고 생각하지 마세요. 코어 기능, 노드의 관련 전송 방식 지원 여부, 라우팅 적용 범위, DNS 처리 방식도 영향을 줍니다. 처음 활성화한 뒤에는 브라우저와 이전에 프록시를 사용할 수 없었던 앱을 각각 테스트하세요.

08 · fake-ip와 DNS 설정을 함께 바꿔야 하나요?

DNS는 도메인 이름을 주소로 변환합니다. mihomo의 fake-ip 모드는 관련 쿼리에 매핑용 가상 주소를 반환하고, 코어는 이를 바탕으로 도메인을 복원해 연결을 처리합니다. 가상 주소가 보인다고 반드시 DNS 오류가 발생한 것은 아닙니다. 중요한 것은 해당 트래픽이 코어에서 정상적으로 처리되는지입니다.

초보자는 사용 가능한 구독과 클라이언트의 기본 DNS 설정을 우선 유지하는 것이 좋습니다. 시스템, 브라우저, 클라이언트에서 동시에 설정을 바꾸지 마세요. 브라우저의 암호화 DNS가 쿼리 경로를 바꿀 수 있으며, TUN의 dns-hijack도 모든 암호화 DNS 요청을 가로채는 범용 기능은 아닙니다.

먼저 증상을 기록하고, 그다음 설정 항목을 바꾸세요

도메인 하나만 실패함: 먼저 적용된 규칙, 사이트 상태, DNS 로그를 확인하세요.
여러 도메인이 모두 해석되지 않음: DNS 업스트림에 연결할 수 있는지, 쿼리가 예상한 경로로 전달되는지 확인하세요.
로컬 네트워크 기기 이름이나 특정 앱에 문제가 있음: DNS 기능 전체를 끄기보다 정확한 fake-ip 제외 설정이 필요한지 확인하세요.
TUN을 켜거나 끈 뒤 동작이 달라짐: 노드만 바꾸지 말고 두 상태의 라우팅과 DNS 처리 방식을 비교하세요.

시스템의 nslookup 결과는 해당 명령이 사용한 쿼리 경로만 보여 줍니다. 브라우저나 모든 앱이 같은 DNS를 사용한다는 것을 단독으로 증명하지는 못합니다. 각 설정 항목을 더 자세히 알아보려면 설정 종합 가이드의 DNS 및 TUN 설명을 참고하세요.

09 · 시작 프로그램에 등록하려면 어떻게 하나요? 재부팅 후 프록시가 작동하지 않는 이유는 무엇인가요?

시작 프로그램 등록, 코어 실행, 시스템 프록시 복구, TUN 권한은 서로 다른 항목입니다. 시작 프로그램에 등록하면 앱 실행을 시도할 뿐, 설정이 정상인지, 네트워크에 연결되었는지, 정책 그룹이 올바른지까지 보장하지는 않습니다. 데스크톱 그래픽 클라이언트는 보통 사용자가 로그인한 뒤 실행되므로, 로그인 전부터 프록시 네트워크를 사용할 수 있다는 뜻은 아닙니다.

재부팅 후 확인할 항목

클라이언트 설정에서 ‘시작 프로그램에 등록’ 또는 비슷한 옵션을 켜세요.
Windows에서는 ‘설정’ → ‘앱’ → ‘시작 프로그램’에서 해당 앱이 비활성화되지 않았는지 확인하세요.
다시 로그인한 뒤 창이 나타나는지만 보지 말고, 시스템 트레이 아이콘과 현재 설정, 코어 로그를 확인하세요.
시스템 프록시가 복구되었는지 확인하세요. TUN을 사용하는 경우 서비스 상태와 권한도 별도로 확인하세요.
네트워크 연결이 완료된 뒤 대상 요청을 다시 테스트해 시작 직후 네트워크가 준비되지 않은 경우를 제외하세요.

일부 클라이언트에서는 ‘창 닫기’가 트레이로 숨기는 동작이고, 다른 클라이언트에서는 프로그램을 종료합니다. 자동 실행을 테스트할 때는 숨김, 종료, 코어 중지를 구분하세요. 클라이언트가 종료됐는데도 시스템 프록시가 127.0.0.1을 가리키면 로컬 포트를 수신하는 프로그램이 없어 시스템 프록시를 지원하는 앱이 인터넷에 연결되지 않을 수 있습니다.

이런 문제가 발생하면 클라이언트를 다시 실행하거나 시스템 설정에서 수동 프록시를 끄세요. 여러 시작 작업과 서비스를 직접 만들지는 마세요. 중복 실행으로 포트가 이미 사용 중이 되어 정상 설정을 불러오지 못할 수 있습니다.

구독을 갱신하면 설정이 덮어써지나요? 문제를 보고할 때 어떤 정보를 제공해야 하나요?

원격 구독을 갱신하면 일반적으로 해당 원격 설정의 내용이 교체됩니다. 다운로드한 YAML을 직접 수정하면 다음 갱신 때 변경 내용이 사라질 수 있습니다. 클라이언트의 덮어쓰기, 병합, 스크립트 기능을 사용하면 개인 설정과 구독 내용을 분리할 수 있지만, 병합 순서와 지원 기능은 구현 방식에 따라 다릅니다.

규칙을 추가하려면 먼저 덮어쓰기 기능이 rules 배열 전체를 교체하는지, 앞이나 뒤에 규칙을 추가하는지 확인하세요. 특정 정책 그룹을 지정한다면 갱신 후에도 해당 그룹 이름이 유지되는지 살펴보세요. 그룹 이름이 바뀌면 이전 이름을 참조하는 규칙 때문에 설정을 불러오지 못할 수 있습니다.

문제 해결에 도움이 되는 기록

환경: 운영체제와 버전, 클라이언트 이름과 버전, 코어 이름과 버전.
연결 방식: 시스템 프록시 또는 TUN, 실제 로컬 포트, 다른 VPN을 함께 실행하는지 여부.
정책: 규칙 또는 전역 모드, 적용된 규칙, 최종 정책 그룹과 노드 이름.
증상: 발생 시각, 대상 도메인, HTTP 상태 코드 또는 오류 원문, 문제가 재현되는지 여부.
비교 결과: 프록시를 끈 경우, 프록시를 명시한 경우, 작동이 확인된 다른 노드로 바꾼 경우의 차이.

로그를 공유하기 전에 구독 주소, 토큰, 노드 비밀번호, 제어 인터페이스 키를 삭제하세요. 보통 오류 발생 전후의 관련 부분만 있으면 충분하며 전체 설정을 업로드할 필요는 없습니다. 여러 옵션을 바꿨다면 먼저 작동하는 백업으로 되돌린 뒤 한 번에 하나씩 변경하며 다시 테스트하세요.