기본 개념
코어, 클라이언트, 구독의 차이를 파악하고 적절한 프록시 모드를 선택하세요.
Clash 클라이언트, Clash for Windows, mihomo는 어떻게 다른가요?
Clash 클라이언트는 이러한 그래픽 도구를 통칭하며, mihomo는 프록시 프로토콜, 규칙 매칭, DNS 처리를 담당하는 코어입니다. Clash Verge Rev, FlClash 등의 제품은 설정 가져오기와 시스템 연동 인터페이스를 제공합니다. Clash for Windows는 지원이 중단된 제품입니다. 제품을 선택할 때는 클라이언트의 유지 관리 상태와 코어 호환성을 함께 확인하세요. 이름이 비슷하다고 기능까지 같다고 볼 수는 없습니다. 전환하기 전에 설정을 내보내고 로컬 오버라이드와 시스템 프록시 포트를 기록해 두세요.
Clash 클라이언트를 설치한 뒤 구독 링크는 어디서 받나요?
클라이언트를 설치해도 사용할 수 있는 프록시가 자동으로 제공되지는 않습니다. 구독은 보통 기존 서비스의 관리 페이지에서 받을 수 있으며, 직접 구축한 서비스의 설정을 사용할 수도 있습니다. 가져오기 전에 Clash YAML 형식이나 사용 중인 클라이언트의 가져오기 방식을 지원하는지 확인하세요. 계정 로그인 페이지를 구독 주소로 착각하지 마세요. 구독 링크에는 계정 정보가 포함될 수 있으므로 포럼이나 스크린샷, 출처를 알 수 없는 변환 사이트에 공개하지 마세요. 링크가 유출됐다면 제공 업체에서 재설정하세요.
규칙 모드, 전역 모드, 직접 연결 모드 중 무엇을 선택해야 하나요?
평소에는 rules가 순서대로 대상과 일치하는 규칙을 찾아 해당 정책으로 연결하는 규칙 모드를 사용하세요. 전역 모드는 코어에 들어온 연결을 전역 정책으로 처리하지만, 모든 앱의 트래픽을 자동으로 가져오지는 않습니다. 앱이 코어를 거치는지는 시스템 프록시나 TUN 설정에 따라 달라집니다. 직접 연결 모드에서는 코어에 들어온 연결이 프록시를 거치지 않고 연결됩니다. 문제를 확인할 때는 전역 모드로 잠시 전환해 정상 작동을 확인한 프록시를 선택하세요. 확인이 끝나면 규칙 모드로 되돌려 임시 설정을 계속 사용하지 않도록 합니다.
시스템 프록시와 TUN 모드를 함께 켜야 하나요?
기본적으로 두 기능을 동시에 켤 필요는 없습니다. 시스템 프록시는 운영체제의 프록시 설정을 변경하므로 해당 설정을 따르는 브라우저와 앱에 적합합니다. TUN은 가상 네트워크 인터페이스와 라우팅을 통해 트래픽을 가져오므로 시스템 프록시를 따르지 않는 프로그램에 유용하지만, 별도의 권한이 필요합니다. 처음 연결할 때는 시스템 프록시로 구독과 정책 그룹이 정상인지 확인한 뒤 앱에 필요한 경우 TUN을 켜세요. 두 기능을 함께 사용하다 문제가 생기면 한쪽의 트래픽 처리 기능을 끄고 다른 VPN도 잠시 중단해 원인을 좁히세요.
구독 링크, 설정 파일, 정책 그룹은 각각 어떤 역할을 하나요?
구독 링크는 원격 콘텐츠를 가져오는 경로이고, 설정 파일은 코어가 실제로 읽는 YAML이며, 정책 그룹은 여러 프록시나 처리 방식을 묶어 선택할 수 있게 합니다. 완전한 설정에는 노드 목록뿐 아니라 DNS, 규칙, 수신 포트도 포함되는 경우가 많습니다. 정책 그룹 이름은 규칙에서 참조하는 이름과 일치해야 합니다. 예를 들어 규칙 끝에서 PROXY를 사용한다면 설정에도 같은 이름의 프록시나 정책 그룹이 있어야 합니다. 프로토콜 링크 하나만 받은 경우에는 클라이언트가 지원하는 방식으로 가져오세요. 이를 완전한 YAML 설정 파일처럼 바로 사용하면 안 됩니다.
설치 및 설정
구독 응답, 서비스 권한, 수신 주소를 차례대로 확인하세요.
구독을 가져올 때 401, 403 또는 404 오류가 나면 무엇부터 확인해야 하나요?
먼저 구독 링크 전체를 복사했는지 확인한 뒤 제공 업체의 계정 페이지에서 서비스 상태와 링크 재설정 여부를 확인하세요. 401이나 403은 인증 또는 접근 제한과 관련된 경우가 많고, 404는 주소가 변경됐다는 뜻일 수 있습니다. 정확한 의미는 제공 업체의 안내를 확인하세요. 가져오기를 반복하지 말고 클라이언트 로그에서 응답 상태를 확인한 다음, 아직 사용할 수 없는 프록시에 구독 업데이트가 잘못 의존하고 있지는 않은지 살펴보세요. 문의할 때는 민감 정보를 가린 상태 코드와 발생 시간만 전달하고 전체 링크는 공개하지 마세요.
가져오기 중 yaml: unmarshal errors 오류가 발생하면 어떻게 해결하나요?
먼저 내려받은 내용이 실제 YAML인지 확인하세요. 로그인 페이지, 웹 오류 메시지, Base64 노드 목록은 완전한 설정 파일로 바로 사용할 수 없습니다. 로그에 yaml: unmarshal errors가 있다면 뒤에 표시된 행 번호를 기준으로 필드 유형, 들여쓰기, 목록 구조를 확인하세요. YAML 들여쓰기에는 탭 대신 공백을 사용해야 합니다. 수정하지 않은 구독 설정으로 되돌려 불러올 수 있는지 확인한 뒤 오버라이드를 하나씩 다시 적용하세요. 오류 내용을 공유하기 전에는 서버 인증 정보와 구독 주소를 삭제하세요.
TUN 모드에서 권한 부족 오류가 납니다. 항상 관리자 권한으로 실행해야 하나요?
사용 중인 클라이언트의 안내에 따라 서비스 모드를 설치하거나 켠 다음 서비스가 실행 중인지 확인하세요. 제품마다 메뉴 이름이 서비스 모드, Service Mode 또는 보조 서비스 등으로 다를 수 있습니다. Windows에서는 서비스 설치에 관리자 권한이 필요한 경우가 많고, macOS에서는 보조 프로그램을 승인해야 할 수 있습니다. Linux에서는 배포판과 클라이언트 안내에 맞게 권한을 설정하세요. 모든 실행 파일의 권한을 무작정 높이지 마세요. 설치 후에도 문제가 계속되면 가상 네트워크 어댑터 생성이나 라우팅 추가 과정에서 발생한 구체적인 오류를 확인하고, 보안 프로그램이나 다른 VPN과 충돌하는지도 살펴보세요.
시스템 프록시가 켜져 있는데 브라우저는 왜 직접 연결되나요?
먼저 시스템 프록시 주소가 127.0.0.1을 가리키는지, 포트가 현재 설정의 mixed-port 또는 HTTP 수신 포트와 일치하는지 확인하세요. 브라우저가 별도의 프록시 설정이나 프록시 확장 프로그램, 조직 정책을 사용하는지도 살펴보세요. 이런 설정이 시스템 프록시보다 우선할 수 있습니다. 클라이언트의 연결 화면을 열고 새 페이지에 접속해 해당 연결이 표시되는지 확인하세요. 연결 기록이 없다면 트래픽이 클라이언트로 들어오는 경로부터 확인하세요. 기록은 있지만 직접 연결된다면 매칭 규칙과 정책 그룹을 살펴보세요. 시스템 프록시를 반복해서 켰다 끄는 것만으로는 해결되지 않습니다.
같은 LAN에 연결된 휴대폰에서 컴퓨터의 프록시를 사용하려면 어떻게 하나요?
컴퓨터에서 LAN 연결 허용을 켜고, 이에 해당하는 allow-lan 설정을 확인하세요. bind-address가 루프백 주소에만 바인딩되어 있지 않은지도 확인해야 합니다. 휴대폰과 컴퓨터를 같은 신뢰할 수 있는 네트워크에 연결한 다음, 휴대폰 Wi-Fi의 수동 프록시 설정에 컴퓨터의 LAN IP 주소와 HTTP 또는 mixed-port 포트를 입력하세요. 방화벽은 필요한 개인 네트워크에서만 연결을 허용하고, 가능하면 인증도 설정하세요. 휴대폰 Wi-Fi 프록시가 모든 앱의 트래픽을 처리하는 것은 아닙니다. 사용 후에는 설정을 원래대로 되돌리고, 수신 포트를 공용 인터넷에 노출하지 마세요.
사용 팁
로컬 변경 사항을 보존하고, 스위치 상태만 보지 말고 실제 적용 결과를 확인하세요.
노드 속도 테스트는 정상인데 실제 앱에서는 왜 작동하지 않나요?
속도 테스트는 테스트 주소에 그 시점에 접속할 수 있었다는 뜻일 뿐, 모든 사이트와 프로토콜, 앱이 작동한다는 보장은 아닙니다. 먼저 실제 연결에 사용된 정책 그룹에서 해당 노드를 선택했는지 확인한 뒤 연결 화면에서 대상 도메인, 매칭 규칙, 연결 오류를 살펴보세요. 브라우저는 되지만 게임이나 통화가 실패한다면 UDP 지원 여부와 트래픽 처리 방식도 확인해야 합니다. 속도 테스트 결과만으로 노드 문제를 배제하지 마세요. 같은 대상과 정책을 기준으로 하나씩 비교해야 차이가 규칙, 프로토콜, 원격 서비스 중 어디에서 비롯됐는지 알 수 있습니다.
구독을 업데이트한 뒤 사용자 지정 규칙이 사라지는 이유는 무엇인가요?
구독에서 생성된 설정을 직접 수정하면 다음 업데이트 때 원격 설정으로 덮어써질 수 있습니다. 계속 유지할 규칙은 클라이언트에서 지원하는 오버라이드, 확장 설정 또는 스크립트에 넣으세요. 자세한 메뉴 위치는 제품 문서를 확인하세요. 복원하기 전에 현재 파일을 백업하고, 최종 적용 설정에서 rules 순서를 확인하세요. 구체적인 규칙은 MATCH보다 앞에 있어야 합니다. 오버라이드에 지정한 정책 그룹 이름도 구독에 실제로 있는 이름과 일치해야 합니다. 그렇지 않으면 정책을 찾을 수 없다는 로드 오류가 발생할 수 있습니다.
컴퓨터를 켤 때 자동 실행되도록 설정하고 연결 실패를 방지하려면 어떻게 하나요?
클라이언트 설정에서 자동 실행을 켠 뒤 운영체제의 시작 프로그램 권한이 실행을 차단하지 않는지 확인하세요. 자동 실행, 시작 후 시스템 프록시 설정, 시스템 시작 시 서비스 실행은 서로 다른 설정이므로 각각 확인해야 합니다. 처음 테스트할 때는 재부팅한 뒤 설정이 정상적으로 불러와졌는지 확인하고 서비스와 네트워크가 준비됐는지 살펴보세요. 구독 업데이트가 너무 일찍 실패한다면 네트워크 연결 후 수동 업데이트로 확인할 수 있습니다. 클라이언트를 제거하거나 바꾸기 전에는 시스템 프록시를 먼저 끄세요. 더 이상 수신하지 않는 포트가 시스템 설정에 남을 수 있습니다.
특정 사이트만 임시로 직접 연결하려면 어떤 설정을 바꿔야 하나요?
규칙 모드를 사용하고 로컬 오버라이드에 정확한 도메인 규칙이나 DOMAIN-SUFFIX 규칙을 추가한 뒤 대상을 DIRECT로 지정하세요. 규칙은 순서대로 적용되므로 더 넓은 범위의 규칙과 MATCH보다 앞에 두어야 합니다. 변경 후 최종 설정에 해당 규칙이 포함됐는지 확인하고 새 연결로 적용 결과를 검증하세요. 기존에 오래 유지된 연결에는 이전 정책이 계속 적용될 수 있습니다. 한 사이트 때문에 클라이언트 전체를 계속 직접 연결 모드로 두지 말고, 필요한 범위보다 지나치게 넓은 도메인 접미사 규칙도 사용하지 마세요.
외부 컨트롤 패널에 연결할 수 없을 때 어떤 설정을 확인해야 하나요?
먼저 external-controller가 활성화되어 있는지 확인하고, 패널에 입력한 주소와 포트, secret이 코어 설정과 일치하는지 살펴보세요. 로컬에서만 사용할 때는 제어 인터페이스를 127.0.0.1에 바인딩하면 됩니다. 연결 편의를 위해 인터넷에 직접 공개하지 마세요. 패널을 HTTPS로 열었는데 제어 인터페이스는 HTTP를 사용하면 브라우저가 혼합 콘텐츠 정책에 따라 요청을 차단할 수 있습니다. 패널 배포 안내에 맞춰 설정을 조정하세요. 스크린샷을 공유하기 전에는 제어 키를 가리고, 원격 접속이 필요하다면 신뢰할 수 있는 네트워크와 접근 보호를 별도로 설정하세요.
문제 해결
원본 오류와 발생 시간, 실패한 대상을 기록한 뒤 문제 원인을 좁혀 보세요.
모든 노드가 timeout으로 표시될 때 어떤 순서로 확인해야 하나요?
먼저 프록시를 끄고 기본 네트워크가 작동하는지 확인한 다음 구독이 유효하고 노드 설정이 정상적으로 불러와졌는지 살펴보세요. 노드 하나를 선택해 실제 대상에 연결하고 로그를 확인합니다. timeout은 요청이 제한 시간 안에 완료되지 않았다는 뜻이지만, 이 단어만으로 서버 장애라고 단정할 수는 없습니다. 시스템 시간, 서버 도메인 이름 확인, 방화벽, 다른 VPN의 간섭 여부를 점검하세요. 여러 노드가 모두 실패한다면 공통으로 사용하는 로컬 환경부터 살펴보고, 일부 노드만 실패한다면 민감 정보를 가린 오류 내용과 발생 시간을 첨부해 제공 업체에 문의하세요.
브라우저는 되지만 Microsoft Store 같은 UWP 앱이 인터넷에 연결되지 않으면 어떻게 해야 하나요?
일부 Windows 앱 컨테이너는 루프백 접근이 제한되어 로컬 프록시 포트에 직접 연결하지 못할 수 있습니다. 클라이언트에서 UWP 루프백 도구를 제공한다면 필요한 앱에만 루프백 예외를 설정하고 해당 앱을 다시 시작하세요. 한 번에 모든 앱에 예외를 허용하지 마세요. 지원되는 환경이라면 TUN으로 트래픽을 가져오는 방법도 시험할 수 있지만, 앱 자체와 시스템의 프록시 설정도 확인해야 합니다. 루프백 예외가 모든 Store 문제를 해결하는 것은 아닙니다. 계정, 시스템 서비스, DNS 오류도 로그를 확인해 각각 원인을 찾아야 합니다.
로그에 DNS 확인 실패가 표시되면 Fake-IP를 바로 꺼야 하나요?
먼저 실패한 도메인과 전체 오류 메시지를 기록한 다음, 설정에 지정된 DNS 업스트림에 연결할 수 있는지, 업스트림 도메인 확인 과정에서 순환 의존성이 생기는지 확인하세요. DNS 시간 초과가 Fake-IP 자체의 문제라는 뜻은 아닙니다. 특정 앱이 가상 주소와 호환되지 않는 것이 확인된 경우에만 필요에 따라 fake-ip-filter를 추가하거나 redir-host 모드와 비교해 보세요. 변경 후에는 관련 DNS 캐시를 비우고 연결을 새로 만드세요. 모든 DNS 설정을 한꺼번에 바꾸면 접속이 복구되더라도 어떤 변경이 효과가 있었는지 알기 어렵습니다.
GeoIP 업데이트에 실패해도 GEOIP 규칙은 정상적으로 사용할 수 있나요?
기존 데이터베이스가 남아 있고 코어에서 읽을 수 있다면 업데이트에 실패해도 기존 GEOIP 매칭이 바로 영향을 받지는 않을 수 있습니다. 데이터베이스가 없거나 손상됐다면 해당 데이터베이스를 참조하는 규칙의 로드나 매칭이 실패할 수 있습니다. 로그에서 데이터베이스 경로와 다운로드 오류를 확인하고, 쓰기 권한과 디스크 공간, 다운로드 연결이 정상인지 점검한 뒤 클라이언트의 데이터베이스 업데이트 기능으로 다시 시도하세요. Country.mmdb는 흔히 사용하는 GeoIP 데이터 파일이지만, 구체적인 형식은 설정에 따라 다릅니다. GeoIP와 geosite는 용도가 다르므로 서로 대체할 수 없습니다.
시작할 때 address already in use 오류가 나거나 종료 후 인터넷이 전혀 되지 않으면 어떻게 해야 하나요?
address already in use는 보통 수신 포트가 이미 사용 중이라는 뜻입니다. 여러 클라이언트가 동시에 실행 중이거나 코어 프로세스가 남아 있는지 확인하세요. 중복 실행을 종료하거나 mixed-port를 변경한 뒤 시스템 프록시 포트도 함께 바꾸세요. 한쪽만 바꾸면 안 됩니다. 클라이언트를 종료한 후 인터넷이 되지 않으면 시스템에 남아 있는 수동 프록시를 먼저 끄세요. TUN을 사용했다면 클라이언트 안내에 따라 서비스를 중지하고 라우팅이 복구됐는지 확인하세요. 기본 네트워크를 복구한 뒤 클라이언트 하나만 실행해 확인하세요.