Clash 자주 묻는 질문
구독·프록시·연결 문제 해결

Clash는 프록시 코어와 설정 생태계에서 널리 쓰이는 이름이고, mihomo는 이 생태계의 오픈소스 코어 구현체입니다. 그래픽 클라이언트는 구독, 프록시 그룹, 로그, 시스템 설정을 관리하는 화면을 제공합니다. 이름이 비슷해도 같은 코어를 사용하는 것은 아니며, 모든 설정 항목을 지원한다는 뜻도 아닙니다. 클라이언트를 선택할 때는 기기 플랫폼, 유지 관리 상태, 코어 호환성을 먼저 확인하고 TUN이나 LAN 공유가 필요한지도 살펴보세요. 문제를 진단할 때는 클라이언트 이름과 코어 정보를 함께 기록해야 합니다. Clash를 사용한다고만 하면 해당 설정 항목의 지원 여부를 판단하기 어려울 수 있습니다.

대부분 필요합니다. 클라이언트는 설정을 읽고 연결을 처리하지만, 설치만으로 사용할 수 있는 프록시 서비스가 생기지는 않습니다. 구독 주소는 보통 서비스 제공자가 발급하며 개인 접속 정보가 포함될 수 있으므로 민감 정보로 취급하세요. 가져오기 전에 현재 코어가 설정 형식을 지원하는지 확인하고, 구독 유효 기간과 계정 잔여량도 살펴보세요. 이 사이트는 클라이언트 다운로드와 설정 안내를 제공하며 구독이나 노드를 생성하지 않습니다. 문의할 때는 오류 문구만 공유하고 전체 구독 주소, QR 코드, 개인 정보가 포함된 설정 파일은 보내지 마세요.

규칙 모드는 rules 순서에 따라 연결 경로를 정하므로 일상적인 사용에 적합합니다. 전역 모드는 코어에 들어온 연결을 대체로 전역 프록시 그룹으로 보내므로 잠깐 비교 테스트할 때 유용합니다. 직접 연결 모드는 코어에 들어온 연결을 대상에 바로 연결합니다. 전역 모드라고 해서 컴퓨터 전체의 트래픽을 처리하는 것은 아닙니다. 시스템 프록시나 TUN을 거치지 않는 앱은 클라이언트를 우회할 수 있습니다. 테스트가 끝나면 규칙 모드로 되돌리고 연결 목록에서 대상 도메인에 어떤 규칙이 적용됐는지 확인하세요. 모드를 바꿔도 만료된 구독이나 계정, 연결할 수 없는 노드가 복구되지는 않으며 기본 네트워크 점검을 대신할 수도 없습니다.

mixed-port는 코어가 HTTP와 SOCKS5 프록시 연결을 함께 받는 포트입니다. 예시로 7890을 자주 사용하지만 실제 포트 번호는 현재 설정을 확인하세요. 시스템 프록시는 운영체제 설정에 프록시 주소를 지정하며, 해당 설정을 따르는 앱에 주로 적용됩니다. TUN은 가상 네트워크 인터페이스를 통해 라우팅 조건에 맞는 트래픽을 처리하며 관련 권한과 네트워크 구성 요소가 필요합니다. 초보자라면 먼저 시스템 프록시를 사용해 브라우저 연결을 확인한 뒤 앱 요구에 따라 TUN을 테스트하세요. 두 기능을 항상 함께 켜둘 필요는 없습니다. 문제가 생기면 각각 따로 테스트해야 포트, 권한, 라우팅 충돌을 찾기 쉽습니다.

클라이언트의 설정 또는 구독 화면에서 새 구독을 만들고 전체 주소를 붙여 넣은 다음 저장하고 업데이트하세요. 업데이트가 끝나면 새 설정을 현재 사용 항목으로 지정합니다. 로컬 파일은 파일 가져오기를 선택하고 확장자뿐 아니라 실제 내용도 YAML인지 확인하세요. 다운로드에 실패해 저장된 웹페이지를 가져오지 않도록 주의해야 합니다. 가져오기에 성공한 뒤에는 프록시 그룹에서 사용할 정책을 선택하고 시스템 프록시를 켜세요. 로컬 파일을 수정했다면 원본을 보관하고 들여쓰기를 확인해 탭 문자를 섞지 마세요. 클라이언트마다 버튼 이름은 다를 수 있지만 설정 가져오기, 활성화, 정책 선택, 트래픽 연결 순으로 진행해야 합니다.

먼저 업데이트 오류를 확인해 HTTP 상태 코드, 연결 시간 초과, 설정 파싱 오류를 구분하세요. 401 또는 403이면 접근 권한, 링크 인증 정보, 계정 상태를 확인하고, 404이면 주소가 완전한지와 제공자가 접속 경로를 변경했는지 살펴보세요. 이런 상태 코드는 중간 게이트웨이에서 발생할 수도 있으므로 서비스 제공자의 안내와 함께 판단해야 합니다. 시간 초과가 발생하면 기본 네트워크와 구독 다운로드에 사용되는 직접 연결 또는 프록시 경로를 확인하세요. HTML 응답이나 YAML 파싱 오류는 로그인 페이지를 받았거나 형식이 잘못된 경우일 수 있습니다. 구독 주소를 공개된 곳에 반복해서 붙여 넣지 마세요. 인증 정보가 유출됐다면 제공자 관리 페이지에서 구독 주소를 재설정하세요.

먼저 TUN을 끄고 일반 시스템 프록시가 작동하는지 확인한 뒤, 클라이언트에 서비스 설치·복구 또는 네트워크 확장 권한 부여 메뉴가 있는지 살펴보세요. Windows에서는 관리자 권한으로 서비스를 설치하거나 시작해야 하는 경우가 많습니다. macOS에서는 시스템 안내에 따라 해당 네트워크 구성 요소를 허용해야 합니다. Linux의 권한과 라우팅 요구 사항은 클라이언트 설치 방식에 따라 다릅니다. 권한을 부여한 뒤 클라이언트를 다시 시작하고 로그에 권한 또는 장치 생성 오류가 남아 있는지 확인하세요. 문제를 해결하려고 방화벽을 계속 꺼두지 마세요. 다른 VPN, 가상 네트워크 어댑터 도구 또는 TUN 클라이언트가 실행 중이라면 하나씩 종료한 뒤 다시 테스트해 라우팅 충돌을 방지하세요.

설정 가져오기와 시스템 VPN 권한 부여는 별개입니다. 설정은 프록시와 규칙을 제공하고, 권한은 클라이언트가 시스템 네트워크 터널을 만들도록 허용합니다. 처음 연결할 때는 권한 요청 창이 현재 사용 중인 클라이언트에서 표시된 것인지 확인한 다음 시스템 안내에 따라 승인하고 기기 인증을 완료하세요. 예를 들어 Clash Plus는 다운로드 페이지에서 App Store로 이동할 수 있으며 제품 정보는 clashplus.io에서 확인할 수 있습니다. 권한을 부여한 뒤에도 연결되지 않으면 설정 활성화 여부, 프록시 그룹 선택 여부, 다른 VPN의 연결 점유 여부를 확인하세요. 구독 형식 지원 범위는 각 클라이언트의 안내를 따르며 파일 이름만으로 호환성을 판단해서는 안 됩니다.

먼저 클라이언트에서 오버라이드 또는 확장 설정 기능을 제공하는지 확인하고, 구독 업데이트로 덮어쓰이지 않는 위치에 규칙을 추가하세요. 규칙은 위에서 아래 순서로 적용됩니다. 예를 들어 DOMAIN-SUFFIX,github.com,PROXY는 해당 도메인에 먼저 적용될 수 있는 넓은 규칙보다 앞에 배치해야 합니다. PROXY는 실제로 존재하는 정책 이름이어야 합니다. 저장한 뒤 설정을 다시 불러오고 새 연결을 만들어 적용된 규칙을 확인하세요. 기존 연결은 새 규칙에 따라 바로 다시 생성되지 않을 수 있습니다. 여전히 규칙이 적용되지 않는다면 앱 트래픽이 코어를 거치는지 확인하고 로그에 기록된 실제 도메인을 살펴보세요. 웹페이지의 기본 도메인과 리소스 도메인을 혼동하지 않도록 주의하세요.

지연 시간 테스트는 특정 대상의 응답 시간을 주로 측정하며 지속적인 전송 속도를 나타내거나 모든 사이트가 같은 경로를 사용한다고 보장하지 않습니다. 같은 네트워크와 대상, 비슷한 시간대에 직접 연결과 프록시를 비교하고 연결 목록에서 예상한 프록시 그룹을 실제로 사용 중인지 확인하세요. 그런 다음 Wi-Fi 신호, 백그라운드 다운로드, 서버 혼잡, 계정 속도 제한, 대상 사이트의 지역별 콘텐츠 배포 차이를 점검하세요. 한 번 측정한 최저 지연 시간만 보고 노드를 계속 바꾸지 마세요. 동영상 연결은 전환 전의 정책을 계속 사용할 수 있으므로 노드를 바꾼 뒤 재생 연결을 새로 만드세요. 속도 테스트 사이트에 접속할 수 없더라도 노드 자체가 만료됐다고 단정할 수는 없습니다.

먼저 휴대폰과 컴퓨터를 신뢰할 수 있는 동일 LAN에 연결한 뒤, 컴퓨터 클라이언트에서 LAN 연결 허용을 켜세요. allow-lan이 true인지, 수신 주소가 LAN 연결을 허용하는지 확인하고 mixed-port의 실제 포트 번호를 기록합니다. 휴대폰 Wi-Fi의 수동 프록시 설정에 컴퓨터의 LAN IP와 포트를 입력하세요. 127.0.0.1은 휴대폰 자체를 가리키므로 입력하면 안 됩니다. 컴퓨터 방화벽에서는 필요한 네트워크 프로필에 대해서만 해당 인바운드 포트를 허용하세요. 이 방법은 주로 Wi-Fi HTTP 프록시를 따르는 앱에 적용되며 모든 트래픽을 처리하지는 않습니다. 사용을 마치면 공유를 끄고 프록시 포트를 공용 인터넷에 노출하지 마세요.

시작 프로그램은 보통 클라이언트 실행만 담당하며 시스템 프록시 활성화, TUN 복구, 이전 설정 선택까지 함께 처리하지 않을 수 있습니다. 이런 동작은 클라이언트 설정에서 각각 제어하며 모든 환경에 공통으로 적용되는 YAML 자동 실행 옵션은 없습니다. 로그인 시 실행, 시작 시 연결, 서비스 상태를 확인한 뒤 컴퓨터를 다시 시작해 검증하세요. 구독에 포함된 규칙과 프록시는 업데이트할 때 바뀔 수 있으므로 로컬 변경 사항은 클라이언트에서 지원하는 오버라이드, 병합 또는 별도 설정 기능으로 저장하세요. 수정 전에 사용할 수 있는 사본을 내보내고 변경한 항목을 기록하세요. 클라이언트를 업데이트한 뒤 동작이 달라지면 설정이 유지됐는지 먼저 확인하고, 구독 원본 파일에 같은 내용을 반복해서 추가하지 마세요.

먼저 코어가 실행 중인지, 현재 설정이 활성화됐는지 확인하고 시스템 프록시 주소가 실제 수신 포트와 일치하는지 살펴보세요. 클라이언트가 로컬에서 수신 대기 중일 때만 시스템 프록시의 127.0.0.1 주소가 작동합니다. 다음으로 브라우저 확장 프로그램, 앱 자체 프록시, 자동 설정 스크립트, 다른 프록시 도구가 시스템 설정을 덮어쓰는지 확인하세요. 연결 목록을 열고 새 요청을 보내 보세요. 기록이 있다면 규칙과 정책을 확인하고, 기록이 없다면 앱이 시스템 프록시 설정을 읽는지 살펴보세요. 명령줄 도구, 일부 게임과 스토어 앱은 별도 설정이나 TUN 테스트가 필요할 수 있습니다. 시스템 프록시 스위치만으로 모든 트래픽이 처리된다고 판단해서는 안 됩니다.

앱 컨테이너 제한을 받는 일부 UWP 앱은 로컬 루프백 프록시에 접근하지 못할 수 있지만 스토어 앱이 모두 같은 상황인 것은 아닙니다. 먼저 일반 브라우저에서 같은 프록시가 정상 작동하는지 확인하고 대상 앱이 실제로 로컬 프록시에 연결해야 하는지도 살펴보세요. 클라이언트에서 UWP 루프백 도구를 제공한다면 필요한 앱에만 예외를 추가하세요. 대개 관리자 권한이 필요합니다. 기존 설정은 CheckNetIsolation LoopbackExempt -s 명령으로 확인할 수도 있습니다. 모든 앱에 일괄적으로 예외를 적용하지 마세요. TUN을 사용 중이라면 라우팅과 DNS를 별도로 점검해야 합니다. 루프백 예외는 모든 Windows 앱의 네트워크 오류를 해결하는 만능 방법이 아닙니다.

먼저 프록시를 끄고 기본 네트워크를 확인한 다음 구독이 업데이트됐는지, 계정이 유효한지, 대상 프록시 그룹에서 사용할 수 없는 노드를 선택하지 않았는지 살펴보세요. timeout은 정해진 시간 안에 연결이 완료되지 않았다는 뜻이며 네트워크 패킷 손실, 연결할 수 없는 주소, 서버 상태, DNS 결과 등이 원인일 수 있습니다. connection refused는 보통 대상 포트가 연결을 거부했다는 의미지만 로컬 프록시 포트가 수신 대기 중이지 않을 때도 발생합니다. 오류에 표시된 대상 주소가 노드 서버, 대상 웹사이트, 로컬 루프백 중 어디에 해당하는지 먼저 확인한 뒤 관련 계층을 점검하세요. 정상 작동이 확인된 다른 연결과 비교하고 오류가 발생한 시간도 기록해 두세요. 모든 시간 초과를 규칙 탓으로 돌리거나 포트, DNS, 모드를 한꺼번에 변경하지 마세요.

먼저 문제가 특정 도메인에만 발생하는지 확인하고 로그에서 DNS 조회 실패, 상위 DNS 시간 초과, 잘못된 규칙 적용 여부를 살펴보세요. Fake-IP를 사용 중이라면 조회 결과로 예약 주소가 반환되는 것이 정상 동작일 수 있습니다. 이것만으로 DNS 오류라고 판단하지 말고 이후 연결이 코어에서 처리되는지 확인하세요. LAN 도메인, 게임 또는 특정 앱에서 호환성 문제가 생기면 설정을 이해한 뒤 해당 항목에 맞는 fake-ip-filter를 추가하거나 지원되는 다른 DNS 모드와 비교해 보세요. 변경 후 설정을 다시 불러오고 운영체제 방식에 따라 DNS 캐시를 비운 다음 앱 연결을 새로 만드세요. 여러 DNS 처리 도구를 동시에 사용하거나 상위 DNS 주소를 모두 임의로 바꾸지 마세요.