Clash 자주 묻는 질문

클라이언트는 구독 관리, 모드 선택, 시스템 프록시 설정 등의 인터페이스를 제공합니다. mihomo 코어는 설정을 읽어 프록시 연결을 만들고 규칙을 적용하며 DNS를 처리합니다. 구독은 서비스 제공자가 설정이나 프록시 정보를 전달하는 경로입니다. 세 가지는 서로 다른 역할입니다. 클라이언트를 설치해도 사용할 수 있는 프록시가 자동으로 생기지 않으며, 클라이언트를 바꿔도 서비스 제공자가 중단한 구독이 복구되지는 않습니다. 문제를 확인할 때는 먼저 현재 설정이 불러와졌는지, 다음으로 코어가 실행 중인지, 마지막으로 구독 서비스가 정상인지 확인하세요. 계정 문제를 설치 문제로 오인하지 않는 것이 중요합니다.

규칙 모드는 rules를 위에서 아래로 확인해 연결에 맞는 규칙을 적용합니다. 전역 모드는 코어로 들어온 연결을 전역 프록시 그룹으로 보내며, 해당 그룹에서 사용할 출구를 선택해야 합니다. 직접 연결 모드는 코어로 들어온 연결이 대상에 바로 접속하도록 합니다. 모드는 이미 코어가 처리하는 트래픽의 경로만 결정하며, 프록시를 사용하지 않는 앱을 자동으로 코어에 연결하지는 않습니다. 평소에는 규칙 모드를 사용하세요. 트래픽 분기 문제를 확인할 때는 잠시 전역 모드로 바꿔 테스트할 수 있지만, 테스트가 끝나면 원래대로 돌려놓으세요. 직접 연결 모드라고 해서 TUN이 꺼지는 것은 아닙니다. 가상 인터페이스가 라우팅과 DNS 처리에 계속 관여할 수 있습니다.

처음 설정할 때는 시스템 프록시를 먼저 켜고, 시스템 프록시 설정을 따르는 브라우저에서 구독, 출구, 규칙이 작동하는지 확인하세요. 시스템 프록시는 해당 설정을 읽는 앱에 주로 적용되며 모든 프로세스를 처리하지는 않습니다. 게임이나 일부 명령줄 도구처럼 시스템 프록시 설정을 따르지 않는 앱까지 처리해야 한다면 그때 TUN을 켜고 서비스 권한, 가상 인터페이스, DNS를 확인하세요. 문제를 찾는 동안에는 설정을 한 번에 하나씩만 변경하세요. 두 방식이 모두 켜져 있다면 하나씩 꺼서 비교해야 트래픽 처리 경로가 겹쳐 생기는 문제를 구분하기 쉽습니다.

지연 시간 테스트는 보통 특정 출구가 설정된 테스트 주소에 접속할 수 있음을 보여줄 뿐, 대상 웹사이트나 모든 프로토콜·앱의 작동까지 보장하지는 않습니다. 먼저 연결 기록에서 브라우저 요청이 코어에 들어왔는지 확인한 다음, 적용된 규칙과 프록시 그룹, 실제 출구를 살펴보세요. 기록이 없다면 트래픽 처리 설정부터 확인하고, 기록은 있지만 연결에 실패한다면 대상 도메인의 DNS 조회, 출구 제한, 서비스 상태를 점검하세요. 테스트한 대상이 단일 프록시인지 자동 선택 그룹인지도 확인해야 합니다. 그룹에서 최종 선택된 프록시가 방금 수동으로 테스트한 프록시와 다를 수 있습니다.

클라이언트의 설정, 구독 또는 Profiles 화면에서 URL 가져오기 메뉴를 찾아 서비스 제공자가 준 전체 구독 주소를 붙여 넣으세요. 저장한 뒤 업데이트하고, 해당 설정을 현재 설정으로 지정합니다. 구독 주소를 external-controller에 입력하거나 웹 대시보드 주소를 구독 링크로 사용하면 안 됩니다. 가져온 뒤 사용할 수 있는 프록시 그룹이 표시되는지, 로그에 파싱 오류가 있는지 확인하세요. 구독 링크에는 계정 정보가 포함되는 경우가 많으므로 공개 채팅방이나 스크린샷, 온라인 변환 사이트에 공유하지 마세요. 유출됐다면 서비스 제공자 계정 페이지에서 먼저 링크를 재설정하세요.

먼저 서비스 제공자 계정 페이지에서 계정이 유효한지, 사용량 한도가 남아 있는지, 구독 주소가 재설정되지 않았는지 확인하세요. 계정 페이지에서 링크를 다시 복사해 주소가 잘리거나 끝에 공백이 붙지 않았는지, 만료된 링크가 아닌지 살펴봅니다. 업데이트 로그도 확인하세요. 401 또는 403은 보통 인증 정보나 접근 제한을, 404는 주소 오류를 의미하며, 시간 초과라면 먼저 네트워크 경로를 점검해야 합니다. 현재 네트워크에서 구독 도메인에 직접 접속할 수 없다면 클라이언트가 지원하는 경우 프록시를 통한 업데이트를 켜고, 사용할 수 있는 설정이 이미 있는지 확인하세요. HTML이나 로그인 페이지가 반환되면 계속 다시 가져오지 말고 서비스 제공자에게 올바른 Clash 또는 mihomo 설정 링크를 문의하세요.

원본 파일을 보관하고 로그에 표시된 줄과 바로 윗줄의 들여쓰기, 콜론, 목록 구조를 확인하세요. YAML은 공백으로 들여쓰며 탭을 섞어 쓰면 안 됩니다. 프록시 그룹이 참조하는 프록시 이름이 실제로 존재하는지, 규칙이 지정한 프록시 그룹 이름이 일치하는지도 확인하세요. 코어가 지원한다면 설정 파일이 있는 디렉터리에서 mihomo -t -f config.yaml을 실행해 검사하고, 현재 코어가 반환한 오류를 기준으로 수정하세요. 구문 검사를 통과해도 설정을 읽을 수 있다는 뜻일 뿐, 출구 연결까지 보장하지는 않습니다. 알 수 없는 필드나 지원되지 않는 프로토콜 오류가 나오면 코어 종류와 구독 형식을 확인하세요. 설정 전체를 바로 삭제하지 마세요.

데스크톱에서는 먼저 클라이언트가 요구하는 서비스 모드가 설치되어 실행 중인지 확인하세요. 필요하면 클라이언트 안내에 따라 관리자 권한이나 시스템 네트워크 확장 권한을 허용합니다. Android에서는 시스템 VPN 연결 요청을 승인하고, VPN 채널을 사용하는 다른 앱을 먼저 종료하세요. Linux에서는 실행 방식에 맞춰 /dev/net/tun, 서비스 계정, 필요한 네트워크 권한을 확인하세요. 모든 파일을 무조건 쓰기 가능하게 바꾸면 안 됩니다. 로그에서 가장 먼저 나타난 권한 또는 인터페이스 오류를 확인하세요. 인터페이스 생성은 성공했지만 트래픽이 흐르지 않는다면 권한을 계속 높이거나 클라이언트를 재설치하는 대신 라우팅과 DNS를 점검해야 합니다.

먼저 실제 mixed-port와 수신 주소를 확인한 뒤, 프록시 인수를 지원하는 도구에 주소를 명시하세요. 포트가 7890이라면 curl -I --proxy http://127.0.0.1:7890 https://example.com으로 요청을 확인하고, 프록시 인수 없이 실행한 결과와 비교할 수 있습니다. 터미널에 HTTP_PROXY, HTTPS_PROXY 또는 ALL_PROXY를 설정할 때는 현재 shell의 문법을 따르고, 사용하려는 도구가 어떤 변수를 읽는지도 확인하세요. 환경 변수는 보통 현재 프로세스와 자식 프로세스에만 적용됩니다. 테스트가 끝나면 임시 설정을 해제해 클라이언트를 종료한 뒤에도 터미널이 로컬 포트를 가리키지 않도록 하세요.

우선 서비스 제공자가 권장하는 업데이트 주기를 따르세요. 클라이언트에서 현재 구독의 편집 화면을 열어 자동 업데이트 또는 업데이트 간격을 찾고, 단위가 분인지 시간인지 확인합니다. 만료된 링크를 아주 짧은 간격으로 계속 재시도하면 서버에서 요청을 제한할 수 있습니다. 전체 설정 업데이트와 proxy-providers의 interval은 구분해야 합니다. 전자는 클라이언트가 관리하고, 후자는 코어가 프로바이더 설정에 따라 내용을 가져옵니다. 업데이트 뒤에는 현재 적용된 설정과 프록시 그룹이 여전히 정상인지 확인하세요. 클라이언트를 완전히 종료했거나 모바일 운영체제가 백그라운드 실행을 제한하면 예약 업데이트가 제때 실행되지 않을 수 있습니다.

먼저 현재 모드가 규칙인지 확인한 다음, 비활성 복사본이 아니라 실제로 사용 중인 설정을 수정했는지 확인하세요. rules는 순서대로 적용되므로 일반적으로 더 구체적인 규칙을 포괄적인 규칙보다 앞에 둬야 하며, MATCH는 맨 끝에 있어야 합니다. 규칙이 지정한 프록시 그룹도 실제로 존재해야 합니다. 저장한 뒤 클라이언트에서 요구하는 방식으로 설정을 다시 불러오고, 새 연결을 만들어 규칙이 적용되는지 확인하세요. 기존 장시간 연결은 이전 경로를 계속 사용할 수 있습니다. 구독 업데이트가 로컬 수정을 덮어쓴다면 클라이언트의 오버라이드 또는 병합 기능으로 규칙을 저장하고, 최종 생성된 설정에서 중복 규칙이나 들여쓰기 오류가 없는지 확인하세요.

먼저 서비스 제공자에게 현재 코어에 맞는 설정 링크가 있는지 확인하세요. 바로 가져올 수 있다면 별도로 변환할 필요가 없습니다. 프록시 정보 목록만 담긴 구독은 규칙, DNS, 프록시 그룹을 포함한 완전한 설정과 다르므로, 변환 후 최종 파일에 필요한 구조가 들어 있는지 확인해야 합니다. 변환 서비스는 원본 구독 주소와 인증 정보에 접근할 수 있습니다. 신뢰할 수 있는 서비스나 직접 설치한 도구를 사용하고, 출처를 알 수 없는 사이트에는 링크를 제출하지 마세요. 변환한다고 구형 코어가 새 프로토콜을 지원하게 되는 것도 아닙니다. 로그에 프로토콜 비호환이 표시되면 호환되는 코어를 사용하거나 서비스 제공자에게 출력 형식 변경을 요청하세요.

먼저 프록시 트래픽 처리를 끄고 일반 웹사이트에 접속해 로컬 네트워크가 정상인지 확인하세요. 그런 다음 시스템 시간, 계정 상태, 구독 업데이트 결과를 점검합니다. 특정 프록시 하나를 직접 테스트하고 도메인 조회, TCP 연결, 핸드셰이크 중 어느 단계에서 실패하는지 로그를 확인하세요. 모든 항목이 시간 초과되어도 테스트 주소 자체에 접속할 수 없는 경우가 있으므로 테스트 목록만 보고 모든 출구가 중단됐다고 판단하면 안 됩니다. 신뢰할 수 있는 다른 네트워크에서도 비교해 보세요. 현재 네트워크에서만 실패한다면 네트워크 제한과 DNS를 중점적으로 확인합니다. 여러 네트워크에서 같은 단계로 실패한다면 민감 정보를 제거한 로그와 발생 시간을 서비스 제공자에게 전달하세요.

시스템 네트워크 설정의 프록시 주소가 클라이언트의 실제 수신 주소와 일치하는지 확인하세요. 일반적인 로컬 주소는 127.0.0.1이지만 포트는 현재 설정을 따라야 하며, 항상 7890이라고 가정하면 안 됩니다. 이어서 브라우저 확장 프로그램, 앱 자체의 프록시 설정, 우회 목록을 확인하세요. 이런 설정이 시스템 프록시를 덮어쓰거나 건너뛸 수 있습니다. 연결 기록에 해당 앱의 요청이 없다면 프록시 주소를 직접 지정해 비교해 보세요. 직접 지정한 프록시는 작동하는데 시스템 프록시는 작동하지 않는다면 앱이 프록시 설정을 읽는 방식을 확인해야 합니다. 일부 프로그램은 시작할 때만 설정을 읽으므로 변경 후 재시작이 필요합니다. 시스템 프록시를 따르지 않는 앱은 TUN 사용을 검토하세요.

먼저 일반 데스크톱 브라우저가 같은 프록시로 인터넷에 접속되는지 확인한 뒤, 문제가 생긴 앱이 루프백 격리 제한을 받는 앱인지 살펴보세요. 클라이언트에서 제공하는 UWP 루프백 도구를 사용해 필요한 앱만 예외로 추가할 수 있습니다. 또는 관리자 터미널에서 CheckNetIsolation LoopbackExempt -s를 실행해 현재 목록을 확인한 뒤, 대상 앱의 패키지 패밀리 이름을 지정해 설정하세요. 모든 앱을 한꺼번에 허용하면 안 됩니다. 설정 후 대상 앱을 다시 시작하고 연결 기록을 확인하세요. 루프백 예외는 로컬 프록시에 접속할 수 있도록 할 뿐, 구독·규칙·DNS 설정을 대신하지 않습니다.

먼저 클라이언트에서 TUN과 시스템 프록시를 끄고 정상적으로 종료한 다음, 시스템 프록시가 더 이상 수신하지 않는 로컬 포트를 가리키고 있지 않은지 확인하세요. 직접 연결이 복구되면 클라이언트를 다시 시작할 때 트래픽 처리 방식 하나만 켜고 가장 먼저 나타나는 라우팅 또는 DNS 오류를 살펴보세요. 여전히 인터넷에 연결할 수 없다면 활성 네트워크 어댑터의 DNS가 접속할 수 없는 주소로 수동 설정되어 있는지 확인하고, 다른 VPN·가상 네트워크 어댑터·보안 소프트웨어와 라우팅 충돌이 있는지도 점검하세요. 네트워크 설정을 복구하기 전에 기존 값을 기록해 두고, 네트워크 어댑터를 전부 삭제하지 마세요. 필요하면 시스템을 재시작해 남은 상태를 정리하세요. 연결이 복구되면 기능을 하나씩 다시 켜고 재현 가능한 최소 설정을 유지하세요.