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

Clash는 일반적으로 규칙 기반 프록시 도구와 그 설정 생태계를 가리킵니다. mihomo는 프로토콜 연결, 규칙 매칭, DNS 처리를 담당하는 코어이며, 데스크톱 클라이언트는 설정 가져오기, 정책 그룹 선택, 시스템 프록시, 로그 등의 그래픽 인터페이스를 제공합니다. 같은 코어를 사용하는 클라이언트라도 메뉴 위치, 서비스 설치 방식, 오버라이드 기능은 다를 수 있습니다. 문제를 진단할 때는 Clash를 사용한다고만 적지 말고 클라이언트 이름과 버전, 코어 버전을 함께 기록하세요. 설정 항목의 지원 여부는 실제로 실행 중인 코어의 지원 범위를 기준으로 확인해야 합니다.

클라이언트는 설정을 읽어 연결을 구성합니다. 설치를 마쳤다고 바로 프록시 서비스를 사용할 수 있는 것은 아닙니다. 일반적으로 직접 준비한 YAML 설정을 가져오거나 서비스 제공업체에서 받은 구독 링크를 설정 페이지에서 다운로드해 활성화해야 합니다. 규칙만 있고 사용 가능한 프록시 항목이 없는 파일로는 원격 연결을 만들 수 없습니다. 가져온 뒤 해당 설정이 선택되어 있는지 확인하고, 프록시 페이지에서 정책 그룹에 선택할 항목이 있는지 살펴보세요. 구독 링크는 민감한 정보이므로 스크린샷을 공유할 때 전체 주소와 사용자 식별 정보, 접속 매개변수를 가리세요.

규칙 모드는 설정에 지정된 순서대로 정책을 선택하므로 도메인, 주소, 지역에 따라 평소 트래픽을 분리할 때 적합합니다. 전역 모드는 코어로 들어온 연결을 전역 정책 그룹으로 보내고, 직접 연결 모드는 코어로 들어온 연결이 대상에 바로 접속하게 합니다. 전역 모드라고 해서 기기의 모든 트래픽이 자동으로 처리되는 것은 아닙니다. 앱 트래픽이 코어로 들어오려면 시스템 프록시나 TUN 같은 진입 경로가 필요합니다. 특정 웹사이트에 문제가 생기면 잠시 전역 모드로 바꿔 비교 테스트한 뒤 규칙 모드로 되돌리세요. 전역 모드에서는 되지만 규칙 모드에서는 안 된다면 우선 적용된 규칙과 정책 그룹을 확인하세요.

꼭 그렇지는 않습니다. 시스템 프록시는 프록시 주소를 운영체제 설정에 등록해 해당 설정을 읽는 앱에 적용합니다. TUN은 가상 네트워크 인터페이스와 라우팅을 통해 조건에 맞는 네트워크 트래픽을 처리하며, 시스템 프록시를 사용하지 않는 프로그램에 주로 쓰입니다. 처음 설정할 때는 시스템 프록시만 켜고 구독, 정책 그룹, 연결이 정상인지 확인한 다음 필요에 따라 TUN을 테스트하세요. 일부 클라이언트는 두 기능을 동시에 지원하지만, 둘 다 켜는 것이 모든 문제의 해결책은 아닙니다. 다른 VPN이나 프록시 도구도 실행 중이라면 라우팅과 DNS 설정이 서로 덮어쓰이지 않도록 하나를 먼저 종료하세요.

클라이언트의 설정 페이지에서 새 설정, 원격 설정 또는 구독 가져오기 메뉴를 찾으세요. 서비스 제공업체가 제공한 전체 주소를 URL 입력란에 붙여 넣고 가져오기를 완료합니다. 다운로드가 끝나면 해당 설정을 활성화하거나 선택한 뒤 프록시 페이지에서 정책 그룹의 사용 가능한 프록시를 고르세요. 마지막으로 설정 페이지에서 시스템 프록시를 켜고 브라우저로 대상 웹사이트에 접속해 확인합니다. 클라이언트마다 버튼 이름은 조금씩 다릅니다. 로컬 YAML 파일을 가져올 때는 파일 가져오기를 선택하고, 구독 주소 입력란에 파일 경로를 넣지 마세요.

먼저 설정 페이지에서 직접 업데이트를 한 번 실행하고 같은 시각의 로그를 확인하세요. 요청 시간 초과가 발생하면 현재 네트워크와 구독 업데이트에 사용하는 프록시 경로를 점검합니다. 401, 403 등의 응답이 나오면 서비스 제공업체에 링크 권한과 유효 기간을 확인하세요. 웹페이지나 로그인 페이지가 반환되면 YAML 설정으로 가져올 수 없습니다. 로그에 특정 줄 번호가 표시된다면 들여쓰기, 콜론 뒤 공백, 중복 항목, 코어에서 지원하지 않는 설정을 확인하세요. 여러 설정을 연달아 바꿔 원인을 가리지 말고, 전체 구독 주소가 포함된 로그를 그대로 공개하지 마세요.

7890은 혼합 포트의 일반적인 예시이며, 실제 값은 클라이언트 설정이나 적용된 설정의 mixed-port 항목에서 확인하세요. 로그에 주소가 이미 사용 중이라고 나오면 다른 프록시 클라이언트를 종료하고 이전 프로세스가 백그라운드에 남아 있는지 확인합니다. 충돌이 계속되면 사용 중이 아닌 로컬 포트로 혼합 포트를 변경하고 설정을 적용하세요. 이후 브라우저 확장 프로그램, 터미널 환경 변수, 직접 입력한 다른 프록시 주소도 함께 수정해야 합니다. 설정 파일만 바꾸고 앱에 이전 포트를 남겨 두지 마세요. 시스템 프록시가 자동으로 갱신되었는지도 시스템 설정에서 확인하세요.

먼저 클라이언트의 서비스 모드가 설치되어 실행 중인지 확인하세요. Windows에서는 서비스를 설치하도록 허용하거나 관리자 권한으로 관련 작업을 수행해야 하는 경우가 많습니다. macOS는 클라이언트 구현에 따라 시스템 설정에서 네트워크 확장 또는 보조 서비스를 승인해야 할 수 있습니다. 권한, 드라이버, 네트워크 어댑터 생성과 관련된 원본 오류를 로그에서 확인한 뒤 해당 클라이언트 안내에 따라 서비스를 복구하세요. 출처가 불분명한 드라이버를 반복해서 설치하지 마세요. 기기가 조직의 관리 정책에 제한되어 있다면 관리자에게 문의하세요. 복구 전에는 TUN을 끄고 시스템 프록시로 기본 연결을 확인할 수 있습니다.

속도 테스트는 대개 설정에 지정된 테스트 주소에만 접속하므로 해당 탐색이 성공했다는 뜻일 뿐, 모든 웹사이트와 프로토콜, DNS 요청이 정상이라는 의미는 아닙니다. 먼저 현재 정책 그룹에서 어떤 프록시가 선택되었는지 확인한 뒤, HTTPS 웹사이트에 접속해 연결 페이지를 살펴보세요. 대상 도메인에 적용된 규칙과 최종 정책을 확인하고, 로그에 이름 해석 실패나 연결 재설정이 기록되었는지도 확인합니다. 필요하면 다른 프록시로 비교하되 한 번에 한 항목만 바꾸세요. 다른 앱은 정상인데 브라우저만 실패한다면 브라우저 확장 프로그램, 사용자 지정 프록시, 보안 DNS 설정도 확인해야 합니다.

먼저 클라이언트에서 제공하는 로컬 규칙 또는 오버라이드 메뉴를 사용해 넓은 범위의 규칙과 마지막 MATCH 규칙보다 앞에 대상 도메인 규칙을 추가하세요. DOMAIN은 정확한 도메인에, DOMAIN-SUFFIX는 지정 도메인과 하위 도메인에 적용됩니다. 규칙 끝의 정책 이름은 현재 설정의 정책 그룹 이름과 일치해야 합니다. 저장하고 적용한 뒤 새 연결을 만들어 연결 페이지에서 규칙 적용 결과를 확인하세요. 웹페이지가 다른 리소스 도메인도 요청할 수 있으므로 필요한 경우 하나씩 추가합니다. 원격 구독에서 생성된 파일을 직접 편집하면 다음 업데이트 때 변경 사항이 덮어써질 수 있습니다.

클라이언트 설정에서 LAN 연결 허용을 켜고, 수신 주소가 127.0.0.1로만 제한되어 있지 않은지 확인하세요. 컴퓨터의 LAN 주소와 실제 혼합 포트도 기록해 둡니다. 다른 기기에는 그 기기 자신의 루프백 주소가 아니라 프록시를 실행하는 컴퓨터의 LAN 주소를 입력해야 하며, 두 기기가 서로 통신할 수 있어야 합니다. 연결되지 않으면 컴퓨터 방화벽, 게스트 네트워크 격리, 무선 액세스 포인트 격리 설정을 확인하세요. 신뢰할 수 있는 LAN에서만 허용하고, 필요한 경우 인증과 접근 범위를 설정하세요. 프록시 포트를 공용 인터넷에 노출하지 마세요. 컴퓨터가 절전 모드에 들어가거나 IP 주소가 바뀌면 다른 기기의 연결도 끊깁니다.

원격 구독을 업데이트하면 설정 파일이 다시 생성되는 경우가 많아 다운로드 파일에 직접 추가한 규칙, DNS, 정책 그룹 설정이 덮어써질 수 있습니다. 먼저 정상 작동하는 설정을 백업한 뒤 클라이언트에서 지원하는 로컬 오버라이드, 설정 병합 또는 스크립트 확장 기능으로 개인 설정을 저장하세요. 클라이언트마다 병합 순서가 다르고 추가한 규칙이 MATCH 앞에 자동 배치되지 않을 수도 있으므로 적용 후 최종 설정과 규칙 적용 결과를 확인해야 합니다. 여러 오버라이드가 동시에 활성화되어 있다면 하나씩 꺼서 비교하고, 같은 항목이 중복 정의되거나 서로 덮어쓰지 않는지 확인하세요.

먼저 시스템 프록시의 주소와 포트가 현재 클라이언트를 가리키는지 확인하고, 코어가 실행 중이며 설정이 활성화되어 있는지도 살펴보세요. 브라우저 확장 프로그램이 시스템 프록시를 덮어쓸 수 있습니다. 일부 터미널 도구는 HTTP_PROXY, HTTPS_PROXY 또는 자체 프록시 매개변수만 읽으므로 별도로 설정해야 합니다. 대상 주소에 접속할 때 클라이언트의 연결 페이지를 확인하세요. 해당 연결이 없다면 트래픽 진입 경로부터 점검하고, 연결은 있지만 정책이 잘못되었다면 규칙을 확인합니다. 문제를 찾는 동안 다른 프록시 프로그램을 잠시 종료하고, 시스템의 프록시 우회 목록에서 대상 도메인이나 주소 범위가 제외되어 있지 않은지도 확인하세요.

AppContainer로 격리되는 일부 UWP 앱은 기본적으로 로컬 루프백 주소에 접근하지 못합니다. 따라서 브라우저가 정상이어도 스토어나 메일 앱은 작동하지 않을 수 있습니다. 클라이언트에 UWP 루프백 예외 도구가 있다면 안내에 따라 관리자 권한으로 실행하고, 실제로 필요한 앱에만 예외를 적용한 뒤 앱을 완전히 종료하고 다시 여세요. Windows에 익숙한 사용자는 CheckNetIsolation으로 예외 목록을 관리할 수도 있지만, 모든 앱을 한꺼번에 허용해서는 안 됩니다. 예외 적용 후 연결이 코어에 들어오는데도 실패한다면 규칙, DNS, 앱 자체 서비스 상태를 계속 확인하세요.

먼저 프록시를 끄고 원래 직접 연결할 수 있던 서비스에 기본 네트워크로 접속되는지 확인하세요. 이때도 실패한다면 Wi-Fi, 게이트웨이, 네트워크 인증 문제부터 해결해야 합니다. 기본 네트워크가 정상이면 설정을 활성화하고 선택 가능한 프록시 두 개를 각각 테스트한 뒤, 로그의 도메인 이름 해석, 핸드셰이크, 연결 시간 초과 정보를 확인하세요. 특정 프록시 하나만 실패하면 원격 서비스 상태를 우선 점검하고, 전부 실패하면 구독 유효성, 시스템 시간, 외부 네트워크 제한, 다른 VPN과의 충돌을 확인합니다. 속도 테스트 시간 초과만으로 설정이 손상되었다고 판단하지 마세요. 테스트 주소 자체에 접속할 수 없어도 탐색에 실패할 수 있습니다.

먼저 도메인 이름이 해석되지 않는 경우와 해석은 됐지만 연결이 실패하는 경우를 구분한 뒤, 실제 적용된 DNS 설정을 확인하세요. Fake-IP가 매핑 주소를 반환하는 것은 설계된 동작이므로, 결과가 공인 IP가 아니라는 이유만으로 오류라고 판단할 수 없습니다. DNS 요청이 예상한 해석 경로를 통과하는지, 직접 연결 및 프록시 해석 경로에 접근할 수 있는지, 브라우저의 보안 DNS가 클라이언트 설정을 우회하지 않는지 확인하세요. 변경 후에는 테스트 연결을 종료하고 새로 연결하며, 필요하면 시스템과 브라우저 캐시를 지우세요. 호환되지 않는 LAN 서비스에는 필요에 따라 Fake-IP 필터 규칙을 설정할 수 있습니다. DNS와 TUN 매개변수를 한꺼번에 모두 바꾸지 마세요.