CLASH VERGE / FAQ
Clash 자주 묻는 질문
설정, 연결 및문제 해결
문제가 발생한 단계를 먼저 확인하세요. 설정이 불러와졌는지, 앱이 프록시 처리 대상인지, 규칙이 적용됐는지, 노드를 사용할 수 있는지 차례로 살펴본 뒤 해당 질문의 안내에 따라 점검하세요.
처음 설정한다면 입문 가이드를 참고하세요. 클라이언트마다 메뉴 이름이 조금씩 다를 수 있으니 현재 화면과 로그를 기준으로 확인하세요.
CONCEPTS
기본 개념
클라이언트, 코어, 설정의 차이를 이해하고 적절한 트래픽 처리 방식을 선택하세요.
Clash Verge, Clash Verge Rev, mihomo는 어떤 관계인가요?
Clash Verge는 데스크톱 클라이언트 프로젝트 이름이며, Clash Verge Rev는 이를 바탕으로 이어서 개발되는 프로젝트입니다. 두 프로젝트의 출시 및 유지 관리 현황은 각각 확인해야 합니다. mihomo는 프록시 연결, DNS 확인, 규칙 매칭을 처리하는 코어입니다. 클라이언트는 설정 가져오기와 제어 기능, 화면을 담당하고 코어는 실제 트래픽을 처리합니다. 따라서 화면이 정상적으로 열려도 코어가 실행 중이라는 뜻은 아니며, 새 클라이언트를 설치했다고 기존 설정의 모든 항목을 바로 사용할 수 있는 것도 아닙니다. 문제를 확인할 때는 먼저 클라이언트 이름을 기록하고 설정 화면에서 코어 정보를 확인해 클라이언트 버전과 코어 버전을 혼동하지 않도록 하세요.
클라이언트를 설치한 뒤에도 구독이나 설정 파일이 필요한 이유는 무엇인가요?
클라이언트는 연결을 관리하는 도구이며, 설치만으로 사용할 수 있는 프록시 서버가 자동 생성되지는 않습니다. 구독은 보통 서비스 제공자가 제공하는 설정 주소로, 노드와 프록시 그룹, 규칙이 포함될 수 있습니다. 로컬 YAML 파일로도 같은 정보를 불러올 수 있습니다. 처음 사용할 때는 설정 화면에서 주소나 파일을 가져온 뒤 파싱이 완료됐는지 확인하고, 해당 설정을 현재 설정으로 선택하세요. 설정 이름이 보인다고 활성화된 것은 아니므로 프록시 화면에서 프록시 그룹이 표시되는지도 확인해야 합니다. 구독 주소에는 계정 인증 정보가 포함될 수 있으니 계정 정보처럼 안전하게 보관하고, 공개 스크린샷이나 게시판, 온라인 변환 사이트에 붙여 넣지 마세요.
규칙 모드, 전역 모드, 직접 연결 모드는 각각 언제 사용하나요?
규칙 모드는 설정에 적힌 규칙을 위에서부터 차례로 적용해 일치하는 연결을 해당 정책으로 처리하므로 일상적인 트래픽 분리에 적합합니다. 전역 모드는 코어가 처리하는 연결을 모두 전역 프록시 그룹으로 보내므로 임시 비교 테스트에 유용하지만, 해당 그룹에서 사용 가능한 노드를 선택해야 합니다. 직접 연결 모드는 처리 대상으로 들어온 연결을 프록시 노드 없이 목적지에 직접 연결합니다. 모드는 코어에 들어온 연결의 처리 방식을 정할 뿐, 어떤 앱의 연결이 코어에 들어오는지는 정하지 않습니다. 시스템 프록시를 사용하지 않는 앱은 전역 모드만 켜도 처리되지 않습니다. 먼저 앱의 프록시 설정을 확인하고 필요하다면 TUN 모드를 검토하세요.
시스템 프록시와 TUN 모드는 어떻게 다르며 둘 다 켜야 하나요?
시스템 프록시는 운영체제의 프록시 설정을 변경합니다. 해당 설정을 따르는 앱은 연결을 클라이언트로 보냅니다. TUN 모드는 가상 네트워크 인터페이스를 통해 라우팅 조건에 맞는 트래픽을 처리하므로 시스템 프록시를 읽지 않는 일부 앱에 적합하지만, 일반적으로 서비스 권한이 필요하고 라우팅 및 DNS 설정에도 영향을 줍니다. 처음에는 시스템 프록시만 켜고 연결을 확인한 뒤 필요에 따라 TUN을 사용하세요. 두 모드를 함께 사용할지는 클라이언트 구현과 설정에 따라 달라지므로 반드시 동시에 켜야 하는 것은 아닙니다. 문제를 확인할 때는 한 번에 설정 하나만 바꾸고 연결 화면에서 대상과 적용된 규칙을 살펴보세요. 그래야 어떤 설정이 영향을 줬는지 파악할 수 있습니다.
CONFIGURATION
설치 및 설정
구독 주소에서 코어 수신까지 설정이 적용되는 각 단계를 확인하세요.
구독 가져오기나 업데이트가 실패하면 어디부터 확인해야 하나요?
먼저 복사한 주소가 계정 홈이나 결제 페이지, 공유 안내 페이지가 아니라 완전한 구독 주소인지 확인하세요. 주소 앞뒤에 공백이나 줄바꿈이 없는지 살펴본 다음 설정 화면에서 다시 업데이트하고 오류 메시지를 확인합니다. 인증 실패나 접근 거부가 표시되면 제공자에게 구독 만료 여부와 주소 변경 여부를 문의하세요. 웹페이지 내용이 반환되면 잘못된 주소를 사용했거나 로그인 인증이 필요한 경우일 수 있습니다. 연결 시간 초과가 발생하면 클라이언트 화면에 있는 옵션에 따라 직접 연결로 업데이트하는 경우와 사용 가능한 프록시를 거쳐 업데이트하는 경우를 각각 테스트하세요. 기존 설정을 모두 삭제하지 마세요. 아직 쓸 수 있는 설정은 남겨 두고 새 구독의 파싱과 선택이 완료된 뒤 정리하세요.
설정을 가져왔는데 프록시 화면에 노드나 프록시 그룹이 없으면 어떻게 하나요?
설정 화면으로 돌아가 가져온 항목을 현재 설정으로 선택했는지 확인하세요. 다운로드만 완료된 상태일 수 있습니다. 다음으로 코어 로그를 살펴 설정 파싱 실패, 원격 노드 목록 가져오기 실패, 설정 자체에 노드가 없는 경우를 구분하세요. 일부 설정은 proxy-providers를 통해 원격 노드 목록을 불러오므로 기본 파일을 다운로드할 수 있어도 해당 주소에 접속할 수 있다는 뜻은 아닙니다. 설정 병합, 스크립트, 오버라이드 기능을 사용 중이라면 관련 처리를 잠시 끄고 원본 설정을 다시 불러와 비교하세요. 그래도 비어 있다면 제공자에게 해당 구독이 mihomo와 호환되는지 확인하세요. 파일 확장자만 바꿔 다른 클라이언트 형식을 YAML로 억지 변환하지 마세요.
TUN을 켤 때 권한 부족 또는 서비스를 사용할 수 없다는 오류가 나오면 어떻게 해야 하나요?
먼저 TUN을 끄고 클라이언트 설정에서 서비스 모드가 설치되어 실행 중인지 확인하세요. 서비스를 설치해야 한다면 클라이언트의 서비스 관리 기능을 이용하고 운영체제 안내에 따라 권한을 허용하세요. 조직에서 관리하는 기기라면 관리자에게 권한을 확인해야 합니다. 서비스를 설치하거나 복구한 뒤 클라이언트를 다시 시작하고 TUN을 켜서 가상 인터페이스나 라우팅 생성 오류가 로그에 남는지 확인하세요. 다른 VPN, 가상 네트워크 어댑터 도구, 보안 소프트웨어를 함께 사용한다면 허가를 받은 경우에만 하나씩 일시 중지해 비교하세요. 네트워크 어댑터를 삭제하거나 보안 기능을 전부 끄지 마세요. 권한에 문제가 없는데도 실패한다면 설정의 TUN 항목이 현재 코어와 호환되는지도 확인해야 합니다.
Clash 포트 설정은 어디서 확인하며 포트가 이미 사용 중이면 어떻게 바꾸나요?
클라이언트 설정에서 현재 프록시 포트를 확인하세요. HTTP, SOCKS, mixed-port는 서로 다르며 mixed-port는 하나의 수신 포트에서 HTTP와 SOCKS 프록시 요청을 모두 받습니다. 실제 적용된 설정과 코어 로그를 기준으로 확인하고 튜토리얼에 나온 숫자를 그대로 따라 하지 마세요. 주소가 이미 사용 중이라는 오류가 나오면 중복 실행 중인 프록시 클라이언트를 먼저 종료하고, 필요하다면 운영체제의 네트워크 도구로 포트를 점유한 프로세스를 확인하세요. 사용 가능한 포트로 바꾼 뒤 설정을 다시 불러오고 브라우저 확장 프로그램, 터미널 등 프록시를 직접 입력한 앱도 함께 수정하세요. 관리 인터페이스 포트는 프록시 포트가 아니므로 앱의 HTTP 프록시 항목에 입력하면 안 됩니다.
DAILY USE
활용 팁
실제 연결로 설정을 검증하고 재현 가능한 트래픽 분리 결과를 확인하세요.
노드를 선택한 뒤 트래픽이 실제로 프록시를 통과하는지 어떻게 확인하나요?
먼저 현재 설정과 프록시 그룹 선택이 적용됐는지 확인한 뒤 시스템 프록시를 켜고 프록시 규칙에 일치하는 사이트에 접속하세요. 바로 클라이언트의 연결 화면을 열어 대상 도메인, 적용된 규칙, 실제로 사용된 정책 또는 노드를 확인해야 합니다. 시스템 프록시 스위치가 켜진 것만으로는 검증이 끝나지 않습니다. 켜기 전후에 같은 IP 조회 서비스를 이용해 출구 IP를 비교할 수도 있지만, 일부 조회 도메인은 규칙에 따라 직접 연결될 수 있으므로 연결 화면도 함께 확인하세요. 테스트 중에는 브라우저에서 별도로 프록시를 설정하는 확장 프로그램을 꺼 두어 설정이 서로 덮어쓰지 않도록 하세요. TUN을 사용한다면 시스템 프록시를 읽지 않는 앱으로도 별도 테스트를 진행하세요.
프록시 그룹에서 select, url-test, fallback은 어떻게 선택하나요?
select는 사용자가 노드를 직접 선택하므로 고정된 출구를 사용하거나 문제를 확인할 때 적합합니다. url-test는 설정된 테스트 주소와 주기에 따라 후보 노드를 비교하고 허용 오차를 고려해 선택합니다. 테스트 결과는 해당 대상에 대한 성능만 보여 줍니다. fallback은 후보 순서에 따라 사용 가능한 항목을 선택하므로 기본 노드와 예비 노드의 순서가 중요한 경우에 적합합니다. 프록시 그룹은 다른 그룹을 참조할 수도 있어 화면에서 그룹 하나를 선택해도 최종 출구는 다음 단계의 그룹에서 정해질 수 있습니다. 특정 요청의 경로를 확인하려면 연결 상세 정보에서 실제 연결 경로를 살펴보세요. 한 번의 테스트 결과만으로 그룹 유형을 계속 바꾸지 말고, 테스트 주소가 유효한지 먼저 확인한 뒤 고정 출구와 자동 전환 중 필요한 방식에 따라 선택하세요.
직접 추가한 분기 규칙이 구독 업데이트 후 사라지는 이유는 무엇인가요?
원격 구독은 업데이트할 때 원본 설정을 다시 생성하는 경우가 많아 직접 편집한 내용이 덮어써질 수 있습니다. 계속 유지할 규칙은 클라이언트에서 지원하는 오버라이드 또는 설정 병합 기능에 추가하고 현재 구독에 연결되어 있는지 확인하세요. 규칙은 보통 순서대로 적용되므로 사용자 규칙은 먼저 일치할 수 있는 포괄적인 규칙보다 앞에 두어야 합니다. 특히 마지막 기본 규칙인 MATCH 뒤에 두지 마세요. 규칙을 추가할 때 참조하는 프록시 그룹이 실제로 존재하는지, 이름의 대소문자와 공백이 정확한지도 확인하세요. 저장 후 설정을 다시 불러오고 연결 화면에서 대상 요청에 적용된 규칙을 확인하세요. 편집기에 글자가 남아 있는지만 확인해서는 안 됩니다.
사용을 마친 뒤 다음 부팅 때 네트워크 문제가 생기지 않도록 어떻게 종료하나요?
사용을 마칠 때는 시스템 프록시와 TUN을 먼저 끈 다음 트레이 메뉴에서 클라이언트를 정상 종료해 관련 설정이 복구되도록 하세요. 브라우저, 터미널, 개발 도구에 프록시를 별도로 입력했다면 해당 앱의 설정도 각각 꺼야 합니다. 비정상 종료 후 인터넷에 연결되지 않으면 시스템 프록시가 여전히 로컬 주소를 가리키는지, 해당 포트를 수신하던 프로세스가 종료됐는지 확인하세요. 확인 후 프록시 설정을 끄고 다시 테스트합니다. 처음부터 네트워크 설정 전체를 초기화하거나 설정 파일을 삭제하지 마세요. 부팅 시 자동으로 사용하려면 클라이언트 자동 시작, 코어 실행, 프록시 적용 상태를 각각 확인해야 합니다. 부팅 시 실행된다고 연결까지 사용할 수 있는 것은 아닙니다.
DIAGNOSTICS
문제 해결
요청이 코어에 들어왔는지 확인한 다음 규칙, DNS 조회, 원격 연결을 점검하세요.
노드 시간 초과나 연결 실패 문제는 어떤 순서로 확인해야 하나요?
먼저 프록시를 끄고 기본 네트워크가 작동하는지 확인한 다음 클라이언트 코어가 실행 중인지, 로컬 포트가 수신 중인지, 대상 앱의 연결이 실제로 클라이언트에 들어오는지 살펴보세요. 이어서 구독 유효 기간을 확인하고 같은 프록시 그룹에서 다른 노드를 선택해 비교한 뒤 해당 요청의 로그를 확인합니다. 도메인 확인에 실패하면 DNS를 먼저 점검하고, 인증에 실패하면 노드 인증 정보와 구독 상태를 확인하세요. 연결이 거부되면 서버 주소와 포트, 서비스 상태를 점검해야 합니다. 모든 노드가 동시에 실패한다면 프로토콜 매개변수를 하나씩 바꾸기보다 먼저 로컬 네트워크와 설정을 확인하세요. 한 번에 한 항목만 조정하고 같은 대상에 다시 연결해 보세요. 변경 전후 로그를 남겨야 조정 효과를 판단할 수 있습니다.
시스템 프록시를 켰는데 브라우저나 다른 앱이 프록시를 사용하지 않나요?
먼저 운영체제의 프록시 설정에서 주소와 포트가 현재 클라이언트를 가리키는지, 코어가 해당 포트에서 수신 중인지 확인하세요. 다음으로 대상 앱에 별도의 프록시 설정, 브라우저 확장 프로그램, 우회 목록 또는 기존 VPN이 있는지 살펴보세요. 이러한 요소가 연결 경로를 바꿀 수 있습니다. 테스트 사이트에 접속하면서 연결 화면을 확인하세요. 기록이 전혀 없다면 우선 트래픽이 클라이언트에 들어오는 경로를 점검해야 합니다. 기록은 있지만 DIRECT로 표시된다면 규칙과 정책을 살펴보세요. 클라이언트를 반복해서 재설치할 필요는 없습니다. 시스템 프록시를 읽지 않는 앱은 앱에서 지원하는 프록시 방식을 설정하거나 TUN 모드를 검토할 수 있습니다. 터미널은 프록시 환경 변수의 영향을 받을 수 있으므로 시스템 설정을 바꾼 뒤 별도로 확인하세요.
Clash DNS 유출은 어떻게 확인하며 브라우저의 보안 DNS를 꺼야 하나요?
먼저 어떤 도메인을 어떤 DNS 서버로 조회할지 정한 다음 설정의 DNS 수신 주소, 상위 DNS 서버, 트래픽 분리 설정을 확인하세요. 브라우저의 보안 DNS, 앱에 내장된 DoH, 운영체제의 암호화 DNS는 서로 다른 조회 경로를 만들 수 있습니다. 끌지 여부는 예상한 설정에 따라 결정해야 하며 스위치 하나만 보고 판단할 수 없습니다. 테스트 서비스를 사용할 때는 프록시 출구 IP와 재귀 DNS 서버 주소를 구분하세요. 두 주소가 다르다는 사실만으로 유출이 입증되는 것은 아니며, 조회가 의도한 경로를 우회하는지가 더 중요합니다. 비교를 위해 브라우저의 별도 DNS 기능을 잠시 끄고 코어 로그도 함께 확인할 수 있습니다. TUN을 사용한다면 DNS 가로채기와 라우팅이 실제로 적용됐는지도 확인하세요.
Windows UWP 앱에서 로컬 프록시를 사용할 수 없을 때 루프백 문제를 어떻게 해결하나요?
AppContainer 격리를 사용하는 일부 Windows 앱은 로컬 루프백 연결이 제한되어 클라이언트가 수신하는 로컬 프록시에 연결하지 못할 수 있습니다. 먼저 일반 브라우저가 같은 프록시로 인터넷에 연결되는지 확인한 다음 클라이언트에 UWP 루프백 예외 기능이 있는지 살펴보세요. 기능이 있다면 필요한 앱만 선택해 권한을 허용하고 모든 앱을 추가하지는 마세요. 관리자 권한으로 Windows의 CheckNetIsolation 도구를 사용해 예외를 관리할 수도 있지만, 앱 패키지 ID를 정확히 확인해야 합니다. 모든 스토어 앱에 같은 제한이 적용되는 것은 아닙니다. 설정 후에도 문제가 계속되면 예외를 반복해서 추가하기보다 앱이 시스템 프록시를 읽는지, 계정에 로그인되어 있는지, 연결 화면에 기록이 남는지 확인하세요.