Clash 자주 묻는 질문

Clash는 일반적으로 프록시 코어와 그 설정 생태계를 가리킵니다. mihomo는 Clash 설정과 호환되면서 기능을 확장해 나가는 코어 프로젝트입니다. 그래픽 클라이언트는 설정 가져오기, 정책 선택, 시스템 프록시 설정, 코어 프로세스 관리를 담당합니다. 화면이 비슷하다고 코어 기능까지 같은 것은 아닙니다. 프로토콜이나 설정 항목의 호환성을 확인할 때는 먼저 클라이언트의 정보 화면이나 시작 로그에서 코어 이름을 확인한 뒤 해당 문서를 살펴보세요. 이 문서의 고급 설정은 mihomo를 기준으로 하며, 구형 코어에서는 일부 항목을 지원하지 않을 수 있습니다.

클라이언트는 프록시 연결과 트래픽 분산 기능을 제공하지만, 설치 프로그램만으로 프록시 서비스를 사용할 수 있는 것은 아닙니다. 구독이나 로컬 YAML 설정에는 보통 프록시 서버, 정책 그룹, 규칙이 포함됩니다. 실제 연결 여부는 서비스가 유효한지와 현재 네트워크에서 접속할 수 있는지에 달려 있습니다. 설정을 가져온 뒤에는 현재 설정으로 선택되었는지 확인하고, 정책 그룹에 선택할 수 있는 프록시가 있는지 살펴보세요. 구독 링크에는 다른 사람이 서비스 설정을 읽을 수 있는 접근 정보가 포함될 수 있으므로 공개 게시판에 올리지 마세요.

일상적인 트래픽 분산에는 Rule 모드를 권장합니다. 연결은 rules를 위에서부터 순서대로 확인하고, 처음 일치하는 규칙에 따라 처리됩니다. Global 모드는 코어로 들어온 연결을 GLOBAL 정책 그룹으로 보내며, 이 그룹에서 실제 프록시를 선택해야 합니다. Direct 모드에서는 코어로 들어온 연결을 직접 연결합니다. 모드만 바꿔서는 모든 앱의 트래픽이 자동으로 코어에 들어오지 않습니다. 트래픽이 코어에 전달되는지는 시스템 프록시나 TUN 설정에 달려 있습니다. 따라서 Global로 바꾼 뒤에도 접속할 수 없다면 모드만 반복해서 바꾸지 말고, 트래픽 전달과 프록시 연결을 함께 확인하세요.

시스템 프록시는 운영체제의 프록시 설정을 클라이언트의 수신 포트로 지정합니다. 이 설정을 따르는 브라우저와 앱에 적합하지만, 직접 연결을 만들거나 별도의 프록시 설정을 사용하는 프로그램은 우회할 수 있습니다. TUN은 가상 네트워크 인터페이스를 만들고 라우팅을 통해 더 많은 IP 트래픽을 처리합니다. DNS, 라우팅, 권한 설정도 함께 맞춰야 합니다. 처음에는 시스템 프록시로 설정이 정상인지 확인하고, 다른 앱의 트래픽까지 처리해야 할 때 TUN을 켜세요. 문제를 점검할 때는 한 번에 하나씩 활성화해 네트워크 경로를 여러 개 동시에 바꾸지 않는 것이 좋습니다.

그렇지는 않습니다. 지연 시간 테스트는 보통 지정된 테스트 주소에 프록시를 통해 요청했을 때 걸리는 시간만 확인하며, 모든 웹사이트나 UDP 또는 대상 서비스의 이용 가능 여부를 보장하지 않습니다. 테스트 주소, 시간 초과 설정, 연결 재사용, 현재 네트워크 상태가 결과에 영향을 줍니다. 먼저 테스트에 사용한 정책이 실제 접속에 사용하는 정책과 같은지 확인한 뒤 대상 웹사이트를 열고, 연결 화면에서 적용된 규칙과 송신 정책을 살펴보세요. 특정 서비스만 실패한다면 출구 지역 제한, 서버 측 거부, 해당 도메인의 잘못된 트래픽 분산 여부도 확인해야 합니다.

클라이언트의 설정 또는 구독 관리 화면에서 원격 설정을 추가하고, 전체 링크를 붙여 넣은 뒤 다운로드하거나 가져오세요. 메뉴 이름은 클라이언트마다 다를 수 있습니다. 다운로드가 끝나면 해당 설정을 현재 설정으로 지정하고 코어가 정상적으로 다시 로드되었는지 확인하세요. 그런 다음 정책 그룹의 프록시 이름, 규칙 내용, 업데이트 로그를 살펴보세요. 화면에 이전 내용이 계속 표시된다면 현재 사용 중인 설정을 업데이트했는지, 로컬 오버라이드가 설정을 대체하지 않았는지 확인하세요. 구독 목록의 업데이트 시간만으로 전체 설정이 적용됐다고 판단해서는 안 됩니다.

먼저 링크가 완전한지, 서비스 제공업체가 링크를 재설정하지 않았는지 확인한 뒤 계정 유효 기간과 데이터 사용량을 살펴보세요. 로그에 HTTP 401 또는 403이 표시되면 인증이나 접근 제한을 우선 확인합니다. 404는 링크 경로가 바뀌었을 수 있고, 시간 초과라면 현재 네트워크에서 구독 주소에 접속할 수 있는지 확인하세요. 프록시를 통해서만 주소에 접속할 수 있다면 클라이언트가 지원하는 경우 설정 업데이트에 사용할 프록시 방식을 바꿔 보세요. 낯선 구독 변환 사이트에 링크를 반복해서 입력하지 마세요. 링크가 유출된 사실을 확인했다면 서비스 제공업체의 관리 페이지에서 구독 식별 정보를 재설정하세요.

먼저 다운로드한 파일이 YAML 설정인지 확인하세요. 로그인 페이지나 오류 페이지, 프록시 링크 목록만 받은 것은 아닌지 살펴봅니다. 로그에 줄 번호가 표시되면 해당 줄과 바로 앞줄의 들여쓰기, 콜론, 따옴표를 확인하세요. YAML 들여쓰기에는 공백을 사용하고 탭은 사용하지 않습니다. 파싱에 성공해도 존재하지 않는 정책 그룹을 규칙에서 참조하거나 구형 코어가 특정 프록시 유형을 지원하지 않는 등 설정 내용 자체의 오류가 있을 수 있습니다. 수정 전 원본 파일을 보관하고 한 번에 한 곳만 변경한 뒤, 클라이언트의 설정 검사 또는 코어 테스트 기능으로 다시 확인하세요.

먼저 로그를 확인해 권한 부족, 서비스 미실행, 가상 인터페이스 생성 실패 중 어떤 문제인지 구분하세요. 우선 클라이언트에서 제공하는 서비스 모드 설치 또는 시작 기능을 사용하고, 시스템 안내에 따라 권한을 허용하세요. 서비스 모드가 없는 클라이언트라면 프로그램 출처를 확인한 뒤 관리자 권한으로 실행해 테스트할 수 있습니다. 서비스를 설치한 뒤 클라이언트를 다시 시작해야 TUN을 켤 수 있는 경우도 있습니다. 그래도 실패하면 보안 소프트웨어의 차단 기록과 다른 VPN의 가상 인터페이스를 확인하세요. 원인을 찾는 대신 방화벽 전체를 끄거나 드라이버 설치를 연달아 반복하지 마세요.

mixed-port는 HTTP와 SOCKS 프록시 연결을 모두 받는 수신 포트입니다. 7890은 흔히 사용하는 설정 예시일 뿐 반드시 써야 하는 포트는 아닙니다. address already in use 오류가 발생하면 다른 프록시 인스턴스를 종료하거나 시스템 도구로 포트 사용 여부를 확인하세요. 그런 다음 클라이언트의 포트 설정 또는 로컬 설정에서 사용 중이 아닌 포트를 선택합니다. 설정을 다시 불러온 뒤 정상적으로 수신 중인지 확인하고, 브라우저와 터미널 등 다른 앱의 수동 프록시 주소도 함께 업데이트하세요. 원격 구독이 변경 사항을 덮어쓸 수 있으므로, 장기간 유지할 설정은 클라이언트의 영구 오버라이드 기능을 사용하세요.

Rule 모드에서 해당 도메인의 직접 연결 규칙을 일반 프록시 규칙과 MATCH보다 앞에 배치하세요. 예를 들어 DOMAIN-SUFFIX,example.com,DIRECT는 example.com과 하위 도메인에 적용되고, DOMAIN,example.com,DIRECT는 해당 도메인에만 적용됩니다. 설정을 다시 불러온 뒤 기존 연결을 닫고 다시 접속해 연결 화면에서 적용된 규칙을 확인하세요. 규칙은 처음 일치하는 항목이 적용되므로 MATCH 뒤에 추가하면 대개 작동하지 않습니다. 원격 구독을 사용한다면 로컬 오버라이드로 사용자 지정 규칙을 보존하세요.

select는 구성원을 직접 선택하는 방식으로, 특정 회선을 고정해 사용할 때 적합합니다. url-test는 테스트 결과에 따라 적절한 구성원을 자동 선택하며, 테스트 주소와 허용 오차 등의 설정에 영향을 받습니다. fallback은 구성원 순서대로 사용 가능한 항목을 선택하므로 기본 회선에 문제가 생겼을 때 예비 회선으로 전환하는 데 적합합니다. 자동 그룹이 웹사이트별 접근 제한까지 파악하는 것은 아니며, 테스트 성공이 대상 서비스 이용 가능성을 뜻하지도 않습니다. 먼저 출구를 고정할지, 테스트 결과로 선택할지, 순서에 따라 장애 조치를 할지 정한 뒤 테스트 간격을 설정하세요. 잦은 전환이 안정성을 보장한다고 생각해서는 안 됩니다.

Fake-IP는 코어가 앱에 가상 주소를 반환하고, 저장된 도메인 매핑을 바탕으로 연결을 처리하는 방식입니다. 원격 프록시 서버의 실제 주소가 아닙니다. mihomo에서는 보통 dns.enable과 dns.enhanced-mode로 설정하며, TUN 환경에서는 DNS 요청이 실제로 코어에 전달되는지도 확인해야 합니다. 로컬 네트워크 기기 검색, 일부 게임, 실제 DNS 응답에 의존하는 앱은 fake-ip-filter 조정이 필요할 수 있습니다. 호환되지 않는다고 확인된 도메인만 먼저 예외로 추가한 뒤 앱이나 시스템의 DNS 캐시를 비우세요. 문제를 피하려고 모든 도메인을 예외 처리하는 것은 바람직하지 않습니다.

먼저 휴대폰과 컴퓨터를 서로 통신할 수 있는 같은 로컬 네트워크에 연결하세요. 컴퓨터 설정에서 allow-lan을 켜고 bind-address가 로컬 네트워크 인터페이스에서 수신하도록 허용하는지 확인합니다. 휴대폰의 Wi-Fi 수동 HTTP 프록시 설정에는 컴퓨터의 로컬 IP 주소와 실제 mixed-port를 입력하세요. 127.0.0.1을 입력하면 안 됩니다. 그런 다음 신뢰할 수 있는 사설 네트워크에서만 해당 인바운드 포트를 허용하고, 접속 가능한 네트워크 범위를 제한하세요. 수동 HTTP 프록시는 휴대폰의 모든 트래픽을 처리하는 기능이 아닙니다. 공용 네트워크에서 수신 포트를 열지 말고, 필요한 경우 프록시 인증을 설정하세요.

원격 설정을 업데이트하면 설정 파일을 다시 다운로드하는 경우가 많아 파일을 직접 편집한 규칙이 덮어써질 수 있습니다. 클라이언트가 제공하는 오버라이드, 병합 또는 스크립트 처리 기능을 사용하고 실행 순서와 적용 범위를 확인하세요. 정책 선택을 유지할 수 있는지는 클라이언트와 profile.store-selected 등의 설정에도 영향을 받습니다. 정책 그룹이나 프록시 이름이 바뀌면 기존 선택에 해당하는 항목이 없어질 수도 있습니다. 업데이트 전에 로컬 오버라이드를 보관하고, 업데이트 후 실제 생성된 설정을 확인하세요. 특히 사용자 지정 규칙이 일반 규칙보다 앞에 있는지 살펴보세요.

먼저 시스템 프록시 주소가 실행 중인 클라이언트의 수신 포트를 가리키는지 확인하세요. 그런 다음 브라우저 프록시 확장 프로그램, 별도 프록시 설정, 시스템 자동 설정 스크립트가 기존 설정을 덮어쓰는지 살펴봅니다. 새 연결로 웹사이트에 접속하면서 클라이언트 연결 화면을 확인하세요. 기록이 전혀 없다면 트래픽 진입 경로를 우선 점검하고, 기록은 있지만 DIRECT로 연결된다면 모드와 규칙을 확인합니다. 터미널 프로그램은 시스템 프록시를 따르지 않을 수 있으므로 해당 프로그램 문서에 따라 별도로 설정하세요. 기업 정책이 프록시를 강제 지정할 수도 있으니 스위치를 반복해서 바꾸기보다 기기 관리 제한을 먼저 확인하세요.

먼저 프록시를 끄고 로컬 네트워크로 정상 접속할 수 있는지 확인한 뒤 시스템 시간, 구독 유효 기간, 현재 설정을 살펴보세요. 로그의 오류 유형도 확인합니다. 도메인 이름 확인에 실패하면 DNS를, 연결 시간 초과라면 서버 접속 가능 여부를 확인하세요. 인증 또는 TLS 오류라면 인증 정보, 시간, 프로토콜 설정을 점검합니다. 그런 다음 정상 작동이 확인된 다른 회선을 사용하거나 네트워크를 바꿔 문제가 회선이나 네트워크에 따라 달라지는지 확인하세요. 테스트 페이지의 시간 초과만으로 모든 프록시가 작동하지 않는다고 단정하지 마세요. 실제 접속도 실패한다면 서비스 제공업체에 문의하고 민감 정보를 가린 오류 로그를 전달하세요.

먼저 시스템에 로컬 포트를 가리키는 수동 프록시 설정이 남아 있는지 확인하세요. 클라이언트를 종료한 뒤에는 해당 주소에서 수신하는 프로그램이 없어 브라우저 연결이 실패할 수 있습니다. 남아 있는 수동 프록시를 끄고 다시 테스트하세요. 이전에 TUN을 사용했다면 클라이언트를 다시 열고 TUN을 끈 뒤 정상 종료한 다음, 시스템 DNS가 중지된 로컬 서비스 주소를 여전히 가리키는지 확인하세요. 처음부터 모든 네트워크 설정을 초기화하지 마세요. 회사나 학교 기기에는 필요한 프록시와 DNS 설정이 있을 수 있으므로 현재 설정을 기록한 뒤 관리자 지침에 맞게 복구하세요.

일부 UWP 앱은 네트워크 격리로 인해 로컬 컴퓨터의 루프백 프록시에 직접 접속할 수 없습니다. 먼저 문제가 발생한 앱이 실제로 시스템 프록시를 사용하는지 확인하세요. 그런 다음 관리자 권한으로 CheckNetIsolation LoopbackExempt -s를 실행해 예외 목록을 확인합니다. 필요한 경우 CheckNetIsolation LoopbackExempt -a -n=Microsoft.WindowsStore_8wekyb3d8bbwe를 실행해 Microsoft Store를 예외에 추가하세요. 다른 앱에는 실제 패키지 패밀리 이름을 사용해야 하며, 스토어에 표시된 이름을 그대로 입력하면 안 됩니다. 필요한 앱에만 권한을 허용하세요. TUN을 사용한다면 라우팅, DNS, 규칙 적용 여부도 따로 확인해야 합니다.

먼저 TUN을 끄고 시스템 프록시로 같은 웹사이트를 테스트해 프록시 서비스 자체가 정상인지 확인하세요. 그런 다음 TUN만 켜고 로그에서 DNS 요청, 송신 연결, 라우팅 오류를 살펴보며 다른 VPN이 동시에 실행 중인지 확인합니다. Fake-IP를 사용한다면 시스템 DNS 조회가 코어에 전달되는지, 앱이 이전 캐시를 사용하고 있지 않은지 확인하세요. 로컬 네트워크 도메인은 직접 연결 시의 DNS 처리 방식도 점검해야 합니다. 브라우저의 보안 DNS는 별도의 조회 경로를 사용할 수 있으므로 잠시 끄고 비교해 보세요. 원래 설정을 보관하고 항목별로 조정하세요. DNS, 네트워크 스택, 모든 규칙을 한꺼번에 바꾸면 원인을 찾기 어렵습니다.