기본 정보
클라이언트, 코어, 서비스 설정을 구분하고 프록시 모드와 트래픽 진입 경로의 범위를 이해하세요.
Clash 클라이언트, mihomo 코어, 구독은 각각 무엇인가요?
클라이언트는 설정 가져오기, 프록시 그룹 선택, 시스템 프록시 전환 등의 기능을 제공하고, 코어는 연결을 받아 도메인을 확인하고 규칙을 적용합니다. mihomo는 Clash 생태계에서 계속 발전 중인 코어로, 이전에는 Clash Meta라는 이름을 사용했습니다. 구독은 일반적으로 서비스 제공자가 생성하는 설정 주소로, 노드나 전체 설정을 가져오는 데 사용됩니다. 클라이언트를 설치한다고 바로 사용할 수 있는 노드가 생기는 것은 아니며, 호환되는 설정과 유효한 서비스도 필요합니다. 문제를 진단할 때는 클라이언트 이름, 코어 이름, 구독 유형을 각각 확인해 화면 기능과 코어 기능을 혼동하지 않도록 하세요.
규칙, 전역, 직접 연결 모드는 어떻게 다른가요?
규칙 모드는 설정에 적힌 규칙 순서에 따라 연결 경로를 정하므로 일상적인 트래픽 분리에 적합합니다. 전역 모드는 보통 코어로 들어온 연결을 GLOBAL 정책에 전달하지만, 해당 정책에서 사용할 노드를 선택해야 합니다. 직접 연결 모드에서는 코어로 들어온 연결이 대상에 바로 접속합니다. 모드는 코어가 연결을 받은 뒤 처리하는 방식을 정할 뿐, 모든 앱의 트래픽을 자동으로 코어에 전달하지는 않습니다. 처음에는 규칙 모드를 사용하고, 필요할 때 잠시 전역 모드로 바꿔 비교해 보세요. 테스트가 끝나면 원래 모드로 되돌린 뒤 실제로 적용된 규칙을 확인하고, 임시 설정을 계속 사용하지 않도록 주의하세요.
시스템 프록시를 켜면 모든 앱의 트래픽이 Clash를 거치나요?
시스템 프록시는 운영체제의 프록시 설정을 사용하는 앱을 위한 기능입니다. 브라우저는 대체로 이 설정을 따르지만, 일부 게임과 명령줄 도구, 자체 네트워크 스택을 사용하는 프로그램은 무시할 수 있습니다. 앱에 별도의 프록시나 우회 목록이 설정되어 있을 수도 있습니다. 따라서 브라우저가 접속된다고 해서 다른 앱도 프록시를 사용한다고 볼 수는 없습니다. 먼저 클라이언트의 연결 목록에서 대상 프로그램의 요청이 표시되는지 확인하세요. 연결 기록이 없다면 트래픽이 들어오는 경로부터 점검하는 것이 좋습니다. 앱에 로컬 프록시를 따로 설정하거나, 라우팅 및 권한 요건을 확인한 뒤 TUN 모드를 사용할 수 있습니다.
Clash Plus, Clash Verge Rev, FlClash 중 어떤 클라이언트를 선택하면 좋을까요?
먼저 운영체제를 기준으로 고른 다음 프로세서 아키텍처, OS 버전, 필요한 기능을 확인하세요. 이 사이트의 다운로드 센터에서는 지원 플랫폼에 Clash Plus를 우선 안내하고, Clash Verge Rev와 FlClash 등도 제공합니다. 클라이언트마다 화면 구성, 설정 덮어쓰기 방식, 서비스 설치 절차, TUN 전환 방법이 다를 수 있으므로 다른 클라이언트의 메뉴 경로를 그대로 따라 하면 안 됩니다. 기존 설정이 안정적으로 작동한다면 이전하기 전에 원본 파일을 보관하고, 새 클라이언트가 사용하는 코어도 확인하세요. 화면 모양만 비교하기보다 현재 OS에 맞고 꾸준히 유지 관리되는 버전을 선택하는 것이 중요합니다.
지연 시간 테스트는 성공했는데 웹페이지가 열리지 않는 이유는 무엇인가요?
지연 시간 테스트는 보통 노드에서 지정된 테스트 주소로 요청을 한 번 보내 확인할 뿐, 모든 웹사이트와 프로토콜, 앱의 접속 가능 여부를 보장하지 않습니다. 규칙에서 잘못된 프록시 그룹을 선택했거나, 대상 사이트가 접속을 제한하거나, DNS 확인에 문제가 있거나, 앱이 프록시를 사용하지 않아 웹페이지가 열리지 않을 수 있습니다. 먼저 웹페이지 요청이 연결 목록에 나타나는지 확인한 뒤 적용된 규칙과 실제 노드를 살펴보세요. 다른 사이트와 같은 그룹의 다른 노드로 교차 테스트해 문제가 발생하는 범위를 기록하세요. 지연 시간 숫자만 보고 DNS를 계속 바꾸거나, 테스트 한 번의 성공을 전체 연결 경로가 정상이라는 근거로 삼지 마세요.
관련 자료: 용어집 · 플랫폼별 클라이언트 선택
설치 및 설정
구독 가져오기, 로컬 포트, TUN 권한, 시작 옵션을 차례로 설정해 사용할 수 있는 구성을 만드세요.
구독 링크는 어떻게 가져오며, 가져온 뒤 무엇을 확인해야 하나요?
서비스 제공자에게서 Clash 또는 mihomo용 설정 링크를 받은 뒤 클라이언트의 설정 또는 구독 화면에서 링크 가져오기를 선택하고, 주소 전체를 붙여 넣어 저장하세요. 링크에 개인 인증 정보가 포함될 수 있으므로 공개 그룹이나 스크린샷에 공유하지 마세요. 가져온 다음에는 해당 설정을 활성화하고 프록시 그룹이 표시되는지 확인한 뒤 노드를 선택하고 적절한 트래픽 경로를 켜야 합니다. 노드만 있고 규칙이 없다면 클라이언트가 지원하는 방식으로 설정을 보완하세요. 메뉴 이름은 클라이언트마다 다를 수 있으니 이 사이트의 안내를 따라 전체 연결 과정을 한 번 확인해 보세요.
Clash 포트 설정에서 mixed-port는 어떻게 지정하나요?
mixed-port는 HTTP와 SOCKS 프록시 연결을 모두 받는 로컬 수신 포트입니다. 설정에 mixed-port: 7890이 지정되어 있다면 같은 기기의 앱에는 보통 호스트 127.0.0.1과 포트 7890을 입력하고, 앱 요구에 맞는 프록시 프로토콜을 선택합니다. 실제 값은 현재 클라이언트에 표시된 값을 기준으로 하세요. 시작 로그에 주소가 이미 사용 중이라고 나오면 다른 프록시 프로그램을 종료하거나 사용 가능한 포트로 바꾸고 앱 설정도 함께 수정하세요. 외부 제어 인터페이스 포트를 프록시 포트로 사용하면 안 됩니다. 이 기기에서만 사용할 경우에는 LAN 접속을 꺼 두어 수신 서비스가 실수로 외부에 노출되지 않도록 하세요.
TUN 모드에서 권한 부족 또는 가상 네트워크 어댑터 생성 오류가 발생하면 어떻게 하나요?
먼저 로그를 확인해 권한 부족, 서비스 미설치, 드라이버 로드 실패 중 어떤 문제인지 구분하세요. Windows 클라이언트는 일반적으로 서비스 구성 요소를 설치하거나 실행해야 합니다. 일부 클라이언트는 관리자 권한으로 실행하는 방법도 지원하지만, 해당 클라이언트의 안내를 따르세요. macOS에서는 보조 서비스 승인이 필요할 수 있고, Linux에서는 적절한 네트워크 관리 권한이 필요합니다. 서비스를 설치한 뒤 클라이언트를 다시 시작하고 가상 네트워크 어댑터와 라우트가 생성됐는지 확인하세요. 그래도 해결되지 않으면 다른 VPN이나 TUN 프로그램을 잠시 종료해 비교하되, 가상 네트워크 어댑터를 여러 개 반복해서 만들거나 시스템 보호 기능을 계속 꺼 두는 방식으로 해결하려고 하지 마세요.
TUN을 사용할 때 DNS와 Fake-IP는 어떻게 설정해야 하나요?
TUN은 네트워크 트래픽을 받아들이고 DNS 설정은 도메인 확인과 연결을 담당하므로 두 설정을 함께 점검해야 합니다. Fake-IP는 일부 도메인에 매핑된 주소를 반환하고, 이후 연결에서 코어가 실제 대상을 복원하는 방식입니다. 공개 DNS 서버 주소가 아닙니다. 먼저 클라이언트의 기본 TUN 및 DNS 조합을 사용한 뒤 설정의 dns.enable, dns.enhanced-mode와 TUN의 DNS 가로채기 옵션을 확인하세요. enhanced-mode 항목 하나만 복사해서 적용하지 마세요. LAN 기기나 특정 앱과 호환되지 않는다면 증상에 맞춰 Fake-IP 제외 항목을 추가하고, 변경 후 관련 앱을 다시 시작해 기존 연결을 정리하세요.
시작 프로그램으로 등록했는데 자동 연결되지 않는 이유는 무엇이며, 휴대폰에서는 왜 백그라운드 연결이 끊기나요?
클라이언트 실행, 코어 서비스 시작, 프록시 전환 복원은 서로 다른 설정입니다. 그중 하나만 선택해도 모든 단계가 자동으로 완료되는 것은 아닙니다. 데스크톱에서는 시작 항목, 활성화된 설정, 시스템 프록시 또는 TUN 복원 동작을 각각 확인하고 재부팅 후 실제 연결을 테스트하세요. Android에서는 백그라운드 실행, 배터리 최적화, VPN 권한도 확인해야 합니다. iOS에서는 시스템의 VPN 상태를 확인하세요. 모바일 운영체제는 일반적으로 활성 VPN을 하나만 허용하므로 다른 VPN이나 필터링 도구가 연결을 대체할 수 있습니다. 먼저 시스템 상태를 점검한 뒤 노드를 확인해 백그라운드 제한을 구독 문제로 오해하지 않도록 하세요.
처음 설정할 때는 Clash 설정 가이드에 따라 가져오기, 모드 선택, 연결 확인을 진행하세요.
사용 팁
사용자 지정 규칙, 프록시 그룹, DNS 설정은 실제 연결 기록을 기준으로 확인해야 합니다.
사용자 지정 규칙을 추가하고 구독 업데이트로 덮어쓰이지 않게 하려면 어떻게 하나요?
클라이언트에서 제공하는 규칙 덮어쓰기, 설정 병합 또는 확장 설정 기능을 사용해 로컬 변경 사항을 원격 구독과 분리해 저장하세요. 규칙은 위에서부터 순서대로 적용되므로 구체적인 도메인 규칙은 보통 포괄적인 규칙이나 MATCH 앞에 배치해야 합니다. 예를 들어 DOMAIN-SUFFIX,example.com,DIRECT는 해당 도메인과 하위 도메인에 직접 연결하라는 뜻입니다. 정책 이름이 실제로 존재하는지 확인하고 대소문자와 이름이 설정과 일치하도록 하세요. 수정 후 설정을 다시 불러오고 연결 목록에서 실제로 적용됐는지 확인하세요. 구독에서 내려받은 파일을 직접 수정하면 업데이트 때 덮어써질 수 있으므로 사본을 보관하고 클라이언트의 병합 순서를 확인하세요.
select, url-test, fallback 프록시 그룹은 각각 어떤 상황에 적합한가요?
select는 노드나 하위 프록시 그룹을 직접 고르는 방식으로, 출구를 명확히 고정해야 할 때 적합합니다. url-test는 지정한 테스트 주소의 결과에 따라 자동으로 선택합니다. 테스트 간격과 허용 오차 등의 설정이 전환 동작에 영향을 주지만, 다운로드 속도 순위를 뜻하지는 않습니다. fallback은 보통 목록 순서대로 사용 가능한 후보를 선택하므로 우선 회선을 유지하다가 문제가 생기면 전환할 때 적합합니다. 그룹 구성원, 테스트 주소, 실제 접속 사이트 모두 결과에 영향을 줍니다. 특정 사이트에 문제가 생기면 먼저 select로 노드를 고정해 비교한 다음 자동 선택 정책을 조정할지 판단하세요. 여러 그룹을 동시에 바꾸지는 마세요.
앱에 실제로 어떤 규칙이 적용됐는지 확인하려면 어떻게 하나요?
클라이언트의 연결 화면을 열고 대상 앱에서 요청을 다시 발생시킨 다음, 프로세스·도메인·대상 주소로 연결을 찾아 규칙 유형, 정책 경로, 최종 출구를 확인하세요. 기존 연결은 이전 정책을 계속 사용할 수 있으므로 설정을 전환한 뒤에는 연결을 종료하거나 앱을 다시 시작해 테스트해야 합니다. 연결 기록이 전혀 없다면 rules를 바로 수정하지 말고 앱이 프록시에 연결되어 있는지 먼저 확인하세요. 로그가 부족하면 잠시 로그 수준을 높이고, 확인이 끝나면 원래 설정으로 되돌리세요. 로그를 공유하기 전에는 구독 주소, 인증 정보, 개인 접속 기록을 가리고 문제 파악에 필요한 오류 부분만 남기세요.
LAN에서 프록시에 연결할 수 있도록 허용할 때 어떤 설정을 주의해야 하나요?
다른 기기에서 이 기기의 프록시를 사용해야 하는 경우에만 allow-lan을 켜고 bind-address, 프록시 포트, 방화벽 인바운드 규칙을 확인하세요. 다른 기기에는 127.0.0.1이 아니라 이 컴퓨터의 LAN 주소를 입력해야 합니다. 컴퓨터의 주소가 바뀌면 설정도 업데이트하세요. 접근 범위를 가능한 한 제한하고 클라이언트에서 지원하는 인증을 설정하세요. 라우터에서 프록시 포트를 공용 인터넷으로 포트 포워딩하지 마세요. 외부 제어 인터페이스와 프록시 수신 포트는 서로 다른 서비스이므로 별도로 관리해야 합니다. 테스트가 끝나면 더 이상 필요하지 않은 공유 접속을 꺼서 알 수 없는 기기가 이 컴퓨터의 네트워크를 사용하지 못하게 하세요.
프록시를 사용하면 DNS 유출을 막을 수 있나요?
프록시 스위치만 보고 DNS 요청의 경로를 판단할 수는 없습니다. 앱이 시스템 리졸버, 내장 암호화 DNS 또는 별도의 네트워크 설정을 사용할 수 있고, TUN 및 DNS 가로채기가 적용되는지도 설정에 따라 달라집니다. 먼저 대상 앱의 요청이 코어에 들어오는지 확인한 다음 코어의 DNS 로그, 상위 DNS 리졸버와 라우팅 정책을 살펴보세요. 브라우저에서 보안 DNS를 사용한다면 이 설정도 점검 대상에 포함해야 합니다. DNS 테스트 사이트에 표시되는 리졸버는 참고 자료일 뿐, 기기 전체의 트래픽 경로를 증명하지 않습니다. 연결 기록과 실제 네트워크 설정을 함께 확인하세요.
문제 해결
문제가 어느 단계에서 발생하는지 먼저 확인하세요. 설정 가져오기, 코어 시작, 트래픽 전달, 노드에서 대상 사이트로의 연결 중 어디인지 구분합니다.
구독 업데이트 실패: 링크 만료, HTTP 오류, YAML 오류는 어떻게 구분하나요?
먼저 다운로드 단계에서 실패했는지, 파싱 단계에서 실패했는지 확인하세요. HTTP 401 또는 403은 인증이나 접근 제한과 관련이 있을 수 있고, 404는 구독 주소가 만료됐을 가능성이 있습니다. 정확한 의미는 서비스 제공자의 안내를 확인하세요. 시간 초과가 발생하면 현재 네트워크에서 구독 주소에 접속할 수 있는지 점검하세요. 다운로드는 성공했지만 파싱에 실패했다면 응답 내용이 로그인 페이지인지, 현재 코어와 형식이 호환되는지, YAML 들여쓰기가 올바른지 확인하세요. User-Agent는 제공자가 명확히 요청한 경우에만 변경하세요. 마지막으로 정상 작동한 설정을 보관하고 새 링크를 받아 업데이트하세요. 인증 정보가 포함된 링크를 출처가 불분명한 변환 사이트에 입력하지 마세요.
모든 노드가 시간 초과될 때 서비스 문제와 내 기기 문제를 어떻게 구분하나요?
먼저 프록시를 끄고 일반 네트워크가 정상인지 테스트한 뒤 설정이 활성화되어 있는지, 계정 서비스가 유효한지, 노드 정보가 완전한지 확인하세요. 다음으로 노드 하나를 선택해 연결 오류를 확인하고 도메인 확인 실패, 연결 시간 초과, 인증 실패, 프로토콜 미지원 중 어떤 문제인지 구분하세요. 모든 노드가 시간 초과되더라도 테스트 주소에 접속할 수 없는 경우가 있으므로 실제 웹페이지 요청으로 교차 확인해야 합니다. 다른 프록시나 VPN을 종료하고 다른 네트워크에서도 테스트하세요. 같은 설정이 다른 기기에서는 정상이라면 이 기기의 포트, 방화벽, 트래픽 진입 경로를 중점적으로 확인하세요. 설정, DNS, 시스템 네트워크를 한 번에 모두 초기화하면 원인을 찾기 어렵습니다.
시스템 프록시를 켰는데 브라우저에서 작동하지 않고, 종료 후에는 인터넷도 안 될 때 어떻게 하나요?
운영체제의 프록시 설정이 클라이언트가 실제로 수신 중인 로컬 주소와 포트를 가리키는지 확인하고, 코어가 실행 중인지도 점검하세요. 브라우저 확장 프로그램, 별도 프록시 설정, 다른 네트워크 도구가 시스템 설정을 덮어쓸 수 있습니다. 해당 항목을 잠시 끄고 브라우저를 다시 시작해 비교해 보세요. 클라이언트를 종료한 뒤 인터넷이 되지 않는 흔한 원인은 시스템에 종료된 포트를 가리키는 프록시 설정이 남아 있기 때문입니다. 먼저 시스템 프록시를 끄거나 이전 설정으로 되돌린 뒤 직접 연결을 테스트하세요. 다시 사용하려면 코어를 먼저 시작한 다음 프록시를 켜세요. 조직 정책으로 관리되는 기기에서는 정책을 따라야 하며 강제로 덮어쓰지 마세요.
Windows UWP 앱이 로컬 프록시에 연결되지 않을 때 루프백 제한을 어떻게 해결하나요?
AppContainer를 사용하는 일부 Windows 앱은 로컬 루프백 제한 때문에 127.0.0.1의 프록시에 연결하지 못할 수 있습니다. 먼저 일반 브라우저가 정상적으로 작동하고 대상 앱이 실제로 시스템 프록시를 사용하는지 확인하세요. 그런 다음 클라이언트에서 제공하는 UWP 루프백 도구를 사용해 필요한 앱에만 권한을 부여하세요. Windows의 CheckNetIsolation 도구를 사용할 수도 있지만, 앱 패키지 식별자와 작업 권한을 확인해야 하며 모든 앱을 일괄 허용해서는 안 됩니다. 권한을 부여한 뒤 대상 앱을 다시 시작하세요. Microsoft Store에서 설치한 앱이라고 모두 이 제한을 받는 것은 아닙니다. 루프백 권한은 노드, DNS, 서버 문제를 해결하지 않으므로 연결 기록도 확인해야 합니다.
Clash 속도가 느리거나 설정을 불러온 뒤 종료될 때 각각 어디를 확인해야 하나요?
속도가 느리다면 직접 연결과 프록시 연결을 비교한 다음 노드를 고정해 같은 대상을 테스트하고, 노드 부하·회선 상태·기기 설정을 구분하세요. 지연 시간이 낮다고 처리량도 높은 것은 아닙니다. 특정 앱에서만 느리다면 해당 앱에 적용된 규칙과 트래픽 진입 경로를 확인하세요. 클라이언트가 비정상 종료되면 설정과 로그를 먼저 보관하고 이전에 정상 작동한 설정으로 되돌린 뒤 최근 추가한 규칙, 프로바이더, 코어 호환성을 살펴보세요. 시작하자마자 종료된다면 클라이언트 문서에 따라 설정 디렉터리를 잠시 다른 곳으로 옮겨 테스트하고, 현재 OS에 맞는 클라이언트로 업데이트하세요. 데이터를 전부 삭제하거나 문제 원인을 찾는 대신 계속 재설치하지 마세요.