Clash 처음부터 익히는 사용 설명서

먼저 Clash 핵심 개념 이해하기

작업을 시작하기 전에 클라이언트, 코어, 설정 파일, 구독, 노드, 프록시 그룹과 규칙을 구분해 두세요. 복잡해 보이는 문제도 실제로는 이 과정 중 두 단계를 혼동한 경우가 많습니다. 예를 들어 클라이언트가 정상적으로 실행됐다고 해서 사용할 수 있는 설정이 있다는 뜻은 아닙니다. 구독 가져오기가 성공해도 해당 설정을 선택했다는 의미는 아니며, 설정을 선택한 뒤에도 프록시 그룹에서 어떤 노드를 사용할지 정해야 합니다. 시스템 프록시를 켜도 시스템 프록시 설정을 따르는 프로그램만 Clash에 자동으로 연결됩니다. 이 흐름을 단계별로 확인하는 편이 반복해서 재설치하는 것보다 문제를 훨씬 쉽게 찾을 수 있습니다.

클라이언트, 코어와 설정의 역할

클라이언트는 화면으로 확인하는 그래픽 인터페이스로, 구독 가져오기, 설정 변경, 연결 기록 표시와 시스템 프록시 제어를 담당합니다. 코어는 설정을 실제로 해석하고 연결을 처리하는 프로그램이며, Mihomo는 현재 널리 사용되는 호환 코어 중 하나입니다. 설정 파일은 보통 YAML 텍스트로 작성되며 포트, 프록시 노드, 프록시 그룹, 규칙과 DNS 등의 내용을 포함합니다. 그래픽 클라이언트가 코어를 실행하면 현재 선택한 설정을 코어에 전달하고, 문법이 유효한 설정이라면 코어는 정의된 순서에 따라 트래픽을 처리합니다.

이 세 계층은 문제 증상도 다릅니다. 클라이언트가 열리지 않는다면 설치, 권한 또는 시스템 호환성을 먼저 확인하세요. 클라이언트는 열리지만 설정 파싱 실패가 표시된다면 YAML 형식이나 구독 내용을 살펴봐야 합니다. 코어가 실행 중인데 웹페이지가 열리지 않는다면 시스템 프록시, 프록시 그룹 선택, 규칙 적용과 노드 사용 가능성을 차례로 확인하세요. 문제를 해결할 때는 먼저 어느 계층에 문제가 있는지 판단해야 하며, 모든 이상을 “노드가 고장 났다”로 단정하지 않는 것이 중요합니다.

구독, 노드와 프록시 그룹의 관계

구독 링크는 설정 제공자가 제공하는 원격 주소입니다. 클라이언트가 이 주소에 요청하면 설정 내용을 받아 로컬 설정으로 저장합니다. 노드는 설정에 포함된 개별 프록시 출구로, 보통 서버 주소, 포트와 프로토콜 매개변수를 기록합니다. 프록시 그룹은 여러 노드를 묶어 수동 선택, 지연 시간 테스트 또는 장애 조치 방식으로 사용할 노드를 결정합니다. 규칙은 일반적으로 특정 노드를 직접 가리키지 않고 “노드 선택”, “자동 선택”과 같은 프록시 그룹을 먼저 지정하며, 최종 출구는 프록시 그룹이 결정합니다.

따라서 노드 목록이 보인다고 해서 현재 연결이 특정 노드를 사용 중인 것은 아닙니다. 먼저 구독 설정을 선택한 다음 프록시 화면에서 주요 프록시 그룹을 찾아 적절한 노드로 전환해야 합니다. 프록시 그룹이 DIRECT에 머물면 해당 연결은 직접 접속하고, REJECT에 머물면 연결이 거부됩니다. 자동 선택을 사용하면 결과는 해당 그룹의 테스트 주소, 테스트 간격과 후보 노드에 따라 달라집니다. 노드는 클라이언트 자체에서 제공되지 않으며, Clash도 설치 후 사용할 수 있는 회선을 자동으로 생성하지 않습니다.

시스템 프록시와 TUN의 적용 범위

시스템 프록시는 운영체제가 제공하는 프록시 주소 설정입니다. 브라우저와 많은 데스크톱 앱은 이 설정을 읽어 HTTP 또는 SOCKS 연결을 Clash의 로컬 수신 포트로 보냅니다. 설정이 간단하고 영향 범위가 명확해 처음 사용할 때 기본 선택으로 적합합니다. 일부 게임, 명령줄 프로그램, 스토어 앱과 자체 네트워크 스택을 사용하는 소프트웨어는 시스템 프록시를 읽지 않으므로 스위치를 켜도 계속 직접 연결할 수 있습니다.

TUN 모드는 가상 네트워크 인터페이스로 더 많은 시스템 트래픽을 받아들이므로 일반적으로 시스템 프록시보다 적용 범위가 넓습니다. 대신 관리자 권한, 라우팅 테이블, DNS 가로채기와 네트워크 보안 소프트웨어 호환성까지 고려해야 합니다. 먼저 시스템 프록시로 구독과 노드가 정상인지 확인한 뒤 실제 필요에 따라 TUN을 켜는 것이 올바른 순서입니다. 처음부터 구독, DNS, 규칙과 TUN을 동시에 변경하면 문제가 어느 단계에서 발생했는지 판단하기 어렵습니다.

운영체제와 사용 방식에 맞는 클라이언트 선택

Clash 생태계에는 여러 그래픽 클라이언트와 독립 실행형 코어가 있습니다. 선택할 때는 먼저 운영체제를 확인하고, TUN, 규칙 편집, 구독 관리와 데스크톱 트레이가 필요한지 살펴보세요. 단순히 화면 디자인만 비교할 필요는 없습니다. 이 사이트의 다운로드 페이지는 Windows, macOS, Android, iOS, Linux와 Mihomo 코어로 나누어 안내하며, 클라이언트 목록도 이 권장 기준과 일치합니다. 처음 사용한다면 유지 관리 상태가 명확하고 주요 기능에 쉽게 접근할 수 있는 그래픽 클라이언트를 우선 선택하세요. 서버와 라우터 환경에서만 코어 직접 실행을 고려하면 됩니다.

플랫폼별 우선 선택 기준

Clash Plus는 Windows, macOS, Android와 iOS를 지원하는 이 설명서의 전 플랫폼 우선 추천 클라이언트입니다. 여러 기기에서 비슷한 방식으로 사용하고 싶은 사람에게 적합하며, 구독과 프록시 설정에도 쉽게 접근할 수 있습니다. Windows에서는 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를 사용할 수 있습니다. 모바일 운영체제는 백그라운드 실행과 배터리 최적화 제한이 많으므로 설치 후 VPN 권한, 백그라운드 활동과 절전 설정도 확인해야 합니다. iOS에서는 Clash Plus의 App Store 버전을 사용하며, 관련 경로는 iOS 다운로드 섹션에서 확인할 수 있습니다.

Linux 데스크톱 환경에서는 Clash Verge Rev 또는 FlClash를 선택할 수 있습니다. 데스크톱 환경이 없는 서버, 소프트 라우터와 컨테이너 환경에서는 Mihomo 코어를 사용할 수 있지만 설정 파일, 서비스 관리와 로그 확인 방식을 직접 준비해야 합니다. 코어를 직접 실행해도 그래픽 인터페이스가 자동으로 제공되거나 시스템의 데스크톱 프록시가 자동 설정되지는 않으므로 포트, 라우팅과 설정 구조를 이미 이해한 사용자에게 더 적합합니다.

그래픽 클라이언트와 독립 코어 중 무엇을 선택할까

그래픽 클라이언트는 일상적인 데스크톱과 모바일 기기에 적합합니다. 구독 업데이트, 프록시 그룹 전환, 연결 확인, 시스템 프록시와 TUN 스위치를 한 화면에서 관리할 수 있어 현재 상태를 확인하기도 쉽습니다. 독립 코어는 systemd, Docker 또는 스크립트로 관리하려는 환경에 적합합니다. 배포 방식이 유연한 대신 설정 경로, 실행 매개변수, 로그 순환과 재시작 정책을 직접 관리해야 합니다.

브라우저와 자주 사용하는 앱만 규칙에 따라 네트워크에 연결하려는 경우라면 “기능이 더 많다”는 이유로 코어를 바로 선택할 필요는 없습니다. 먼저 그래픽 클라이언트로 규칙 모드, 프록시 그룹과 연결 기록을 익힌 뒤 서버 환경으로 옮기면 이해하기가 훨씬 쉽습니다. 반대로 대상 기기에 데스크톱이 없고 장기간 실행해야 하며 자동화 시스템이 설정을 배포한다면 그래픽 인터페이스는 오히려 필요하지 않습니다.

기존 클라이언트에서 이전할 때 보존할 정보

Clash for Windows 또는 ClashX Meta에서 이전할 때 가장 중요한 것은 원본 구독 주소와 직접 작성한 오버라이드 규칙을 보관하는 것입니다. 클라이언트마다 설정 디렉터리, 데이터베이스와 화면 설정을 구성하는 방식이 다르므로 캐시 디렉터리만 복사하지 마세요. 구독에 계속 접근할 수 있다면 새 클라이언트에서 URL로 다시 가져오는 편이 일반적으로 안전합니다. 설정에 로컬 규칙 세트나 스크립트가 포함되어 있다면 관련 파일을 별도로 백업하고 새 코어가 해당 문법을 지원하는지 확인하세요.

이전이 끝나면 기존 클라이언트를 먼저 종료해 두 프로그램이 동시에 시스템 프록시를 수정하거나 같은 포트를 점유하지 않도록 하세요. 작업 표시줄, 메뉴 막대 또는 백그라운드 프로세스에서 하나의 코어만 남아 있는지 확인한 뒤 새 클라이언트를 실행합니다. 이후 구독 가져오기, 설정 선택, 프록시 그룹 선택과 시스템 프록시 활성화를 순서대로 진행하세요. 기존 클라이언트는 비교를 위해 잠시 보관할 수 있지만 동시에 실행하지는 마세요.

설치, 권한 허용과 첫 실행 완료하기

설치 단계의 목표는 모든 고급 설정을 즉시 바꾸는 것이 아니라 클라이언트, 코어와 시스템 권한을 확인 가능한 상태로 만드는 것입니다. 설치 후 먼저 한 번 실행해 메인 화면이 열리고 코어가 정상이며 포트 점유 경고가 없는지 확인한 다음 구독을 가져오세요. 첫 실행부터 오류가 발생한다면 설정을 반복해서 가져오지 말고 설치와 권한 문제부터 해결해야 합니다.

Windows 설치와 포트 점검

Windows 사용자는 다운로드 페이지에서 시스템 아키텍처에 맞는 설치 파일을 선택하고 설치 마법사에 따라 설치하세요. 방화벽을 통한 앱 통신을 허용할지 묻는다면 현재 네트워크 유형에 맞춰 승인할 수 있습니다. 로컬 네트워크에서 프록시를 공유하는 기능은 처음 사용할 때 필수가 아니므로 LAN 연결을 미리 켤 필요는 없습니다. 설치 후 시작 메뉴에서 클라이언트를 실행하고 코어가 정상적으로 작동하는지 확인하세요. TUN을 사용할 때는 이후 서비스 설치 또는 관리자 권한을 통한 가상 네트워크 인터페이스 초기화가 필요할 수 있습니다.

포트 점유는 Windows에서 첫 실행 때 자주 발생하는 문제입니다. Clash 설정은 로컬 HTTP, SOCKS 또는 mixed 수신 포트를 사용하는 경우가 많으므로 기존 프록시 도구가 백그라운드에서 실행 중이면 새 코어가 같은 포트에 바인딩하지 못할 수 있습니다. 먼저 다른 프록시 클라이언트를 종료한 뒤 Clash를 다시 시작하세요. 추가 확인이 필요하다면 PowerShell에서 특정 포트를 수신 중인 프로세스를 확인할 수 있습니다:

Get-NetTCPConnection -State Listen |
  Where-Object LocalPort -In 7890,7891,7892 |
  Select-Object LocalAddress,LocalPort,OwningProcess

Get-Process -Id <OwningProcess>

설정마다 사용하는 포트가 다를 수 있으므로 화면에 표시된 실제 수신 포트가 판단 기준입니다. 익숙하다는 이유로 7890을 바로 시스템 프록시에 지정하지 마세요. 그래픽 클라이언트는 일반적으로 올바른 주소를 시스템 설정에 자동으로 기록합니다.

macOS 보안 경고와 네트워크 권한

macOS 설치가 끝나면 앱을 “응용 프로그램” 폴더로 옮긴 뒤 해당 위치에서 실행하세요. 시스템에서 앱 출처 확인, 네트워크 구성 추가 또는 관리자 암호 입력을 요구할 수 있습니다. 시스템 프록시는 네트워크 프록시 설정만 변경하면 되지만, TUN이나 확장된 트래픽 인계에는 보조 서비스 설치가 추가로 필요할 수 있습니다. 각 권한 요청은 현재 수행 중인 작업과 일치해야 합니다. 권한을 취소해도 클라이언트 화면은 열릴 수 있지만 관련 스위치는 적용되지 않습니다.

메뉴 막대 클라이언트와 기존 프록시 프로그램이 동시에 실행되는 경우가 많습니다. 메뉴 막대 아이콘과 “활성 상태 보기”를 확인해 기존 코어가 종료되었는지 살펴보세요. 시스템 프록시를 켠 직후 자동으로 꺼진다면 먼저 클라이언트 로그에서 권한 부족 메시지를 확인한 뒤 다른 네트워크 관리 도구가 네트워크 설정을 덮어쓰고 있는지 점검하세요. Wi-Fi, 유선 네트워크 또는 핫스팟을 전환하면 시스템에서 사용하는 네트워크 서비스가 달라질 수 있으므로 필요하면 시스템 프록시 스위치를 다시 전환하세요.

Android와 iOS의 VPN 권한 허용

모바일 기기는 일반적으로 시스템 VPN 인터페이스를 통해 트래픽을 인계합니다. 처음 연결을 시작하면 시스템에서 VPN 구성 또는 연결 요청을 표시하며, 동의해야 클라이언트가 작동합니다. Android 상태 표시줄에 VPN 아이콘이 나타나면 보통 시스템 인터페이스가 연결된 것이지만, 설정과 프록시 그룹이 올바른지도 확인해야 합니다. 앱을 백그라운드로 보낸 뒤 연결이 빠르게 중단된다면 시스템 배터리 설정에서 백그라운드 활동을 허용하고 과도한 절전 제한에서 클라이언트를 제외하세요.

일반적으로 한 번에 하나의 앱만 시스템 VPN 인터페이스를 사용할 수 있습니다. 기기에 회사 VPN, 다른 프록시 클라이언트 또는 개인정보 보호 도구가 이미 있다면 Clash를 시작할 때 기존 연결 중 하나가 끊길 수 있습니다. 어떤 연결을 유지할지 먼저 정하고 서로 경쟁하는 VPN을 동시에 켜지 마세요. iOS에서 VPN 구성을 추가하면 시스템 설정에서 해당 항목을 확인할 수 있습니다. 클라이언트를 삭제하기 전에 연결 구성을 완전히 제거하려면 시스템 VPN 목록도 함께 확인하세요.

Linux 데스크톱과 코어 실행 방식

Linux 그래픽 클라이언트는 배포판에 맞는 설치 파일을 선택하세요. 설치 후 앱은 실행되지만 시스템 프록시를 설정하지 못한다면 데스크톱 환경이 프록시 설정 자동 기록을 지원하는지 확인해야 합니다. GNOME, KDE와 경량 데스크톱은 프록시 설정 저장 방식이 다르므로 필요하면 데스크톱 네트워크 설정에서 주소와 포트를 직접 확인하세요. Wayland 또는 샌드박스 환경에서는 트레이 아이콘과 권한 제한도 살펴봐야 하지만, 이러한 화면 문제는 코어 실행 자체에 영향을 주지 않을 수 있습니다.

Mihomo 코어를 직접 실행할 때는 먼저 별도의 작업 디렉터리를 만들고 설정을 읽을 수 있는 파일로 저장한 뒤, 로그를 확인할 수 있도록 포그라운드에서 시작하세요. 다음은 일반적인 실행 형식이며 경로는 실제 컴퓨터의 디렉터리로 바꿔야 합니다:

mkdir -p "$HOME/.config/mihomo"
mihomo -d "$HOME/.config/mihomo"

설정이 정상적으로 로드된 것을 확인한 뒤 systemd와 같은 서비스 관리자를 사용하세요. 처음 테스트할 때 바로 백그라운드로 실행하면 설정 파싱 오류와 포트 충돌이 서비스 로그에만 남아 알아채기 어렵습니다. 서버에서는 제어 인터페이스와 프록시 포트의 수신 범위도 제한해야 하며, 기본적으로 로컬에서만 사용할 경우 루프백 주소에 바인딩하면 됩니다.

구독을 가져오고 복구 가능한 설정 흐름 만들기

구독 가져오기는 원격 설정을 클라이언트가 관리하도록 전달하는 과정입니다. 시작하기 전에 완전한 구독 URL을 준비하고 복사할 때 공백, 줄바꿈 또는 설명 문자가 섞이지 않았는지 확인하세요. 구독은 설정의 출처이므로 노드 이름, 프록시 포트 또는 컨트롤러 주소 입력란에 붙여 넣으면 안 됩니다. 클라이언트마다 메뉴 이름이 “설정”, “구독”, “Profiles” 또는 “프로필”처럼 다를 수 있지만 핵심 과정은 URL로 설정을 내려받아 로컬에 저장하고 현재 설정으로 지정하는 것입니다.

URL 가져오기 표준 절차

설정 또는 구독 페이지로 이동해 URL에서 새 설정을 만드는 항목을 선택한 다음 전체 링크를 주소 입력란에 붙여 넣으세요. 이름은 용도나 기기를 구분할 수 있는 짧은 텍스트처럼 알아보기 쉽게 입력하고, 전체 URL을 이름으로 표시하는 것은 권장하지 않습니다. 제출 후 클라이언트의 다운로드가 끝날 때까지 기다리세요. 성공하면 새 설정 항목과 업데이트 시간 또는 업데이트 버튼이 표시되는 경우가 많습니다. 다음으로 해당 항목을 클릭해 현재 설정으로 지정하세요. 일부 클라이언트는 가져오기 후 자동으로 선택하지 않으며, 이것이 “구독은 보이는데 노드가 없다”는 흔한 원인입니다.

설정을 활성화한 뒤 프록시 페이지로 이동해 주요 프록시 그룹이 표시되는지 확인하고 노드를 하나 선택하세요. 그런 다음 시스템 프록시를 켜고 브라우저로 기본 접속을 테스트합니다. 전체 과정은 “설정 다운로드”, “설정 선택”, “노드 선택”, “트래픽 인계 활성화”의 네 단계로 나누어야 하며, 구독 항목이 존재한다는 이유만으로 설정이 끝났다고 판단하지 마세요. 전체 과정을 그림과 함께 확인하려면 Clash 구독 링크 가져오기 방법을 참고하세요.

클라이언트가 링크 형식을 인식하는지 확인하기

일반적인 구독 콘텐츠에는 Clash YAML 설정, 노드 목록과 변환 후에야 Clash가 인식할 수 있는 형식이 포함됩니다. 클라이언트는 URL로 콘텐츠를 요청한 뒤 설정 파서에 전달합니다. 응답이 로그인 페이지, 오류 페이지, 빈 텍스트 또는 호환되지 않는 형식이면 단순한 네트워크 오류가 아니라 파싱 실패로 표시될 수 있습니다. 이때는 구독 제공자 페이지에서 Clash 또는 Mihomo 전용 링크를 다시 복사하고, 웹페이지 주소를 구독 주소로 임의 사용하지 마세요.

기본 YAML 설정에는 보통 포트, 프록시, 프록시 그룹과 규칙 등의 필드가 포함됩니다. 다음 예시는 실제 노드 정보 없이 구조 관계만 보여 줍니다:

mixed-port: 7890
mode: rule
log-level: info

proxies: []

proxy-groups:
  - name: 노드 선택
    type: select
    proxies:
      - DIRECT

rules:
  - GEOIP,LAN,DIRECT
  - MATCH,노드 선택

YAML은 들여쓰기에 민감하며 일반적으로 공백을 사용합니다. 탭 문자를 섞지 마세요. 구독이 원격 서비스에서 생성된 것이라면 원본 파일을 직접 수정할 필요가 없습니다. 사용자 지정 규칙을 추가할 때는 클라이언트가 제공하는 오버라이드 또는 병합 기능을 우선 사용하세요. 다운로드한 설정을 직접 수정하면 다음 업데이트 때 변경 내용이 덮어써질 가능성이 큽니다.

응답 유형에 따라 업데이트 실패 처리하기

구독 업데이트가 시간 초과되었다면 제한 시간 안에 요청을 완료하지 못한 것입니다. 현재 네트워크에서 구독 주소에 접근할 수 없거나 DNS 해석에 문제가 있거나, 업데이트 요청이 기존 프록시를 거쳐야 할 수 있습니다. 먼저 현재 네트워크에서 구독 제공자의 관리 페이지를 직접 열어 서비스에 접근할 수 있는지 확인하세요. 클라이언트에 “프록시를 통해 업데이트” 옵션이 있다면 이미 사용 가능한 설정이 있을 때 활성화해 볼 수 있습니다. 처음 가져오는 단계라 사용할 설정이 없다면 구독 주소가 현재 직접 연결 네트워크에서 열리는지 먼저 확인해야 합니다.

404 또는 유사한 리소스 없음 메시지가 표시되면 링크 경로가 만료되었거나 토큰이 변경되었거나 복사가 완전하지 않은 경우가 많습니다. 이때 재시도만으로 주소가 고쳐지지는 않으므로 구독 출처로 돌아가 링크를 다시 생성하세요. 인증되지 않았거나 접근이 거부되었다면 계정 상태, 링크 권한과 서버 제한을 확인해야 합니다. 오류 유형별 처리 방법은 구독 업데이트 실패 해결에서 더 확인할 수 있습니다.

자동 업데이트 간격과 로컬 백업

자동 업데이트를 지나치게 자주 설정할 필요는 없습니다. 노드와 규칙은 서버 콘텐츠가 변경될 때만 달라지므로 짧은 시간에 연속 요청하면 실패 가능성이 커지고 현재 어느 업데이트 결과를 사용하는지 판단하기도 어려워집니다. 일반적인 기기는 클라이언트가 제공하는 시간 단위 간격으로 설정하고, 즉시 동기화가 필요할 때만 수동 업데이트하세요. 업데이트 후 노드 목록이 눈에 띄게 이상하다면 먼저 설정 업데이트 시간을 확인하고, 여전히 사용할 수 있는 이전 로컬 설정으로 되돌려 보세요.

구독 URL은 계정에 해당하는 설정 내용을 가져오는 데 사용될 수 있으므로 민감한 설정 정보로 관리해야 합니다. 스크린샷을 공유할 때는 전체 주소를 가리고, 문제를 확인할 때도 링크를 공개하기보다 오류 유형과 로그 일부를 우선 제공하세요. 백업할 때는 구독 주소, 사용자 지정 오버라이드와 클라이언트 설정 설명을 저장할 수 있습니다. 원격 구독으로 생성된 노드 목록은 다시 내려받을 수 있으므로 여러 기기 사이에 전체 캐시 디렉터리를 복사할 필요는 없습니다.

규칙, 전역과 직접 연결 세 가지 프록시 모드 이해하기

프록시 모드는 연결이 Clash에 들어온 뒤 어떤 출구를 선택할지 결정합니다. 트래픽이 클라이언트로 들어오는지 여부는 결정하지 않으며, 그 역할은 시스템 프록시 또는 TUN이 담당합니다. 모드를 바꾼다고 노드 자체의 사용 가능 여부가 달라지는 것도 아닙니다. 이 두 경계를 이해하면 문제를 훨씬 명확하게 좁힐 수 있습니다. 연결 기록에 요청이 전혀 없다면 트래픽 인계를 확인하고, 요청은 있지만 출구가 예상과 다르면 모드, 규칙과 프록시 그룹을 확인하세요. 프록시가 선택되었지만 연결에 실패한다면 노드와 대상 네트워크를 점검해야 합니다.

규칙 모드는 일상적인 사용에 적합

규칙 모드는 설정의 규칙을 위에서부터 확인하며, 처음으로 일치한 규칙이 연결을 어떤 정책 그룹에 전달할지, 직접 연결할지 또는 거부할지를 결정합니다. 일반적인 기준에는 도메인, 도메인 접미사, IP 주소, 지리 데이터베이스, 프로세스 이름과 규칙 세트가 있습니다. LAN, 로컬 서비스와 자주 직접 연결하는 사이트는 직접 연결로 유지하고 프록시가 필요한 연결만 지정된 프록시 그룹으로 보내 로컬 서비스 호환성과 접속 경로를 함께 관리할 수 있습니다.

규칙 모드가 모든 것을 “자동 판단”한다는 뜻은 아닙니다. 판단 기준은 설정 파일에 있으며 규칙의 적용 범위와 순서가 결과에 영향을 줄 수 있습니다. 새로운 도메인이 아직 규칙 세트에 포함되지 않았다면 마지막 MATCH 규칙으로 처리됩니다. 특정 웹사이트의 출구가 잘못되었다면 먼저 연결 기록에서 대상 도메인을 찾아 어떤 규칙과 최종 정책이 적용되었는지 확인하세요. 곧바로 전역 모드로 장기간 전환하기보다 필요한 경우에만 사용자 지정 규칙을 추가하는 것이 좋습니다.

전역 모드는 비교 테스트에 사용

전역 모드는 일반적으로 인계된 연결을 모두 전역 프록시 그룹으로 전달합니다. “문제가 규칙 때문인지” 짧게 확인할 때 적합합니다. 규칙 모드에서 접속에 실패했지만 전역 모드에서 복구된다면 노드와 트래픽 인계 흐름은 대체로 정상이며, 다음으로 규칙 적용이나 DNS 결과를 확인해야 합니다. 전역 모드에서도 실패한다면 노드, 포트, 권한과 네트워크 환경을 우선 점검하세요.

전역 모드라고 해서 운영체제의 모든 트래픽이 반드시 인계되는 것은 아닙니다. 시스템 프록시만 켠 경우 시스템 프록시를 읽지 않는 앱은 계속 직접 연결할 수 있으며, 범위를 넓히려면 TUN이 필요합니다. 전역 모드는 LAN 기기, 프린터, 개발 서비스 또는 로컬 네트워크에서만 접근할 수 있는 리소스까지 프록시로 보낼 수도 있습니다. 따라서 모든 문제를 해결하는 고정 스위치가 아니라 테스트 도구나 명확한 필요가 있을 때의 임시 선택으로 사용하는 편이 좋습니다.

직접 연결 모드는 복구와 기준선 점검에 사용

직접 연결 모드는 Clash에 들어온 연결이 프록시 출구를 우회하도록 합니다. 시스템의 원래 네트워크가 정상인지 확인하거나 클라이언트를 실행한 상태에서 일시적으로 프록시를 중지할 때 사용할 수 있습니다. 직접 연결로 전환한 뒤에도 일반 웹사이트에 접속할 수 없다면 원격 노드가 아니라 로컬 DNS, 시스템 네트워크, 남아 있는 프록시 설정 또는 TUN 라우팅이 원인일 수 있습니다.

클라이언트를 종료하기 전에는 시스템 프록시와 TUN을 먼저 끈 뒤 프로그램을 종료하는 것이 좋습니다. 프로그램을 강제 종료하면 시스템 프록시 주소가 이미 사라진 로컬 포트를 계속 가리킬 수 있어 시스템 프록시를 따르는 모든 앱의 인터넷 연결이 갑자기 끊길 수 있습니다. 이때는 클라이언트를 다시 시작해 스위치를 정상적으로 끄거나 시스템 네트워크 설정에서 프록시 주소를 삭제하세요. 직접 연결 모드와 트래픽 인계를 끄는 것은 완전히 같지 않습니다. 전자는 여전히 코어를 거친 뒤 직접 연결하고, 후자는 해당 트래픽을 코어로 보내지 않습니다.

프록시 그룹의 수동 선택, 자동 선택과 장애 조치

select 유형 프록시 그룹은 사용자가 노드 또는 다른 하위 그룹을 직접 선택합니다. 결과가 안정적이고 이해하기 쉬워 주요 출구에 적합합니다. url-test 유형은 테스트 주소에 주기적으로 요청해 후보 노드 중 응답 상태가 더 적합한 노드를 선택합니다. 테스트 결과는 해당 테스트 대상만 반영하며 모든 웹사이트의 실제 체감 품질과 같지는 않습니다. fallback 유형은 순서대로 사용 가능 여부를 확인하고 현재 항목이 실패하면 다음 후보로 전환하므로 연속성이 중요한 환경에 적합합니다.

자동 그룹이 자주 전환되면 기존 연결이 항상 매끄럽게 이동하는 것은 아니며 로그인 세션과 다운로드 작업에도 영향을 줄 수 있습니다. 테스트 간격을 너무 짧게 설정하지 말고 후보 노드도 무한히 늘리지 마세요. 고정 출구가 필요한 계정이나 서비스에는 안정적인 수동 그룹이 일관성을 유지하기 쉽습니다. 프록시 그룹 안에 다른 프록시 그룹이 중첩될 수도 있으므로 문제를 해결할 때는 단계별로 확인해야 하며, 외부 그룹 이름만 보고 최종 노드를 판단하지 마세요.

규칙 순서, 분할 작성과 DNS 연동 익히기

규칙 분할은 Clash의 핵심 기능이며, 설정에서 “일부 웹사이트는 정상이고 일부는 이상한” 문제가 발생할 때 가장 먼저 확인할 부분입니다. 규칙은 설정에 배치된 순서대로 하나씩 적용되고 일치하면 더 이상 확인하지 않습니다. 따라서 범위가 넓은 규칙을 너무 앞에 배치하면 뒤의 정밀한 규칙이 가려질 수 있습니다. 규칙을 설계할 때는 보통 LAN과 명확한 예외를 먼저 처리하고, 구체적인 도메인이나 규칙 세트를 배치한 뒤 IP 규칙을 처리하며 마지막에 MATCH로 남은 연결을 받습니다.

일반적인 규칙 유형 활용법

DOMAIN은 완전한 도메인에 사용하며 단일 호스트를 처리할 때 적합합니다. DOMAIN-SUFFIX는 특정 도메인과 하위 도메인을 매칭합니다. DOMAIN-KEYWORD는 범위가 더 넓어 오탐 가능성이 있으므로 도메인 구조가 불안정하고 키워드가 충분히 명확할 때만 사용하세요. IP-CIDR은 IPv4 네트워크 대역을 기준으로 매칭하고, IP-CIDR6은 IPv6에 대응합니다. GEOIP은 IP 지리 데이터베이스를 기준으로 처리하며 RULE-SET은 외부 또는 내장 규칙 모음을 참조합니다.

rules:
  - DOMAIN,printer.lan,DIRECT
  - DOMAIN-SUFFIX,example.internal,DIRECT
  - DOMAIN-SUFFIX,example.com,노드 선택
  - IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
  - IP-CIDR,10.0.0.0/8,DIRECT,no-resolve
  - GEOIP,LAN,DIRECT
  - MATCH,노드 선택

예시의 no-resolve는 해당 IP 규칙을 매칭할 때 도메인에 대한 추가 해석을 실행하지 않는다는 뜻이며, 명확한 로컬 네트워크 대역에 적합합니다. 실제 설정에서는 구독에 포함된 기존 규칙 구조를 유지하고 꼭 필요한 예외만 적절한 위치에 추가하세요. 클라이언트가 오버라이드 규칙을 지원한다면 구독 업데이트 후 자동 병합할 수 있습니다. 다운로드한 설정을 직접 수정하면 다음 업데이트 때 변경 사항이 덮어써질 가능성이 큽니다.

연결 기록으로 규칙 문제 역추적하기

특정 웹사이트를 점검할 때는 먼저 관련 없는 앱을 닫거나 일시 중지하고 대상 페이지를 다시 연 다음 연결 기록에서 도메인으로 필터링하세요. 기록에는 보통 대상 호스트, 사용된 규칙, 정책 그룹과 연결 경로가 표시됩니다. 예상과 다른 직접 연결 규칙이 적용되었다면 범위가 지나치게 넓은 도메인 접미사나 지리 규칙이 있는지 확인하세요. MATCH로 처리되었다면 앞선 규칙이 해당 요청을 포함하지 못한 것입니다. 예상한 프록시 그룹이 적용되었지만 최종적으로 DIRECT가 선택되었다면 해당 그룹의 현재 선택을 추가로 확인하세요.

현대 웹페이지는 여러 도메인에 동시에 접속하므로 메인 페이지가 정상이라고 정적 리소스, 로그인 API와 이미지 도메인도 같은 정책을 사용한다는 뜻은 아닙니다. 주 도메인 하나만 규칙에 추가했는데 페이지가 완전히 표시되지 않는다면 실패한 요청에서 관련 도메인을 찾아야 하며, 무작정 범위가 넓은 키워드를 추가하지 마세요. 브라우저 개발자 도구와 Clash 연결 기록을 함께 보면 전자는 어떤 요청이 실패했는지, 후자는 해당 요청이 어떤 출구를 사용했는지 확인할 수 있습니다.

DNS가 규칙 결과에 영향을 주는 이유

DNS는 도메인을 IP 주소로 변환합니다. 앱이 트래픽이 Clash에 들어오기 전에 직접 해석하고 IP만 전송하면 도메인 기반 규칙이 원래 호스트 정보를 바로 얻지 못할 수 있습니다. 해석 결과가 네트워크 환경의 영향을 받으면 노드가 정상이어도 잘못된 주소로 연결될 수 있습니다. Clash의 DNS 모듈은 설정에 따라 조회를 처리하며 fake-ip 또는 redir-host 등의 모드로 도메인 매핑을 유지할 수 있습니다.

fake-ip 모드는 앱에 예약된 주소 대역의 임시 주소를 반환하고, 코어는 매핑을 통해 실제 도메인을 찾아 규칙을 적용합니다. 일반적으로 도메인 규칙 인식 성능이 좋지만 일부 LAN 기기, 오래된 앱 또는 실제 IP에 의존하는 프로그램은 필터 목록에 추가해야 할 수 있습니다. redir-host는 실제 해석 결과를 반환하는 방식에 가까워 호환성 측면에서 직관적이지만 도메인 매핑과 연결 인식 방식은 다릅니다. 이름이 낯설다는 이유만으로 모드를 바꾸지 마세요. 현재 구독의 DNS 설정이 안정적이라면 우선 그대로 유지하는 것이 좋습니다.

dns:
  enable: true
  listen: 0.0.0.0:1053
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  nameserver:
    - 1.1.1.1
    - 8.8.8.8
  fake-ip-filter:
    - "*.lan"
    - "localhost.ptlogin2.qq.com"

이 예시는 필드 간 관계만 보여 주며 모든 네트워크 환경에서 같은 상위 DNS 주소를 사용해야 한다는 뜻은 아닙니다. 구독 설정은 DoH, DoT, 시스템 DNS 또는 도메인별 분할을 사용하는 nameserver-policy를 적용할 수 있습니다. 변경하기 전에 기존 값을 기록하세요. 변경 후 모든 도메인을 해석하지 못한다면 먼저 구독 기본 설정으로 되돌린 뒤 1053과 같은 수신 포트의 충돌, 시스템 방화벽 차단 여부와 TUN DNS 가로채기가 올바른 포트를 가리키는지 확인하세요.

IPv6, LAN과 사용자 지정 규칙의 경계

기기에 IPv6 연결이 있으면 앱이 AAAA 레코드를 우선 요청할 수 있습니다. 설정이 IPv4만 처리하고 시스템이 IPv6으로 직접 연결하면 출구가 일치하지 않을 수 있습니다. IPv6을 끌지는 노드, 코어와 로컬 네트워크가 완전히 지원하는지에 따라 결정해야 하며, 무조건 끄는 것을 정답으로 삼아서는 안 됩니다. 먼저 연결 기록에서 문제가 된 요청이 IPv6을 사용하는지 확인한 뒤 규칙 추가, DNS 반환값 조정 또는 해당 경로의 일시적 비활성화를 결정하는 편이 안전합니다.

라우터, NAS, 프린터와 개발 서버에 접속할 때는 사설 주소 대역과 로컬 도메인이 직접 연결되도록 해야 합니다. TUN 환경에서는 로컬 연결이 원격 프록시로 전송되지 않도록 LAN 라우팅도 유지해야 합니다. LAN 기기가 Clash 로컬 프록시에 연결하도록 허용하는 것은 별도의 기능이며 수신 범위를 변경합니다. 실제 공유가 필요할 때만 켜고 신뢰할 수 있는 네트워크로 방화벽을 제한하세요. “LAN에 접속하기”와 “LAN에 프록시를 개방하기”를 혼동하지 마세요.

필요할 때 TUN으로 전체 트래픽 인계하기

TUN 모드는 가상 네트워크 인터페이스를 만들고 라우팅을 통해 더 많은 연결을 Clash로 전달합니다. 시스템 프록시를 읽지 않는 게임, 명령줄 도구, 스토어 앱과 TCP·UDP 트래픽을 통합 처리해야 하는 환경에 적합합니다. TUN은 인계 범위를 넓힐 수 있지만 고장 난 노드, 잘못된 구독 또는 부적절한 규칙을 고쳐 주지는 않습니다. 따라서 활성화하기 전에 시스템 프록시 모드에서 설정이 정상인지 확인하고 기존 DNS와 프록시 설정을 기록해 두어야 문제가 생겼을 때 빠르게 되돌릴 수 있습니다.

활성화 전 네 가지 점검

첫째, 현재 설정이 규칙 모드와 시스템 프록시에서 정상적으로 접속되는지 확인하세요. 둘째, 다른 VPN, 가상 네트워크 인터페이스 프록시와 라우팅을 변경할 수 있는 네트워크 도구를 종료해 여러 인계 계층이 서로 덮어쓰지 않도록 하세요. 셋째, 클라이언트에 관리자 권한이 있거나 필요한 서비스가 설치되어 있는지 확인하세요. 넷째, 사용 중인 설정을 저장하고 TUN 끄기, 시스템 프록시 끄기와 클라이언트 종료 위치를 정확히 알아 두세요. 준비가 끝나면 TUN을 켜고 가상 네트워크 인터페이스 초기화를 기다립니다.

Windows 클라이언트는 라우팅 변경에 필요한 권한을 얻기 위해 서비스 모드를 사용하는 경우가 많습니다. 스위치를 누른 직후 원래 상태로 돌아간다면 서비스 설치 필요, 권한 부족 또는 드라이버 초기화 실패 메시지가 있는지 확인하세요. macOS에서는 네트워크 확장이나 보조 서비스 설치를 요구할 수 있습니다. Android와 iOS는 시스템 VPN 인터페이스를 사용하므로 데스크톱과 구현 방식이 다르며, 화면에서 완전히 같은 이름의 TUN 스위치를 찾을 필요가 없는 경우가 많습니다.

일반적인 TUN 매개변수의 의미

auto-route는 필요한 라우팅을 자동으로 추가하며 대부분의 데스크톱 클라이언트에 적합합니다. 끄면 트래픽이 가상 네트워크 인터페이스로 들어가는 방식을 직접 관리해야 합니다. auto-detect-interface는 현재 실제로 연결된 인터페이스를 식별하려고 하며 Wi-Fi, 유선 네트워크와 핫스팟을 오갈 때 유용합니다. dns-hijack은 지정된 DNS 요청을 코어의 DNS 모듈로 전달해 시스템 DNS 우회를 줄입니다. strict-route는 라우팅 동작을 더 엄격하게 제한해 누수를 줄일 수 있지만 여러 네트워크 인터페이스, 가상 머신과 LAN 접속에 영향을 줄 수도 있습니다.

stack 매개변수는 TUN 네트워크 스택 구현을 결정합니다. 시스템과 클라이언트에 따라 system, gVisor 또는 mixed 같은 선택지가 제공될 수 있습니다. system은 일반적으로 시스템 네트워크 스택에 더 가깝지만 성능과 호환성은 플랫폼에 따라 달라집니다. gVisor는 사용자 공간 네트워크 스택을 사용하므로 일부 환경에서 격리와 호환성 특성이 다릅니다. mixed는 프로토콜을 조합해 처리합니다. 명확한 문제가 없다면 클라이언트 권장값을 우선 사용하고 이론적인 차이만으로 자주 전환하지 마세요.

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

이 예시는 일반적인 구조만 보여 줍니다. 설정 파일에서 지원되는 구체적인 필드는 현재 코어와 클라이언트에 따라 달라지며, 그래픽 인터페이스가 생성한 설정에는 기기 이름, MTU, 라우팅 포함 항목과 제외 항목이 추가될 수 있습니다. 구독 오버라이드를 사용할 때는 병합 결과에 tun 블록이 중복 정의되지 않았는지 확인하세요. 나중에 등장하는 필드가 앞선 설정을 덮어쓸 수 있습니다.

활성화 후 확인 순서

TUN을 켠 뒤에는 현재 트래픽이 어느 경로로 인계되는지 명확히 알 수 있도록 시스템 프록시를 끈 상태로 유지하세요. 일반 웹페이지에 접속해 연결 기록에 도메인 요청이 나타나는지 확인한 다음, 이전에 시스템 프록시를 따르지 않던 앱도 테스트합니다. 이후 LAN 기기, DNS 해석과 자주 사용하는 로그인 서비스를 확인하세요. 웹페이지는 열리지만 LAN이 작동하지 않는다면 사설 네트워크 대역 라우팅과 strict-route를 중점적으로 확인하세요. 모든 도메인을 해석하지 못하지만 IP 직접 접속은 응답한다면 DNS 가로채기, 수신 포트와 상위 DNS를 점검해야 합니다.

명령줄로 시스템 라우팅을 확인할 수 있지만 작동 방식을 모르는 상태에서 전체 라우팅을 수동으로 삭제하지 마세요. Windows에서는 route print 또는 PowerShell로 인터페이스를 확인할 수 있고, macOS와 Linux에서는 netstat -rn, route -n get 또는 ip route를 사용할 수 있습니다. 활성화 전후의 기본 라우팅과 가상 인터페이스를 비교해 트래픽이 실제로 TUN으로 들어가는지 확인하세요. 더 자세한 원리와 설정 방법은 Clash TUN 모드 활성화 방법에서 확인할 수 있습니다.

이상 발생 시 안전하게 종료하는 방법

활성화 후 네트워크가 완전히 끊기면 먼저 TUN을 끄고 라우팅이 복구될 때까지 기다린 다음 시스템 프록시를 끄고 클라이언트를 종료하세요. 그래도 복구되지 않으면 Wi-Fi 또는 유선 네트워크를 다시 연결해 시스템이 주소와 DNS를 새로 받도록 하세요. 이후 시스템 프록시가 남아 있는지, 가상 네트워크 인터페이스가 여전히 활성화되어 있는지 확인합니다. 네트워크가 끊긴 상태에서 여러 클라이언트를 연달아 재설치하지 마세요. 기존 서비스, 네트워크 인터페이스와 새 설정이 겹쳐 문제를 판단하기 더 어려워집니다.

절전 모드에서 깨어나거나 네트워크를 전환하거나 회사 네트워크에서 가정용 네트워크로 돌아온 뒤 자동 인터페이스 감지가 잠시 이전 라우팅을 유지할 수 있습니다. TUN 스위치를 한 번 껐다가 켜 클라이언트가 인터페이스를 다시 만들도록 하세요. 특정 네트워크에서만 문제가 반복된다면 당시의 물리 인터페이스, DNS, 라우팅과 로그를 기록한 뒤 인터페이스 제외, 라우팅 제외 또는 다른 stack 사용을 결정하세요. 기업용 VPN과 TUN을 함께 사용할 때는 라우팅 우선순위 충돌이 특히 쉽게 발생하므로 어떤 도구가 어떤 대상 네트워크 대역을 담당할지 명확히 정해야 합니다.

일상 관리, 문제 해결과 고급 설정 경로 만들기

설정을 완료한 뒤 안정적으로 사용하는 데 필요한 것은 계속 매개변수를 조정하는 일이 아니라 반복 가능한 관리 습관입니다. 정상적인 구독 하나, 명확하게 선택한 프록시 그룹, 규칙 모드, 작동하는 시스템 프록시와 필요할 때만 활성화하는 TUN을 포함한 검증된 기본 상태를 유지하세요. 클라이언트, 구독 또는 사용자 지정 규칙을 업데이트할 때마다 이 기본 연결 흐름이 여전히 정상인지 확인하면 됩니다. 여러 단계가 동시에 바뀌면 문제가 생겼을 때 확실한 상태로 돌아가기 어렵습니다.

일상 업데이트는 세 가지로 나누기

클라이언트 업데이트, 코어 업데이트와 구독 업데이트는 서로 다른 작업입니다. 클라이언트 업데이트는 화면, 시스템 통합과 코어 관리 방식을 바꾸고, 코어 업데이트는 설정 문법, 프로토콜과 네트워크 처리에 변화를 줄 수 있습니다. 구독 업데이트는 원격 설정, 노드와 규칙만 새로 고칩니다. 문제가 발생하면 최근 어느 계층이 바뀌었는지 기록하세요. 구독만 업데이트한 뒤 프록시 그룹이 사라졌다면 새 설정 내용을 먼저 확인하고, 클라이언트 업데이트 후 TUN 서비스가 시작되지 않는다면 권한과 서비스 상태를 점검해야 합니다.

일상적으로는 비교적 긴 고정 간격으로 구독을 업데이트하고, 업데이트 후 현재 설정이 계속 선택되어 있는지 확인하세요. 클라이언트를 업그레이드하기 전에 구독 주소, 사용자 지정 오버라이드와 핵심 설정을 기록합니다. 업그레이드 직후 기존 설정을 삭제하지 말고 브라우저 접속, 연결 기록, LAN과 TUN 테스트를 한 번 완료하세요. 장기간 실행되는 기기는 관리 시간에 클라이언트를 한 번 능동적으로 재시작해 서비스 자동 시작, 권한 또는 설정 로드 문제를 조기에 확인하는 것이 좋습니다.

로그와 연결 기록으로 범위 좁히기

연결 기록은 “특정 요청이 어디를 거쳤는가”를 알려 주고, 로그는 “코어가 처리하는 동안 무슨 일이 있었는가”를 보여 줍니다. 웹사이트의 출구가 예상과 다르면 연결 기록을 먼저 확인하고, 구독 파싱, 포트 바인딩, DNS 조회, TUN 초기화와 네트워크 오류는 로그를 확인하는 편이 적합합니다. 문제를 해결할 때 로그 수준은 우선 info로 유지하세요. 대개 충분한 정보가 포함됩니다. debug는 기록이 매우 많아지므로 짧은 문제를 재현할 때만 임시로 켜고 완료 후 되돌리세요.

로그를 추출할 때는 오류 전후의 적은 양의 문맥을 남기고 구독 주소, 인증 필드, 기기 식별자와 불필요한 접속 기록을 제거하세요. 자주 보이는 키워드로는 timeout, connection refused, network unreachable, address already in use, parse error와 permission denied가 있습니다. 각각 시간 초과, 대상의 연결 거부, 라우팅 부재, 포트 점유, 설정 파싱과 권한 문제를 가리킵니다. 먼저 오류 유형에 따라 처리한 뒤 클라이언트 교체를 고려하세요.

안정적인 문제 해결 순서

1. 원래 네트워크 확인. 시스템 프록시와 TUN을 끄고 일반 네트워크로 로컬 및 자주 사용하는 사이트에 접속할 수 있는지 확인하세요. 원래 네트워크에 문제가 있다면 Wi-Fi, 유선 네트워크, 인증 페이지 또는 시스템 DNS부터 해결해야 합니다.
2. 코어 상태 확인. 클라이언트를 실행하고 설정 파싱, 포트 점유 또는 권한 오류가 있는지 확인하세요. 코어가 실행되지 않으면 이후의 모드와 노드 설정은 적용되지 않습니다.
3. 설정 흐름 확인. 구독 업데이트 시간, 현재 선택한 설정, 주요 프록시 그룹과 최종 노드를 확인하세요. 필요하면 구독을 수동으로 업데이트하되 연속해서 반복 요청하지 마세요.
4. 트래픽 인계 확인. 시스템 프록시를 켜고 새 요청을 보낸 뒤 연결 기록을 확인하세요. 기록이 없다면 앱이 시스템 프록시를 사용하지 않거나 로컬 포트 설정에 문제가 있는 것입니다.
5. 규칙과 출구 확인. 규칙 모드와 전역 모드의 결과를 비교하고 대상 도메인에 적용된 규칙을 확인하세요. 전역 모드는 작동하지만 규칙 모드에서 실패한다면 규칙 분할을 집중적으로 점검해야 합니다.
6. 마지막으로 TUN 확인. 기본 연결이 정상인 뒤 TUN을 켜고 DNS, LAN, UDP와 절전 모드 복귀를 각각 테스트하세요. 여러 변수를 한 번에 추가하지 마세요.

구체적인 증상에 따라 계속 점검하려면 문제 해결에서 시스템 프록시, 구독, TUN과 연결 문제의 해당 항목을 확인하세요. 오류를 설명할 때 플랫폼, 클라이언트 이름, 트래픽 인계 방식, 프록시 모드, 연결 기록에 요청이 표시되는지 여부와 오류 유형을 함께 알려 주면 “인터넷이 안 돼요”라는 설명보다 정확한 판단을 받기 쉽습니다.

실제로 유용한 백업 항목

백업할 가치가 있는 항목은 구독 주소 목록, 사용자 지정 규칙 오버라이드, 사용자 지정 DNS 조각, 코어 서비스 설정과 핵심 설정에 대한 간단한 설명입니다. 클라이언트가 설정 내보내기를 지원한다면 보조 수단으로 활용할 수 있지만, 단일 내보내기 파일만 유일한 복구 방법으로 의존하지 마세요. 클라이언트 간 이전에서 가장 범용적인 자료는 여전히 구독 URL과 표준 YAML 조각입니다.

사용자 지정 설정에는 변경 이유를 함께 기록하세요. 특정 도메인 규칙이 어떤 서비스를 위해 필요한지, 특정 LAN 대역을 왜 제외했는지, TUN 매개변수가 어떤 네트워크 환경을 대상으로 하는지 적어 두면 좋습니다. 몇 달 뒤 다시 확인할 때 이러한 설명이 규칙이 여전히 필요한지 판단하는 데 도움이 됩니다. 이유를 기록하지 않은 설정은 계속 쌓여 중복, 충돌과 순서를 이해하기 어려운 문제를 만들기 쉽습니다.

일상 사용에서 고급 설정으로 나아가기

고급 학습은 연결 처리 순서를 따라 진행할 수 있습니다. 먼저 프록시 그룹의 select, url-test와 fallback을 익히고, 다음으로 규칙 세트와 규칙 제공자를 학습한 뒤 DNS의 fake-ip, 분할 DNS와 IPv6을 이해하고 마지막으로 TUN 라우팅, 프로세스 규칙과 독립 코어 배포를 살펴보세요. 각 단계에는 명확한 사용 목적이 있어야 하며 모든 기능을 한 번에 활성화할 필요는 없습니다. 연결 기록을 통해 특정 요청이 왜 어떤 출구를 선택했는지 설명할 수 있는 능력이 많은 매개변수를 외우는 것보다 중요합니다.

여러 기기에서 사용해야 한다면 안정적인 사용자 지정 규칙을 별도 오버라이드 파일로 관리해 원격 구독 본문을 직접 수정하는 일을 줄일 수 있습니다. 서버 환경에서는 최소 수신 범위, 서비스 사용자 권한, 설정 디렉터리 권한, 로그 관리와 시작 실패 시 복구까지 추가로 익혀야 합니다. 그래픽 클라이언트 사용자도 YAML 기초를 알아 두면 병합 결과와 파싱 오류를 이해하는 데 도움이 되지만, 일상적인 수정은 클라이언트가 제공하는 구조화된 입력 방식을 우선 사용하세요.