1. Clash를 설치했는데 사용할 수 있는 노드가 없는 이유는 무엇인가요?
Clash 클라이언트는 설정을 읽고 프록시 규칙을 실행하며 연결을 전달하는 역할을 합니다. 설치 파일에는 일반적으로 바로 사용할 수 있는 프록시 노드가 포함되어 있지 않습니다. 처음 실행한 뒤 프록시 목록이 비어 있거나 「설정을 선택하지 않음」이라는 안내가 표시된다면, 설치 실패가 아니라 설정 파일이나 구독 주소를 아직 가져오지 않은 경우가 대부분입니다.
구독 링크는 어디에서 받나요
구독 주소는 이용 중인 프록시 서비스 제공업체가 생성합니다. 보통 해당 서비스의 관리 페이지에서 「구독」, 「원클릭 구독」 또는 「Clash 설정」 메뉴를 찾을 수 있습니다. Clash 프로젝트, Clash Meta(mihomo) 코어, 그래픽 클라이언트 자체는 서버 계정을 발급하지 않으며 연결 가능한 노드를 자동으로 생성하지도 않습니다.
- Clash, Clash Meta 또는 YAML로 명확히 표시된 구독 형식을 우선 선택하세요.
- 링크를 복사할 때 시작 부분이
https://인지 확인하세요. 웹페이지 주소를 구독 주소로 잘못 사용하지 않도록 주의해야 합니다. - 구독 주소에는 보통 접근 인증 정보가 포함되므로 스크린샷, 포럼 또는 공개 코드 저장소에 올리지 마세요.
- 서비스 제공업체가 도메인을 변경하거나 구독을 초기화하면 기존 주소가 404, 403 또는 빈 설정을 반환할 수 있습니다.
2. 구독 링크는 어떻게 가져오며 설정 파일은 어디에 저장되나요?
데스크톱 클라이언트에서는 보통 「설정」→「새 설정 만들기」→「URL 가져오기」순서로 이동한 뒤 구독 주소를 붙여 넣고 다운로드합니다. 일부 클라이언트는 메뉴를 「Profiles」→「New Profile」→「Import from URL」로 표시합니다. 가져오기를 마친 뒤에는 해당 설정을 클릭해 현재 활성 설정으로 지정해야 합니다. 다운로드만 하고 선택하지 않으면 코어가 계속 기존 파일을 사용할 수 있습니다.
URL 가져오기와 로컬 YAML의 차이
| 방식 | 적용 상황 | 업데이트 방법 |
|---|---|---|
| 구독 URL | 서비스 제공업체가 노드와 규칙을 지속적으로 관리하는 경우 | 설정 목록에서 업데이트를 클릭하거나 지정한 주기에 따라 새로 고침 |
| 로컬 YAML | 고정 포트, 규칙 또는 프록시 그룹을 직접 작성하는 경우 | 파일을 편집한 뒤 설정을 다시 불러오기 |
| 원격 Provider | 노드와 규칙을 여러 출처로 나누는 경우 | interval에 따라 정기적으로 가져오기 |
최소 설정에는 수신 대기 포트, 프록시 정의, 프록시 그룹과 규칙이 필요합니다. 코어마다 지원하는 필드가 완전히 같지는 않으므로 다른 클라이언트가 내보낸 JSON을 Clash YAML로 바로 사용하면 안 됩니다. 아래 조각은 일반적인 구조만 보여 주며, 노드 매개변수는 실제 서비스 설정에서 제공해야 합니다.
mixed-port: 7890
mode: rule
allow-lan: false
log-level: info
proxy-groups:
- name: PROXY
type: select
proxies:
- DIRECT
rules:
- MATCH,PROXY가져오는 중 YAML 구문 오류가 발생하면 먼저 들여쓰기를 확인하세요. YAML은 일반적으로 공백으로 계층을 표현하며 Tab을 사용할 수 없습니다. 콜론 뒤에는 공백을 두어야 하고 같은 계층의 목록 항목에 있는 하이픈도 정렬되어야 합니다.
3. 규칙, 전체 모드와 직접 연결 모드는 어떻게 선택하나요?
Clash에서 자주 사용하는 실행 모드는 Rule, Global, Direct 세 가지입니다. 초보자는 일상적인 사용에서 규칙 모드를 우선 선택하는 것이 좋습니다. 설정의 rules를 위에서 아래로 확인해 대상 도메인이나 IP를 매칭하고, 연결을 지정된 프록시 그룹으로 전달합니다. 일치하는 규칙이 없으면 보통 마지막 MATCH 규칙이 연결 방향을 결정합니다.
| 모드 | 처리 방식 | 일반적인 용도 |
|---|---|---|
| 규칙 Rule | 도메인, IP, 프로세스 등의 규칙에 따라 정책 선택 | 일상적인 웹 이용, 업무와 스트리밍 서비스 분할 연결 |
| 전체 Global | 대부분의 연결을 전체 프록시 그룹으로 전달 | 규칙이 누락되어 매칭되지 않는지 임시로 확인 |
| 직접 연결 Direct | 프록시 노드를 거치지 않고 연결 | 프록시를 일시 중지하거나 노드 문제를 배제 |
빠른 판단 방법
- 먼저 규칙 모드로 대상 사이트에 접속하고 연결 목록에 표시되는 정책 이름을 확인하세요.
- 실패하면 전체 모드로 임시 전환한 뒤 지연 시간 테스트를 통과한 노드를 선택하세요.
- 전체 모드에서 접속된다면 노드는 기본적으로 정상입니다. 규칙 매칭이나 DNS를 계속 확인하세요.
- 전체 모드에서도 실패한다면 노드 상태, 시스템 시간, 방화벽과 네트워크 환경을 다시 확인하세요.
4. 시스템 프록시를 켰는데도 브라우저에서 작동하지 않는 이유는 무엇인가요?
「코어 시작」과 「시스템 프록시 켜기」는 서로 다른 작업입니다. 코어를 시작하면 로컬 포트(예: 혼합 포트 127.0.0.1:7890)를 열어 수신 대기합니다. 시스템 프록시는 운영체제의 프록시 설정을 따르는 앱이 해당 포트로 연결되도록 지정합니다. 코어만 시작하고 시스템 프록시를 켜지 않으면 브라우저는 보통 직접 인터넷에 연결합니다.
다음 네 곳을 순서대로 확인하세요
- 「설정」→「코어 설정」으로 이동해 코어 상태가 실행 중인지 확인하세요.
- 「설정」→「매개변수 설정」으로 이동해 Mixed Port가
7890인지, 포트 사용 중이라는 표시가 없는지 확인하세요. - 홈으로 돌아가 「시스템 프록시」를 켠 뒤 운영체제의 프록시 주소가
127.0.0.1인지, 포트가 일치하는지 다시 확인하세요. - 브라우저의 독립 프록시 확장 기능을 끄세요. 확장 기능에 저장된 기존 포트가 시스템 설정을 덮어쓰는 것을 방지할 수 있습니다.
터미널에서 로컬 포트가 수신 대기 중인지 확인할 수 있습니다. Windows에서는 netstat -ano | findstr :7890, macOS 또는 Linux에서는 lsof -iTCP:7890 -sTCP:LISTEN을 실행하세요. 결과가 없으면 코어가 포트를 정상적으로 열지 못한 것입니다. 현재 Clash 클라이언트가 아닌 다른 프로세스가 표시되면 포트 충돌일 수 있습니다.
Firefox 같은 앱은 독립적인 프록시 설정을 사용할 수 있습니다. 「프록시 사용 안 함」으로 설정했거나 다른 포트를 직접 입력했다면 시스템 프록시를 따르지 않습니다. 이 경우 브라우저의 네트워크 설정에서 「시스템 프록시 설정 사용」을 선택하거나 HTTP/SOCKS 주소를 직접 입력하고 포트를 일치시키세요.
5. 노드는 어떻게 전환하며 프록시 그룹은 무엇인가요?
「프록시」 또는 「Proxies」 페이지로 이동하면 단순한 노드 목록이 아니라 여러 프록시 그룹이 표시되는 경우가 많습니다. 프록시 그룹은 규칙에서 참조하는 정책 진입점입니다. 예를 들면 PROXY, Streaming, Telegram이 있습니다. 각 그룹 안에서 특정 노드를 선택하거나 자동 테스트 그룹 또는 다른 프록시 그룹을 선택할 수 있습니다.
수동 선택과 자동 선택
- select: 사용자가 노드를 직접 지정하며, 선택 결과는 보통 다음 실행 때까지 유지됩니다.
- url-test: 지정된 주소로 지연 시간을 측정하고 현재 측정값이 낮은 노드를 자동으로 선택합니다.
- fallback: 목록 순서대로 사용 가능 여부를 확인하고 현재 노드에 문제가 생기면 다음 노드로 전환합니다.
- load-balance: 코어의 정책에 따라 여러 노드에 연결을 분산합니다. 로그인 기반 서비스는 출구 IP가 자주 바뀌어 적합하지 않을 수 있습니다.
노드를 전환할 때는 먼저 현재 규칙이 실제로 사용하는 프록시 그룹을 찾으세요. 예를 들어 규칙이 DOMAIN-SUFFIX,example.com,PROXY라면 이름이 비슷하지만 참조되지 않는 그룹이 아니라 PROXY 그룹을 수정해야 합니다. 「연결」 페이지에서 대상 사이트에 한 번 접속하고 정책 경로가 PROXY / 노드 이름으로 표시되는지 확인할 수도 있습니다.
6. 지연 시간이 낮을수록 노드가 반드시 더 빠른가요?
클라이언트에 표시되는 지연 시간은 보통 로컬 기기에서 테스트 주소로 HTTP 요청을 한 번 보내고 응답을 받는 데 걸리는 시간입니다. 노드에 연결할 수 있는지와 기본 응답 속도는 보여 주지만, 다운로드 대역폭, 피크 시간대의 혼잡, 패킷 손실률 또는 대상 사이트와 출구 서버 사이의 회선 품질을 완전히 나타내지는 않습니다.
일반적인 테스트 결과 읽는 법
- 50~120밀리초: 상호작용 응답이 대체로 빠르지만 실제 웹사이트에서도 함께 테스트해야 합니다.
- 120~250밀리초: 일반 웹페이지는 사용할 수 있지만 동영상 탐색이나 실시간 통신에서 대기 시간이 뚜렷할 수 있습니다.
- 500밀리초 초과: 혼잡, 우회 경로 또는 패킷 손실이 있을 수 있으므로 다른 노드로 바꿔 다시 테스트하는 것이 좋습니다.
- Timeout: 테스트 주소가 제한 시간 안에 응답하지 않았다는 뜻입니다. 모든 대상에 접속할 수 없다는 의미는 아니지만 이상 징후로 보아야 합니다.
지연 시간 테스트를 연속으로 클릭하면 수치가 흔들릴 수 있습니다. 10~20초 간격으로 두 번 테스트한 뒤 실제 다운로드나 동영상 재생으로 확인하는 방법이 더 안정적입니다. 멀리 있는 노드의 경우 패킷 손실이 없는 150밀리초 연결이 지연 시간은 80밀리초지만 자주 끊기는 연결보다 실제 사용감이 좋을 수 있습니다.
7. 노드에는 연결되지만 웹사이트에서 DNS 조회 실패가 표시되면 어떻게 하나요?
노드에 연결된다는 것은 프록시 서버 주소와 연결을 수립할 수 있다는 뜻일 뿐이며, 도메인 이름 조회는 여전히 실패할 수 있습니다. 로그에 no such host가 표시되거나 브라우저에서 서버를 찾을 수 없다고 나오고, IP 주소로는 접속되지만 도메인으로는 열리지 않는 경우가 대표적입니다. 이때는 Clash DNS가 활성화되어 있는지, nameserver에 접근할 수 있는지, 시스템에서 다른 DNS 도구가 동시에 요청을 가로채고 있지 않은지 확인해야 합니다.
Clash Meta에서 자주 사용하는 DNS 강화 모드는 fake-ip와 redir-host입니다. Fake-IP는 먼저 앱에 매핑 주소를 반환한 뒤 코어가 도메인 정보를 보존하고 규칙을 매칭하므로 TUN 및 정밀한 도메인 분할 연결에 더 적합한 경우가 많습니다. 일부 로컬 네트워크 기기, 게임 또는 특수한 DNS 처리 과정과 호환되지 않는다면 fake-ip-filter로 해당 도메인을 제외할 수 있습니다.
dns:
enable: true
listen: 0.0.0.0:1053
enhanced-mode: fake-ip
nameserver:
- 223.5.5.5
fallback:
- tls://1.1.1.1:853
fake-ip-filter:
- "*.lan"
- "localhost.ptlogin2.qq.com"8. 시스템 프록시와 TUN 모드는 어떻게 다른가요?
시스템 프록시는 HTTP 또는 SOCKS 프록시 설정을 읽는 앱에 적합하며, 대부분의 브라우저와 데스크톱 소프트웨어가 여기에 해당합니다. 일부 게임, 명령줄 프로그램, 스토어 앱과 UDP를 사용하는 프로그램은 시스템 프록시를 따르지 않으므로 이때 TUN 모드를 고려해야 합니다. TUN은 가상 네트워크 인터페이스를 만들고 코어가 더 넓은 범위의 TCP 및 UDP 트래픽을 처리하도록 합니다.
| 항목 | 시스템 프록시 | TUN 모드 |
|---|---|---|
| 처리 범위 | 시스템 프록시를 따르는 앱 | 가상 네트워크 어댑터를 통과하는 시스템 트래픽 |
| 권한 요구 사항 | 일반적으로 일반 사용자 권한 | 관리자 권한 또는 VPN 승인이 필요한 경우가 많음 |
| UDP 지원 | 앱과 SOCKS 사용 방식에 따라 다름 | 코어와 노드 프로토콜에 따라 결정됨 |
| 문제 해결 난이도 | 낮음 | 라우팅, DNS와 가상 네트워크 어댑터를 확인해야 함 |
초보자는 먼저 시스템 프록시로 기본 연결을 확인한 다음 TUN을 활성화하는 것이 좋습니다. Windows에서 처음 활성화할 때는 가상 네트워크 어댑터 서비스를 설치하고 관리자 권한을 허용해야 할 수 있습니다. Android와 iOS에서는 시스템 VPN 승인 안내가 표시되며, 일반적으로 한 번에 하나의 앱만 VPN 인터페이스를 사용할 수 있습니다. 다른 VPN이 실행 중이면 Clash의 TUN 또는 모바일 VPN 서비스가 시작되지 않을 수 있습니다.
9. 구독을 업데이트하면 수동 선택과 사용자 지정 규칙이 덮어써지나요?
구독을 업데이트하면 보통 원격 설정을 다시 다운로드합니다. 구독 생성 파일에 직접 입력한 규칙, DNS 또는 프록시 그룹은 새 내용으로 덮어써질 수 있으므로 장기간 수동 수정하기에 적합하지 않습니다. 클라이언트에 「오버라이드」, 「Mixin」, 「확장 설정」 또는 「설정 전처리」 기능이 있다면 로컬 고정 설정을 해당 메뉴에 넣고, 업데이트할 때마다 클라이언트가 병합하도록 하세요.
권장 업데이트 절차
- 「설정」 페이지에서 현재 활성 설정 이름과 마지막 업데이트 시간을 기록하세요.
- 업데이트한 뒤 먼저 설정 검사를 실행하고 기존 설정을 바로 삭제하지 마세요.
- 프록시 그룹, 노드 수, DNS와 규칙이 모두 로드되었는지 확인하세요.
- 직접 연결 대상 하나와 프록시 대상 하나를 테스트하고 연결 페이지에서 매칭된 정책을 확인하세요.
- 업데이트에 문제가 생기면 이전에 정상 작동하던 설정으로 되돌린 뒤 구독 응답 내용을 확인하세요.
수동으로 선택한 노드가 유지되는지는 클라이언트의 저장 방식과 프록시 그룹 이름이 바뀌었는지에 따라 달라집니다. 서비스 제공업체가 PROXY를 다른 이름으로 변경하면 기존 선택이 새 그룹과 연결되지 않아 목록의 첫 번째 항목으로 돌아갈 수 있습니다. 자동 업데이트 주기도 너무 짧게 설정하지 마세요. 노드 구독은 보통 6시간 또는 24시간 간격으로 새로 고치며, 매분 업데이트해도 실질적인 이득은 없습니다.
10. 처음 문제를 해결할 때는 어떤 순서로 확인해야 하나요?
Clash 연결 문제는 보통 설정, 코어, 포트, 노드, 규칙, DNS와 시스템 처리 설정이 서로 얽혀 발생합니다. 무작정 재설치하기보다 정해진 순서대로 확인하는 편이 원인을 찾기 쉽습니다. 각 단계를 완료할 때마다 로그와 연결 페이지를 확인하고, 구독·모드·DNS·클라이언트 버전을 동시에 바꾸지 마세요.
10분 기본 점검 목록
- 시스템 시간 확인: 날짜, 시간대와 분 단위 오차가 정확해야 합니다. 시간 차이는 TLS 연결에 영향을 줄 수 있습니다.
- 설정 상태 확인: 현재 설정이 선택되어 있고 구문 검사를 통과했으며 누락된 프록시 그룹이 없어야 합니다.
- 코어 확인: 로그에 수신 대기 포트가 표시되고 시작 직후 종료되지 않는지 확인하세요.
- 포트 확인:
7890또는 현재 mixed-port를 다른 프로그램이 사용하고 있지 않아야 합니다. - 노드 확인: 지연 시간 테스트를 실행하고 서로 다른 노드를 두 개 이상 수동으로 전환해 보세요.
- 전체 모드 전환: 규칙 문제와 노드 문제를 구분하기 위해 사용하고, 테스트가 끝나면 규칙 모드로 되돌리세요.
- 시스템 프록시 확인: 주소가
127.0.0.1이고 포트가 클라이언트와 일치해야 합니다. - DNS 확인: 로그에 시간 초과, 조회 실패 또는 반복 조회가 나타나는지 확인하세요.
- TUN 임시 해제: 먼저 일반 시스템 프록시를 테스트해 가상 네트워크 어댑터와 라우팅 충돌을 배제하세요.
- 로그 원문 확인: 「연결할 수 없음」이라고만 기록하지 말고 발생 시간, 대상 도메인, 정책 이름과 구체적인 오류를 기록하세요.
로그의 connection refused는 보통 대상 포트가 연결을 명확히 거부했다는 뜻입니다. i/o timeout 또는 dial tcp timeout은 네트워크 연결 불가, 노드 혼잡 또는 방화벽에 의한 패킷 폐기에서 더 자주 발생하고, no such host는 우선 DNS 문제를 가리킵니다. 오류를 확인한 뒤 먼저 문제가 로컬 수신 대기, 프록시 노드 또는 최종 대상 중 어디에서 발생했는지 판단하면 점검 범위를 크게 줄일 수 있습니다.