Clash 자주 묻는 질문 및 문제 해결
문제가 발생한 위치를 기준으로 범위를 나눠 점검하세요. 먼저 클라이언트·코어·설정의 관계를 확인한 뒤 구독 가져오기, 시스템 프록시, TUN, 규칙 라우팅, DNS를 차례로 살펴봅니다. 각 답변에는 실행 가능한 판단 순서가 포함되어 있습니다.
기초 지식
인터페이스, 코어, 설정, 규칙, 연결 출구의 관계부터 구분해야 이후 구독 문제를 클라이언트 오류로 잘못 판단하지 않을 수 있습니다.
Clash 클라이언트, 코어, 설정 파일은 각각 어떤 역할을 하나요?
클라이언트는 그래픽 인터페이스, 구독 관리, 시스템 프록시 전환, 시작 시 자동 실행 같은 시스템 통합 기능을 제공합니다. mihomo 같은 코어는 연결을 수립하고 규칙을 해석하며 DNS와 트래픽 전달을 처리합니다. YAML 설정 파일에는 노드, 정책 그룹, 규칙 및 DNS 매개변수가 저장됩니다. 문제가 발생하면 인터페이스 조작, 코어 실행, 설정 내용 중 어디에 해당하는지 먼저 판단해야 같은 재설치를 반복하는 일을 피할 수 있습니다.
구독 링크, 단일 노드 링크, YAML 파일은 어떻게 다른가요?
구독 링크는 일반적으로 서비스 제공자가 생성하며, 클라이언트는 이 주소에서 전체 노드와 규칙 설정을 정기적으로 가져옵니다. 단일 노드 링크는 하나의 연결 노드만 설명하므로 완전한 Clash 설정을 대신할 수 없습니다. YAML 파일은 로컬에서 가져올 수 있는 전체 설정입니다. 가져오기 전에 클라이언트 입력란이 구독 URL, 노드 링크, 로컬 설정 파일 중 무엇을 요구하는지 확인하세요. 형식이 맞지 않으면 파싱에 실패합니다.
규칙 모드, 전역 모드, 직접 연결 모드 중 무엇을 선택해야 하나요?
일상적인 사용에는 설정의 규칙에 따라 트래픽을 프록시로 보낼지 직접 연결할지 결정하는 규칙 모드가 적합합니다. 전역 모드는 가로챌 수 있는 대부분의 트래픽을 현재 전역 정책으로 보내므로 특정 노드가 대상 웹사이트에 접속할 수 있는지 임시로 확인할 때 유용합니다. 직접 연결 모드는 프록시를 우회해 문제가 프록시 경로에서 발생했는지 판단하는 데 사용할 수 있습니다. 점검이 끝나면 불필요한 트래픽이 한 출구로 몰리지 않도록 규칙 모드로 되돌리는 것이 좋습니다.
Clash의 mixed-port, HTTP 포트, SOCKS 포트는 어떻게 다른가요?
mixed-port는 하나의 포트에서 HTTP와 SOCKS5 프록시 요청을 모두 받아 대부분의 데스크톱 프로그램에 입력하기 편리합니다. port는 HTTP 프록시만 제공하고, socks-port는 SOCKS5 프록시만 제공합니다. 시스템 프록시는 보통 클라이언트가 자동으로 설정하므로 직접 입력할 필요가 없습니다. 다른 프로그램을 Clash에 연결할 때는 클라이언트에 현재 표시된 수신 주소와 포트를 사용하고, 다른 프로그램이 해당 포트를 사용하고 있지 않은지 확인하세요.
정책 그룹과 노드는 어떤 관계인가요?
노드는 실제 연결 출구이고, 정책 그룹은 여러 노드나 다른 정책을 묶어 규칙에서 사용할 수 있게 합니다. 규칙은 보통 고정 노드가 아니라 정책 그룹을 가리키므로 그룹 안의 선택 항목을 바꾸면 해당 트래픽의 출구가 변경됩니다. 노드를 바꾼 뒤에도 웹사이트가 같은 경로로 연결된다면 적용된 규칙이 최종적으로 어느 정책 그룹을 가리키는지 확인하고, 이름이 비슷한 다른 그룹이 아닌 해당 그룹을 수정했는지 점검하세요.
설치 및 설정
가져오기에 성공했다고 해서 트래픽이 이미 가로채어진 것은 아닙니다. 구독 형식, 코어 실행, 시스템 권한, 운영체제 네트워크 설정을 각각 확인해야 합니다.
Clash 구독 링크를 가져오지 못할 때 무엇을 확인해야 하나요?
먼저 브라우저에서 구독 주소에 여전히 접속할 수 있는지 확인하고, 복사 과정에서 공백·줄바꿈·끝의 문장 부호가 포함되지 않았는지 살펴보세요. 이어서 클라이언트가 구독에서 반환하는 형식을 지원하는지와 시스템 시간이 정확한지 확인합니다. 주소에서 콘텐츠는 다운로드되지만 클라이언트가 파싱 오류를 표시한다면 반환 내용이 Clash YAML이 아니거나, 설정 들여쓰기가 손상되었거나, 필수 필드가 누락되었을 가능성이 큽니다. 이 경우 호환 형식으로 구독을 다시 생성하세요.
구독이 만료 또는 무효로 표시되거나 401, 403을 반환하면 어떻게 해야 하나요?
401 또는 403은 대개 구독 인증 정보가 유효하지 않거나, 주소가 재설정되었거나, 요금제 상태가 변경되었거나, 서버가 요청을 제한하고 있음을 뜻합니다. 클라이언트에서 새로 고침만 반복하지 말고 먼저 구독 서비스 페이지에 로그인해 계정과 구독 상태를 확인한 뒤 최신 주소를 복사해 기존 설정을 교체하세요. 브라우저에서도 접속에 실패하면 구독 서비스 측 문제입니다. 브라우저에서는 접속되지만 클라이언트에서 실패한다면 클라이언트 네트워크, 요청 헤더 호환성, 시스템 시간을 확인하세요.
시스템 프록시를 켰는데도 브라우저가 직접 연결되면 어떻게 해야 하나요?
먼저 Clash 코어가 실행 중인지 확인한 다음 운영체제의 프록시 설정에 현재 HTTP 또는 mixed 포트가 입력되어 있는지 확인하세요. 일부 브라우저, 다운로드 도구, 보안 프로그램은 별도의 프록시 설정을 사용하거나 시스템 프록시를 무시하므로 프로그램 내부에서 따로 설정해야 합니다. 프록시 포트가 이미 사용 중인지, 브라우저에 직접 연결 확장 프로그램이 활성화되어 있는지, 로컬 네트워크 프록시 스크립트가 시스템 설정을 덮어쓰는지도 확인하세요.
TUN 모드를 켤 때 권한 부족 메시지가 표시되면 어떻게 해야 하나요?
TUN은 가상 네트워크 어댑터 생성, 라우팅 변경, 시스템 서비스 설치가 필요하므로 보통 관리자 권한을 요구합니다. Windows에서는 클라이언트를 관리자 권한으로 실행하거나 서비스 모드를 다시 설치해 보세요. macOS에서는 시스템 안내에 따라 네트워크 확장을 허용하고 관리자 인증 정보를 입력해야 합니다. Linux에서는 프로세스에 TUN 장치 생성 및 라우팅 변경 권한이 있는지 확인하세요. 권한을 처리한 뒤에는 클라이언트를 완전히 종료하고 다시 시작해야 합니다.
Windows 스토어 앱에서 Clash를 사용할 수 없습니다. UWP 루프백은 어떻게 설정하나요?
일부 UWP 앱은 앱 컨테이너의 네트워크 격리 때문에 로컬 루프백 주소의 프록시 포트에 직접 접근하지 못합니다. 클라이언트에서 제공하는 UWP 루프백 도구를 사용해 실제로 프록시가 필요한 앱의 루프백 제한을 해제한 뒤 해당 앱을 다시 시작하세요. 모든 시스템 구성 요소를 한꺼번에 선택하지 마세요. TUN을 통해 이미 정상적으로 인터넷에 연결되는 앱이라면 변수를 늘리지 않도록 루프백을 중복 설정할 필요도 없습니다.
Clash가 시작 시 자동 실행되는데 트래픽을 자동으로 가로채지 않는 이유는 무엇인가요?
시작 시 자동 실행은 클라이언트 프로세스가 시작된다는 뜻일 뿐, 코어 실행·시스템 프록시 활성화·TUN 복원이 함께 이루어진다는 의미는 아닙니다. 클라이언트 자동 시작, 코어 자동 실행, 시스템 프록시 자동 설정, TUN 자동 활성화 옵션을 각각 확인하세요. 로그인 직후 네트워크가 아직 준비되지 않는다면 시작을 조금 늦추는 방법도 있습니다. 서비스 모드를 사용한다면 서비스 상태가 정상인지 확인하고, 구버전 클라이언트가 동시에 실행되어 포트 충돌을 일으키지 않는지도 점검하세요.
사용 팁
노드 전환, 규칙 적용, DNS 경로에 따라 접속 결과가 달라집니다. 연결 기록과 로그를 통해 트래픽이 실제로 어디로 향했는지 확인할 수 있습니다.
노드에 시간 초과가 표시될 때 노드 문제와 로컬 문제를 어떻게 구분하나요?
먼저 같은 구독에 포함된 여러 노드를 연속으로 테스트하세요. 소수의 노드만 시간 초과가 발생하면 노드 점검, 회선 혼잡, 연결 매개변수 만료가 원인일 가능성이 큽니다. 모든 노드에서 동시에 시간 초과가 발생한다면 로컬 네트워크, 시스템 시간, 방화벽, 코어 실행 상태, 구독 설정을 확인하세요. 지연 시간 테스트 주소 자체가 일시적으로 접속 불가일 수도 있으므로 실제 웹페이지 접속도 시도하고, 로그에서 DNS·핸드셰이크·연결 거부 정보를 확인해야 합니다.
규칙이 예상대로 트래픽을 분기하지 않을 때 어디부터 확인해야 하나요?
먼저 연결 기록이나 로그에서 대상 요청을 찾아 실제로 일치한 도메인, 대상 IP, 규칙 유형, 정책 그룹을 확인하세요. Clash 규칙은 일반적으로 위에서 아래 순서로 적용되므로, 범위가 넓은 규칙이 앞에 있으면 트래픽을 먼저 가로챌 수 있습니다. 도메인 규칙과 IP 규칙의 차이, 스니핑 결과, 규칙 세트 업데이트 여부, 최종 MATCH 규칙이 가리키는 정책 그룹도 확인해야 합니다.
Clash에 DNS 유출이 있는지 어떻게 확인하나요?
먼저 현재 시스템 프록시와 TUN 중 어느 방식을 사용하는지 확인하세요. 시스템 프록시는 모든 프로그램의 DNS 조회를 자동으로 가로채지 않습니다. 그런 다음 설정의 dns.enable, 수신 주소, 모드, 업스트림 서버, 규칙 정책을 확인해 DNS 요청이 예상 경로를 우회하지 않는지 살펴보세요. 테스트할 때는 브라우저의 보안 DNS를 끄거나 현재 구성과 일치하도록 설정하고, 코어 로그를 함께 확인해 실제로 어느 업스트림으로 조회가 전송되었는지 판단하세요.
구독을 업데이트하면 수동으로 선택한 노드와 로컬 규칙이 덮어써지나요?
노드 선택이 유지되는지는 클라이언트의 설정 캐시 방식에 따라 다릅니다. 대부분의 클라이언트는 정책 그룹 이름을 기준으로 이전 선택을 복원하려고 하지만, 정책 그룹 이름이 바뀌거나 노드가 삭제되면 유지할 수 없습니다. 구독에서 생성된 YAML을 직접 편집하면 다음 업데이트 때 덮어써지는 경우가 많습니다. 로컬 사용자 지정 규칙은 클라이언트가 지원하는 오버라이드, 확장 설정, 스크립트 기능에 넣고 업데이트 후 병합 순서를 확인하세요.
로컬 네트워크의 다른 기기에서 컴퓨터의 Clash를 사용하려면 어떻게 해야 하나요?
Clash에서 로컬 네트워크 연결을 허용하고, 수신 주소가 127.0.0.1에만 묶이지 않고 로컬 네트워크 어댑터를 포함하도록 설정해야 합니다. 다른 기기에서는 프록시 서버에 Clash가 실행 중인 컴퓨터의 로컬 네트워크 IP를 입력하고 실제 HTTP·SOCKS·mixed 포트를 사용하세요. 운영체제 방화벽이 해당 포트의 인바운드 연결을 허용하는지도 확인하고, 관리 인터페이스를 신뢰할 수 없는 네트워크에 직접 노출하지 마세요.
문제 해결
기본 네트워크부터 시작해 DNS, 노드 연결, 라우팅 가로채기, 시스템 충돌을 차례로 확인하세요. 화면에 표시되는 연결 상태보다 로그의 오류 유형이 더 신뢰할 만합니다.
Clash에는 연결됨으로 표시되지만 모든 웹사이트가 열리지 않으면 어떻게 해야 하나요?
먼저 직접 연결 모드로 전환해 기본 네트워크가 정상인지 확인한 다음, 전역 모드에서 확실히 작동하는 노드를 선택해 테스트하세요. 직접 연결은 정상인데 전역 모드가 실패한다면 로그에서 DNS 실패, 연결 거부, 핸드셰이크 시간 초과, 인증 오류가 있는지 확인합니다. 시스템 프록시 포트가 클라이언트 설정과 일치하는지, 정책 그룹에서 만료된 노드를 선택하지 않았는지, 다른 VPN·방화벽·프록시 프로그램이 동시에 라우팅을 변경하고 있지 않은지도 점검하세요.
프록시 사용 후 HTTPS 인증서 오류가 발생하는 이유는 무엇인가요?
일반적인 Clash 전달 방식은 웹사이트 인증서를 교체하지 않습니다. 인증서 오류가 발생하면 먼저 시스템 시간과 시간대, 브라우저 인증서 상태, 보안 프로그램의 HTTPS 검사, 조직 네트워크의 중간 프록시, 대상 웹사이트의 인증서 체인을 확인하세요. 특정 트래픽 가로채기 도구를 켠 뒤에만 발생한다면 관련 기능을 하나씩 비활성화해 원인을 찾고, 브라우저의 인증서 경고를 무시하지 마세요.
TUN을 켠 뒤 인터넷이 끊기거나 프록시 루프가 발생하거나 다른 VPN과 충돌하면 어떻게 해야 하나요?
먼저 가상 네트워크 어댑터를 만들거나 기본 라우팅을 변경하거나 DNS를 가로채는 다른 VPN 및 네트워크 도구를 종료한 뒤 Clash를 다시 시작하세요. TUN 자동 라우팅, 엄격한 라우팅, 인터페이스 선택, DNS 하이재킹 매개변수가 현재 시스템에 적합한지 확인하고, 프록시 서버 주소 자체가 다시 TUN으로 전송되어 루프를 만들고 있지 않은지도 점검하세요. TUN을 끄면 시스템 프록시가 작동한다면 TUN 설정을 하나씩 복원해 충돌 항목을 찾을 수 있습니다.
Android에서 화면을 잠근 뒤 Clash 연결이 끊기거나 시스템이 종료하면 어떻게 해야 하나요?
Android 제조사의 절전 정책은 화면이 잠긴 뒤 VpnService를 제한하거나 백그라운드 프로세스를 정리할 수 있습니다. 클라이언트의 백그라운드 실행을 허용하고 배터리 최적화 제외 목록에 추가하세요. 시스템의 자동 시작, 백그라운드 활동, 작업 잠금 설정에서도 클라이언트를 유지해야 합니다. 알림 권한이 꺼져 있지 않은지도 확인하세요. 지속적인 VPN 포그라운드 서비스는 보통 상시 알림에 의존합니다. 설정을 변경한 뒤 VPN 연결을 다시 만들고 화면 잠금 상태에서 테스트하세요.
Clash 로그를 볼 때 어떤 정보를 중점적으로 확인해야 하나요?
먼저 문제가 발생한 정확한 시간을 기록한 뒤 해당 시간대의 요청 대상, 적용 규칙, 정책 그룹, 실제 노드, 오류 유형을 찾으세요. DNS timeout은 DNS 조회 경로 문제를, connection refused는 대상 포트나 로컬 수신 문제를, i/o timeout은 네트워크에 도달하지 못했거나 응답이 지나치게 느린 상황을 가리키는 경우가 많습니다. authentication failed가 표시되면 노드 인증 정보를 확인하세요. 문제 전후의 연속 로그를 보존하는 편이 한 줄만 잘라 보는 것보다 원인 파악에 훨씬 유용합니다.