Clash 설정 가이드

1. 핵심 개념과 연결 경로

클라이언트·코어·서버 구분하기

먼저 세 가지 계층을 구분해야 합니다. Clash Plus, Clash Verge Rev, FlClash 같은 이름은 일반적으로 사용자가 조작하는 클라이언트를 가리킵니다. 클라이언트는 설정을 가져오고, 정책 그룹을 표시하며, 기능을 전환하고 백그라운드 프로세스를 관리합니다. mihomo는 프록시 연결, 규칙 매칭, 도메인 조회를 처리하는 코어입니다. 서버는 원격에 있으며 클라이언트가 전달한 연결을 받습니다. 인터페이스를 설치했다고 사용할 수 있는 서버까지 생기는 것은 아니며, 클라이언트 다운로드 페이지가 구독 구매 페이지인 것도 아닙니다.

모든 설정 이름을 외우는 것보다 한 번의 요청이 거치는 경로를 이해하는 편이 중요합니다. 앱은 먼저 대상을 조회하거나 연결을 시도한 다음 시스템 프록시, 수동 프록시 또는 가상 네트워크 어댑터를 통해 코어로 트래픽을 보냅니다. 코어는 대상 도메인, 주소, 규칙을 확인해 직접 연결하거나 차단하거나 정책 그룹으로 전달합니다. 정책 그룹은 마지막으로 실제 출구를 선택합니다. 페이지가 열리지 않는다면 어느 단계에서든 문제가 생겼을 수 있습니다. 클라이언트 아이콘이 켜져 있다는 이유만으로 전체 연결 경로가 정상이라고 판단하지 마세요.

구독·노드·정책 그룹 구분하기

구독 링크는 설정이나 노드 정보를 가져오는 경로이며, 보통 접근 자격 증명이 포함되므로 비밀번호처럼 관리해야 합니다. 노드는 서버 주소, 포트, 프로토콜, 인증 매개변수 등을 포함한 원격 연결을 나타냅니다. 정책 그룹은 여러 노드나 다른 그룹을 묶어 수동 선택, 사용 가능 여부에 따른 대체 등의 동작을 제공합니다. 하나의 노드를 여러 그룹에서 참조할 수 있지만, 그룹 이름이 실제 위치를 뜻하지는 않으며 특정 웹사이트 접속을 보장하지도 않습니다.

설정 파일에는 DNS, 수신 포트, 규칙 모음, 원격 리소스 주소도 들어갈 수 있습니다. 일부 구독은 노드 목록만 제공하며, 나머지 설정은 클라이언트의 템플릿이나 병합 기능으로 보완해야 합니다. 다른 구독은 완성된 설정을 바로 제공합니다. 두 형식을 구분 없이 서로 바꿔 쓸 수는 없습니다. 가져오기에 성공했다는 것은 클라이언트가 리소스를 받아들였다는 뜻일 뿐, 해당 설정이 선택되었거나 코어에 로드되었다는 뜻은 아닙니다. 원격 계정이 아직 유효하다는 의미도 아닙니다.

단계별로 검증하기

로컬 수신 포트는 앱이 코어에 연결되는 입구이지 원격 서버 포트가 아닙니다. 예를 들어 mixed-port는 하나의 수신 포트에서 HTTP와 SOCKS 프록시 요청을 모두 받을 수 있습니다. Windows에서 흔히 사용하는 로컬 주소 127.0.0.1은 현재 기기만을 가리킵니다. 프록시를 수동으로 입력할 때는 클라이언트에 표시된 주소와 포트를 그대로 사용하세요. 스크린샷에 나온 숫자를 따라 입력하거나 구독 주소를 프록시 서버 입력란에 넣지 마세요.

연결은 네 단계로 확인하세요. 먼저 코어가 실행 중인지 확인하고, 다음으로 트래픽이 들어오는지 확인한 뒤 규칙 선택을 살펴보고, 마지막으로 출구에서 응답이 오는지 판단합니다. 연결 목록에 기록이 전혀 없다면 앱이 시스템 프록시를 따르는지 먼저 확인하세요. 기록은 있지만 차단으로 표시되면 매칭된 규칙을 확인합니다. 예상한 정책을 거쳤는데도 시간 초과가 발생한다면 노드, 원격 서비스, 대상 사이트를 점검하세요. 이 순서대로 확인하면 반복해서 재설치하는 일을 줄이고 DNS 문제를 구독 문제로 오해하는 것도 막을 수 있습니다.

전송 암호화와 안전한 이용도 구분해야 합니다. 클라이언트가 특정 프로토콜을 지원한다고 해서 설정 출처까지 믿을 수 있는 것은 아닙니다. 트래픽을 원격 출구로 보낸다고 피싱 페이지로부터 계정이 자동으로 보호되는 것도 아닙니다. 신뢰할 수 있는 출처의 설정만 가져오고, 브라우저에서 인증서 오류가 발생하면 작업을 중단하세요. 연결 문제를 해결하려고 출처가 불분명한 루트 인증서를 설치하지 마세요. 프로젝트의 역사와 역할 분담은 Clash, mihomo, Clash Verge Rev의 관계 정리에서 확인할 수 있습니다.

2. 클라이언트 및 기기 아키텍처 선택

사용 플랫폼에 맞춰 선택 범위 좁히기

처음 클라이언트를 고를 때는 인터페이스 취향보다 기기 플랫폼, 프로세서 아키텍처, 필요한 기능을 먼저 확인하세요. Windows 사용자는 우선 Clash Plus를 살펴보고 Windows 다운로드 페이지에서 설치 요구 사항을 확인하세요. 이 가이드에 나온 서비스 모드, 로그, 규칙 예제를 따라야 한다면 Clash Verge Rev도 선택할 수 있습니다. 이후 설명은 Clash Verge Rev에서 흔히 쓰는 메뉴 이름을 기준으로 합니다. 다른 클라이언트에서는 설정, 프록시, 옵션과 같은 기능을 찾아보세요.

Windows에서는 FlClash와 Clash Nyanpasu도 사용할 수 있습니다. 테스트할 때 여러 클라이언트를 동시에 실행하지 마세요. 수신 포트, 시스템 프록시, 가상 네트워크 어댑터가 서로 간섭할 수 있습니다. 클라이언트를 바꾸기 전에 이전 클라이언트의 시스템 프록시와 TUN을 끈 다음 프로세스를 완전히 종료하세요. 이전 설정은 백업해 두면 충분합니다. 인터페이스를 비교하려고 모든 프로그램을 시작 프로그램에 등록할 필요는 없습니다. 문제 해결 중에는 트래픽 진입점을 하나만 명확하게 유지하세요.

운영체제 이름만 보지 말고 아키텍처도 확인하기

Windows에서 ‘설정 → 시스템 → 정보’를 열어 ‘시스템 종류’를 확인하세요. x64 기반 프로세서는 일반적으로 x64 또는 AMD64 설치 패키지를 사용합니다. 여기서 두 표기는 같은 아키텍처를 뜻하며 특정 프로세서 제조사 전용이라는 의미는 아닙니다. ARM64 기기는 다운로드 페이지에서 해당 빌드를 제공하는지, 클라이언트가 현재 Windows 환경을 지원하는지 먼저 확인하세요. 코어 압축 파일을 그래픽 클라이언트 설치 파일로 착각하지 마세요.

macOS에서는 Apple Silicon과 Intel을 구분해야 합니다. Android는 기기 아키텍처에 맞춰 범용 패키지나 해당 아키텍처 패키지를 선택하고, Linux는 패키지 관리 방식도 확인해야 합니다. 패키지를 다운로드할 수 있다고 해서 모든 시스템에 설치할 수 있는 것은 아닙니다. 데스크톱 클라이언트에 필요한 그래픽 환경, 권한, 시스템 구성 요소는 명령줄 코어와 다릅니다. 서버나 라우터를 사용하는 경우에만 독립 mihomo 코어의 실행 방식과 서비스 관리 방법을 추가로 살펴보면 됩니다.

지원 상태와 필요한 기능을 기준으로 선택하기

Clash for Windows와 ClashX Meta는 지원이 중단되었습니다. 이전 사용법을 확인하는 용도로는 참고할 수 있지만 신규 사용자의 기본 선택으로 권장하지 않습니다. 오래된 클라이언트는 새 설정 필드, 프로토콜 기능, 시스템 호환성을 지원하지 않을 수 있습니다. 가져오기 오류가 발생하면 먼저 설정 요구 사항을 확인한 뒤 지원 중인 클라이언트로 옮기는 방안을 검토하세요. 오류가 난 필드를 무조건 삭제하는 방식은 피해야 합니다. 삭제한 항목이 구독 작동에 필요한 설정일 수 있습니다.

비슷한 코어를 사용하는 클라이언트라도 설정 저장 방식, 확장 스크립트, 서비스 설치 절차는 다를 수 있습니다. 이전할 때는 구독을 새로 가져온 다음 필요한 규칙만 항목별로 옮기세요. 프로그램 데이터 폴더 전체를 그대로 복사하지 마세요. 특정 클라이언트가 생성한 실행 설정을 장기 보관할 원본 파일로 취급해서도 안 됩니다. 임시 포트, 제어 인터페이스 주소, 절대 경로, 기존 환경에서만 유효한 오버라이드가 들어 있을 수 있습니다.

마지막으로 일상적인 사용 목적을 확인하세요. 브라우저 접속이 주된 용도라면 우선 시스템 프록시를 사용하면 됩니다. 시스템 프록시를 따르지 않는 앱까지 처리해야 한다면 TUN을 검토하고, 도메인별로 출구를 나누려면 규칙과 정책 그룹 관리가 중요합니다. 기능이 많다고 처음 설정하기 쉬운 것은 아닙니다. 먼저 최소한의 연결을 만든 뒤 요구 사항을 하나씩 추가하고 매번 검증하세요. 그러면 문제가 생겨도 확실하게 되돌아갈 수 있습니다.

3. 클라이언트 설치 및 첫 점검

설치 전에 충돌하는 연결 경로 정리하기

다운로드 센터에서 운영체제와 아키텍처에 맞는 설치 패키지를 선택하세요. 찾기 쉬운 로컬 폴더에 저장하고, 임시 압축 폴더에서 프로그램을 반복 실행하지 마세요. 설치 전에 실행 중인 다른 프록시 클라이언트를 종료하고 기존 프록시 포트와 TUN 사용 여부를 기록해 두세요. 조직에서 관리하는 기기라면 가상 네트워크 어댑터와 백그라운드 서비스를 설치해도 되는지 먼저 확인하세요. 관리 제한을 우회하려고 시스템 정책을 변경하지 마세요.

설치 프로그램을 실행할 때는 시스템에 표시되는 게시자 정보와 권한 요청을 확인하세요. 관리자 권한이 필요한 단계는 설치 경로, 서비스, 네트워크 구성 요소와 관련이 있어야 합니다. 출처나 파일 형식, 안내 내용이 예상과 다르면 설치를 중단하세요. Windows 보안 경고를 모두 오탐으로 간주해서는 안 되며, 클라이언트 설치를 위해 보호 기능을 장기간 끄는 것도 바람직하지 않습니다. 다운로드 출처, 기기 아키텍처, 시스템 요구 사항을 다시 확인한 뒤 진행하세요.

시스템 프록시를 켜기 전에 코어부터 확인하기

처음 실행한 뒤 설정 페이지에서 코어가 실행 중인지, 수신 포트가 열렸는지 확인하세요. 아직 구독이 없다면 프록시 페이지에 선택할 노드가 없는 것이 정상입니다. 바로 재설치할 필요는 없습니다. 시스템 프록시와 TUN은 일단 꺼둔 상태에서 기본 설정과 구독 가져오기를 마치세요. 코어가 시작되지 않으면 로그를 열어 가장 먼저 나타난 설정 구문 오류, 주소 충돌, 권한 오류를 확인하세요. 마지막 종료 메시지만 보지 마세요.

포트 충돌은 이전 클라이언트가 종료되지 않았거나 같은 프로그램이 중복 실행될 때 자주 발생합니다. 점유 중인 프로세스를 확인한 뒤 조치하고, 시스템 프로세스를 무작정 종료하지 마세요. 아래 예시는 포트 7897을 조회합니다. 실제로는 설정 페이지에 표시된 포트로 바꿔야 합니다. 명령에 표시된 프로세스 번호는 프로그램을 추가로 확인하기 위한 정보이지, 해당 프로세스에 반드시 문제가 있다는 뜻은 아닙니다. 확인 후에는 해당 소프트웨어의 정상 종료 기능을 사용해 포트를 해제하세요.

netstat -ano | findstr ":7897"
tasklist /FI "PID eq 1234"

두 번째 줄의 1234는 예시 프로세스 번호입니다. 실행하기 전에 첫 번째 줄에서 확인한 실제 번호로 바꾸세요. 포트를 다른 필수 프로그램이 사용 중이라면 클라이언트 설정에서 사용하지 않는 포트로 변경한 뒤, 해당 포트에 의존하는 도구도 함께 업데이트하세요. Windows 시스템 프록시의 포트만 바꾸고 코어 수신 포트는 그대로 두지 마세요. 두 값이 다르면 앱이 아무 서비스도 수신하지 않는 위치로 요청을 보냅니다.

필요한 경우에만 서비스 모드 설치하기

Clash Verge Rev의 서비스 모드는 백그라운드 서비스가 해당 권한이 필요한 코어 작업을 맡도록 합니다. TUN 사용 시 주로 활용됩니다. ‘설정’에서 ‘서비스 모드’ 관련 메뉴를 찾아 설치를 실행하고 시스템 안내에 따라 권한을 허용하세요. 메뉴 이름은 인터페이스 버전에 따라 조금 다를 수 있습니다. 설치가 끝나면 서비스 상태를 확인한 뒤 클라이언트 안내에 따라 관련 구성 요소를 다시 시작하세요. 서비스가 설치되었다고 TUN까지 켜진 것은 아닙니다. 두 상태는 서로 다릅니다.

보안 소프트웨어나 조직 권한 제한으로 서비스 설치가 실패할 수 있습니다. 구체적인 오류를 기록한 뒤 Windows 서비스 관리 도구에서 서비스가 등록되어 있는지, 시작할 수 있는지 확인하세요. 토글 색상만 보고 설치 성공 여부를 판단하지 말고, 출처가 불분명한 복구 명령을 반복해서 실행하지도 마세요. 일반 시스템 프록시는 작동하지만 서비스 설치만 실패한다면, 우선 시스템 프록시를 유지하고 서비스 권한을 별도로 점검하세요. 이미 작동하는 네트워크 경로까지 손상시키지 않도록 주의해야 합니다.

설치 점검의 완료 기준은 클라이언트가 정상적으로 열리고, 코어 로그에 지속적인 시작 실패가 없으며, 포트가 예상한 값과 일치하고, 종료와 재실행을 제어할 수 있는 상태입니다. 시작 프로그램 등록은 연결을 검증한 뒤에 설정하세요. ‘인터페이스 시작’, ‘백그라운드 서비스 시작’, ‘시스템 프록시 자동 복원’은 서로 다른 기능입니다. 설정, 프록시, 로그 페이지가 낯설다면 Clash Verge Rev 인터페이스 빠르게 살펴보기를 참고하세요.

4. 구독 가져오기 및 설정 적용

가져온 뒤 사용할 설정을 명확히 선택하기

먼저 서비스 제공업체에서 현재 클라이언트 또는 mihomo에 사용할 수 있는 구독 링크를 받으세요. 주소를 완전히 복사하고 채팅 앱이 덧붙인 문장 부호, 공백, 줄바꿈이 포함되지 않도록 주의하세요. 클라이언트의 ‘설정’ 페이지에서 구독 주소 입력란에 링크를 붙여 넣고 ‘가져오기’를 누릅니다. 일부 인터페이스에서는 이 페이지를 ‘구독’이라고 부릅니다. 다운로드가 끝나면 새 항목이 표시되는지 확인하고, 해당 항목을 직접 선택하거나 활성화하세요. 목록에 설정 카드가 나타났다고 전환까지 끝난 것은 아닙니다.

활성 설정이 로드되면 ‘프록시’ 페이지에서 정책 그룹이 표시되는지 확인하세요. 노드만 있고 예상한 규칙과 그룹이 없다면 구독이 노드 리소스만 반환하는지, 완성된 설정을 반환하는지 먼저 확인해야 합니다. 일부 클라이언트는 템플릿으로 그룹과 규칙을 생성할 수 있지만, 다른 클라이언트는 완성된 YAML을 가져와야 합니다. 서비스 제공업체가 안내한 방법을 사용하고, 구독 링크를 낯선 온라인 변환 사이트에 입력하지 마세요. 변환 과정에서 링크의 인증 정보가 노출될 수 있습니다.

다운로드 실패와 파싱 실패 구분하기

구독 다운로드에 실패하면 현재 네트워크에서 구독 도메인에 접속할 수 있는지 먼저 확인한 다음, 로그의 HTTP 상태와 연결 오류를 살펴보세요. 인증 실패는 링크 만료나 계정 상태 변경을 의미할 수 있습니다. 연결 시간 초과는 DNS, 네트워크 제한, 서비스 제공업체 장애와 관련이 있을 수 있습니다. 브라우저에서 특정 페이지가 열린다고 해서 클라이언트도 구독을 가져올 수 있는 것은 아닙니다. 프록시 경로, 인증서 환경, 요청 방식이 서로 다를 수 있습니다.

다운로드는 완료됐지만 파싱에 실패했다면 반환된 내용과 설정 형식을 확인해야 합니다. 서버가 예상한 YAML 대신 로그인 페이지, 오류 안내, 호환되지 않는 필드를 반환했을 수 있습니다. 오류에 언급된 필드와 줄 번호를 확인하고 구독 제공업체에 지원 범위를 문의하세요. 개인 인증 정보가 들어 있는 완성된 설정 파일을 공개 질문 게시판에 올리지 마세요. 도움을 요청할 때는 서버 주소, 인증 매개변수, 구독 링크를 제거한 오류 주변 내용만 공유하세요.

원본 설정·오버라이드·실행 설정 구분하기

구독을 업데이트하면 원격 콘텐츠를 다시 가져옵니다. 다운로드한 파일을 직접 수정하면 다음 업데이트 때 변경 사항이 덮어써질 수 있습니다. 실행 중 합성된 설정을 직접 수정한 내용도 설정을 전환하거나 코어를 다시 시작하면 사라질 수 있습니다. 장기적으로 유지할 사용자 설정은 클라이언트가 지원하는 오버라이드, 병합, 스크립트 기능에 넣고 적용 순서를 파악하세요. 작은 변경 하나를 저장하고 코어를 다시 불러온 뒤 최종 설정을 확인하세요. 이후 구독을 업데이트해도 변경 사항이 남는지 검증해야 합니다.

YAML은 들여쓰기와 자료형에 민감합니다. 공백으로 들여쓰고 탭 문자를 섞지 마세요. 목록 항목의 하이픈을 유지하고 문자열에 특수 문자가 있으면 올바르게 따옴표로 감싸야 합니다. 같은 키를 반복해서 적는다고 값이 ‘추가’되는 것은 아닙니다. 파서에 따라 오류가 발생하거나 한 항목만 남을 수 있습니다. 완성된 설정 파일 두 개를 그대로 이어 붙이지 마세요. 노드, 정책 그룹, 규칙, DNS는 각각 구조에 맞게 병합하고 참조하는 그룹 이름이 모두 존재하는지 확인해야 합니다.

자동 업데이트 주기는 서비스 제공업체의 권장 사항을 따르되 지나치게 자주 설정하지 않아도 됩니다. 업데이트 전에 복구할 수 있는 설정과 로컬 오버라이드를 보관하세요. 업데이트 후에는 그룹에서 이전에 선택한 노드가 여전히 있는지 확인해야 합니다. 노드 이름이 바뀌면 이전 선택이 유효하지 않을 수 있으며, 그룹이 기본 선택으로 돌아가거나 출구가 바뀔 수 있습니다. 중요한 용도라면 업데이트 알림이 성공으로 표시되는지만 보지 말고 규칙 매칭과 출구도 다시 확인하세요.

구독 가져오기의 완료 기준은 사용할 설정이 명확하고, 코어가 정상적으로 로드되며, 정책 그룹이 표시되고, 사용 가능한 출구를 하나 이상 선택할 수 있는 상태입니다. 로컬 파일에서 이전하는 경우 신뢰할 수 있는 기기에서 만든 파일인지 확인하고 필요한 인증 정보를 유지하세요. 클라우드 드라이브나 채팅 앱으로 전송하기 전에는 노출 범위를 고려해야 합니다. 설정을 읽을 수 있다고 해서 공개적으로 공유해도 되는 것은 아닙니다. 노드 비밀번호, 제어 인터페이스 키, 구독 링크를 스크린샷에 포함하지 마세요.

5. 프록시 모드와 연결 검증

트래픽 진입점과 출구 선택 구분하기

시스템 프록시는 ‘앱이 요청을 코어로 보내는 방법’을 결정하고, 규칙·전역·직접 연결 모드는 ‘코어에 들어온 요청의 경로’를 결정합니다. 서로 다른 설정이므로 대신 사용할 수 없습니다. 전역 모드를 켜도 모든 Windows 앱의 트래픽이 자동으로 코어를 통과하는 것은 아닙니다. 시스템 프록시를 켜도 모든 요청이 반드시 원격 노드를 거치는 것은 아닙니다. 바꾸려는 것이 진입점인지 라우팅인지 먼저 확인한 다음 연결 기록을 살펴보면 토글의 실제 효과를 이해할 수 있습니다.

일상적인 사용에는 우선 ‘규칙’ 모드를 선택하세요. 코어가 설정된 규칙에 따라 요청을 매칭합니다. ‘전역’ 모드에서는 코어에 들어온 요청이 대체로 전역 정책 그룹으로 전달되며, 해당 그룹에서 적절한 출구를 선택해야 합니다. 직접 연결 옵션을 선택했다면 여전히 직접 접속할 수 있습니다. ‘직접 연결’ 모드는 코어에 들어온 연결을 바로 내보냅니다. 어떤 모드도 코어에 들어오지 않은 트래픽을 처리하거나 원격 계정과 노드의 유효성을 확인해 주지는 않습니다.

시스템 프록시를 켜고 앱 동작 확인하기

설정과 노드가 준비되었는지 확인한 다음 클라이언트에서 ‘시스템 프록시’를 켜세요. Windows의 ‘설정 → 네트워크 및 인터넷 → 프록시’에서 현재 상태를 확인하고 주소와 포트가 실행 중인 로컬 수신 포트를 가리키는지 점검하세요. 클라이언트마다 프록시 설정을 적용하는 방식이 다를 수 있고 조직 정책이 해당 설정을 덮어쓸 수도 있습니다. 상태가 일치하지 않으면 먼저 다른 프록시 소프트웨어를 종료하세요. 여러 위치에서 설정을 반복해서 덮어쓰지 마세요.

브라우저는 보통 시스템 프록시를 사용하지만 확장 프로그램, 별도의 프록시 설정, 관리 정책에 따라 다르게 동작할 수 있습니다. 기존 연결을 닫고 브라우저를 다시 열어 테스트 페이지에 접속하면서 클라이언트의 연결 페이지를 살펴보세요. 페이지를 새로고침하는 것만으로는 이전 연결이나 로컬 캐시가 재사용될 수 있어 새 설정이 적용되었음을 증명할 수 없습니다. 테스트할 때는 새 요청임을 확인하기 쉬운 대상을 선택하고 도메인, 정책 경로, 연결 상태를 점검하세요. 웹페이지 모서리에 표시되는 알림만 유일한 증거로 삼지 마세요.

명령줄 도구가 Windows 시스템 프록시를 자동으로 따르지는 않을 수 있습니다. 로컬 HTTP 진입점을 따로 검증하려면 프록시 주소를 명시할 수 있습니다. 아래 예시는 혼합 포트 7897을 사용합니다. 실행 전에 현재 포트로 바꾸세요. 이 명령은 대상의 응답을 확인하기 위한 것이며 모든 네트워크에서 특정 공개 사이트에 접속할 수 있음을 보장하지 않습니다. 모든 앱이 프록시를 사용한다는 증거도 아닙니다.

curl.exe --proxy http://127.0.0.1:7897 --head https://example.com

HTTP 응답이 돌아오면 이번 요청이 대상과 왕복 통신을 마쳤다는 뜻입니다. 그래도 클라이언트에서 어떤 정책을 거쳤는지 확인해야 합니다. 로컬 포트 연결 실패가 표시되면 코어와 수신 상태를 먼저 점검하세요. 로컬에서 요청을 받았지만 원격 시간 초과가 발생하면 출구를 확인하세요. 인증서 오류가 표시되면 기기 시간과 신뢰할 수 있는 인증서 환경을 점검하고, 인증서 검증을 무시하는 옵션을 추가하지 마세요. 오류가 발생한 계층에 맞춰 처리하는 편이 여러 노드로 바꾸며 새로고침을 반복하는 것보다 효과적입니다.

속도 테스트와 전역 모드를 올바르게 이해하기

노드 속도 테스트는 보통 클라이언트에 설정된 테스트 주소로 요청을 보내며 결과는 테스트 대상, 네트워크 경로, 프로토콜 구현에 따라 달라집니다. 테스트에 성공해도 다른 사이트 접속이 보장되는 것은 아니며, 실패했다고 노드가 완전히 사용할 수 없다는 뜻도 아닙니다. 실제 문제를 확인할 때는 해당 대상에 직접 접속하고 도메인 조회 실패, 규칙 오매칭, 대상 거부가 발생했는지 살펴보세요. 노드를 비교할 때는 테스트 조건을 동일하게 유지하고, 서로 다른 시점의 단일 측정값으로 장기적인 품질을 판단하지 마세요.

클라이언트를 종료하기 전에 시스템 프록시를 먼저 끄세요. 프로그램이 설정을 자동으로 복원하는지 확인하지 못했다면 특히 주의해야 합니다. 프로그램이 비정상 종료된 뒤 브라우저가 인터넷에 연결되지 않으면 Windows 프록시 설정이 이미 종료된 로컬 포트를 가리키는지 확인하세요. 네트워크를 복구한 뒤 클라이언트를 다시 시작하면 됩니다. 남아 있는 시스템 프록시를 고치려고 모든 네트워크 어댑터를 즉시 초기화하지 마세요. 시스템 프록시로 주된 요구 사항을 충족할 수 있다면 일단 이 방식을 유지하고 다음 장에서 출구 선택을 자세히 살펴보세요.

6. 규칙 분기와 사용자 설정

규칙 매칭 순서 이해하기

규칙 모드는 보통 위에서 아래로 확인하며, 조건에 맞는 규칙을 만나면 해당 정책을 적용합니다. 더 구체적인 규칙을 포괄적인 규칙보다 위에 두고 마지막 기본 규칙인 MATCH는 맨 아래에 배치하세요. 규칙을 추가한 뒤에는 요청에 규칙 매칭에 필요한 정보가 실제로 있는지 확인해야 합니다. 도메인 규칙에는 확인 가능한 도메인이 필요하고, IP 대역 규칙은 대상 IP를 기준으로 합니다. 프로세스 규칙은 플랫폼 권한과 코어의 프로세스 정보 확인 기능에도 영향을 받으므로 앱 이름만 보고 반드시 매칭된다고 판단할 수 없습니다.

일반적으로 DOMAIN은 전체 도메인을 매칭하고, DOMAIN-SUFFIX는 도메인과 하위 도메인을 매칭하며, IP-CIDR은 IP 주소 대역을 매칭합니다. 내장 정책 DIRECT는 직접 연결, REJECT는 차단을 뜻합니다. 그 밖의 정책 이름은 보통 기존 프록시 그룹이나 노드를 참조합니다. 이름은 대소문자와 공백까지 정확히 일치해야 합니다. 존재하지 않는 그룹을 참조하면 설정을 불러오지 못하거나 예상과 다르게 라우팅될 수 있습니다.

검증하기 쉬운 규칙 하나부터 추가하기

아래는 특정 도메인, 루프백 주소, 로컬 네트워크 주소를 직접 연결하도록 설정하는 규칙 예시입니다. 완성된 설정이 아니므로 노드와 정책 그룹이 포함되어 있지 않으며 원격 구독을 그대로 대체할 수도 없습니다. 로컬 규칙 오버라이드에 사용할 경우 기존 규칙 목록에서 알맞은 위치에 필요한 항목을 추가하고 마지막 기본 정책을 유지하세요. 로컬 네트워크 주소를 모두 직접 연결할지는 기기가 연결된 네트워크와 실제 보안 경계를 고려해 결정해야 합니다.

rules:
  - DOMAIN,example.com,DIRECT
  - IP-CIDR,127.0.0.0/8,DIRECT,no-resolve
  - IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
  - IP-CIDR,10.0.0.0/8,DIRECT,no-resolve
  - IP-CIDR,172.16.0.0/12,DIRECT,no-resolve

no-resolve는 해당 주소 규칙을 판단하기 위해 도메인을 임의로 조회하지 않도록 합니다. DNS 전체를 끄는 옵션은 아닙니다. 도메인 요청이 앞쪽의 도메인 규칙과 매칭되면 뒤에 있는 주소 규칙은 더 이상 선택에 관여하지 않습니다. 문제를 확인할 때는 먼저 연결 세부 정보를 열어 실제로 매칭된 규칙을 확인하고 목록에서 어디에 있는지 살펴보세요. ‘우선순위를 높인다’며 모든 주소 규칙을 맨 위에 배치하지 마세요. 기존 도메인 분기 결과가 달라질 수 있습니다.

규칙 집합으로 많은 규칙 관리하기

규칙이 많다면 rule-providers로 원격 또는 로컬 규칙 집합을 관리하고 RULE-SET으로 참조할 수 있습니다. 집합의 behavior, 형식, 내용은 서로 맞아야 합니다. 도메인 목록을 변환 없이 기존 규칙 목록처럼 사용할 수는 없습니다. 리소스를 가져오지 못하면 다운로드 경로, 캐시 파일, 로그를 확인하세요. 클라이언트가 구독을 업데이트했다고 해서 모든 원격 규칙 리소스까지 정상적으로 업데이트된 것은 아닙니다.

규칙 소스를 선택할 때는 한 번에 많은 출처를 가져오기보다 관리 범위와 업데이트 방식을 고려하세요. 여러 규칙 집합이 같은 대상을 중복으로 다룰 수 있으며 최종 결과는 참조 순서에 따라 결정됩니다. 업무 앱, 결제 페이지, 로컬 네트워크 기기에 예외를 추가한다면 사유와 검증 날짜를 기록해 두세요. 나중에 규칙의 용도를 잊지 않도록 하는 데 도움이 됩니다. 원본 설정이 업데이트된 뒤에는 사용자 규칙이 예상한 위치에 병합되었는지도 확인하세요.

트래픽 분기를 검증할 때는 기존 연결을 종료하고 새 요청을 보내세요. 이미 연결된 세션은 규칙을 수정해도 보통 출구가 바로 바뀌지 않습니다. 브라우저와 데스크톱 앱은 여러 도메인에 동시에 요청할 수 있으므로 페이지의 기본 도메인 규칙 하나로 이미지, 인증, API 도메인까지 모두 처리하지 못할 수 있습니다. 먼저 누락된 요청을 확인한 뒤 정확한 규칙을 추가하세요. 지나치게 광범위한 키워드 규칙으로 관계없는 업무까지 한꺼번에 우회시키지 마세요.

마지막으로 라우팅과 DNS를 따로 살펴보세요. 규칙이 출구를 결정하지만 도메인 조회는 로컬, 코어, 원격 중 어디서든 발생할 수 있으며 주소 규칙은 조회 결과의 영향을 받을 수 있습니다. 조회 문제가 생겼을 때 규칙을 계속 추가해 덮어 버리지 마세요. 먼저 DNS 응답과 연결 대상 주소를 확인한 뒤 조회 정책을 조정할지 판단하세요. 재현 가능한 요청 기록을 하나 남겨 두면 이후 TUN과 Fake-IP 설정을 검토할 때 믿을 만한 비교 기준으로 활용할 수 있습니다.

7. TUN 모드와 DNS 점검

가상 네트워크 어댑터가 필요한지 확인하기

TUN 모드는 가상 네트워크 어댑터와 라우팅을 통해 트래픽을 처리하므로 시스템 프록시를 따르지 않는 앱에 적합할 수 있습니다. 다만 처리 범위는 운영체제, 라우팅, 제외 설정, 클라이언트 구현에 따라 달라집니다. 모든 문제를 해결하는 ‘성능 향상 스위치’는 아닙니다. 브라우저는 정상이고 특정 앱만 실패한다면 먼저 앱이 실제로 사용하는 네트워크 인터페이스와 프로토콜을 확인한 뒤 TUN이 필요한지 판단하세요. 노드 인증이나 규칙 오류가 원인이라면 진입점을 바꿔도 출구 문제는 해결되지 않습니다.

활성화하기 전에 다른 VPN, 가상 네트워크 어댑터 기반 프록시, 유사한 트래픽 가로채기 도구를 끄고 현재 시스템 프록시 상태를 기록해 두세요. Clash Verge Rev에서 서비스 모드가 설치되어 정상 작동하는지 확인한 다음 TUN을 켜세요. 처음 테스트할 때는 요청 경로를 명확히 알 수 있도록 시스템 프록시를 잠시 끌 수 있습니다. 클라이언트에서 특정 조합을 요구한다면 해당 안내를 따르세요. 활성화한 뒤에는 일반 웹사이트, 로컬 네트워크 리소스, 필수 업무 앱을 확인하세요. 웹페이지 하나만 테스트하고 장기간 사용하지 마세요.

일반적인 TUN 필드 이해하기

아래는 mihomo 설정의 TUN 부분으로, 필드 구조를 설명하기 위한 예시이며 실행 가능한 완성 설정이 아닙니다. 클라이언트가 인터페이스를 통해 같은 내용을 생성할 수도 있으므로 한 가지 관리 방식을 우선 사용하세요. 인터페이스 설정과 수동 설정이 서로 충돌하지 않도록 주의해야 합니다. 지원되는 필드는 실제 코어에 따라 달라집니다. 설정을 불러오지 못하면 해당 버전의 문서를 확인하고, 동작을 알 수 없는 트래픽 가로채기 환경을 억지로 켜려고 오류 필드를 전부 삭제하지 마세요.

tun:
  enable: true
  stack: mixed
  auto-route: true
  auto-detect-interface: true
  dns-hijack:
    - any:53

enable은 활성화 여부를 제어하고, stack은 네트워크 스택 구현을 선택합니다. auto-route는 라우팅을 자동으로 설정하며, auto-detect-interface는 외부 연결에 사용할 인터페이스를 식별합니다. dns-hijack의 예시는 해당하는 일반 DNS 트래픽을 가로채는 용도입니다. 앱 내부에서 HTTPS나 다른 암호화 채널로 보내는 모든 조회 요청까지 자동으로 처리하지는 않으며, 전체 코어 DNS 설정을 대신하지도 않습니다.

DNS 경로를 따로 검증하기

Fake-IP 모드는 예약된 주소를 도메인에 매핑해 코어가 이후 연결에서 원래 도메인을 복원하고 라우팅에 활용하도록 합니다. 이 주소는 대상 서버의 실제 공인 IP가 아닙니다. 조회 결과가 Fake-IP 주소 대역에 속한다고 해서 바로 DNS 오염으로 판단하지 마세요. 코어 로그, 연결 세부 정보, 최종 응답을 함께 확인해야 합니다. 앱에서 실제 주소가 필요하거나 호환성 문제가 있다면 fake-ip-filter에 필요한 항목만 구체적으로 추가하세요.

DNS 모드를 변경한 뒤에도 시스템과 앱 캐시에 이전 결과가 남아 있을 수 있습니다. 영향을 받은 앱을 종료하고 필요하다면 시스템 DNS 캐시를 비운 다음 연결을 다시 만드세요. 아래 Windows 명령은 시스템 조회 캐시를 갱신하지만 브라우저 내부 캐시를 모두 지우지는 않으며 원격 서비스 문제도 해결하지 않습니다. 명령이 성공으로 끝났다는 이유만으로 네트워크 문제가 해결되었다고 판단하지 말고 새 요청을 확인하세요.

ipconfig /flushdns

회사 네트워크, 학교 네트워크, 가상 머신, 여러 네트워크 어댑터를 사용하는 환경에서는 라우팅 경계에 특히 주의해야 합니다. 기본 인터페이스 변경이나 유무선 전환으로 자동 감지 결과가 예상과 달라질 수 있습니다. 로컬 프린터, 공유 폴더, 내부 도메인은 기존 경로를 유지해야 할 수도 있습니다. 문제가 발생하면 먼저 TUN을 끄고 정상으로 돌아오는지 확인한 뒤 라우팅과 DNS를 점검하세요. 네트워크 어댑터를 삭제하거나 시스템 네트워크를 초기화하는 방식부터 시도하지 마세요.

Windows UWP 앱에는 별도의 루프백 제한도 있습니다. 로컬 시스템 프록시를 사용할 때 샌드박스 제한으로 인해 앱이 루프백 주소에 접근하지 못할 수 있습니다. 일반 데스크톱 브라우저와는 다른 문제입니다. UWP 루프백 예외 안내를 참고해 해당 앱만 확인하고 모든 앱의 권한을 일괄 변경하지 마세요. DNS 처리 과정과 호환성 경계는 Fake-IP와 redir-host의 차이에서 자세히 확인할 수 있습니다. 매핑 방식부터 이해한 뒤 필터 목록을 확장하세요.

8. 일상 관리와 문제 해결

복구 가능한 설정 상태 보관하기

안정적으로 사용하기 시작하면 관리 대상을 클라이언트, 코어, 구독, 로컬 오버라이드 네 가지로 나누세요. 클라이언트를 업그레이드하면 인터페이스나 포함된 코어가 함께 바뀔 수 있습니다. 구독을 업데이트하면 노드와 규칙이 달라지고, 오버라이드를 수정하면 최종 실행 설정에 영향을 줍니다. 한 번에 한 종류만 변경하고 작업 전후 상태를 기록하세요. 그러면 문제가 생겨도 어떤 업데이트가 연결을 바꿨는지 추측하지 않고 명확한 단계로 되돌릴 수 있습니다.

백업에는 구독 링크의 안전한 보관 정보, 로컬 사용자 규칙, 오버라이드 스크립트, 필요한 설정이 포함되어야 합니다. 모든 로그와 임시 캐시까지 설정 백업으로 취급할 필요는 없습니다. 실행 설정에는 민감한 인증 정보와 로컬 경로가 들어 있을 수 있으며 새 기기로 옮겨도 그대로 작동하지 않을 수 있습니다. 암호화된 저장소나 접근이 통제되는 위치에 보관하고, 동기화 소프트웨어를 통해 다른 구성원에게 노출되지 않는지 확인하세요. 백업 파일에도 접근 제한이 필요합니다.

오류 계층에 따라 로그 확인하기

연결이 끊기면 발생 시각, 사용 중인 네트워크, 영향을 받은 앱, 가장 최근의 변경 사항을 먼저 기록하세요. 코어가 계속 실행 중인지 확인한 다음 시스템 프록시나 TUN이 예상한 상태인지 살펴보세요. 특정 사이트만 실패한다면 곧바로 시스템 전체를 다시 시작하지 마세요. 다른 앱이나 다른 대상과 비교해 확인하세요. 모든 앱에서 동시에 실패한다면 로컬 수신 포트, 네트워크 인터페이스, DNS, 서비스 상태를 차례로 점검하며 범위를 좁히세요.

설정 파싱 오류는 해당 필드와 들여쓰기를 다시 확인해야 합니다. 로컬 포트 바인딩 실패는 포트 점유 여부를 확인하고, 도메인 조회 실패는 DNS를 살펴보세요. 원격 핸드셰이크나 인증 실패라면 프로토콜 매개변수와 서비스 제공업체 상태를 점검해야 합니다. 시간 초과만으로는 원인을 단정할 수 없습니다. 제한 시간 안에 어떤 단계가 완료되지 않았다는 의미일 뿐입니다. 주변 로그를 살펴 구독 다운로드, 대상 연결, 규칙 리소스 업데이트, 노드 테스트 중 어디서 발생했는지 판단하세요. 관련 없는 복구 방법을 적용하지 않도록 주의해야 합니다.

일시적으로 로그 상세도를 높이면 문제를 재현하는 데 도움이 되지만, 디버그 로그를 장기간 활성화하지 마세요. 상세 로그에는 접속 도메인, 대상 주소, 정책 선택 정보가 기록될 수 있으므로 공유 전에 민감한 내용을 삭제해야 합니다. 문제를 문의할 때는 운영체제, 클라이언트 이름, 사용 중인 기능, 오류 발생 시각, 최소 재현 절차를 제공하면 충분합니다. 구독 원본 링크, 노드 인증 정보, 제어 인터페이스 전체 설정은 공유하지 마세요. 스크린샷에 주소 표시줄, 사이드바, 알림 내용이 포함되어 개인정보가 노출되지 않는지도 확인하세요.

실행 가능한 복구 순서 만들기

규칙을 수정한 뒤 문제가 생기면 마지막으로 추가한 규칙 묶음을 먼저 되돌리고 다시 불러오세요. 구독 업데이트 후 문제가 생겼다면 그룹 선택과 새 필드를 확인한 뒤 필요할 경우 이전 백업을 복원하세요. TUN 활성화 후 문제가 생기면 먼저 TUN을 끄고 시스템 프록시 경로가 정상인지 확인하세요. 클라이언트가 비정상 종료된 뒤 인터넷이 끊겼다면 Windows에 로컬 프록시 설정이 남아 있는지 점검하세요. 복구는 이전에 검증한 상태로 되돌리는 과정이지 보안 기능을 무작정 전부 끄는 일이 아닙니다.

시작 프로그램 등록은 안정화된 뒤에 설정하는 것이 좋습니다. 기기를 재부팅해 서비스, 인터페이스, 프록시 설정의 시작 순서가 예상과 맞는지 확인하세요. 시스템 프록시가 먼저 복원되고 코어는 아직 수신을 시작하지 않았다면 부팅 초기에 잠시 접속 오류가 발생할 수 있습니다. 절전 모드에서 복귀하거나 네트워크를 전환하는 상황도 별도로 테스트해야 합니다. 네트워크 인터페이스와 라우팅이 바뀔 수 있기 때문입니다. 절전 해제 후에만 문제가 생긴다면 반복해서 재설치하는 것보다 당시 로그를 보관하는 편이 도움이 됩니다.

노드를 자주 바꾸는 일을 일상적인 관리 방법으로 삼지 마세요. 규칙과 출구가 올바른지 먼저 확인한 뒤 필요할 때 사용 가능한 노드로 변경하세요. 한 번의 속도 테스트만으로 모든 선택지를 삭제하지도 마세요. 추가로 문제를 확인하려면 도움말 센터에서 증상에 맞는 항목을 찾고 민감한 정보를 제거한 오류 내용을 함께 정리하세요. 관리의 목표는 불확실한 변경을 줄이고 ‘마지막으로 작동했던 상태’를 설명하고 복구할 수 있도록 하는 것입니다.

9. 고급 설정과 학습 과정

최종 실행 설정부터 이해하기

앞의 8개 장을 마쳤다면 고급 설정의 첫 단계는 필드를 더 추가하는 것이 아니라 클라이언트가 코어에 전달하는 최종 설정을 이해하는 것입니다. 원본 구독, 로컬 오버라이드, 실행 결과를 비교해 수신 포트, 프록시 그룹, 규칙, DNS가 각각 어디서 오는지 확인하세요. 작은 변경 하나를 저장하고 합성 결과에서 해당 설정의 위치를 살펴본 뒤 동작을 검증하세요. 특정 필드가 어디서 생성되는지 설명할 수 없다면 중요한 업무에 의존하지 않는 편이 좋습니다.

두 번째 단계는 정책 그룹의 동작을 익히는 것입니다. 수동 선택 그룹은 출구를 직접 지정할 때 적합하고, 자동 테스트나 대체 그룹은 테스트 조건에 따라 항목을 선택합니다. 테스트 주소, 간격, 허용 오차, 지연 테스트 설정이 결과에 영향을 줍니다. 그룹 이름에 ‘자동’이 있다고 해서 모든 작업에 최적이라는 뜻은 아닙니다. 중요하지 않은 트래픽 한 종류에서 먼저 검증한 다음 적용 범위를 넓히세요. 자동 정책으로 인한 변화를 파악할 수 있도록 수동으로 되돌릴 수 있는 선택 그룹을 유지하세요.

리소스와 조회 정책 나누어 살펴보기

세 번째 단계에서는 proxy-providers와 rule-providers를 살펴보세요. 전자는 프록시 리소스를, 후자는 규칙 리소스를 관리하며 참조 관계와 업데이트 방식도 서로 다릅니다. 리소스를 분리하면 설정 중복을 줄일 수 있지만 경로, 캐시, 원격 다운로드에 대한 의존성이 늘어납니다. 각 리소스가 실패할 때 어떤 현상이 나타나는지 확인하고 캐시가 없는 첫 실행에서도 설정을 불러올 수 있는지 검증하세요. 로컬에 캐시가 있는 상태에서만 테스트해 신뢰성을 판단하지 마세요.

네 번째 단계에서는 DNS를 세부적으로 살펴보세요. 시스템, 브라우저, 코어, 원격 서버가 각각 어느 단계에서 이름을 조회하는지 정리하고 앱 자체의 암호화 DNS 사용 여부를 확인하세요. 이어서 도메인별 조회 서버 선택, 직접 연결 도메인의 조회, 프록시 서버 주소 조회와 관련된 설정을 익히세요. 필드마다 서로 의존할 수 있으므로 조합이 잘못되면 조회 순환이 발생할 수 있습니다. 예를 들어 프록시 서버 주소를 가져오려면 프록시 연결이 필요한데, 프록시 연결을 위해서는 먼저 해당 주소를 조회해야 하는 상황이 생길 수 있습니다.

조회 순환이 발생하면 먼저 검증된 경로로 돌아간 뒤 정책을 하나씩 추가하세요. 공개 DNS 주소를 긴 목록으로 무작정 섞지 마세요. 주소가 많다고 호환성이 입증되는 것은 아닙니다. 내부 도메인에는 보통 조직에서 제공하는 조회 환경이 필요하며 공용 DNS 서비스는 해당 레코드를 알지 못할 수 있습니다. 웹페이지는 열리지만 업무 리소스가 조용히 실패하지 않도록 라우팅 출구, DNS 선택, 로컬 네트워크 접근을 함께 확인하세요.

마지막으로 인터페이스·스크립트·로컬 네트워크 공유 검토하기

제어 인터페이스는 클라이언트나 관리 도구가 코어와 통신하기 위한 것으로, 일반 앱에서 사용하는 프록시 포트가 아닙니다. external-controller를 설정할 때는 먼저 로컬 기기에서만 접근하도록 제한하고 인증 방식과 수신 범위를 이해한 뒤에만 확장을 검토하세요. 관리 편의를 위해 인터넷에 직접 공개하지 마세요. 제어 인터페이스 포트를 HTTP 프록시 포트처럼 브라우저에 입력해서도 안 됩니다. 설정을 변경할 수 있는 인터페이스는 일반 웹페이지가 아니라 관리 진입점으로 취급해야 합니다.

로컬 네트워크 공유에는 allow-lan, 바인딩 주소, Windows 방화벽 설정도 관련됩니다. 토글 하나를 켠다고 다른 기기에서 사용할 수 있다고 보장할 수 없으며 접근 범위가 의도치 않게 넓어질 수도 있습니다. 공유가 필요하면 신뢰할 수 있는 네트워크, 접속 기기, 포트를 먼저 제한한 뒤 다른 기기에서 검증하세요. 공용 Wi-Fi, 게스트 네트워크, 조직 네트워크에서는 수신을 함부로 허용하지 마세요. 테스트가 끝나면 노출 범위를 최소화해 잊고 끄지 않은 진입점이 남지 않도록 하세요.

확장 스크립트와 설정 오버라이드는 반복 작업을 줄이는 데 유용하지만 실행 가능한 로직이므로 출처와 변경 범위를 먼저 검토해야 합니다. 대상 필드만 조정하고 정책 그룹을 삭제하거나 DNS를 변경하거나 제어 인터페이스의 수신 범위를 넓히지 않는지 확인하세요. 구독을 바꾼 뒤에도 다시 검증해야 합니다. 스크립트가 특정 그룹 이름에 의존할 수 있기 때문입니다. 그룹 이름이 바뀌면 스크립트가 실행되더라도 결과가 올바르다는 보장은 없습니다. 스크립트가 없는 기준 설정을 비교용으로 보관하세요.

마지막으로 학습 흐름을 완성하세요. 입문 가이드에서 가장 짧은 연결 절차를 다시 확인하고, 이 가이드로 동작 원리를 이해한 뒤 로그와 연결 페이지에서 가설을 검증하세요. 장기간 유지할 변경 사항은 관리 가능한 오버라이드에 기록하세요. 일반 데스크톱 사용자는 당장 독립 코어 설치로 전환할 필요가 없습니다. 서버, 라우터, 자동화 관리가 실제로 필요할 때 서비스 관리, 파일 권한, 네트워크 경계를 추가로 익히면 됩니다. 설정이 복잡할수록 단순하고 검증되었으며 복구 가능한 경로를 유지해야 합니다.