Clash 자주 묻는 질문

Clash는 프록시 도구 생태계의 프로젝트 이름이고, mihomo는 Clash 설정과 호환되면서 기능을 확장해 온 코어입니다. GUI 클라이언트는 구독 관리, 정책 선택, 시스템 프록시 설정, 로그 표시를 담당하며 실제 연결은 대개 코어가 처리합니다. 같은 클라이언트라도 배포 버전에 따라 탑재된 코어가 다를 수 있으므로 화면에 표시된 이름만으로 특정 설정 항목의 지원 여부를 판단하면 안 됩니다. 문제를 확인하기 전에 정보 화면이나 시작 로그에서 클라이언트 이름, 코어 이름과 버전을 확인한 뒤 해당 설정 문서를 참고하세요. 다른 코어용 설정 블록을 현재 설정 파일에 그대로 섞어 넣지 마세요.

일상적인 사용에는 보통 규칙 모드가 적합합니다. 연결은 rules를 위에서 아래로 확인해 지정된 정책 그룹, DIRECT 또는 REJECT로 전달됩니다. 전역 모드는 클라이언트가 가로챈 연결에 전역 정책을 적용하지만, 모든 프로세스가 자동으로 프록시를 사용하는 것은 아닙니다. 실제로 가로채는 범위는 시스템 프록시나 TUN 설정에 따라 달라집니다. 직접 연결 모드는 가로챈 연결을 대상에 바로 연결하므로 비교 테스트에 활용할 수 있습니다. 테스트할 때는 모드만 바꾸고 DNS나 노드는 동시에 변경하지 마세요. 같은 대상의 연결 기록을 비교해야 차이가 분할 규칙 때문인지 출구 때문인지 확인할 수 있습니다.

클라이언트는 연결과 트래픽 분기 기능을 제공하며, 설치한다고 해서 사용할 수 있는 출구가 자동으로 생기지는 않습니다. 구독은 직접 관리하는 서버, 소속 조직에서 제공하는 서비스 또는 이용 권한이 명확한 서비스 제공업체에서 받으세요. 공개된 무료 노드는 금방 작동하지 않게 될 수 있고 연결 정보를 기록할 수도 있으므로 민감한 용도로 사용하지 않는 편이 좋습니다. 가져오기 전에 출처, 유효 기간, 호환 클라이언트를 확인하세요. 이 사이트는 노드 구독을 제공하지 않습니다. 구독 주소에는 계정 식별 정보가 포함되는 경우가 많으므로 비밀번호처럼 관리하세요. 도움을 요청할 때는 전체 주소, 노드 비밀번호, 개인정보를 가리고 설정 파일을 그대로 공개하지 마세요.

시스템 프록시는 운영체제에 HTTP 또는 SOCKS 프록시 주소를 등록합니다. 이 주소를 사용할지는 앱의 네트워크 구현 방식에 따라 달라지며, 일부 게임과 명령줄 프로그램, 자체 네트워크 스택을 사용하는 앱은 시스템 프록시를 따르지 않습니다. TUN은 가상 네트워크 인터페이스와 라우팅을 이용해 트래픽을 가로채므로 적용 범위가 더 넓은 편이지만, 적절한 권한이 필요하고 DNS·라우팅·다른 VPN과의 조정도 필요합니다. 먼저 시스템 프록시로 기본 연결을 확인한 뒤 앱에 필요한 경우 TUN을 사용하세요. TUN은 노드 속도를 높이는 기능이 아니므로 출구 장애, 구독 만료, 서버의 연결 거부를 해결할 수 없습니다.

먼저 업데이트 로그에서 HTTP 상태 코드와 파싱 오류를 확인하세요. 403은 대개 서버가 요청을 거부했다는 뜻이지만, 정확한 원인은 제공업체에 문의해야 합니다. 계정 상태와 구독 유효 기간, 클라이언트 종류를 확인하세요. 파싱에 실패한다면 주소에서 호환되는 설정 파일이 반환되는지 확인하세요. 로그인 페이지, 오류 페이지 또는 일반 노드 목록은 설정 파일이 아닙니다. 클라이언트에서 업데이트 연결을 직접 연결 또는 프록시로 선택할 수 있다면 각각 한 번씩 테스트해 다운로드 경로 문제를 구독 만료로 오인하지 않도록 하세요. 아직 사용할 수 있는 기존 설정은 보관하고, 계속 삭제한 뒤 다시 만들지 마세요. 제공업체에 문의할 때는 민감한 정보를 가린 오류 내용만 전달하세요.

먼저 오류가 표시된 줄 주변의 들여쓰기, 콜론, 목록의 하이픈을 확인하세요. YAML 들여쓰기는 공백을 사용하며 탭을 섞으면 안 됩니다. 다음으로 구문 오류와 필드 검증 오류를 구분하세요. 구문 오류가 있으면 파일을 파싱할 수 없고, 필드 검증 오류는 정책 이름이 없거나 노드 필드가 누락됐거나 현재 코어가 해당 기능을 지원하지 않는 경우가 많습니다. proxy-groups와 rules에서 참조하는 이름이 정확히 일치하는지 확인하고 MATCH가 규칙의 마지막에 있는지도 살펴보세요. 한 번에 한 곳만 수정한 다음 저장하고 클라이언트의 설정 검사 기능을 실행하세요. 계정 정보가 들어 있는 파일은 공개 온라인 파서에 올리지 마세요.

먼저 로그에서 가상 인터페이스 생성 실패, 권한 부족, 라우팅 충돌을 구분하세요. Windows 클라이언트는 서비스 모드를 설치하거나 시작해야 하는 경우가 많고, 일부 클라이언트는 관리자 권한으로 실행할 수도 있습니다. macOS에서는 보조 서비스 권한을 허용해야 할 수 있으며, Linux에서는 서비스 권한과 /dev/net/tun 사용 가능 여부가 중요합니다. 현재 클라이언트의 안내에 따라 필요한 최소 권한만 부여하고, 출처를 알 수 없는 스크립트를 그대로 실행하지 마세요. 라우팅을 가로채는 다른 VPN을 끈 뒤 다시 시도하세요. 인터페이스는 만들어졌는데 접속되지 않는다면 권한을 계속 높이기보다 DNS와 라우팅을 확인해야 합니다.

시스템 트레이, 구독 관리, 시각적인 정책 선택 기능이 필요하다면 GUI 클라이언트를 우선 고려하세요. 서버나 라우터에서는 환경에 맞춰 mihomo 코어를 배포할 수 있습니다. 먼저 uname -m을 실행해 아키텍처를 확인하세요. x86_64는 보통 AMD64, aarch64는 보통 ARM64에 해당합니다. 그런 다음 배포판에 맞는 deb, rpm 또는 프로젝트에서 실제 제공하는 다른 형식을 선택하세요. 프로세서 브랜드만 보고 설치 패키지를 추측하지 마세요. 설치 후에는 데스크톱 의존성, 서비스 권한, 설정 파일 경로도 확인해야 합니다. 코어가 실행된다고 해서 시스템이 이미 트래픽을 가로채는 것은 아니므로 프록시 주소나 TUN 라우팅도 점검하세요.

연결 패널에서 실제 요청을 찾아 대상 도메인, 대상 IP, 적용된 규칙, 최종 출구를 확인하세요. 브라우저 주소 표시줄만 봐서는 부족합니다. 규칙은 순서대로 적용되므로 범위가 넓은 DOMAIN-KEYWORD, GEOIP 또는 앞쪽에 있는 MATCH가 뒤의 정밀 규칙을 먼저 처리할 수 있습니다. 연결 정보에 IP만 표시된다면 DNS 매핑이나 스니핑 결과가 도메인 규칙에 영향을 줄 수도 있습니다. 임시로 도메인을 정확히 지정한 규칙을 추가해 관련 범위가 넓은 규칙보다 앞에 배치한 뒤 기존 연결을 끊고 다시 요청하세요. 규칙이 적용되는 것을 확인한 후 장기적으로 사용할 규칙을 정리하세요. 모든 분기 규칙을 점검하는 대신 전역 모드로 바꾸지는 마세요.

구독에서 생성된 설정을 직접 수정하면 다음 업데이트 때 원격 내용으로 덮어써질 수 있습니다. 규칙, DNS, 정책 변경을 계속 유지하려면 현재 클라이언트가 지원하는 오버라이드, 병합 또는 설정 스크립트 기능을 사용하고, 먼저 전체 설정을 처리하는지 일부 설정만 처리하는지 확인하세요. 특히 배열은 항목이 추가되는 대신 통째로 교체될 수 있으며, 규칙을 삽입하는 위치도 적용 결과에 영향을 줍니다. 수정 전에 원본 설정을 백업하고, 업데이트 후에는 편집기 내용만 보지 말고 최종 적용된 설정을 확인하세요. 다른 클라이언트의 오버라이드 구문을 그대로 가져오지 마세요. 클라이언트마다 병합 방식이 다릅니다.

로그인 후 클라이언트 실행, 시스템 시작 시 백그라운드 서비스 실행, 시작 후 시스템 프록시 복구는 서로 다른 기능이며 하나의 스위치로 제어되지 않을 수 있습니다. 데스크톱에서는 클라이언트에서 시작 시 자동 실행을 켠 뒤 프록시 설정이 유지되는지 확인하세요. TUN을 사용한다면 필요한 서비스도 자동으로 시작되는지 점검해야 합니다. 재부팅한 뒤 프로세스, 현재 설정, 실제 연결 기록을 확인하세요. 시스템 트레이 아이콘만 보고 정상 작동한다고 판단하지 마세요. Linux의 systemd 서비스는 실행 사용자와 설정 파일 경로도 확인해야 합니다. 시작 시 네트워크가 연결되지 않아 구독 업데이트에 실패했다면 인터넷 연결 후 직접 업데이트해 확인하세요.

먼저 컴퓨터와 기기를 서로 통신할 수 있는 같은 LAN에 연결하세요. 클라이언트에서 LAN 연결 허용을 켜고 allow-lan, bind-address, 실제 수신 포트를 확인합니다. 기기의 프록시 주소에는 컴퓨터의 LAN IP를 입력하세요. 127.0.0.1을 입력하면 안 됩니다. 포트는 현재 설정의 HTTP 또는 mixed-port를 입력합니다. 그래도 연결되지 않으면 방화벽의 인바운드 규칙, 게스트 네트워크 격리, 컴퓨터 IP 변경 여부를 확인하세요. 신뢰할 수 있는 네트워크에서만 수신을 허용하고 필요에 따라 authentication을 설정해 접속 가능한 출처를 제한하세요. 프록시 포트를 인터넷에 직접 공개하지 말고, 문제를 확인한다고 방화벽을 통째로 끄지도 마세요.

먼저 프록시를 끄고 로컬 네트워크에서 인터넷에 접속되는지 확인하세요. 그런 다음 구독이 만료됐는지, 노드 주소를 확인할 수 있는지, 시스템 시간이 정확한지 살펴봅니다. 지연 시간 테스트 실패는 해당 테스트 요청이 완료되지 않았다는 뜻일 뿐, 노드를 전혀 사용할 수 없다는 증거는 아닙니다. 실제 웹 요청과 코어 로그를 함께 확인하세요. 특정 노드만 실패한다면 정상 작동이 확인된 다른 출구로 바꿔 보세요. 모든 노드가 실패한다면 DNS, 네트워크 제한, 인증 정보, 다른 VPN과의 충돌을 중점적으로 확인합니다. 다른 네트워크에서 각각 다시 테스트하면 원인을 좁히는 데 도움이 됩니다. 한 번에 조건 하나만 바꾸고 오류가 발생했을 때의 로그를 보관하세요.

먼저 코어가 실행 중인지, 수신 포트와 시스템에 등록된 값이 일치하는지 확인한 다음 연결 패널에 해당 앱의 요청이 표시되는지 살펴보세요. 브라우저는 별도의 프록시 확장 프로그램이나 자체 설정을 사용할 수 있습니다. 명령줄 도구는 HTTP_PROXY, HTTPS_PROXY 같은 환경 변수만 읽을 수도 있습니다. 변수 이름에 HTTPS가 포함되어 있다고 해서 프록시 연결에 HTTPS 프로토콜을 사용해야 하는 것은 아닙니다. 프록시 우회 목록, 이전 프록시 프로그램, 앱별 설정을 확인하고 변경한 뒤 대상 프로그램을 다시 시작하세요. 앱이 시스템 프록시를 따르지 않는다면 전용 프록시 주소를 설정하거나 기본 연결이 정상인지 확인한 뒤 TUN을 사용하고, 트래픽이 가로채지는 범위도 다시 점검하세요.

일부 AppContainer 앱은 루프백 격리 때문에 로컬 프록시 주소에 직접 연결할 수 없습니다. 먼저 일반 브라우저가 같은 프록시를 사용하는지 확인한 다음 클라이언트에서 제공하는 UWP 루프백 도구를 사용해 실제로 필요한 앱만 예외로 추가하세요. 도구 실행에 관리자 권한이 필요할 수 있습니다. 관리자 터미널에서 CheckNetIsolation LoopbackExempt -s를 실행해 기존 예외를 확인할 수도 있지만, 모든 앱을 일괄 허용하지 마세요. 예외를 추가한 뒤에는 대상 앱을 완전히 종료했다가 다시 실행하세요. 그래도 실패한다면 시스템 프록시, 앱 오류 코드, 연결 로그를 확인하세요. 루프백 예외로 구독이나 노드 문제를 해결할 수는 없습니다.

먼저 TUN을 끄고 시스템 프록시만 켠 상태와 비교한 뒤 가상 인터페이스, 기본 경로, DNS 수신 주소, dns-hijack이 실제로 적용됐는지 확인하세요. 도메인은 열리지 않지만 IP로는 접속된다면 DNS 경로를 먼저 살펴보세요. 브라우저의 보안 DNS, 시스템 암호화 DNS, 다른 VPN이 예상한 경로를 우회할 수 있습니다. fake-ip 모드는 도메인 매핑과 라우팅이 함께 작동해야 하므로 enhanced-mode만 바꾸면 해결되지 않습니다. 설정을 수정한 뒤 기존 연결을 끊고 다시 조회한 다음 연결 로그와 DNS 테스트를 함께 확인하세요. 검사 페이지에 표시되는 DNS 서비스 위치는 참고 정보일 뿐이며, 위치만으로 유출 여부를 단정할 수 없습니다.