Clash 초보자부터 고급 설정까지

1. 핵심 개념과 연결 경로

클라이언트, 커널, 서비스의 역할

Clash 생태계에서 쓰이는 이름이 모두 같은 소프트웨어 계층을 가리키는 것은 아닙니다. 클라이언트는 보통 창 표시, 설정 관리, 시스템 프록시 변경, 백그라운드 서비스 실행을 담당합니다. 커널은 로컬 포트를 열고 규칙을 해석해 외부 연결을 설정합니다. mihomo는 지속적으로 개발 중인 프록시 커널이며, 관련된 과거 자료를 살펴볼 때 Clash Meta라는 이름도 자주 접하게 됩니다. 그래픽 클라이언트를 설치한 뒤 화면이 열린다고 해서 프런트엔드 프로그램이 실행 중이라는 사실만 확인된 것입니다. 커널이 시작되었거나 구독이 정상 작동한다고 단정할 수는 없습니다.

구독은 원격 설정이나 노드 정보를 제공하며, 노드는 프록시 서버에 연결하는 데 필요한 주소, 프로토콜, 인증 매개변수를 설명합니다. 클라이언트를 설치했다고 바로 사용할 수 있는 연결이 생기는 것은 아닙니다. 연결의 유효 기간, 트래픽 한도, 서비스 품질은 해당 서비스에서 결정합니다. 구독을 가져오기 전에 출처를 신뢰할 수 있고 사용 권한이 있는지 확인하세요. 로그나 화면 캡처를 공유할 때는 구독 링크에 접근 자격 증명이 포함될 수 있다는 점도 유의해야 합니다. 일반 웹 주소처럼 공개 게시해서는 안 됩니다.

웹 접속 과정을 네 단계로 나누어 보기

웹 접속은 진입, 판단, 이름 해석, 외부 연결의 네 단계로 나눠 이해할 수 있습니다. 진입 단계에서는 앱 트래픽이 커널로 들어오는지 결정하고, 판단 단계에서는 어떤 규칙과 정책 그룹을 사용할지 정합니다. 이름 해석 단계에서는 도메인을 연결에 필요한 주소로 변환하며, 외부 연결 단계에서는 직접 연결, 프록시 또는 차단을 수행합니다. 실제 흐름에서는 DNS 모드, 도메인 스니핑, 연결 유형이 서로 영향을 주지만, 이 네 가지 질문은 문제 해결에 도움이 됩니다. 브라우저에서 페이지가 열리지 않는다면 모든 DNS 필드를 바로 바꾸기보다 먼저 트래픽이 커널에 들어오는지 확인하세요.

DIRECT는 기기 자체의 네트워크로 대상에 직접 연결한다는 뜻이고, REJECT는 해당 연결을 차단한다는 뜻입니다. 정책 그룹은 하나 이상의 프록시 노드를 가리킬 수 있습니다. 규칙 모드에서는 웹사이트마다 다른 경로를 사용할 수 있으므로, 로컬 주소와 프록시 출구 주소가 함께 보이더라도 반드시 이상한 것은 아닙니다. 반대로 전역 모드에서 DIRECT를 선택하면 커널에 들어온 연결이 모두 직접 연결될 수도 있습니다. 동작을 판단할 때는 현재 모드, 실제로 적용된 규칙, 최종 외부 연결을 함께 확인해야 합니다. 창에 표시된 연결 상태만으로는 충분하지 않습니다.

반복해서 검증할 수 있는 방법 마련하기

예상 결과가 명확한 접속 대상 두 개를 준비하세요. 하나는 직접 연결되어야 하고, 다른 하나는 프록시를 통해 연결되어야 합니다. 연결 패널을 열어 대상 도메인, 적용된 규칙, 정책 그룹, 최종 노드를 기록한 다음 페이지가 로드되는지 확인합니다. 웹사이트에 표시되는 출구 주소 하나만 보고 모든 앱의 연결 경로를 추정하지 마세요. 브라우저 캐시, 앱의 프록시 설정, IPv6, 연결 프로토콜에 따라 결과가 달라질 수 있습니다. 검증의 핵심은 단편적인 속도 수치를 모으는 것이 아니라 요청과 커널 기록을 대응시키는 것입니다.

설정도 이 연결 경로에 맞춰 익혀야 합니다. 먼저 노드 연결을 확인하고, 다음으로 앱 트래픽이 프록시에 들어오는지 확인한 뒤 규칙과 DNS를 세부 조정하세요. 앞 단계가 해결되지 않은 상태에서 규칙을 추가하면 변수만 늘어납니다. 클라이언트 이름, 시스템 아키텍처, 리스닝 포트, 트래픽 처리 방식, 검증 결과를 적은 로컬 설정 기록을 만들어 두는 것이 좋습니다. 구독과 인증 정보가 포함된 원본은 별도로 보관하고, 공개 가능한 문제 해결 자료에는 넣지 마세요.

2. 플랫폼과 유지 관리 방식에 맞는 클라이언트 선택

클라이언트를 고른 뒤 기능 범위를 확인하세요

처음 사용한다면 먼저 Clash Plus를 살펴보고, 플랫폼과 필요 기능에 따라 다른 클라이언트와 비교해 보세요. 운영체제와 프로세서 아키텍처를 우선 확인하고, 구독 관리, 시스템 프록시, TUN, 로그 내보내기, 설정 덮어쓰기 기능이 필요한지 살펴보세요. 인터페이스에 스위치가 있다고 해서 모든 운영체제에서 같은 방식으로 작동하는 것은 아닙니다. 권한, 백그라운드 실행, 시스템 네트워크 인터페이스에 따라 같은 클라이언트라도 플랫폼별 동작이 달라질 수 있습니다. 특정 기능이 필요하다면 설치 후 실제 연결로 검증하세요.

Windows에서는 Clash Plus, Clash Verge Rev, FlClash, Clash Nyanpasu를 비교해 볼 수 있습니다. Clash for Windows는 유지 관리가 중단된 아카이브용 선택지입니다. macOS에서는 Clash Plus, Clash Verge Rev, FlClash를 비교할 수 있으며 ClashX Meta도 아카이브용 선택지입니다. 아카이브된 소프트웨어는 이전 가이드를 이해하거나 설정을 이전하는 데 쓸 수 있지만, 초보자가 장기간 사용할 기본 클라이언트로는 적합하지 않습니다. 구버전 화면 캡처, 버튼 위치, 설정 옵션을 현재 클라이언트의 사용 방법으로 그대로 적용해서도 안 됩니다.

Android에서는 Clash Plus, Clash Meta for Android, FlClash, Surfboard를 살펴볼 수 있습니다. iOS에서는 Clash Plus를 확인해 보세요. 공식 사이트는 clashplus.io입니다. Linux에서는 Clash Verge Rev와 FlClash를 우선 비교할 수 있습니다. 이 목록은 설정 호환성을 보장하지 않습니다. 특히 Surfboard 설정과 mihomo YAML은 그대로 함께 사용할 수 없습니다. 설치 경로는 다운로드 페이지에서 확인하고, 플랫폼을 먼저 선택한 다음 앱을 고르세요.

아키텍처, 배포 형식, 실행 권한 구분하기

프로세서 아키텍처에 따라 프로그램 실행 여부가 결정되고, 배포 형식에 따라 설치 방법이 달라집니다. Windows에서는 주로 x64와 ARM64를 구분하고, macOS에서는 Apple Silicon과 Intel을 확인해야 합니다. Android에서는 ARM64와 구형 ARM 환경을 구분하세요. Linux의 DEB와 RPM은 배포판별 패키지 형식으로, 설치 명령이 서로 통용된다는 뜻은 아닙니다. 데스크톱 시스템에서 호환 실행이 가능하더라도 아키텍처에 맞는 패키지를 우선 선택하면 서비스 구성 요소와 가상 네트워크 인터페이스의 차이를 줄일 수 있습니다.

그래픽 클라이언트와 독립 커널 중 선택

독립 mihomo 커널은 서버, 라우터, 시스템 서비스에 익숙한 사용자에게 적합합니다. 설정을 읽고 프록시 리스너를 제공할 수 있지만, 데스크톱 트레이 아이콘, 구독 편집기, 시스템 프록시 버튼이 자동으로 생기지는 않습니다. 독립 커널을 사용한다면 프로세스 재시작, 파일 권한, 서비스 시작 순서, 로그 저장 방식을 직접 계획해야 합니다. 일반 데스크톱 사용자는 그래픽 인터페이스로 작동 흐름을 익힌 뒤 명령줄 환경으로 옮기는 편이 좋습니다. 네트워크 설정과 서비스 관리라는 두 가지 체계를 동시에 익히는 부담을 줄일 수 있습니다.

클라이언트를 옮길 때는 기존 구독 출처, 정책 그룹 선택, 필요한 덮어쓰기 규칙만 유지하고 이전 프로그램의 데이터 디렉터리 전체를 복사하지 마세요. 클라이언트마다 데이터 구조, 암호화 저장 방식, 서비스 설정이 호환되지 않을 수 있습니다. 새 클라이언트에서 설정을 다시 가져와 기본 동작을 검증한 뒤 사용자 지정 규칙을 조금씩 옮기는 것이 안전합니다. 이전하는 동안 시스템 프록시나 터널을 한 번에 하나만 사용하세요. 기존 클라이언트를 종료했는데 시스템 프록시 설정이 남아 있다면 시스템 네트워크 설정에서도 확인해야 합니다.

3. 설치, 권한, 최소 실행 기준

설치 전에 트래픽 처리 충돌 정리하기

다운로드 페이지에서 운영체제와 아키텍처에 맞는 설치 파일을 선택하고, 클라이언트가 안내하는 일반적인 설치 절차를 따르세요. 처음 실행하기 전에 프록시나 라우팅을 변경하는 다른 도구를 종료하고, 시스템에 이전 프록시 주소가 남아 있는지 확인합니다. 회사 기기, 학교 네트워크, 관리되는 컴퓨터에서는 가상 네트워크 인터페이스나 백그라운드 서비스 설치가 제한될 수 있습니다. 관리 정책을 우회해 설정을 강제로 변경하지 마세요. 일반 인터페이스는 실행되지만 서비스 설치가 실패한다면 설치를 반복하기보다 권한 안내와 시스템 제한부터 확인하세요.

Windows에서는 백그라운드 커널이나 TUN에 서비스 모드와 관리자 권한이 필요할 수 있습니다. macOS에서는 네트워크 관련 권한을 확인해야 할 수 있고, 모바일 운영체제에서는 VPN 설정 생성에 대한 사용자 동의가 일반적으로 필요합니다. 여기서 VPN이라는 표시는 시스템이 해당 네트워크 트래픽 처리 인터페이스를 사용한다는 뜻일 뿐, 원격 프로토콜을 특정하지는 않습니다. 필요한 경우에만 클라이언트의 안내에 따라 권한을 허용하세요. 시스템에서 앱 출처나 서명에 문제가 있다고 알리면 다운로드 출처와 보안 안내를 확인해야 합니다. 시스템 보호를 끄는 것을 일반적인 설치 절차로 삼지 마세요.

복잡한 설정을 가져오기 전에 로컬 리스너부터 확인하기

최소 실행 기준에는 로컬 리스너, 규칙 모드, 명확한 직접 연결 경로만 있으면 됩니다. 아래 설정은 독립 커널의 로컬 테스트용이며 프록시 노드를 포함하지 않으므로 원격 프록시 연결을 검증할 수 없습니다. 그래픽 클라이언트는 리스닝 포트와 제어 인터페이스를 직접 관리할 수 있으니 가져온 뒤 실제 적용 설정에서 해당 필드가 덮어써졌는지 확인하세요. 테스트의 목표는 커널이 설정을 정상적으로 읽고, 로컬 프록시를 명시적으로 사용한 요청 하나가 연결 기록에 나타나게 하는 것입니다.

mixed-port: 7890
allow-lan: false
bind-address: 127.0.0.1
mode: rule
log-level: info

rules:
  - MATCH,DIRECT

mixed-port는 하나의 리스닝 포트에서 HTTP와 SOCKS 프록시 연결을 모두 받습니다. 원격 서버 포트가 아닙니다. allow-lan: false는 로컬 네트워크 공유를 제한하므로, 로컬 테스트에서는 다른 기기에 프록시를 노출할 필요가 없습니다. 리스닝 주소와 허용할 출처는 시스템 방화벽의 영향도 받으므로 필드 하나만으로 접근 제어가 완성되지는 않습니다. 나중에 로컬 네트워크 공유가 필요하다면 허용 기기, 네트워크 범위, 방화벽 규칙을 별도로 명확히 정하세요.

포트와 설정 문법 확인하기

독립 커널을 사용한다면 먼저 아래 설정 검사 명령을 실행할 수 있습니다. 실행 파일 이름과 경로는 실제 설치 위치에 맞게 지정해야 합니다. 검사를 통과했다는 것은 설정을 해석할 수 있다는 뜻이지, 구독에 있는 원격 서버에 연결할 수 있다는 뜻은 아닙니다. YAML에는 공백을 사용해 들여쓰고 같은 단계의 필드는 정렬을 맞추세요. 목록 항목에는 하이픈을 유지합니다. 문서의 일부를 복사할 때 들여쓰기가 탭으로 바뀌지 않도록 주의하고, 기존 설정에 같은 이름의 최상위 필드를 두 번 만들지 마세요. 한쪽 설정이 덮어써지거나 모호해질 수 있습니다.

mihomo -t -f config.yaml
curl -I -x http://127.0.0.1:7890 https://example.com

시작 로그에 포트 충돌이 표시되면 사용 중인 프로세스를 확인한 뒤 기존 프로그램을 종료할지 리스닝 포트를 바꿀지 결정하세요. 포트를 변경한 뒤에는 시스템 프록시, 브라우저 확장 프로그램, 터미널 환경 변수의 포트도 맞춰야 합니다. Windows에서는 netstat -ano | findstr :7890을 실행해 관련 연결을 확인할 수 있습니다. 프로세스 번호로 해당 앱을 추가 확인하고, 출처를 모르는 시스템 프로세스를 바로 종료하지 마세요. 자세한 해결 방법은 포트 충돌 및 mixed-port 변경 안내를 참고하세요.

4. 구독 가져오기, 적용 설정, 덮어쓰기

구독 내용과 가져오기 결과 확인하기

클라이언트의 설정 또는 구독 관리 화면에서 원격 주소를 추가하고, 알아보기 쉬운 이름을 입력한 다음 다운로드나 업데이트를 실행하세요. 가져오기가 끝나면 해당 설정이 현재 설정으로 선택되었는지 확인하고 프록시 노드와 정책 그룹이 표시되는지 살펴보세요. 제공처에 따라 전체 YAML, 노드 목록만 포함된 데이터, 다른 소프트웨어용 형식이 반환될 수 있습니다. 서버 응답이 성공했다고 해서 현재 클라이언트에 맞는 내용이라는 뜻은 아닙니다. 가져온 뒤 구문 오류가 발생하면 먼저 제공처의 형식과 구독 안내를 확인하세요.

구독 오류는 다운로드 실패와 구문 분석 실패로 나눠 살펴보세요. 다운로드 실패는 대개 시간 초과, 인증서 문제, 인증 만료, 서버 거부로 나타납니다. 구문 분석 실패는 웹페이지가 반환되거나 형식이 호환되지 않거나 필드에 문제가 있을 때 발생할 수 있습니다. 먼저 클라이언트에서 구체적인 오류를 확인하고, 구독 주소를 출처가 불분명한 온라인 변환 사이트에 입력하지 마세요. 링크의 쿼리 매개변수는 계정 권한을 포함할 수 있습니다. 오류 화면을 공유할 때는 전체 주소와 노드 인증 정보를 가리고, 문제 유형을 파악하는 데 필요한 부분만 남기세요.

실제로 적용되는 설정 계층 찾기

그래픽 클라이언트에는 원본 구독, 로컬 덮어쓰기, 실행 중인 최종 설정이 함께 존재하는 경우가 많습니다. 원본 구독은 다운로드한 내용이고, 덮어쓰기는 포트, DNS, 규칙 등을 추가합니다. 최종 설정은 커널이 실제로 읽는 결과입니다. 인터페이스에서 스위치를 변경했다면 실행 중인 설정에도 반영되었는지 확인하세요. 캐시 파일을 직접 편집하면 다음 업데이트 때 덮어써질 수 있습니다. 설정이 계속 원래대로 돌아간다면 같은 임시 파일을 반복해서 수정하지 말고 변경한 위치부터 확인하세요.

계속 유지할 사용자 설정은 클라이언트가 명시적으로 지원하는 덮어쓰기 또는 병합 기능에 두는 것이 좋습니다. 배열을 처리하는 방식은 클라이언트마다 크게 다릅니다. 일부는 목록 전체를 교체하고, 일부는 앞이나 뒤에 항목을 추가할 수 있으므로 병합 후에도 기존 규칙이 유지된다고 가정하지 마세요. 특히 rules, proxy-groups, dns.nameserver를 통째로 바꾸면 구독에서 제공한 구조가 사라질 수 있습니다. 덮어쓰기를 처음 적용하기 전에 백업하고, 최종 설정에서 필드 순서를 확인하세요.

참조 관계를 유지하며 구독 업데이트하기

규칙은 정책 그룹을 참조하고, 정책 그룹은 노드나 제공자를 참조하므로 이름이 바뀌면 참조 관계에 영향을 줍니다. 원격 업데이트로 노드가 삭제되었는데 로컬에서 작성한 정책 그룹이 이전 이름을 참조하고 있으면 설정을 불러오지 못하거나 정책을 선택할 수 없게 될 수 있습니다. 제공자가 자주 변경하는 개별 노드 이름보다 안정적인 정책 그룹 이름을 로컬 규칙에서 참조하는 편이 좋습니다. 아래 예시는 구조 설명용이며 전체 프록시 설정이 아닙니다. “프록시 출구”라는 정책 그룹은 실제 설정에 정의되어 있어야 합니다.

rules:
  - DOMAIN-SUFFIX,example.com,프록시 출구
  - DOMAIN-SUFFIX,lan,DIRECT
  - MATCH,DIRECT

업데이트 전에 현재 사용할 수 있는 정책 선택을 기록하고, 업데이트 뒤 노드와 규칙을 다시 검증하세요. 자동 업데이트 간격을 지나치게 짧게 설정해도 서버 할당량 초과나 인증 만료는 해결되지 않으며, 오히려 접근 제한이 발생할 수 있습니다. 새 구독 다운로드에 실패하면 장애 중에 기존 설정을 모두 지우지 말고 마지막으로 정상 작동한 설정을 우선 보존하세요. 클라이언트에서 설정 기록을 지원한다면 어떤 버전으로 되돌릴 수 있는지 확인하고, 최신 결과만 저장한다면 필요한 로컬 백업을 별도로 보관하세요.

구독 변환은 제공 형식과 대상 형식이 다를 때만 필요합니다. 변환 과정에서 프로토콜 매개변수, 규칙 집합, DNS 동작이 완전히 유지된다는 보장은 없습니다. 변환이 끝난 뒤에도 구문 검사와 연결 검증을 해야 합니다. “변환 성공”을 실제 동작 결과로 대신할 수는 없습니다. 일상적인 관리에서는 구독 업데이트와 노드 변경도 구분하세요. 전자는 설정 데이터를 바꾸고, 후자는 현재 외부 연결 선택만 변경합니다. 기본 절차는 입문 가이드의 구독 가져오기 안내를 참고해 단계별로 확인하세요.

5. 프록시 모드, 시스템 프록시, 실제 트래픽 처리

규칙, 전역, 직접 연결 모드의 차이

규칙 모드는 설정에 적힌 매칭 순서에 따라 외부 연결 경로를 결정하며, 일상적인 트래픽 분기의 기본 모드입니다. 전역 모드에서는 커널에 들어온 연결을 전역 정책에 따라 처리하므로, 특정 경로로 대상에 접속할 수 있는지 임시로 확인할 때 유용합니다. 직접 연결 모드는 커널에 들어온 연결을 기기의 네트워크로 보냅니다. 세 모드는 커널에 들어온 트래픽의 처리 방식을 바꾸지만, 트래픽을 커널로 전달하는 진입 경로를 대신하지는 않습니다. 앱이 커널을 거치지 않는다면 모드를 바꿔도 연결은 대개 달라지지 않습니다.

첫 연결에서는 정책 그룹에서 특정 노드를 선택한 뒤 규칙 모드로 검증하세요. 대상에 연결되지 않으면 잠시 전역 모드로 전환하고 같은 노드를 명확히 선택해 연결 패널의 결과를 비교합니다. 전역 모드에서는 되지만 규칙 모드에서는 실패할 때 규칙과 그룹 선택을 우선 점검할 이유가 있습니다. 두 모드 모두 실패한다면 노드, 네트워크, 이름 해석을 계속 확인하세요. 비교가 끝나면 원래 모드로 되돌리세요. 임시 진단 상태를 일상 설정으로 남기면 직접 연결되어야 할 서비스까지 프록시를 거칠 수 있습니다.

시스템 프록시는 설정을 따르는 앱에만 적용됩니다

시스템 프록시는 보통 운영체제가 지원하는 프록시 설정을 로컬 리스닝 주소로 지정합니다. 브라우저나 해당 설정을 따르는 데스크톱 앱에서 주로 사용합니다. 일부 터미널 프로그램, 게임, 자체 네트워크 스택을 사용하는 소프트웨어, 백그라운드 서비스는 이 설정을 자동으로 읽지 않습니다. 그러므로 브라우저에서는 되지만 명령줄에서는 실패하더라도 노드 문제라고 바로 단정할 수 없습니다. 터미널 도구의 명시적 프록시 매개변수 지원 여부를 확인하고, 먼저 진입 경로를 지정해 테스트한 다음 환경 변수나 TUN으로 처리 범위를 넓힐지 결정하세요.

curl -I -x http://127.0.0.1:7890 https://example.com
curl -I --proxy socks5h://127.0.0.1:7890 https://example.com

위의 두 명령은 서로 다른 프록시 진입 방식을 사용합니다. socks5h는 현재 도구가 로컬에서 먼저 도메인을 해석하는 대신 프록시 측에서 대상 도메인을 해석한다는 뜻입니다. 이후 실제 DNS 경로는 커널 설정에 따라 달라집니다. 명시적 프록시 테스트가 성공하면 프로그램 자체의 프록시 옵션을 확인하세요. 환경 변수를 인식하는 방식은 프로그램마다 다릅니다. 일부 도구는 소문자 변수를 읽고, 일부는 자체 설정으로 이를 덮어쓸 수도 있습니다. 하나의 환경 변수 설정이 모든 명령줄 앱에 적용된다고 일반화하지 마세요.

연결 기록으로 트래픽 진입 문제 확인하기

대상에 접속할 때 연결 패널에 기록이 전혀 없다면 시스템 프록시가 켜져 있는지, 리스닝 포트가 일치하는지, 앱에 우회 주소가 설정되어 있는지, 다른 프록시 확장 프로그램이 있는지 먼저 확인하세요. 기록은 있지만 DIRECT가 적용되었다면 모드와 규칙을 살펴보세요. 프록시가 적용되었는데 실패했다면 연결 오류와 원격 상태를 확인합니다. 화면 갱신이나 너무 짧은 연결 때문에 기록을 놓칠 수 있으므로 필요한 경우 잠시 로그를 관찰하되, 처음부터 상세 로그를 오래 켜 두지는 마세요.

사용을 마칠 때는 시스템 프록시를 끄거나 클라이언트 종료 시 자동 복구되는지 확인한 다음 커널을 종료하세요. 프로세스는 종료됐는데 시스템 프록시가 로컬 포트를 계속 가리키면 해당 설정을 따르는 앱은 더 이상 존재하지 않는 리스너에 접속해 인터넷이 전반적으로 끊긴 것처럼 보일 수 있습니다. 모바일 기기에서는 시스템 VPN 설정이 여전히 연결 상태인지도 확인하세요. 진입 방식의 차이는 TUN 모드와 시스템 프록시의 차이를 참고하세요. “전역 모드”와 “시스템 전체 트래픽 처리”는 같은 뜻이 아닙니다.

6. 규칙 순서, 정책 그룹, 규칙 집합

먼저 일치하는 규칙이 외부 연결을 결정합니다

규칙은 순서대로 확인하며 일반적으로 처음 일치한 규칙에 따라 처리 방향이 결정됩니다. 구체적인 예외 규칙은 범위가 넓은 규칙보다 앞에, 최종 대체 규칙은 맨 뒤에 둡니다. DOMAIN은 완전한 도메인 하나와 일치하고, DOMAIN-SUFFIX는 지정 도메인과 하위 도메인에 일치합니다. IP-CIDR은 대상 주소 범위에 적용되며, MATCH는 앞선 규칙에 일치하지 않은 연결을 처리합니다. 규칙 종류마다 필요한 정보가 다르므로 도메인을 확인할 수 없는 상황에서는 도메인 규칙만으로 기대한 결과를 얻지 못할 수 있습니다.

아래는 규칙 순서와 그룹 참조를 이해하기 위한 독립 실행형 직접 연결 예시입니다. 원격 프록시 기능은 제공하지 않습니다. 현재 “일상 연결” 그룹에는 DIRECT만 있으므로 허용된 연결은 모두 기기의 네트워크를 사용합니다. 실제 설정에서는 노드나 제공자가 있어야 해당 이름을 정책 그룹에 추가할 수 있습니다. 그룹 정의를 빠뜨리고 참조 규칙만 복사하지 마세요. 커널이 설정을 불러올 때는 이름을 완전한 의존 관계로 해석해야 합니다.

mixed-port: 7890
allow-lan: false
mode: rule
log-level: info

proxy-groups:
  - name: 일상 연결
    type: select
    proxies:
      - DIRECT

rules:
  - DOMAIN,example.com,일상 연결
  - DOMAIN-SUFFIX,localhost,DIRECT
  - IP-CIDR,127.0.0.0/8,DIRECT,no-resolve
  - IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
  - MATCH,일상 연결

정책 그룹은 규칙과 노드를 잇는 안정적인 인터페이스입니다

수동 선택 그룹은 동작을 이해하기 쉽게 구성하는 데 적합합니다. 규칙은 고정된 그룹을 가리키고, 사용자는 그룹 안에서 연결 경로를 바꿉니다. 자동 속도 측정 그룹은 테스트 결과에 따라 노드를 선택하지만, 테스트 주소와 시간 초과, 검사 주기에 따라 선택 결과가 달라집니다. 측정값은 주로 요청 연결과 응답 과정을 반영하며 파일 다운로드 속도와 같지 않고 모든 대상에 최적이라는 보장도 없습니다. 연결 경로를 바꾸면 로그인 상태나 원격 세션에 영향을 줄 수 있으므로 자동 선택이 잦을수록 좋은 것은 아닙니다. 실제 앱에서 동작을 확인하세요.

no-resolve는 일부 IP 규칙에서 해당 규칙을 판단하기 위해서만 도메인 이름을 해석하지 않도록 합니다. 클라이언트 전체 DNS를 끄는 옵션은 아닙니다. 연결에 대상 IP가 이미 포함되어 있다면 이를 기준으로 계속 매칭할 수 있습니다. 이 매개변수를 추가하기 전에 규칙이 어떤 역할을 맡는지 먼저 정하세요. 이미 있는 주소만 처리할 것인지, 도메인도 해석한 뒤 판단할 것인지 확인해야 합니다. 모든 주소 규칙에 기계적으로 같은 매개변수를 붙이면 원래 의도와 다르게 작동할 수 있습니다.

규칙 집합 관리와 업데이트 범위

규칙 제공자를 사용하면 규칙을 별도 파일이나 원격 출처로 분리하고, 주 설정에서 RULE-SET으로 참조할 수 있습니다. 도메인 목록과 일반 규칙 행은 입력 형식이 다르므로 제공자의 동작 유형과 콘텐츠 형식이 맞는지 확인하세요. 먼저 소규모 로컬 규칙으로 검증한 다음 신뢰할 수 있는 출처의 규칙 집합을 추가합니다. 규칙 집합 다운로드 실패, 오래된 캐시, 형식 불일치가 발생하면 주 설정의 구문 검사만 보지 말고 제공자 로드 기록을 확인하세요.

규칙을 추가한 뒤에는 대상 연결을 닫았다가 다시 요청해 검증하세요. 기존 장기 연결은 규칙 변경 직후 새 경로로 전환되지 않을 수 있고, 브라우저 캐시가 새 요청을 가릴 수도 있습니다. 문제를 해결할 때는 전체 규칙을 붙여 넣기보다 대상, 규칙, 그룹, 노드 네 항목을 기록하는 편이 효과적입니다. 규칙이 많다고 분기 정확도가 높아지는 것은 아닙니다. 중복되는 목록이 많아지면 이해와 유지 관리가 어려워집니다. 용도와 출처, 적용 순서를 설명할 수 있는 규칙만 장기적으로 유지하세요.

로컬 네트워크, 회사 내부망, 개발 환경은 별도로 테스트하는 것이 좋습니다. 사설 주소를 직접 연결하는 것은 대개 합리적이지만, 로컬 서비스가 사용자 지정 도메인, 별도 DNS, 특정 라우팅을 사용하는 경우 주소 규칙 하나만으로 해결되지 않을 수 있습니다. 내부망 예외를 추가할 때는 범위를 좁혀 다른 서비스의 경로까지 바꾸는 광범위한 도메인 접미사 규칙을 피하세요. 구체적인 규칙 문제가 있다면 고객 지원 센터에서 더 살펴보고, 민감 정보를 가린 매칭 정보를 함께 제공하세요.

7. TUN, DNS, 가상 네트워크 인터페이스

기본 프록시가 정상 작동한 뒤 TUN을 켜세요

TUN은 가상 네트워크 인터페이스와 라우팅을 통해 트래픽을 받아 시스템 프록시 설정을 따르지 않는 앱을 처리할 때 유용합니다. 그렇다고 모든 트래픽이 반드시 프록시를 거치는 것은 아닙니다. 시스템 라우팅, 제외 주소, 프로세스 권한, 다른 터널, 커널 제한이 여전히 결과에 영향을 줍니다. 켜기 전에 일반 프록시로 대상에 접속할 수 있는지 확인하고 현재 네트워크 상태를 기록하세요. 그렇지 않으면 노드, DNS, 가상 네트워크 인터페이스 문제가 동시에 발생해 추가 설정의 영향을 파악하기 어렵습니다.

데스크톱 클라이언트는 백그라운드 서비스를 설치하거나 권한 상승을 요청할 수 있고, 모바일 기기는 대개 시스템에서 제공하는 터널 인터페이스를 사용합니다. 활성화에 실패하면 먼저 권한과 서비스 상태를 확인하고, 그다음 인터페이스와 라우팅 로그를 살펴보세요. 회사 VPN, 가상 머신 네트워크, 컨테이너 브리지, 다른 프록시 터널이 라우팅 우선순위를 바꿀 수 있습니다. 테스트하는 동안 필요한 트래픽 처리 도구만 하나씩 사용하고, 반드시 유지해야 할 내부망 대상을 기록하세요. 원격 근무에 특정 터널이 필요하다면 복구 가능한 환경에서 단계별로 검증하세요.

DNS 리스너, 업스트림, 가로채기 이해하기

DNS 설정은 최소 세 계층으로 나눠 살펴봐야 합니다. 커널이 DNS 서비스를 제공하는지, 시스템이나 앱의 조회가 그 서비스로 들어오는지, 커널이 어떤 업스트림을 사용해 이름을 해석하는지 확인하세요. dns.enable을 켰다고 모든 조회가 자동으로 커널에 전달되는 것은 아닙니다. 아래는 TUN과 DNS의 연동을 설명하기 위한 병합용 설정 조각입니다. 기존에 사용 가능한 설정에 추가하고 클라이언트가 별도로 덮어쓰지 않도록 확인하세요. 이미 dns나 tun 구역이 있다면 최상위 키를 중복으로 추가하지 말고 필드를 병합하세요.

dns:
  enable: true
  listen: 127.0.0.1:1053
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  nameserver:
    - https://1.1.1.1/dns-query
    - https://dns.google/dns-query

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

예시 업스트림에 연결할 수 있는지는 현재 네트워크에 따라 달라지므로 모든 환경의 기본값으로 간주해서는 안 됩니다. 암호화 DNS 서버 주소에 도메인을 사용하면 서버 도메인 자체를 먼저 해석해야 할 수 있습니다. 이를 부트스트랩 해석 문제라고 합니다. dns-hijack의 포트 규칙도 앱에 내장된 모든 암호화 DNS를 처리하지 못합니다. 브라우저나 앱이 직접 만드는 HTTPS 이름 해석 연결은 DNS 이름을 사용한다는 이유만으로 일반적인 53번 포트 조회로 바뀌지 않습니다.

fake-ip의 역할과 호환성 검증

fake-ip 모드는 앱에 합성 주소를 반환하고, 커널은 이후 연결을 도메인 기준으로 처리할 수 있도록 주소와 도메인의 대응 관계를 저장합니다. 해당 주소 대역이 보인다고 곧바로 오류로 판단하지 마세요. 다만 일부 로컬 네트워크 탐색, 특수 인증, 실제 주소에 의존하는 앱은 예외 설정이 필요할 수 있습니다. 예외는 모든 도메인을 제외하지 말고 해당 앱에서 검증한 뒤 추가하세요. DNS 모드를 바꾸면 앱과 시스템에 이전 결과가 남아 있을 수 있으므로 필요하면 다시 연결하고 관련 캐시를 정리하세요.

DNS를 검증할 때는 해석 결과뿐 아니라 조회 경로와 최종 연결 경로도 확인해야 합니다. 출구 주소가 맞더라도 DNS 경로가 예상과 다를 수 있으며, 온라인 검사 페이지 하나의 결과가 모든 앱을 대표하지도 않습니다. IPv6는 별도로 확인해야 할 경로입니다. DNS 옵션 하나를 끈다고 시스템 IPv6가 비활성화되는 것은 아닙니다. IPv6를 사용하지 않으려면 설정 하나만 보고 전체 동작을 추측하지 말고 클라이언트, 시스템, 네트워크 측 동작을 명확히 확인하세요.

활성화한 뒤 브라우저, 터미널, 로컬 네트워크 서비스, 절전 모드 복귀, 네트워크 전환을 하나씩 테스트하세요. 인터넷이 전반적으로 끊기면 먼저 TUN을 끄고 정상 작동이 확인된 시스템 프록시 기준으로 복구한 다음 로그와 라우팅을 비교하세요. 노드, 업스트림, 네트워크 스택을 동시에 바꾸지 마세요. “연결됨”으로 표시되지만 접속되지 않는 문제의 단계별 확인 방법은 연결 후 웹페이지가 열리지 않을 때 확인할 항목을 참고하세요. 고급 트래픽 처리를 활성화하기 전에 복구 방법을 마련해 두어야 합니다.

8. 유지 관리, 백업, 문제 복구

프로그램, 커널, 구독을 구분해 관리하기

클라이언트 업데이트, 커널 업데이트, 구독 업데이트는 서로 다른 작업입니다. 클라이언트 업데이트는 인터페이스, 서비스 구성 요소, 설정 생성 방식을 바꿀 수 있습니다. 커널 업데이트는 필드 지원을 추가하거나 네트워크 동작을 조정할 수 있고, 구독 업데이트는 노드, 규칙, 정책 그룹을 바꿉니다. 문제가 발생하면 최근에 어느 계층이 바뀌었는지 먼저 돌아보세요. 모든 변화를 막연히 업데이트 탓으로 돌리지 마세요. 중요한 환경에서는 이 작업들을 되도록 나눠 진행하고, 각 작업을 마칠 때마다 기본 동작을 테스트하면 되돌릴 범위를 파악하기 쉽습니다.

백업에는 원본 구독 출처에 관한 안전한 기록, 사용자 지정 덮어쓰기, 중요한 정책 그룹 선택, 리스닝 포트, 트래픽 처리 방식이 포함되어야 합니다. 클라이언트 화면 캡처만으로는 설정을 복구하기 어렵고, 데이터 디렉터리 전체를 복사하면 캐시, 이전 서비스 상태, 기기별 경로까지 들어갈 수 있습니다. 필요한 설정과 임시 데이터를 분리하고 접근 제어가 적용된 위치에 백업하세요. 클라우드나 다른 기기에 동기화하기 전에 구독 주소, 노드 인증 정보, 제어 인터페이스 정보가 해당 동기화 범위에 포함되어도 되는지 확인하세요.

정해진 순서로 이상 원인 찾기

기기 네트워크, 커널 프로세스, 설정 로드, 트래픽 진입, 규칙 판단, DNS, 원격 노드 순서로 확인하는 것이 좋습니다. 먼저 프록시를 끄고 기본 네트워크를 테스트한 뒤 다시 켜서 대상 요청이 나타나는지 확인하세요. 요청은 커널에 들어오지만 사용할 수 있는 정책이 없다면 설정과 그룹 참조를 확인합니다. 정책이 명확한데 연결이 실패하면 오류 원인을 살펴보세요. 시간 초과는 대기 시간 안에 작업이 끝나지 않았다는 뜻일 뿐, DNS 장애를 바로 의미하지 않습니다. 연결 거부, 인증 실패, 인증서 오류는 각각 해결 방법이 다릅니다.

한 번에 변수 하나만 바꾸고 변경 전후의 대상과 결과를 기록하세요. 예를 들어 규칙과 DNS는 그대로인데 노드를 바꾼 뒤 대상에 접속할 수 있었다면 외부 연결 경로를 계속 확인해야 합니다. 규칙을 바꿔 예상대로 매칭되었지만 여전히 시간 초과가 발생한다면 문제가 해결된 것이 아닙니다. 복잡한 표는 필요 없습니다. 시간, 증상, 변경 사항, 결과 네 가지면 충분합니다. 간헐적인 문제에서는 이런 기록이 반복 재시작보다 유용하며 절전 모드, 네트워크 전환, 구독 업데이트와의 연관성도 파악하기 쉽습니다.

지연 시간과 로그 올바르게 읽기

노드 테스트 값은 선택을 돕는 참고 지표이지 연결 전체를 평가하는 최종 기준이 아닙니다. 테스트 주소는 가까워도 실제 서비스 대상은 다른 네트워크에 있을 수 있습니다. 연결은 빨라도 혼잡 때문에 다운로드가 느릴 수 있습니다. 실제 대상의 응답, 연속 요청의 안정성, 필요한 프로토콜을 함께 고려해 사용성을 판단하세요. 자동 속도 측정 실패는 테스트 주소에 연결할 수 없어서일 수도 있으므로 모든 노드를 바로 삭제하지 마세요. 측정의 한계는 url-test 지연 시간과 실제 속도의 차이를 참고하세요.

로그 수준은 현재 진단에 필요한 만큼만 설정하세요. 평소에는 일반 정보를 유지하고 문제를 재현할 때만 잠시 상세 수준을 높인 뒤 원래대로 돌립니다. 전체 로그에는 도메인, 주소, 프로그램 경로, 인증 관련 정보가 포함될 수 있으므로 공개하기 전에 반드시 민감 정보를 가리세요. 문제를 설명할 때는 클라이언트 이름, 운영체제, 트래픽 처리 방식, 재현 절차, 주요 오류 줄만 제공하면 됩니다. 전체 설정을 공개할 필요는 없습니다. 안정적으로 재현되는 문제라면 먼저 최소 재현 사례를 만들고, 관련 없는 추가 규칙을 제거해 비교하세요.

실행 가능한 복구 순서 마련하기

복구할 때는 최근 변경을 먼저 되돌리고 TUN을 끈 다음, 명시적 프록시나 시스템 프록시로 돌아가 테스트하세요. 필요하면 이전에 정상 작동한 설정을 복구합니다. 클라이언트는 종료했는데 시스템에서 여전히 인터넷에 연결할 수 없다면 모든 네트워크 설정을 바로 초기화하지 말고 시스템 프록시 잔여 설정과 다른 터널의 상태를 확인하세요. 원격 관리 기기에서는 기본 경로를 변경할 때 특히 주의해야 합니다. 관리 연결이 끊길 수 있습니다. 시스템 네트워크에 영향을 주는 작업을 하기 전에 로컬 접속이나 다른 복구 경로를 준비하세요.

9. 고급 설정 단계와 검증 목록

필드를 쌓기보다 문제에 맞춰 기능 추가하기

기본 흐름이 안정된 뒤에는 세 가지 방향으로 고급 설정을 익힐 수 있습니다. 반복되는 규칙을 규칙 제공자로 분리하고, 노드 출처를 프록시 제공자로 구성하며, 정책 그룹으로 앱마다 다른 연결 경로를 관리하는 방법입니다. 한 번에 한 가지 방식만 추가하고 복사본에서 검증한 뒤 일상 설정에 적용하세요. 고급 필드가 기본적으로 필요한 것은 아닙니다. 명확한 문제를 발견하고 필드의 역할을 이해하며 결과를 검증할 수 있을 때만 설정을 추가하세요. 숨은 의존성을 줄이는 편이 장기적인 유지 관리에 더 도움이 되는 경우가 많습니다.

프록시 제공자를 학습할 때는 노드 데이터를 어디서 가져오는지, 캐시는 어디에 저장되는지, 언제 업데이트되는지, 그룹이 어떻게 참조하는지 먼저 알아보세요. 규칙 제공자는 콘텐츠 형식과 동작 유형을 파악한 다음 로드 실패를 확인하는 방법을 계획해야 합니다. 둘 다 외부 데이터에 의존하므로 설정 구문이 올바르더라도 실행 중 다운로드에 성공한다는 보장은 없습니다. 다운로드 경로, 파일 권한, 캐시 상태, 참조 이름을 각각 확인해 제공자 문제를 모든 노드를 사용할 수 없는 문제로 오인하지 마세요.

도메인 정보를 파악한 다음 스니핑 살펴보기

일부 연결은 대상 주소만 가진 채 커널에 들어오므로 도메인 규칙을 직접 적용할 근거가 부족할 수 있습니다. 도메인 스니핑은 지원되는 프로토콜과 조건에서 도메인 정보를 추출할 수 있지만, 범용 복호화 도구가 아니며 모든 연결에서 도메인을 얻을 수 있는 것도 아닙니다. 활성화하기 전에 문제가 실제로 도메인 정보 부족에서 비롯된 것인지 확인한 다음 연결 기록을 살펴보세요. 가이드에 스니핑 설정이 나온다는 이유만으로 전체 설정을 복사하지 마세요. 앱 호환성, 제외 범위, 추가 처리 비용을 특히 고려해야 합니다.

프로세스 규칙, 인터페이스 바인딩, 라우팅 제외도 시스템 환경에 맞춰 설정해야 합니다. 프로세스 식별은 권한과 플랫폼 지원에 영향을 받고, 백그라운드 서비스의 프로세스 정보는 프런트엔드 창과 다를 수 있습니다. 프로세스별 연결 경로를 설정할 때는 실제 프로세스 정보를 먼저 확인하고 규칙을 추가하세요. 화면에 표시된 프로그램 이름만 보고 매칭 경로를 추정할 수는 없습니다. 가상 머신, 컨테이너, 로컬 네트워크 기기에 프록시를 제공하려면 전달, 접근 제어, DNS 출처도 고려해야 합니다. 이는 단일 기기의 브라우저 프록시 범위를 넘어섭니다.

설정 습관에 보안 경계 반영하기

제어 인터페이스, 로컬 네트워크 리스닝, 원격 구독은 모두 명확한 용도가 있어야 합니다. 기기 내부에서만 사용한다면 로컬 바인딩을 유지하세요. 다른 기기에서 접근해야 할 때는 인증, 허용 출처, 시스템 방화벽을 함께 설계합니다. 편리하게 디버깅하려고 모든 리스너를 전체 네트워크 인터페이스에 연결한 뒤 계속 열어 두지 마세요. 설정 저장소와 이슈 첨부 파일도 최소 공개 원칙을 지켜야 합니다. 구조와 민감 정보를 가린 예시는 공개할 수 있지만, 실제 구독 정보, 인증 필드, 전체 접근 기록은 공개하지 마세요. 예시 설정과 실제 운영 설정은 분리해 보관해야 합니다.

고급 설정을 검증할 때는 대상 웹사이트가 열리는지만 확인해서는 안 됩니다. 직접 연결되어야 할 내부망, 앱 로그인, 파일 전송, 절전 모드 복귀, 네트워크 전환도 점검하세요. 규칙 업데이트 후에는 새롭게 잘못 매칭되는 항목이 있는지 살펴보고, 노드 변경 후에는 장기 연결을 다시 설정해야 하는지 확인합니다. 모바일 기기에서는 백그라운드 실행과 배터리 관리 정책이 연결에 미치는 영향도 살펴야 합니다. 환경마다 조건이 다르므로 데스크톱에서 한 번 성공했다고 모든 기기에서 똑같이 동작한다고 추정하지 마세요.

이 단계를 마치면 반복해서 재설치하는 대신 실패한 요청을 바탕으로 트래픽 진입, 규칙, 이름 해석, 외부 연결을 역으로 확인할 수 있어야 합니다. 새 가이드를 참고할 때는 먼저 대상 클라이언트, 커널, 운영체제를 확인한 다음 현재 환경에 적용할 필드를 판단하세요. 첫 연결 절차를 다시 확인하려면 입문 가이드로 돌아가고, 구체적인 증상에 따라 문제를 해결하려면 고객 지원 센터를 이용하세요. 이후의 모든 테스트를 위한 기준으로 간결하고, 동작을 설명할 수 있으며, 복구 가능한 최종 설정을 보관하세요.