Clash 자주 묻는 질문
과 문제 해결

커널은 프록시 연결, DNS 조회, 규칙 매칭을 담당합니다. 그래픽 클라이언트는 설정 가져오기, 프록시 그룹 선택, 시스템 프록시 관리를 담당합니다. Mihomo는 Clash 생태계에서 계속 개발되는 호환 커널이지만, 클라이언트마다 포함된 커널과 지원하는 설정 항목이 다를 수 있습니다. 문제를 확인할 때는 설정 → 정보 또는 커널 정보에서 클라이언트 이름과 커널 버전을 먼저 기록하세요. Clash를 설치했다고만 설명해서는 정확한 원인을 파악하기 어렵습니다. 다른 클라이언트에서 읽히는 설정이라고 해서 현재 커널도 모든 항목을 지원한다는 뜻은 아닙니다. unsupported 또는 unknown field 오류가 나타나면 프로그램 화면을 반복해서 재설치하기보다 현재 커널의 지원 범위에 맞게 설정을 수정하세요.

클라이언트와 구독 서비스는 별개입니다. 프로그램을 설치해도 프록시 노드가 자동으로 제공되지는 않습니다. 직접 설정 파일을 가져오거나 서비스 제공업체가 제공하는 Clash 호환 구독을 사용해야 합니다. 보통 설정 또는 Profiles 화면에서 새로 만들기 → URL에서 가져오기를 선택하고, 다운로드가 끝나면 해당 설정을 선택한 뒤 프록시 화면에서 프록시 그룹을 고릅니다. 서비스 제공업체의 로그인 페이지 주소를 구독 주소로 사용하면 안 되며, 공유 링크 하나만 들어 있는 내용을 전체 YAML 설정으로 착각하지 마세요. 구독 URL의 token은 계정 접근 정보와 같으므로 스크린샷, 질문글, 공개 로그에서 반드시 가려야 합니다. 유출됐다면 서비스 제공업체 관리 페이지에서 구독 링크를 재설정하세요.

평소에는 규칙 모드를 사용하는 것이 일반적입니다. 트래픽이 rules에 따라 차례로 매칭된 뒤 해당 프록시 그룹으로 전달됩니다. 전역 모드는 커널에 들어온 요청에 전역 정책을 적용하지만 모든 앱의 트래픽을 자동으로 가로채지는 않습니다. 시스템 프록시, TUN 또는 명시적 프록시를 사용하지 않는 프로그램은 커널을 우회할 수 있습니다. 직접 연결 모드에서는 커널에 들어온 연결이 대상에 바로 접속합니다. 전역 모드가 더 빠른 것은 아닙니다. 라우팅 선택만 바꿀 뿐 회선 성능을 개선하지는 않습니다. 문제를 확인할 때 같은 노드로 규칙 모드와 전역 모드를 비교해 보세요. 규칙 모드에서만 실패한다면 적용된 규칙과 프록시 그룹을 우선 확인하세요. 테스트가 끝나면 규칙 모드로 되돌리고, 전역 그룹과 사용 중인 그룹이 서로 다른 노드를 선택하지 않았는지도 확인하세요.

지연 시간 테스트는 특정 대상에 보낸 작은 요청의 응답 시간을 측정합니다. 지속적인 다운로드 대역폭을 측정하는 것은 아닙니다. 측정 대상, 시간 제한, 프록시 경유 여부에 따라 결과가 달라집니다. 지연 시간이 짧더라도 저녁 시간대에 회선 용량이 충분하다는 뜻은 아닙니다. 실제 연결에 테스트한 노드가 사용되는지 먼저 확인하세요. 자동 프록시 그룹이 다른 회선을 선택했을 수 있습니다. 같은 파일을 같은 시간대에 다운로드해 비교해 보세요. 다운로드 속도는 대상 사이트의 속도 제한, Wi-Fi 환경, 네트워크 간 혼잡, 서비스 제공업체의 사용량 제한에도 영향을 받습니다. 모든 노드를 짧은 간격으로 반복 측정하지 마세요. 부하가 늘거나 제한이 걸릴 수 있습니다. timeout이 표시되어도 해당 테스트가 실패했다는 의미일 뿐입니다. 실제 접속 상태와 연결 로그를 함께 확인하고, 숫자 하나만으로 노드가 완전히 끊겼다고 판단하지 마세요.

먼저 다운로드 실패와 설정 파싱 실패를 구분하세요. 로그에 401 또는 403이 표시되면 구독 링크가 재설정됐는지, 요금제가 만료됐는지, 서비스 제공업체가 요청을 제한하는지 확인하세요. 403은 접근 보호 기능 때문에 발생할 수도 있으므로 반드시 비밀번호 오류인 것은 아닙니다. 연결 시간 초과라면 시스템 시간이 정확한지, 현재 네트워크에서 구독 도메인에 접속할 수 있는지, 구독 업데이트가 이미 사용할 수 없는 프록시를 경유하도록 설정됐는지 확인하세요. 업데이트 경로를 바꿀 수 있다면 잠시 직접 연결로 전환해 다시 시도해 보세요. 다운로드는 성공했지만 가져오기에 실패한다면 응답 내용이 YAML이 아니라 로그인 페이지나 오류 안내인지 확인하세요. 서비스 제공업체 관리 페이지에서 Clash 호환 링크를 다시 복사하되, 쿼리 매개변수를 임의로 지우지 마세요. 전체 링크를 공개 게시판에 올려서도 안 됩니다.

오류에 표시된 줄 번호와 필드 경로를 확인한 뒤 해당 줄과 바로 위 줄을 살펴보세요. YAML 들여쓰기에는 공백을 사용하고 Tab은 섞지 마세요. 목록 항목 앞에는 하이픈을 붙이고, 키 이름 뒤에는 영문 콜론을 사용합니다. 값에 특수 문자가 있으면 따옴표로 감쌀 수 있습니다. 코드를 복사할 때 전각 문장 부호가 섞이거나, dns 아래에 있어야 할 필드가 최상위에 놓이거나, 같은 단계에 rules를 두 번 선언하는 경우가 흔합니다. 수정하기 전에 원본 파일을 백업하고 한 번에 한 곳씩 고친 다음 클라이언트의 설정 검사 기능을 사용하세요. 구문 검사를 통과한 뒤 프록시 그룹이나 노드가 없다는 오류가 뜬다면 이름 참조를 확인해야 합니다. 이는 들여쓰기 문제가 아닙니다. 원격 구독 파일은 업데이트할 때 수정 내용이 덮어써질 수 있으므로 장기적으로 유지할 설정은 클라이언트의 덮어쓰기 또는 병합 기능에 넣으세요.

먼저 현재 클라이언트와 커널이 TUN을 지원하는지 확인한 다음 시작 로그에서 구체적인 실패 원인을 찾으세요. Windows에서는 보통 클라이언트의 서비스 모드를 설치하거나 활성화해야 합니다. 필요한 경우 클라이언트 안내에 따라 최초 설정을 관리자 권한으로 완료하세요. macOS에서는 클라이언트 구현 방식에 따라 백그라운드 서비스나 네트워크 확장을 승인해야 할 수 있습니다. Linux에서는 /dev/net/tun이 있는지, 서비스에 인터페이스 생성과 라우팅 변경에 필요한 권한이 있는지 확인하세요. 데스크톱 프로그램 전체를 계속 높은 권한으로 실행하는 것을 유일한 해결책으로 삼지 마세요. 라우팅 충돌을 피하려면 다른 VPN의 가상 네트워크 어댑터도 잠시 비활성화하세요. 트래픽을 가로채는 방식은 한 번에 하나만 켜세요. 로그에서 인터페이스 생성 성공을 확인한 뒤 DNS와 앱 연결을 점검하세요.

시작할 때 시스템의 VPN 연결 요청을 허용했고 클라이언트 실행 알림이 표시되는지 먼저 확인하세요. 일반적으로 Android에서는 같은 사용자 환경에서 활성 VPN을 하나만 사용할 수 있습니다. 다른 VPN이나 VPN 인터페이스를 사용하는 필터링 도구가 현재 연결을 대체할 수도 있습니다. 화면을 잠근 뒤에만 연결이 끊긴다면 시스템 설정 → 앱 → 해당 클라이언트 → 배터리에서 백그라운드 실행을 허용하거나 제한 없음으로 설정하세요. 제조사별 자동 시작, 백그라운드 활동, 작업 잠금 옵션도 확인하세요. 메뉴 이름은 시스템마다 다릅니다. 앱을 최근 앱 목록에 남겨 두는 것만으로 백그라운드 실행이 허용됐다고 볼 수는 없습니다. 알림은 계속 표시되는데 트래픽이 끊긴다면 로그에서 네트워크 전환 또는 노드 재연결 실패 여부를 확인하고 Wi-Fi와 모바일 네트워크를 각각 테스트하세요.

시스템 프록시 스위치는 운영체제에 프록시 주소를 설정할 뿐, 커널이 정상적으로 연결을 수신하고 있다는 뜻은 아닙니다. 로그에서 mixed-port의 실제 수신 주소와 포트를 확인한 뒤 시스템 네트워크 설정의 HTTP 및 HTTPS 프록시와 비교하세요. 브라우저 확장 프로그램, 사용자 지정 프록시 설정, 일부 앱 자체의 네트워크 옵션이 시스템 설정을 덮어쓸 수 있으므로 테스트할 때는 이런 설정을 잠시 끄세요. 대상에 접속한 뒤 클라이언트 연결 화면을 확인하세요. 기록이 전혀 없다면 요청이 아직 커널에 들어오지 않은 것입니다. 기록은 있지만 DIRECT로 표시된다면 시스템 프록시를 계속 바꾸기보다 규칙과 프록시 그룹을 확인하세요. 일부 앱은 시스템 프록시를 따르지 않으므로 프록시를 직접 설정하거나 TUN을 사용해야 합니다. 프록시 우회 목록도 확인하세요. 대상 도메인이 제외되어 있으면 예상대로 프록시를 사용하지 않습니다.

포트를 바꾸기 전에 먼저 어떤 프로세스가 사용 중인지 확인하세요. Windows에서는 netstat -ano | findstr :7890을 실행한 뒤 PID로 프로세스를 찾을 수 있습니다. macOS 또는 Linux에서는 lsof -nP -iTCP:7890 -sTCP:LISTEN을 사용하세요. 다른 클라이언트 인스턴스가 사용 중이라면 기존 인스턴스를 정상적으로 종료하세요. 정체를 모르는 시스템 프로세스를 강제 종료하지 마세요. 포트를 바꿔야 한다면 아래 설정처럼 혼합 포트를 7891로 변경하고 로컬에서만 사용할 수 있도록 유지하세요. 저장 후 설정을 다시 불러와 커널이 정상적으로 수신하는지 확인한 다음 시스템 프록시를 껐다가 다시 켜 주소를 동기화하세요. 브라우저, 터미널, 프록시를 직접 설정한 다른 도구의 포트도 함께 변경해야 합니다. 클라이언트에 별도의 포트 설정 화면이 있다면 최종 적용된 설정과 로그를 기준으로 확인하세요.

mixed-port: 7891
allow-lan: false

휴대폰에서 컴퓨터의 프록시 포트에 연결하려면 보통 컴퓨터에서 allow-lan을 켜고, 수신 주소가 LAN 연결을 허용하도록 설정해야 합니다. 127.0.0.1만 수신하도록 설정하면 다른 기기에서는 접속할 수 없습니다. 두 기기는 서로 통신할 수 있는 신뢰할 수 있는 로컬 네트워크에 연결해야 합니다. 휴대폰 Wi-Fi의 수동 HTTP 프록시에 컴퓨터의 LAN IP와 실제 mixed-port를 입력하세요. 127.0.0.1을 입력하면 안 됩니다. 컴퓨터 방화벽은 필요한 네트워크 범위만 허용하고 커널이 지원하는 경우 프록시 인증도 설정하세요. 라우터에서 프록시 포트를 공용 인터넷에 노출하지 마세요. 일부 무선 네트워크에서는 클라이언트 격리가 적용되어 같은 핫스팟에 연결해도 기기끼리 통신할 수 없습니다. 또한 휴대폰의 HTTP 프록시가 모든 앱과 프로토콜을 가로채는 것은 아닙니다. 먼저 브라우저로 기본 연결을 확인하세요.

먼저 해당 앱이 실제로 로컬 프록시에 의존하는지 확인하세요. 일부 UWP 또는 AppContainer 앱은 네트워크 격리 때문에 로컬 루프백 주소에 직접 접속할 수 없습니다. 따라서 브라우저가 정상이라고 해서 이 문제를 배제할 수는 없습니다. 클라이언트에 UWP 루프백 또는 Loopback 도구가 있다면 필요한 앱에 루프백 예외를 추가하세요. CheckNetIsolation LoopbackExempt -s로 기존 예외를 확인한 다음 정확한 앱 패키지 패밀리 이름을 기준으로 Windows 도구 안내에 따라 추가할 수도 있습니다. 이 작업에는 보통 관리자 권한이 필요합니다. 모든 앱의 격리를 한꺼번에 해제하지 말고 루프백 예외를 모든 연결 문제의 해결책으로 여기지도 마세요. TUN을 사용한 뒤 정상 작동한다면 기존 시스템 프록시 경로를 점검할 필요가 있습니다. 그래도 실패한다면 앱 계정, DNS, 적용된 규칙을 계속 확인하세요.

먼저 프록시를 끈 상태에서 로컬 네트워크가 정상적으로 인터넷에 연결되는지 확인하세요. 그런 다음 구독이 유효한지, 사용 가능한 데이터가 남았는지, 시스템 날짜와 시간이 정확한지 점검하세요. 노드를 테스트할 때 로그도 함께 확인해 서버 연결 시간 초과, TLS 핸드셰이크 오류, 도메인 조회 실패를 구분하세요. 세 문제는 해결 방법이 서로 다릅니다. 일괄 속도 테스트만 실패한다면 실제 접속 가능한 테스트 URL로 바꾸고 대상 사이트도 직접 열어 보세요. 테스트 주소 문제를 모든 회선의 장애로 오해하지 않도록 주의하세요. 프록시 클라이언트나 VPN이 두 개 동시에 실행 중이지 않은지도 확인하세요. 같은 노드가 다른 네트워크에서는 정상이라면 현재 네트워크의 제한과 로컬 라우팅을 우선 점검하세요. 여러 기기와 네트워크에서 모두 실패할 때는 서비스 제공업체에 서버 상태를 문의하세요.

그럴 수 있지만 먼저 로그에서 조회 실패, 시간 초과 또는 비정상 주소가 나타나는지 확인하세요. 시스템의 nslookup은 보통 시스템 DNS 리졸버를 조회하므로 앱이 커널을 거칠 때 사용하는 조회 경로와 다를 수 있습니다. 따라서 nslookup이 성공해도 커널 DNS가 정상이라고 단정할 수는 없습니다. 현재 적용된 설정에서 dns.enable, enhanced-mode, nameserver를 확인하고 업스트림 리졸버에 현재 네트워크에서 접속할 수 있는지 점검하세요. fake-ip를 사용하는 경우 TUN, DNS 가로채기, 앱 캐시 설정이 서로 맞는지도 확인해야 합니다. 모드를 바꾼 뒤에는 영향을 받는 앱을 다시 시작하고 DNS 캐시를 지울 수 있습니다. 낯선 DNS 설정 전체를 그대로 복사하거나 fallback을 추가하면 반드시 DNS 오염이 해결된다고 생각하지 마세요. 먼저 구독의 원래 설정으로 복원한 뒤 한 번에 필드 하나씩 바꾸며 같은 도메인의 결과를 확인하세요.

가장 흔한 원인은 시스템이 더 이상 연결을 수신하지 않는 로컬 프록시를 계속 가리키는 것입니다. Windows에서는 설정 → 네트워크 및 인터넷 → 프록시에서 수동 프록시를 확인하세요. macOS에서는 시스템 설정 → 네트워크 → 현재 연결 → 세부사항 → 프록시에서 HTTP, HTTPS, SOCKS 설정을 확인하세요. 클라이언트가 남긴 것이 확실한 항목만 끄세요. 회사 네트워크의 기존 프록시는 먼저 기록하고 함부로 지우지 마세요. 터미널에서 HTTP_PROXY, HTTPS_PROXY, ALL_PROXY를 설정했다면 현재 세션과 시작 설정도 확인해야 합니다. 앞서 TUN을 사용했다면 클라이언트를 다시 시작하고 TUN을 끈 뒤 정상적으로 종료해 프로그램이 라우팅과 DNS 설정을 정리하도록 하세요. 그래도 문제가 지속된다면 모든 네트워크 설정을 처음부터 초기화하지 말고 현재 설정을 기록한 뒤 네트워크에 다시 연결하세요.

재설치하기 전에 설정과 로그부터 보존하세요. 클라이언트 데이터 디렉터리나 시스템 충돌 보고서에서 종료 직전의 마지막 로그를 찾아 설정 파싱 실패, 커널 파일 실행 실패, 권한 거부, 그래픽 실행 환경 누락을 구분하세요. 최근 설정을 수정했다면 먼저 백업한 뒤 마지막으로 정상 작동한 버전으로 복원해 보세요. 설정을 되돌려도 계속 종료된다면 설치 파일의 아키텍처가 시스템과 맞는지 확인하고 보안 소프트웨어가 커널 파일을 격리했는지 살펴보세요. 문제를 피하려고 보안 기능 전체를 계속 꺼 두지 마세요. 재설치 전에 구독, 덮어쓰기 설정, 프록시 선택을 백업했는지 확인하세요. 프로그램을 다시 설치해도 손상된 사용자 데이터가 제거되지 않을 수 있습니다. 문의할 때는 클라이언트와 커널 버전, 시스템 정보, 재현 단계, 민감 정보를 가린 로그를 제공하고 구독 인증 정보는 첨부하지 마세요.