Clash 자주 묻는 질문

클라이언트는 설정 가져오기, 화면 조작, 시스템 연동을 담당합니다. mihomo 코어는 프록시 포트를 열고 DNS를 해석하며 트래픽 분기 규칙을 적용합니다. 구독은 서비스 제공업체가 설정이나 노드 정보를 전달하는 경로입니다. 클라이언트를 설치했다고 사용할 수 있는 노드까지 확보되는 것은 아니며, 구독을 가져왔다고 앱 트래픽이 코어를 통과하는 것도 아닙니다. 처음 사용할 때는 설정이 활성화되어 있는지, 정책 그룹에서 사용할 출구를 선택했는지 차례로 확인한 뒤 시스템 프록시나 TUN을 켜세요. 문제를 점검할 때 이 세 계층을 구분하면 계정 만료를 설치 실패로 오해하거나 시스템 프록시 설정 문제를 노드 장애로 착각하는 일을 줄일 수 있습니다.

일반적으로는 rule 모드를 사용합니다. 코어가 rules를 위에서부터 차례로 확인해 연결을 해당 정책으로 보냅니다. global 모드는 연결을 GLOBAL 정책으로 보내지만, 해당 정책에서 실제로 어떤 출구를 선택했는지 확인해야 합니다. direct 모드는 대상에 직접 연결합니다. 전역 모드도 코어에 들어오지 않은 앱 트래픽까지 자동으로 처리하지 않으며, 사용할 수 없는 노드를 복구해 주지도 않습니다. 특정 사이트의 분기가 예상과 다르면 연결 기록에서 적용된 규칙과 최종 정책을 먼저 확인한 다음 규칙이나 정책 그룹을 조정하세요. 모드만 바꾸고 출구를 확인하지 않으면 트래픽 분기 문제와 노드 연결 상태를 혼동하기 쉽습니다.

공개 노드는 이용 가능 여부와 운영 주체, 데이터 처리 방식을 확인하기 어려운 경우가 많으므로 민감한 계정이나 중요한 업무에는 사용하지 않는 편이 좋습니다. HTTPS는 정상적으로 암호화된 연결의 내용을 보호하지만 클라이언트, 인증서, 서비스 출처를 확인하는 일을 대신하지는 않습니다. 구독 링크에는 계정 식별 정보나 접속 자격 증명이 들어 있을 수 있으므로 민감 정보처럼 관리하고, 공개 포럼이나 스크린샷, 출처를 알 수 없는 변환 사이트에 올리지 마세요. 문제 해결을 요청할 때는 자격 증명을 제거한 오류 메시지와 설정 필드 구조만 전달하면 됩니다. 링크가 유출됐다면 서비스 제공업체의 계정 페이지에서 구독 링크를 재설정하고 클라이언트 설정도 함께 업데이트하세요.

일반적으로 구독 주소와 표준 YAML 설정은 옮길 수 있지만, 기존 클라이언트의 모든 설정이 그대로 가져와진다고 가정해서는 안 됩니다. 필요한 프로토콜을 지원하고 계속 유지 관리되는 클라이언트를 선택한 뒤 구독을 다시 가져오고, 정책 그룹과 규칙, 노드 프로토콜을 현재 코어가 지원하는지 확인하세요. 이전 클라이언트의 화면 설정, 서비스 설치 방식, 스크립트, 덮어쓰기 로직은 별도로 다시 구성해야 할 수 있습니다. 옮기기 전에 기존 클라이언트를 종료하고 시스템 프록시와 백그라운드 서비스를 끈 다음 새 클라이언트를 실행하세요. 두 프로그램이 포트를 놓고 충돌하거나 프록시 설정을 서로 바꾸는 일을 막을 수 있습니다. 기존 설정은 백업해 두고 접속이 정상인지 확인한 뒤 이전 환경을 정리하세요.

먼저 계정 페이지 주소가 아니라 전체 구독 주소를 복사했는지 확인하고, 주소에 공백이나 줄바꿈이 들어갔는지 살펴보세요. 다음으로 클라이언트 업데이트 로그를 확인합니다. 401이나 403은 보통 인증 또는 접근 제한을, 404는 구독 주소 변경 가능성을 나타냅니다. 요청은 성공했지만 내용을 해석하지 못한다면 응답이 로그인 페이지나 오류 페이지인지, 지원하지 않는 형식인지 확인하세요. 계정 만료나 트래픽 소진, 서비스 제공업체의 주소 변경으로도 구독을 사용할 수 없게 될 수 있습니다. 업데이트에 프록시가 필요하다면 클라이언트가 지원하는 경우 사용 가능한 출구를 지정하세요. 로컬 설정을 계속 덮어쓰지 말고 마지막으로 정상 작동한 사본을 보관한 뒤 서비스 제공업체에 구독 주소 상태를 문의하세요.

오류가 표시된 줄 번호를 기준으로 들여쓰기, 콜론 뒤 공백, 목록의 계층을 확인하고 탭 대신 공백을 사용하세요. 줄 번호는 오류가 발견된 위치일 수 있으므로 실제 원인은 바로 앞 줄에 있을 수도 있습니다. 노드 이름이나 비밀번호에 특수 문자가 포함됐다면 YAML 문법에 맞게 따옴표로 묶으세요. 구문 검사는 통과했는데 알 수 없는 필드나 지원하지 않는 프록시 유형이 표시된다면 들여쓰기를 계속 바꾸기보다 클라이언트에서 실제로 사용하는 코어와 버전이 해당 기능을 지원하는지 확인해야 합니다. 원본 설정을 복사해 최근 변경 사항을 한 부분씩 되돌리고, 한 번에 한 항목만 바꿔 불러오기가 성공하는지 확인한 뒤 다음 필드를 추가하세요.

mixed-port는 하나의 포트에서 HTTP와 SOCKS 프록시 연결을 모두 받습니다. port는 HTTP 프록시용이고 socks-port는 SOCKS 프록시용입니다. 앱에서 사용하는 프록시 프로토콜에 맞춰 주소와 포트를 입력해야 하며, 포트 번호가 같다는 이유만으로 설정이 올바르다고 볼 수는 없습니다. mixed-port: 7890으로 설정했다면 로컬 앱은 보통 127.0.0.1:7890에 연결하지만, 실제 포트는 현재 실행 중인 설정을 기준으로 확인하세요. address already in use 오류가 나면 먼저 해당 포트를 사용 중인 프로세스를 찾고, 기존 인스턴스를 종료할지 포트를 바꿀지 결정하세요. 포트를 변경했다면 시스템 프록시, 브라우저 확장 프로그램, 터미널 환경 변수도 함께 업데이트해야 합니다.

TUN은 가상 네트워크 인터페이스를 만들고 라우팅을 변경하므로 보통 관련 시스템 권한이 필요하지만, 클라이언트 전체를 계속 관리자 권한으로 실행해야 하는 것은 아닙니다. 일부 클라이언트는 서비스를 설치해 권한이 필요한 작업을 처리하며, 방식은 플랫폼과 구현에 따라 다릅니다. 먼저 서비스가 설치되어 실행 중인지, 가상 인터페이스가 생성됐는지 확인한 다음 로그에서 권한 또는 라우팅 오류를 살펴보세요. 다른 VPN을 함께 실행하면 인터페이스나 경로가 충돌할 수 있으므로 다른 네트워크 연결 프로그램을 잠시 종료해 비교해 보세요. 권한 오류를 해결하려고 방화벽을 계속 꺼 두지 말고 서비스 상태, 권한 또는 구체적인 충돌 항목을 바로잡으세요.

속도 측정은 보통 지정된 테스트 주소에 대한 노드 요청 결과만 확인하므로 모든 웹사이트와 프로토콜, 포트가 정상이라는 뜻은 아닙니다. 먼저 실패한 요청이 코어에 들어왔는지, 최종 적용된 정책 그룹에서 방금 테스트한 노드를 실제로 선택했는지 확인하세요. 이어서 대상 도메인의 DNS 해석, 해당 사이트에 대한 노드의 연결 가능 여부, 서버 측 제한을 각각 점검합니다. 속도 측정 결과가 오래된 기록이라면 다시 측정한 뒤 대상 사이트에도 직접 접속해 보세요. 동영상이나 게임, 음성 기능만 문제가 있다면 UDP 지원 여부와 관련 트래픽 분기도 확인해야 합니다. 측정 순위만 보고 노드를 자주 바꾸지 말고, 같은 대상과 같은 네트워크 조건에서 비교해야 정확히 판단할 수 있습니다.

계속 유지해야 하는 규칙을 업데이트 때마다 교체되는 원격 설정 본문에만 작성하지 마세요. 클라이언트가 제공하는 덮어쓰기, 병합 또는 확장 설정 기능을 우선 사용해 개인 규칙을 원격 구독과 분리하고 병합 순서를 확인하세요. 규칙은 보통 기본 처리 규칙인 MATCH보다 앞에 두어야 합니다. 그렇지 않으면 연결이 먼저 일치할 수 있습니다. 참조하는 정책 그룹 이름도 최종 설정에 있어야 합니다. 클라이언트마다 배열 항목을 뒤에 추가하거나 앞에 넣거나 교체하는 방식이 다르므로 업데이트 후에는 편집기의 일부 내용만 보지 말고 실제 실행 설정을 확인하세요. 처음 설정을 마친 뒤 구독을 한 번 직접 업데이트해 수정 내용이 유지되는지 검증하세요.

먼저 두 기기가 로컬 네트워크에서 서로 접속할 수 있는지 확인한 뒤 allow-lan을 켜고 bind-address가 로컬 네트워크 인터페이스의 연결을 허용하는지 확인하세요. 다른 기기의 프록시 주소에는 PC의 로컬 네트워크 IP를 입력해야 하며 127.0.0.1을 입력하면 안 됩니다. 포트에는 현재 HTTP 또는 혼합 프록시 수신 포트를 입력하세요. PC 방화벽에서 신뢰할 수 있는 네트워크에만 해당 포트를 허용하는지, 무선 액세스 포인트에서 클라이언트 격리가 켜져 있는지도 확인합니다. 신뢰할 수 있는 네트워크에서만 프록시 연결을 허용하고, 필요한 경우 인증을 설정하세요. 프록시 포트를 공용 인터넷에 노출하지 마세요. HTTP 프록시를 설정해도 기기의 모든 트래픽이 프록시를 통과하는 것은 아닙니다.

많은 명령줄 도구는 데스크톱 시스템 프록시를 자동으로 사용하지 않으므로 도구 자체의 프록시 옵션이나 환경 변수를 설정해야 합니다. 먼저 curl -x http://127.0.0.1:7890 https://example.com을 실행해 단일 요청을 비교해 보세요. 포트는 현재 수신 포트로 바꿔야 합니다. 단일 요청이 성공한다면 터미널과 도구 문서에 따라 http_proxy, https_proxy 또는 ALL_PROXY를 설정하고 no_proxy에서 대상이 제외되지 않았는지 확인하세요. 환경 변수는 보통 현재 프로세스와 하위 프로세스에만 적용되므로 이미 열려 있는 터미널을 다시 시작해야 할 수 있습니다. HTTPS 사이트에 로컬 HTTP 프록시를 사용할 때도 프록시 주소에는 http:// 접두사를 사용할 수 있습니다.

모든 노드가 시간 초과되면 먼저 로컬 네트워크에서 일반 웹사이트에 직접 접속할 수 있는지 확인하세요. 다음으로 구독 업데이트가 성공했는지, 계정이 유효한지, 클라이언트가 올바른 설정을 불러왔는지 확인합니다. 이어서 시스템 시간, 노드 도메인 해석, 포트 연결 상태, 로그의 프로토콜 오류를 점검하세요. 다른 네트워크에서 같은 노드를 사용해 비교하면 로컬 네트워크 제한과 서버 장애를 구분하는 데 도움이 됩니다. 일부 노드만 시간 초과된다면 해당 노드의 서버 주소, 포트, 프로토콜 매개변수, 서비스 상태를 우선 비교하세요. DNS, TUN, 노드 설정을 한꺼번에 변경하면 어떤 조치가 효과가 있었는지 판단하기 어렵습니다. 오류가 발생한 시간과 자격 증명을 제거한 로그를 보관한 뒤 서비스 제공업체에 해당 출구 상태를 확인하세요.

먼저 시스템 프록시의 주소와 포트가 코어의 수신 설정과 일치하는지, 코어가 실행 중인지 확인하세요. 다음으로 프록시 확장 프로그램이나 브라우저 자체 프록시 설정, 조직 정책이 시스템 설정을 덮어쓰는지 살펴봅니다. 충돌하는 확장 프로그램을 잠시 사용 중지하고 같은 주소로 다시 테스트하세요. 클라이언트의 연결 기록을 확인하면 원인을 찾기 쉽습니다. 해당 연결이 없다면 트래픽이 들어오는 경로를 점검하고, 연결은 기록됐지만 DIRECT로 처리된다면 규칙과 정책 선택을 확인하세요. 프록시를 통과했는데도 실패한다면 노드와 DNS를 점검합니다. 시스템 프록시를 수정하는 다른 프로그램은 종료해 설정이 반복해서 덮어써지지 않도록 하세요. TUN을 켜기 전에 원인을 먼저 찾아야 하며, TUN을 모든 문제의 기본 해결책으로 여길 필요는 없습니다.

앱 컨테이너를 사용하는 일부 Windows 앱은 기본적으로 로컬 루프백 주소에 접속할 수 없습니다. 따라서 브라우저가 정상이라고 해서 해당 앱도 127.0.0.1의 프록시를 사용할 수 있는 것은 아닙니다. 먼저 앱이 실제로 시스템 프록시를 읽는지 확인한 뒤, 클라이언트의 루프백 예외 기능으로 필요한 앱만 허용하세요. 시스템 도구 사용법을 알고 있다면 현재 예외 목록을 확인하는 방법도 있습니다. 작업에 관리자 권한이 필요할 수 있고 앱마다 네트워크 구현이 다르므로 모든 앱을 일괄 허용하지 마세요. 설정한 뒤 대상 앱을 완전히 종료하고 다시 실행하면서 연결 기록을 확인하세요. 그래도 실패하면 앱 자체 서비스와 계정 상태, 트래픽 분기 규칙을 점검합니다.

문제를 가리기 위해 DNS를 바로 끄는 것은 권장하지 않습니다. Fake-IP는 도메인에 가상 주소를 할당하므로 실제 IP에 의존하는 로컬 네트워크 서비스나 앱에는 예외 설정이 필요할 수 있습니다. 먼저 내부 도메인을 어느 DNS 서버에서 해석해야 하는지 확인하고, fake-ip-filter와 nameserver-policy를 활용해 해당 도메인을 필터링하거나 지정된 경로로 해석하도록 설정하세요. redir-host로 전환하는 것만으로 라우팅이나 캐시, 멀티캐스트 검색 문제가 해결된다고 보장할 수는 없습니다. 변경 후 관련 DNS 캐시를 지우고 영향을 받은 앱을 다시 시작한 다음 해석 결과와 연결 기록을 확인하세요. 기기 검색에 멀티캐스트 트래픽을 사용한다면 네트워크 격리와 TUN 라우팅도 별도로 점검해야 합니다. 도메인 해석만 조정해서는 해결되지 않을 수 있습니다.