1. Clash의 노드는 어디에서 가져오나요
핵심 결론: Clash 클라이언트는 설정을 읽고, 트래픽을 분배하며, 프록시 연결을 수립하지만 노드를 직접 생성하지는 않습니다. 노드는 보통 서비스 제공업체가 제공하는 구독 URL에서 가져오며, 사용자가 YAML 설정에 직접 입력할 수도 있습니다.
사용 가능한 설정에는 보통 프록시 노드, 정책 그룹, 규칙, DNS 설정이 포함됩니다. 노드 목록만 있고 정책 그룹이 없으면 화면에서 서버는 보여도 “자동 선택”이나 “장애 조치” 방식으로 전환할 수 없습니다. 반대로 규칙만 있고 노드가 없으면 프록시 규칙에 사용할 출구가 없습니다.
구독 URL과 일반 웹 URL의 차이
- 구독 URL은 보통 서비스 제공업체가 생성하며, 복사한 뒤 클라이언트의 설정 가져오기 입력란에 붙여 넣어야 합니다.
- 구독 URL은 Clash YAML을 반환할 수도 있고 Base64 형식의 노드 목록을 반환할 수도 있습니다. 후자는 클라이언트가 해당 형식을 지원하거나 신뢰할 수 있는 변환 서비스를 먼저 이용해야 합니다.
- 브라우저에서 URL이 열린다고 해서 Clash가 인식할 수 있는 형식이라는 뜻은 아닙니다. 로그인 페이지, 요금제 페이지 또는 HTML 오류 페이지가 표시된다면 유효한 설정 내용이 아닙니다.
- 구독 URL에는 보통 인증 정보가 포함되므로 계정 자격 증명처럼 취급해야 합니다. 스크린샷, 포럼 또는 공개 코드 저장소에 올리지 마세요.
가져온 뒤에는 설정 목록에서 방금 추가한 설정을 선택해야 합니다. Clash Verge Rev 2.x의 일반적인 화면을 예로 들면 경로는 보통 「구독」→「새로 만들기」→ URL 붙여넣기 →「저장」이며, 이후 구독 목록으로 돌아가 해당 설정을 클릭합니다. 클라이언트에 따라 “구독”이 Profiles, 설정 또는 설정 파일로 표시될 수 있지만 과정은 모두 “추가, 업데이트, 선택”의 세 단계입니다.
2. 구독 가져오기에 성공했는데 왜 아직 사용할 수 없나요
핵심 결론: “가져오기 성공”은 클라이언트가 설정을 받았다는 뜻일 뿐, 노드가 선택되었거나 시스템 트래픽이 Clash로 전달되고 있다는 뜻은 아닙니다. 초보자는 뒤의 두 단계를 가장 자주 놓칩니다.
다음 네 가지를 하나씩 확인하세요
- 설정 활성화: 설정 목록에서 현재 항목이 선택된 상태여야 하며, 단순히 기록에 남아 있는 것만으로는 충분하지 않습니다.
- 정책 그룹 선택: 「프록시」 또는 Proxies 페이지에서 주요 정책 그룹이 비어 있지 않은지 확인하고, 사용 가능한 노드나 자동 속도 측정 그룹을 선택하세요.
- 실행 모드가 직접 연결이 아님: 문제를 점검할 때는 먼저 규칙 모드를 사용하고 Direct 또는 직접 연결 모드를 잘못 선택하지 않도록 하세요.
- 트래픽 진입점 활성화: 일반 브라우저는 보통 시스템 프록시를 켜야 하며, 시스템 프록시를 따르지 않는 앱은 TUN이 필요할 수 있습니다.
실행 로그도 확인할 수 있습니다. 웹사이트에 접속했는데 새 로그가 전혀 없다면 요청이 Clash에 들어오지 않은 것이므로 시스템 프록시, 브라우저 개별 프록시, TUN 또는 포트 설정을 확인해야 합니다. 로그에 요청은 나타나지만 timeout, connection refused 또는 DNS 오류가 표시될 때는 노드·네트워크·DNS를 추가로 점검하세요.
3. 규칙 모드·전체 모드·직접 연결 모드 중 무엇을 선택하나요
핵심 결론: 일상적인 사용에는 규칙 모드를 우선 선택하세요. 전체 모드는 트래픽 분배 문제를 임시로 점검할 때 적합하고, 직접 연결 모드는 프록시 출구를 일시 중지할 때 사용하지만 일반적으로 트래픽은 여전히 Clash 코어를 통과합니다.
| 모드 | 처리 방식 | 적합한 상황 | 흔한 오해 |
|---|---|---|---|
| 규칙 모드 | 위에서부터 규칙을 대조해 직접 연결·프록시·차단 여부를 결정 | 일상적인 웹 이용, 소프트웨어 업데이트, 로컬 서비스 병행 | 규칙이 오래되면 일부 도메인이 잘못된 정책으로 연결될 수 있음 |
| 전체 모드 | 대부분의 요청을 선택한 프록시 정책으로 일괄 전달 | 문제가 규칙 분배에서 발생했는지 확인 | 운영체제의 모든 트래픽이 자동으로 Clash에 들어간다는 뜻은 아님 |
| 직접 연결 모드 | 로컬 네트워크가 대상에 직접 접속 | 프록시 출구를 일시 중지하고 네트워크 상태 비교 | 시스템 프록시는 여전히 켜져 있을 수 있음 |
규칙 모드의 핵심은 “위에서 아래로, 처음 일치한 규칙 적용”입니다. 예를 들어 도메인이 먼저 DOMAIN-SUFFIX 규칙과 일치하면 뒤의 MATCH는 더 이상 처리하지 않습니다. 설정 마지막에 자주 보이는 MATCH는 앞에서 일치하지 않은 연결을 처리하는 기본 규칙입니다.
rules:
- DOMAIN-SUFFIX,example.com,Proxy
- DOMAIN-SUFFIX,lan,DIRECT
- IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
- MATCH,Proxy어떤 웹사이트가 전체 모드에서는 작동하지만 규칙 모드에서는 작동하지 않는다면 노드 자체에는 대개 문제가 없습니다. 우선 규칙 적용 결과를 확인하세요. 연결 기록에서 대상 도메인이 최종적으로 DIRECT, 특정 프록시 그룹 또는 REJECT 중 어디로 처리되었는지 확인한 뒤 설정을 업데이트하거나 해당 규칙을 조정하세요.
4. 7890 포트란 무엇이며 기본값을 계속 유지해야 하나요
핵심 결론: 7890은 많은 Clash 설정에서 사용하는 로컬 프록시 포트지만, 모든 클라이언트가 강제로 사용하는 고정값은 아닙니다. mixed-port로 설정될 수도 있고 HTTP 프록시에만 해당할 수도 있으므로 실제 값은 현재 클라이언트의 실행 설정과 YAML 설정을 기준으로 확인해야 합니다.
| 설정 항목 | 일반적인 포트 | 용도 |
|---|---|---|
mixed-port |
7890 | 하나의 포트에서 HTTP와 SOCKS5 프록시 요청 수신 |
port |
7890 | HTTP 프록시 진입점 |
socks-port |
7891 | SOCKS5 프록시 진입점 |
external-controller |
9090 | 그래픽 인터페이스가 상태를 읽고 정책을 전환하는 제어 인터페이스 |
9090은 브라우저에 입력하는 프록시 포트가 아닙니다. 브라우저 프록시를 127.0.0.1:9090으로 잘못 설정하면 대개 연결에 실패합니다. 혼합 포트를 사용할 때 프록시 주소는 보통 127.0.0.1:7890이며, 클라이언트에 다른 포트가 표시된다면 현재 적용된 값을 사용해야 합니다.
포트가 이미 사용 중일 때 해결 방법
로그에 address already in use, bind failed 또는 “포트 사용 중”이 표시되면 먼저 다른 프록시 도구를 종료한 뒤 Clash를 다시 시작하세요. 그래도 충돌이 계속되면 「설정」→「매개변수 설정」 또는 「설정」→「포트 설정」에서 혼합 포트를 7892, 7893 등 사용되지 않는 포트로 바꾸고 시스템 프록시를 다시 켜세요. 브라우저에 프록시를 수동으로 설정했다면 브라우저 포트도 함께 변경해야 합니다.
포트를 변경한 뒤에는 스위치 상태만 확인하지 마세요. 로그에서 로컬 수신 대기가 시작되었는지 확인하거나 클라이언트 홈 화면에서 HTTP, SOCKS, Mixed 진입점의 실제 포트를 확인하세요. 시스템 프록시 자동 설정은 보통 새 포트를 따라 업데이트되지만 수동 설정은 자동으로 바뀌지 않습니다.
5. 시스템 프록시를 켰는데도 왜 웹사이트가 열리지 않나요
핵심 결론: 먼저 요청이 Clash에 들어갔는지 확인한 다음, 들어왔다면 어느 단계에서 멈췄는지 확인하세요. 시스템 프록시 스위치가 켜진 것은 시작일 뿐입니다. 사용할 수 없는 노드, 직접 연결로 처리된 규칙, DNS 실패, 브라우저의 시스템 설정 덮어쓰기로 인해 “켜도 연결되지 않는” 문제가 발생할 수 있습니다.
5분 점검 절차
- 클라이언트의 로그 또는 연결 페이지를 열고 현재 필터를 초기화하세요.
- 브라우저에서 대상 웹사이트에 접속하고 해당 도메인이 표시되는지 확인하세요.
- 로그가 없다면 브라우저에 별도로 설치한 프록시 확장 프로그램을 끄고, 프록시 주소가
127.0.0.1인지와 포트가 클라이언트와 일치하는지 확인하세요. - 로그는 있지만
DIRECT로 처리된다면 임시로 전체 모드로 전환해 비교하세요. 전체 모드에서 작동한다면 규칙을 점검해야 합니다. - 로그에 timeout이 표시되면 지연 시간이 정상인 다른 노드로 바꾸고 로컬 네트워크에서 일반 웹사이트에 접속할 수 있는지 테스트하세요.
- 로그에 DNS error, no such host 또는 DNS 조회 시간 초과가 표시될 때는 포트를 계속 바꾸기보다 DNS 설정을 확인하세요.
Windows에서는 시스템 프록시가 다른 소프트웨어에 의해 변경되지 않았는지도 확인해야 합니다. 일반적인 경로는 「설정」→「네트워크 및 인터넷」→「프록시」입니다. Clash가 시스템 프록시를 자동 관리 중이라면 수동 프록시 주소는 보통 로컬 루프백 주소를 가리킵니다. 클라이언트를 종료하기 전에 시스템 프록시를 먼저 꺼야 운영체제가 더 이상 수신 대기가 중단된 7890 포트로 요청을 보내지 않습니다.
macOS에서는 「시스템 설정」→「네트워크」→현재 네트워크→「세부사항」→「프록시」에서 상태를 확인할 수 있습니다. 여러 프로토콜을 수동으로 동시에 선택하고 클라이언트가 다시 관리하도록 할 필요는 보통 없습니다. 중복 설정으로 포트가 일치하지 않을 수 있으므로 클라이언트의 “시스템 프록시로 설정” 기능으로 통합 관리하는 것을 우선하세요.
6. 노드 지연 시간은 어느 정도가 정상이며, 숫자가 작으면 항상 더 빠른가요
핵심 결론: 지연 시간은 테스트 요청의 왕복에 걸리는 시간을 나타내며 다운로드 속도와 직접적인 관련은 없습니다. 일상적인 웹 이용에서는 50~150ms가 대체로 빠른 편이고, 150~300ms도 사용할 수 있습니다. 500ms를 지속적으로 넘거나 timeout이 표시될 때 우선 노드를 바꿔 보세요.
이 수치는 절대적인 품질 기준이 아닙니다. 지역, 통신사, Wi-Fi 신호, 테스트 주소에 따라 결과가 크게 달라집니다. 같은 노드라도 한 테스트 URL에서는 92ms, 다른 주소에서는 180ms가 나올 수 있으며, 저녁 시간대에는 110ms에서 260ms로 증가할 수도 있습니다. 2~3회 연속 테스트하고 실제 웹페이지 열기, 동영상 재생, 파일 다운로드 결과를 함께 보고 판단하세요.
지연 시간은 낮지만 속도가 느린 일반적인 원인
- 노드에서 속도 측정 주소까지의 경로는 짧지만 실제 대상 사이트로 가는 회선이 혼잡함.
- 서버에서 사용할 수 있는 대역폭이 제한되어 연결 수립은 빠르지만 지속 전송 속도는 낮음.
- 로컬 Wi-Fi에서 패킷 손실이 발생해 지연 시간은 가끔 정상이어도 연결 안정성이 떨어짐.
- 정책 그룹에 표시된 값이 이전 캐시 결과이며 노드의 현재 상태가 이미 바뀜.
- UDP, 동영상 분할 전송 또는 대용량 파일 전송은 일반 HTTP 지연 시간 테스트와 다른 경로를 사용함.
자동 선택 그룹은 보통 주기적인 URL 테스트를 통해 지연 시간이 낮은 노드를 고르고, 장애 조치 그룹은 현재 노드의 사용 가능 여부를 더 중시합니다. 전자는 일상적인 선택에, 후자는 연결 지속성 유지에 적합합니다. 테스트 간격을 너무 짧게 설정하지 마세요. 보통 300~600초마다 확인하면 충분하며, 몇 초마다 테스트하면 불필요한 요청이 발생합니다.
7. 시스템 프록시와 TUN 모드는 어떻게 다른가요
핵심 결론: 시스템 프록시는 앱이 운영체제의 프록시 설정을 직접 읽어야 작동하고, TUN 모드는 가상 네트워크 어댑터를 통해 더 많은 IP 트래픽을 가로챕니다. 브라우저와 대부분의 데스크톱 소프트웨어는 시스템 프록시를 사용할 수 있지만, 게임·명령줄 프로그램·일부 스토어 앱·사용자 지정 네트워크 스택을 사용하는 소프트웨어는 TUN이 필요할 수 있습니다.
| 항목 | 시스템 프록시 | TUN 모드 |
|---|---|---|
| 처리 방식 | 앱이 HTTP 또는 SOCKS 프록시 설정을 읽음 | 가상 네트워크 어댑터가 시스템 네트워크 트래픽을 수신 |
| 권한 요구 사항 | 보통 일반 사용자 권한 | 대개 관리자 권한 또는 서비스 모드 필요 |
| 적합한 프로그램 | 브라우저, 시스템 프록시를 따르는 소프트웨어 | 시스템 프록시를 읽지 않는 프로그램, 일부 UDP 앱 |
| 점검 난이도 | 낮음 | 라우팅, DNS, 가상 네트워크 어댑터, 방화벽을 함께 확인해야 함 |
처음 사용할 때는 시스템 프록시를 안정적으로 작동시킨 뒤 TUN을 고려하는 것이 좋습니다. Mihomo 1.19.x 설정 구문을 사용하는 클라이언트를 예로 들면 TUN의 일반적인 설정에는 enable, stack, auto-route, auto-detect-interface와 DNS 하이재킹이 포함됩니다. 그래픽 클라이언트에서는 보통 「설정」→「시스템 설정」→「서비스 모드」에서 백그라운드 서비스를 설치한 다음 「설정」→「네트워크」 또는 홈 화면에서 TUN을 켭니다.
tun:
enable: true
stack: mixed
auto-route: true
auto-detect-interface: true
dns-hijack:
- any:53stack: mixed는 호환성을 고려할 때 자주 선택하는 값입니다. 특정 시스템에서 연결 문제가 발생하면 클라이언트 안내에 따라 system 또는 gVisor를 테스트할 수 있습니다. 기존 설정을 잘 모르는 상태에서 구독 설정의 TUN과 DNS 항목 전체를 덮어쓰지 마세요. 구독에 이미 환경에 맞는 매개변수가 포함되어 있을 수 있습니다.
8. 브라우저는 되는데 게임·터미널·스토어 앱은 왜 프록시를 사용하지 않나요
핵심 결론: 해당 프로그램이 시스템 프록시를 읽지 않거나 UDP, 자체 DNS, QUIC 등 다른 네트워크 방식을 사용할 수 있습니다. 브라우저가 작동한다면 노드와 기본 프록시 진입점은 대체로 정상이라는 뜻이므로, 다음 단계로 프로그램의 트래픽이 Clash에 들어오는지 확인해야 합니다.
명령줄 도구에는 별도의 프록시 환경 변수가 있는 경우가 많습니다. 현재 터미널 세션에서만 로컬 HTTP 프록시를 사용하려면 도구가 지원하는 방식에 따라 HTTP_PROXY와 HTTPS_PROXY를 설정하세요. SOCKS5를 지원하는 프로그램은 127.0.0.1:7890 또는 클라이언트에 표시된 SOCKS 포트를 지정할 수 있습니다. 변수 이름과 프록시 프로토콜은 프로그램 문서에 맞춰야 하며, 모든 도구가 시스템 설정을 읽는다고 가정해서는 안 됩니다.
HTTP_PROXY=http://127.0.0.1:7890
HTTPS_PROXY=http://127.0.0.1:7890게임과 일부 스토어 앱은 UDP를 사용하는 경우가 많아 일반 HTTP 시스템 프록시로는 이런 트래픽을 직접 처리할 수 없습니다. 이때는 노드가 해당 전송을 지원하는지 확인한 뒤 TUN을 켜고, 연결 목록에서 대상 IP·프로토콜·적용 정책을 확인하세요. TUN을 켠 뒤에도 기록이 없다면 가상 네트워크 어댑터, 라우팅 제외 항목, 앱이 다른 네트워크 인터페이스를 사용하는지 점검해야 합니다.
또한 “전체 모드”는 이미 Clash에 들어온 연결의 출구 선택만 결정하며 모든 프로그램을 강제로 코어로 보내지는 않습니다. 따라서 규칙 모드를 전체 모드로 바꾸는 것만으로 시스템 프록시나 TUN을 대신할 수 없습니다. 초보자가 가장 자주 혼동하는 두 단계는 바로 이것입니다. 트래픽 진입점은 “Clash에 들어오는가”를, 프록시 모드는 “들어온 뒤 어디로 가는가”를 결정합니다.
9. 구독 업데이트 실패·404·시간 초과는 각각 어떻게 해결하나요
핵심 결론: 404는 대체로 URL 자체 또는 계정 상태와 관련 있고, 시간 초과는 네트워크 경로·서버 응답·프록시 업데이트 설정 때문일 가능성이 큽니다. 오류 유형에 따라 처리하고, 현재 사용할 수 있는 설정을 바로 삭제하지 마세요.
404·401·403이 표시될 때
- 404: 구독 경로가 존재하지 않거나 URL이 변경되었거나 서버가 공통 오류 페이지를 반환한 것입니다. 서비스 제공업체의 관리 패널에서 최신 URL을 다시 복사하세요.
- 401: 인증 정보가 만료되었거나 누락된 상태이므로 계정에 다시 로그인해 구독 URL을 받아야 합니다.
- 403: 서버가 현재 요청을 거부한 것입니다. 계정 상태, 요청 빈도 또는 접속 출처가 원인일 수 있습니다.
timeout 또는 connection reset이 표시될 때
먼저 브라우저로 구독 도메인에 연결할 수 있는지 테스트하되 전체 구독 URL은 공개하지 마세요. 현재 네트워크에서 구독 서버에 직접 연결할 수 없다면 클라이언트에서 “프록시를 통한 업데이트”, “프록시 구독 업데이트”와 같은 옵션을 찾으세요. 서버가 직접 연결만 허용한다면 해당 옵션을 꺼야 합니다. 두 방식을 짧은 시간에 반복해서 재시도하면 서버의 요청 빈도 제한이 걸릴 수 있습니다.
자동 업데이트 간격은 너무 짧게 설정하지 않는 것이 좋습니다. 노드 정보는 매분 바뀌지 않으므로 일반적으로 1440분마다 업데이트하면 충분하며, 빠른 동기화가 필요할 때는 360분으로 설정할 수 있습니다. 5분으로 설정하면 불필요한 요청이 늘고 일시적인 네트워크 변동으로 상태가 반복해서 덮어써질 수 있습니다. 업데이트에 실패하면 마지막으로 성공한 설정을 유지한 채 수동으로 다시 시도하세요.
업데이트 후 설정이 갑자기 비어 있다면 먼저 이전 로컬 기록으로 전환하고, 반환된 내용이 HTML 로그인 페이지·오류 JSON·호환되지 않는 형식인지 확인하세요. 클라이언트에 YAML parse error가 표시되면 오류 행 번호를 확인할 수 있습니다. 들여쓰기, 콜론 뒤 공백, 중복 키, 닫히지 않은 따옴표가 파싱 실패의 원인일 수 있습니다.
10. 첫 주에는 어떻게 설정해야 안정적이며, 문제가 생기면 어디서 복구하나요
핵심 결론: 설정을 단순하게 유지하고 먼저 규칙 모드·주요 정책 그룹 하나·시스템 프록시만 사용하세요. 브라우저가 안정적으로 작동한 뒤 자동 속도 측정, TUN, 사용자 지정 DNS 또는 스크립트를 차례로 활성화하세요. 기능을 하나 추가할 때마다 실제 접속을 확인해야 합니다.
초보자에게 적합한 기본 상태
- 현재 설정을 명확히 선택하고, 최근에 정상 작동한 로컬 기록을 하나 보관합니다.
- 실행 모드는 규칙 모드로 사용하고, 주요 프록시 그룹에서는 검증된 노드 하나를 수동으로 선택합니다.
- 혼합 포트는 클라이언트가 자동 관리하는 값을 사용합니다. 예: 7890.
- 시스템 프록시는 클라이언트 스위치로 관리하고, 브라우저에서 확장 프로그램을 중복으로 사용하지 않습니다.
- 자동 업데이트 간격은 360~1440분으로 설정합니다.
- 로그 수준은 일상적인 사용에서 information을 사용하고, 문제를 점검할 때만 일시적으로 debug로 전환합니다.
- TUN, 스크립트 덮어쓰기, 사용자 지정 DNS는 실제로 필요할 때 하나씩 활성화합니다.
설정을 망쳤다면 다음 순서로 복구하세요
- TUN·스크립트·수동 덮어쓰기를 끄고 원래 구독 설정만 남깁니다.
- 규칙 모드로 돌아가 테스트를 통과한 노드 하나를 선택합니다.
- 로컬 혼합 포트를 확인하고 포트 충돌이 없는지 점검합니다.
- 시스템 프록시를 껐다가 다시 켜 운영체제가 프록시 주소를 갱신하도록 합니다.
- 브라우저로 대상 사이트에 접속하면서 연결 로그를 함께 확인합니다.
- 기본 접속이 복구된 뒤 사용자 지정 설정을 하나씩 다시 추가하고, 각 단계의 변화를 기록합니다.
Clash를 완전히 종료한 뒤 모든 웹사이트가 열리지 않는다면 시스템 프록시 설정이 남아 있을 가능성이 큽니다. 클라이언트를 다시 시작해 시스템 프록시를 끄거나 운영체제의 네트워크 설정에서 수동 프록시를 해제하세요. Clash를 켠 뒤 중국 본토의 일반 웹사이트도 느려진다면 모든 요청이 프록시 그룹으로 전달되도록 규칙이 설정되어 있는지, 현재 전체 모드로 잘못 설정되어 있지 않은지 확인하세요.
첫 주부터 모든 설정 항목을 동시에 이해할 필요는 없습니다. 먼저 네 가지 계층만 구분하면 됩니다. 구독은 설정을 제공하고, 노드는 연결 출구를 담당하며, 시스템 프록시 또는 TUN은 트래픽을 유입시키고, 규칙은 출구를 선택합니다. 대부분의 “켜도 연결되지 않는” 문제는 이 네 계층을 따라 단계적으로 확인하면 해결할 수 있습니다.