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

Clash는 프록시 코어와 설정 생태계를 가리키는 이름이며, 원본 프로젝트는 유지 관리가 중단되었습니다. mihomo는 호환성을 유지하며 개발을 이어가는 코어로, 프로토콜과 규칙, 네트워크 스택 기능을 확장했습니다. 그래픽 클라이언트는 구독 관리, 프록시 그룹 선택, 시스템 프록시 설정, 서비스 설치를 담당하며 실제 트래픽 전달은 코어가 처리합니다. 문제를 해결할 때는 Clash 최신 버전이라고만 적지 말고 클라이언트 이름과 코어 정보도 함께 기록하세요. 인터페이스에서 특정 옵션을 지원하더라도 현재 코어가 해당 설정 항목을 지원한다는 뜻은 아닙니다. 설정 오류가 발생하면 먼저 코어 문서를 확인한 뒤 클라이언트가 기존 설정을 덮어쓰는지 살펴보세요.

클라이언트는 로컬 포트 수신, 규칙 판정, 트래픽 전달 기능을 제공하지만 설치만으로 사용할 수 있는 원격 프록시가 생기지는 않습니다. 구독에는 보통 노드, 프록시 그룹, 규칙이 포함되지만 노드 목록만 제공되는 경우도 있어 로컬 템플릿과 함께 사용해야 할 수 있습니다. 먼저 설정 화면에서 가져오기가 제대로 완료됐는지 확인하고, 프록시 그룹에 선택할 항목이 있는지도 살펴보세요. 구독 주소에는 계정 접근 정보가 포함되는 경우가 많으니 공개 게시판에 올리지 마세요. 유출됐다면 제공업체에서 링크를 재발급받으세요. 이 사이트는 클라이언트 정보와 설정 안내를 제공하며 구독을 발급하거나 제공업체 계정을 복구해 드리지는 않습니다.

일상적으로는 rules에 정의된 순서에 따라 요청을 매칭하는 규칙 모드를 사용하는 것이 일반적입니다. 전역 모드는 코어에 전달된 요청을 전역 정책으로 처리하므로 분기 규칙에 문제가 있는지 임시로 확인할 때 유용합니다. 직접 연결 모드는 코어에 전달된 요청을 프록시 없이 연결합니다. 세 모드 모두 시스템 프록시나 TUN의 트래픽 가로채기를 대신하지는 않습니다. 전역 모드로 바꾼 뒤 접속이 되더라도 기존 분기 경로를 확인할 필요가 있다는 뜻일 뿐, 모든 네트워크 문제가 해결된 것은 아닙니다. 테스트를 마치면 규칙 모드로 되돌리고 연결 기록에서 실제로 적용된 규칙과 정책을 확인하세요.

시스템 프록시는 운영체제의 프록시 설정을 변경해 해당 설정을 따르는 앱에 주로 영향을 줍니다. TUN은 가상 네트워크 인터페이스를 만들고 라우팅을 통해 더 많은 프로그램의 트래픽을 처리하며, 보통 서비스 설치나 관리자 권한이 필요합니다. 일부 클라이언트에서는 두 기능을 함께 사용할 수 있지만 라우팅 제외 설정, DNS, 코어 구현에 따라 올바르게 동작하는지가 달라집니다. 처음 설정할 때는 시스템 프록시만 켜서 브라우저 연결을 확인한 뒤 게임이나 명령줄 도구 등의 필요에 따라 TUN을 활성화하세요. 함께 켠 뒤 연결이 반복되거나 리소스 사용량이 비정상적이거나 인터넷이 끊기면 한 가지 방식만 남기고 재현 가능한 최소 설정으로 확인하세요.

운영체제, 클라이언트 이름, 코어 정보, 트래픽 처리 방식, 문제가 발생한 정확한 시각을 기록하고 실패한 요청 전후의 로그를 보관하세요. 설정 로드 오류, 수신 주소, DNS 조회 실패, 연결 대상, 적용된 정책을 중점적으로 확인합니다. 필요한 경우 잠시 로그 수준을 높여 문제를 재현한 뒤 기본값으로 되돌리세요. 로그를 공유하기 전에는 구독 주소, 인증 정보, 노드 서버, 개인 접속 기록을 삭제하고 스크린샷에 주소 표시줄이 노출되지 않았는지도 확인하세요. 브라우저는 되지만 특정 앱에서 실패한다고 설명하는 편이 단순히 연결이 안 된다고 하는 것보다 문제 파악에 도움이 됩니다. 한 번에 변수 하나만 바꿔야 로그가 추측 게임이 되지 않습니다.

먼저 기기의 시간과 기본 네트워크 연결을 확인한 다음, 제공업체 계정 페이지에서 구독 만료 여부, 사용량 초과 여부, 링크 재설정 여부를 확인하세요. 업데이트 로그의 HTTP 상태도 살펴보세요. 401 또는 403은 보통 인증이나 접근 제한과 관련이 있고, 404는 주소가 바뀌었을 수 있으며, 시간 초과라면 DNS 조회와 접속 경로를 추가로 확인해야 합니다. 클라이언트에서 업데이트 방식을 선택할 수 있다면 직접 연결 업데이트와 사용 가능한 기존 프록시를 통한 업데이트를 각각 테스트해 보세요. 마지막으로 정상 작동했던 설정은 보관하고 계속 삭제하거나 다시 만들지 마세요. 로그인 또는 인증 페이지가 다운로드되면 요청이 성공했더라도 가져올 수 있는 설정 파일은 아닙니다.

가져온 항목이 완전한 Clash 설정인지, 노드 목록인지, 일반 웹페이지인지 먼저 확인하세요. 노드 목록은 해당 프록시 제공자나 클라이언트 템플릿에 넣어야 하며 완전한 실행 설정처럼 바로 사용할 수는 없습니다. YAML 오류가 있으면 로그에 표시된 줄과 바로 윗줄부터 확인하세요. 들여쓰기에 공백을 사용했는지, 목록의 하이픈이 올바른지, 콜론 뒤 문자열에 따옴표가 필요한지 살펴봅니다. 이어서 현재 코어가 구독의 프로토콜과 설정 항목을 지원하는지 확인하세요. 가져오기가 끝나면 해당 설정을 선택하고 다시 불러와야 합니다. 설정 목록에 항목이 보인다고 해서 코어가 그 설정으로 전환된 것은 아닙니다.

먼저 클라이언트 로그에서 mixed-port가 실제로 수신 중인 포트를 확인한 뒤, 시스템 HTTP 및 HTTPS 프록시가 동일한 로컬 주소와 포트(예: 127.0.0.1:7890)를 가리키는지 살펴보세요. 포트는 예시이므로 현재 설정을 기준으로 확인해야 합니다. 브라우저의 개별 프록시 확장 프로그램을 끄고 브라우저를 다시 시작한 다음, 별도 프록시 설정이나 조직 정책이 적용되고 있는지 확인하세요. curl -x http://127.0.0.1:7890 -I https://example.com 명령으로 프록시를 직접 테스트할 수 있습니다. 명령은 성공하지만 브라우저에서 실패한다면 노드를 바로 바꾸기보다 브라우저 설정과 시스템 프록시 적용 여부를 점검하세요.

먼저 다른 VPN과 유사한 가상 네트워크 어댑터 프로그램을 종료한 뒤 클라이언트 안내에 따라 서비스 모드를 설치하거나 복구하세요. Windows에서는 서비스 실행 여부와 보안 프로그램의 차단 기록을 확인합니다. macOS에서는 시스템 설정에서 관련 네트워크 확장 프로그램이나 VPN 권한을 확인하세요. Linux에서는 /dev/net/tun이 있는지, 서비스를 실행하는 데 필요한 네트워크 관리 권한이 있는지 살펴보세요. 실행을 위해 시스템 보호 기능을 계속 꺼 두거나 출처를 알 수 없는 파일에 함부로 권한을 부여하지 마세요. 권한을 허용한 뒤 코어를 다시 시작하고도 실패한다면 화면의 전체 스위치 상태만 볼 것이 아니라 네트워크 어댑터나 라우팅 관련 첫 번째 오류를 확인하세요.

먼저 편집 중인 설정이 현재 적용된 설정인지 확인한 뒤, 클라이언트가 로드 과정에서 오버라이드, 스크립트 또는 병합 설정을 추가하는지 살펴보세요. 원격 구독 파일을 직접 수정하면 다음 업데이트 때 변경 사항이 덮어써질 수 있습니다. 포트, DNS, 사용자 지정 규칙처럼 계속 유지할 설정은 클라이언트의 오버라이드 기능으로 관리하는 편이 좋습니다. 수정 전에는 사본을 내보내고 한 번에 한 묶음의 설정 항목만 변경하세요. 저장한 뒤 설정을 다시 불러오고 로그를 확인합니다. 클라이언트마다 배열 병합 방식이 다를 수 있으므로 특히 rules가 추가되는지 교체되는지 살펴보세요. 편집기에서 보이는 특정 파일이 아니라 최종 실행 설정을 기준으로 판단해야 합니다.

규칙 모드에서 DOMAIN-SUFFIX,example.com,DIRECT를 먼저 매칭될 수 있는 포괄적인 규칙보다 앞에 두고, 마지막 기본 규칙은 유지하세요. DOMAIN-SUFFIX는 해당 도메인과 하위 도메인에 모두 적용됩니다. 완전한 호스트 이름 하나만 일치시키려면 DOMAIN을 사용하세요. 저장하고 설정을 다시 불러온 다음 대상 웹사이트의 기존 연결을 닫고 새 요청을 보내세요. 연결 화면에서 적용된 규칙 유형과 최종 정책을 확인합니다. 웹페이지가 여러 리소스 도메인에 동시에 접속할 수 있으므로 기본 도메인만 허용해도 모든 요청이 처리되지 않을 수 있습니다. 규칙은 이미 생성된 장기 연결에 소급 적용되지 않으므로 필요하면 관련 연결을 끊고 다시 시도하세요.

공유가 꼭 필요한지 먼저 확인한 다음 allow-lan을 활성화하고, 수신 주소가 연결에 사용할 네트워크 인터페이스를 포함하도록 설정하세요. 다른 기기에서는 클라이언트가 실행 중인 컴퓨터의 로컬 네트워크 주소를 입력해야 합니다. 127.0.0.1은 해당 기기 자신을 가리키므로 사용할 수 없습니다. 호스트 방화벽에서는 신뢰할 수 있는 서브넷만 프록시 포트에 접근하도록 제한하고, 클라이언트가 지원한다면 프록시 인증도 설정하세요. 라우터에서 해당 포트가 공용 인터넷에 포트 포워딩되지 않았는지도 확인합니다. 관리 인터페이스와 프록시 포트는 용도가 다르므로 함께 열지 마세요. 공유 테스트가 끝나면 로컬 네트워크 연결 옵션을 꺼서 장시간 열어 두는 인터페이스를 줄이는 것이 좋습니다.

먼저 curl -x http://127.0.0.1:7890 -I https://example.com처럼 도구 자체의 프록시 옵션으로 연결을 확인한 다음, 터미널과 도구 문서에 따라 HTTP_PROXY, HTTPS_PROXY 또는 ALL_PROXY를 설정하세요. 변수 이름의 HTTPS는 보통 대상 요청 유형을 뜻하며 프록시 주소도 반드시 HTTPS여야 한다는 의미는 아닙니다. 프로토콜은 로컬 수신 설정과 일치해야 합니다. 환경 변수는 대개 현재 프로세스와 하위 프로세스에만 적용되므로 이미 열려 있는 터미널이나 백그라운드 서비스에는 반영되지 않을 수 있습니다. 테스트가 끝나면 임시 설정을 제거해 클라이언트를 종료한 뒤에도 명령이 작동하지 않는 포트를 가리키지 않도록 하세요. 도메인 조회와 관련된 문제라면 로컬 DNS 조회와 프록시 서버 측 조회도 구분해야 합니다.

먼저 제공업체가 현재 코어에 맞는 구독 형식을 제공하는지 확인하세요. 바로 사용할 수 있다면 변환 단계를 추가할 필요가 없습니다. 변환이 꼭 필요하다면 신뢰할 수 있는 로컬 도구를 우선 사용하고, 입력이 노드 링크인지 노드 목록인지 완전한 설정인지 명확히 구분하세요. 전체 구독을 온라인 변환 서비스에 전달하면 구독에 포함된 인증 정보와 노드 정보를 해당 서비스에 맡기는 셈입니다. 변환 후에는 프록시 그룹 참조, 규칙 순서, 프로토콜 설정을 확인하세요. 가져오기에 성공했다는 사실만으로는 충분하지 않습니다. 변환은 형식을 바꿀 뿐, 만료된 계정이나 접속할 수 없는 서버 또는 코어가 아직 지원하지 않는 프로토콜 기능을 해결하지는 못합니다.

현재 적용 중인 설정을 내보내고 클라이언트 설정, 수신 포트, 코어 정보, 서비스 모드 사용 여부를 기록하세요. 필요한 오버라이드 파일도 보관합니다. 백업에는 구독과 인증 정보가 포함될 수 있으므로 접근을 통제할 수 있는 곳에 저장하고 공개 저장소에는 올리지 마세요. 업데이트할 때는 클라이언트, 코어, 구독 템플릿을 따로 처리하고 하나를 변경할 때마다 브라우저 접속, DNS, 자주 사용하는 앱을 확인하세요. 문제가 다시 발생하면 우선 이전 설정으로 복원한 뒤 프로그램도 되돌릴지 판단합니다. 서비스나 드라이버를 변경했다면 클라이언트의 제거 절차를 따르세요. 이전 서비스와 새 프로그램을 함께 사용하는 상황을 피해야 합니다.

시간 초과는 제한 시간 안에 이번 테스트가 완료되지 않았다는 뜻일 뿐입니다. 테스트 대상 주소에 접속할 수 없거나, 기기 시간이 잘못됐거나, DNS 조회가 실패했거나, 외부 연결이 제한됐거나, 노드 자체에 문제가 있을 수 있습니다. 먼저 일반 직접 연결이 정상인지 확인한 다음, 사용 가능한 것으로 확인된 노드를 선택해 실제 웹페이지 요청을 보내고 연결 로그에서 실패한 단계를 살펴보세요. 모든 노드가 동시에 실패한다면 DNS, 네트워크 환경, 코어 설정처럼 공통으로 사용하는 부분부터 확인합니다. 일부 노드만 실패한다면 서버나 프로토콜 차이를 살펴보세요. 연결 테스트에 성공해도 모든 웹사이트, UDP, 장기 연결이 작동한다고 보장되지는 않으므로 대상 앱에서 실제 요청을 다시 확인해야 합니다.

먼저 프록시를 끄고 기본 네트워크 연결이 되는지 확인한 다음 클라이언트를 다시 시작해 설정 로드 여부, 포트 수신 상태, 프록시 그룹에서 사용 가능한 노드를 선택했는지 살펴보세요. 이어서 프록시를 명시한 요청으로 로컬 연결과 시스템 프록시 처리 문제를 구분합니다. 잠시 전역 모드로 바꿔 분기 규칙 문제인지 확인한 뒤 마지막으로 DNS 조회와 TUN 라우팅 로그를 살펴보세요. 각 단계의 결과를 기록하고 포트, DNS, 노드를 동시에 바꾸지 마세요. 화면에 연결됨으로 표시되는 것은 보통 로컬 기능이 활성화됐다는 뜻이지 대상 요청이 성공했다는 의미는 아닙니다. 문제를 찾으려면 실제 접속 하나를 선택해 DNS 조회부터 연결 실패까지 전 과정을 추적하세요.

먼저 브라우저에서 로컬 프록시를 사용할 수 있는지 확인하고, 문제가 있는 앱이 앱 컨테이너의 루프백 제한을 받는지 살펴보세요. 일부 UWP 앱은 로컬 루프백 프록시에 직접 접속할 수 없습니다. 클라이언트에서 제공하는 루프백 예외 도구를 사용해 필요한 앱에만 권한을 부여하세요. 또는 관리자 터미널에서 CheckNetIsolation LoopbackExempt -s를 실행해 현재 예외 항목을 확인할 수 있습니다. 편의를 위해 모든 앱의 제한을 한꺼번에 해제하지 마세요. 루프백 권한을 부여한 뒤에도 문제가 계속되면 앱이 사용하는 네트워크 인터페이스, 프록시 설정, 방화벽을 확인하고 필요하면 TUN도 따로 테스트하세요. Windows 스토어 앱이 모두 UWP인 것은 아니므로 설치 경로만으로 판단할 수 없습니다.

시스템 DNS, 브라우저의 보안 DNS, 클라이언트 DNS, 현재 트래픽 처리 방식을 먼저 기록하세요. 테스트 사이트에 표시된 위치만 보고 DNS 유출 여부를 판단하지 마세요. fake-ip를 사용한다면 dns.enable과 enhanced-mode가 적용됐는지 확인하고, 사용 중인 코어의 설정 문서에 따라 TUN에서 DNS 가로채기, 라우팅, DNS 조회 출구를 점검하세요. 브라우저가 자체적으로 암호화 DNS 요청을 보내는지도 별도로 확인해야 합니다. 시스템과 브라우저의 DNS 캐시를 비운 다음 연결을 다시 만들고 테스트하세요. respect-rules를 켰다면 DNS 규칙과 프록시 서버 도메인의 초기 DNS 조회도 함께 확인해 DNS가 프록시에 의존하고 프록시는 다시 DNS에 의존하는 순환이 생기지 않도록 하세요.

클라이언트를 종료한 뒤 인터넷이 끊겼다면 시스템 프록시가 종료된 로컬 포트를 계속 가리키는지 확인하세요. 남아 있는 프록시 설정을 끄고 TUN 서비스, 가상 네트워크 어댑터, 라우팅이 클라이언트 종료 절차에 따라 해제됐는지도 살펴봅니다. 포트가 사용 중이라면 먼저 해당 프로세스를 확인하세요. Windows에서는 netstat -ano로 수신 포트와 PID를 확인할 수 있고, macOS 또는 Linux에서는 예시 포트에 lsof -nP -iTCP:7890 -sTCP:LISTEN을 사용할 수 있습니다. 정체를 모르는 시스템 프로세스를 바로 종료하지 마세요. mixed-port를 변경했다면 시스템 프록시, 터미널 환경 변수, 로컬 네트워크 기기 설정도 함께 바꿔야 합니다. 그렇지 않으면 포트 충돌이 연결 거부 오류로 바뀔 뿐입니다.