Clash 클라이언트 다운로드 센터 모든 플랫폼 클라이언트 및 설정 참고

PROFILE INPUT / YAML

구독 링크, 원격 설정 및 로컬 YAML

Clash 클라이언트는 보통 구독 주소에서 설정을 가져오며, 로컬 YAML 파일을 직접 불러올 수도 있습니다. 구독 주소는 설정을 가져오는 경로이고, YAML 파일에는 포트, 프록시 노드, 정책 그룹, 규칙, DNS 같은 구체적인 항목이 저장됩니다. 처음 사용할 때는 전체 주소를 설정 관리 화면에 추가하고 클라이언트가 파싱을 마칠 때까지 기다린 다음 새 설정을 현재 설정으로 지정하세요. 웹페이지 주소를 노드로 착각하거나 링크 일부가 누락된 경우, 또는 일반 텍스트를 가져온 경우에는 설정을 인식하지 못할 수 있습니다.

가져오기에 성공한 뒤 같은 주소를 곧바로 반복해서 추가하지 마세요. 먼저 설정 이름, 업데이트 시간, 프록시 그룹이 표시되는지 확인한 다음 정책 화면에서 노드를 선택하세요. 원격 설정을 업데이트하면 제공자가 관리하는 일부 내용이 교체되며, 로컬에서 직접 수정한 내용은 다음 업데이트 때 덮어써질 수 있습니다. 장기간 유지할 규칙은 클라이언트의 오버라이드, 병합 또는 스크립트 설정에 작성하는 편이 적합합니다. 전체 작업 순서는 사용 가이드에서 확인할 수 있습니다.

POLICY GROUP / PROXY

먼저 정책 그룹을 파악한 뒤 구체적인 노드를 선택하세요

정책 그룹은 특정 연결을 어떤 노드나 하위 정책으로 처리할지 결정합니다. 일반적인 유형으로는 수동 선택, 자동 지연 시간 측정, 장애 조치, 부하 분산이 있습니다. 클라이언트 기본 화면에 표시되는 선택 항목이 모두 개별 서버인 것은 아니며, 다른 정책 그룹이 포함될 수도 있습니다. 처음 연결할 때는 주요 프록시 트래픽을 담당하는 선택 그룹을 찾고, 그룹 안에서 사용할 노드를 선택하세요. 설정 파일만 바꾸고 실제 출구 노드는 바뀌지 않는 상황을 피할 수 있습니다.

지연 시간 테스트는 해당 시점의 네트워크 환경에서 테스트 대상이 보인 응답만 반영하며, 다운로드 속도나 안정성, 모든 웹사이트의 접속 품질과 같지는 않습니다. 노드 지역, 회선 배율, 프로토콜 지원 여부와 서버 부하도 결과에 영향을 줍니다. 더 정확하게 판단하려면 후보 노드를 여러 개 테스트한 뒤 실제 웹페이지나 애플리케이션으로 연결을 확인하고, 실행 로그에서 시간 초과, 핸드셰이크 실패 또는 연결 거부가 발생하는지 살펴보세요. 노드 선택 방법은 사이트의 노드 선별 문서를 참고할 수 있습니다.

RULE ENGINE / MATCH ORDER

도메인, 주소, 최종 정책을 순서대로 매칭

규칙 모드는 설정의 규칙 목록을 위에서부터 확인하고, 조건에 맞는 첫 번째 규칙이 발견되면 이후 매칭을 중단합니다. 일반적인 규칙 유형으로는 도메인, 도메인 접미사, 키워드, IP 주소 대역, 프로세스 이름, 최종 매칭 항목이 있습니다. 규칙 순서는 결과에 직접 영향을 줍니다. 범위가 지나치게 넓은 규칙을 앞에 두면 뒤의 규칙이 처리해야 할 연결을 먼저 가로챌 수 있으며, 최종 규칙이 없거나 대상 정책 그룹 이름이 일치하지 않으면 트래픽 동작이 예상과 달라질 수 있습니다.

사용자 지정 규칙을 추가할 때는 먼저 매칭 대상을 명확히 하고 대상 정책 그룹이 실제로 존재하는지 확인하세요. 도메인 규칙은 특정 호스트 이름에, 도메인 접미사 규칙은 같은 사이트의 여러 하위 도메인에 적합합니다. IP-CIDR은 알려진 주소 대역에 사용할 수 있지만 DNS 해석 건너뛰기 옵션을 활성화할 때는 그 영향을 이해해야 합니다. 사이트 이름만 보고 모든 연결 도메인을 추측하지 마세요. 브라우저 개발자 도구, DNS 조회 결과와 Clash 실행 로그를 활용하면 실제 요청을 파악하는 데 도움이 됩니다. 자세한 문법은 설정 참고에 정리되어 있습니다.

rules:
  - DOMAIN-SUFFIX,example.com,Proxy
  - DOMAIN,api.example.net,Proxy
  - IP-CIDR,192.0.2.0/24,DIRECT,no-resolve
  - MATCH,Proxy

DNS PIPELINE / FAKE IP

도메인 해석 경로와 규칙 판단 기준 통일

DNS 설정은 도메인을 누가 해석하는지, 해석 요청이 어떤 네트워크 경로를 거치는지, 규칙 엔진이 도메인 정보를 유지할 수 있는지에 영향을 줍니다. Fake IP 모드에서는 먼저 예약 주소를 반환한 뒤 코어가 연결을 원래 도메인에 매핑하므로 도메인 규칙으로 트래픽을 처리하기 쉽습니다. Redir Host는 실제 주소를 반환하는 기존 해석 방식에 더 가깝습니다. 두 모드에는 각각 호환성 범위가 있으며, LAN 기기, 게임, 프린터 서비스 또는 실제 주소에 의존하는 일부 앱은 별도로 제외해야 할 수 있습니다.

DNS 문제를 해결할 때는 시스템 DNS, 브라우저 보안 DNS, 클라이언트 수신 포트와 업스트림 리졸버를 구분해야 합니다. 이 중 한 곳만 수정해도 전체 경로가 바뀌지 않을 수 있습니다. 먼저 Clash DNS 모듈이 활성화되어 있는지 확인하고, 시스템 요청이 해당 포트로 들어오는지 점검한 다음 로그에서 조회와 연결 기록을 확인하세요. 도메인은 해석되지만 웹페이지가 열리지 않는다면 규칙 대상, 노드 연결과 IPv6 동작도 계속 점검해야 하며, 모든 연결 실패를 DNS 탓으로 돌려서는 안 됩니다.

NETWORK MODE / TUN

애플리케이션 프록시 설정과 시스템 수준 트래픽 제어 구분

시스템 프록시는 주로 운영체제의 프록시 설정을 따르는 앱에 영향을 줍니다. 대부분의 브라우저와 데스크톱 소프트웨어가 여기에 해당합니다. 일부 게임, 명령줄 도구, 스토어 앱 또는 자체적으로 네트워크 연결을 생성하는 프로그램은 이 설정을 읽지 않습니다. TUN 모드는 가상 네트워크 인터페이스를 통해 더 넓은 범위의 TCP, UDP와 DNS 트래픽을 처리하므로 통합 제어가 필요한 상황에 적합하지만, 관리자 권한, 라우팅 테이블, 네트워크 인터페이스와 보안 소프트웨어 호환성도 함께 고려해야 합니다.

처음 설정할 때는 시스템 프록시로 기본 연결을 먼저 확인하는 것이 좋습니다. 구독, 노드와 규칙이 정상인지 확인한 후 애플리케이션 요구 사항에 따라 TUN을 활성화하세요. TUN을 켠 뒤 인터넷이 끊기면 먼저 TUN을 끄고 네트워크를 복구한 다음 서비스가 정상적으로 시작되었는지, 가상 인터페이스가 생성되었는지, DNS 가로채기 설정이 현재 시스템과 일치하는지, 다른 VPN이나 가상 네트워크 카드와 충돌하지 않는지 확인하세요. Windows 서비스 모드, macOS 시스템 확장과 Linux 권한 설정은 처리 방식이 서로 다릅니다.