Clash 사용 및 설정 완벽 가이드

제1장 · 핵심 개념과 연결 경로

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

Clash 생태계의 클라이언트는 일반적으로 그래픽 인터페이스와 프록시 코어로 구성됩니다. 인터페이스에서는 설정을 가져오고 프록시 그룹을 확인하며 시스템 프록시와 로그를 관리합니다. 코어는 로컬 포트를 열고 규칙을 적용해 연결을 설정합니다. mihomo는 이 생태계에서 널리 쓰이는 코어입니다. 인터페이스 이름이 비슷하더라도 포함된 코어, 지원 필드, 권한 방식이 반드시 같지는 않습니다. 설정을 옮기기 전에 대상 클라이언트의 안내를 확인하세요.

설정 파일은 코어가 작동하는 방식을 정의하며, 보통 YAML 형식으로 저장됩니다. 로컬 수신 포트, 사용 가능한 프록시, 프록시 그룹, 라우팅 규칙과 DNS 동작을 지정합니다. 구독은 원격 설정을 가져오는 주소이지 클라이언트 자체가 아니며, 스위치 하나만 켜면 사용할 수 있는 서비스도 아닙니다. 클라이언트가 유효한 설정을 가져와 활성화하고 앱 트래픽이 코어로 들어와야 규칙과 프록시 선택이 적용됩니다.

노드, 프록시 그룹, 규칙의 관계

노드는 연결 매개변수를 포함한 실제 출구를 나타냅니다. 프록시 그룹은 노드나 다른 프록시 그룹을 묶어 관리하는 방식으로, 직접 선택하거나 주기적으로 확인해 자동 선택할 수 있습니다. 규칙은 연결을 어느 출구로 보낼지 결정합니다. 특정 사이트에 문제가 생기면 설정 전체를 반복해서 바꾸기보다 먼저 연결 기록에서 어떤 규칙이 적용됐고 어느 그룹으로 전달됐는지 확인한 다음, 그룹에서 실제로 선택된 노드를 살펴보세요.

브라우저 연결은 하나의 처리 과정으로 볼 수 있습니다. 앱이 시스템 프록시나 자체 설정을 확인해 요청을 로컬 수신 포트로 전달하고, 코어는 확인 가능한 도메인과 주소, 규칙을 바탕으로 출구를 정합니다. 선택된 노드는 대상 서버와 연결을 맺습니다. 각 단계에서 문제가 생길 수 있습니다. 브라우저의 시간 초과 메시지는 연결 과정이 완료되지 않았다는 뜻일 뿐, 구독 만료나 DNS 오류, 서버 장애를 단정할 근거는 아닙니다.

시스템 프록시와 TUN은 서로 다른 계층입니다

시스템 프록시는 앱이 참조하는 운영체제 설정이며, 모든 프로그램이 반드시 따르는 것은 아닙니다. TUN은 가상 네트워크 인터페이스와 라우팅을 통해 트래픽을 받아들이므로 추가 권한, DNS 및 라우팅 설정이 필요합니다. 처음에는 시스템 프록시로 브라우저 연결을 확인하세요. 실제로 시스템 프록시를 우회하는 앱이 있는지 확인한 뒤 TUN 도입을 검토하면, 기본 설정이 작동하지 않는 상황에서 여러 네트워크 계층을 한꺼번에 점검하는 일을 피할 수 있습니다.

로컬 포트도 구분해야 합니다. 혼합 포트는 HTTP 및 SOCKS 프록시 요청을 받을 수 있지만, 컨트롤 인터페이스는 클라이언트가 코어를 관리하는 데 사용됩니다. 두 포트는 서로 바꿔 쓸 수 없습니다. 브라우저 프록시 주소에 컨트롤 인터페이스 주소를 입력하면 대개 연결 오류가 발생합니다. 일상적인 사용에서는 클라이언트가 시스템 프록시를 자동으로 설정하도록 하세요. 다른 기기의 포트를 그대로 따라 하지 말고, 직접 입력해야 한다면 현재 실행 설정에서 실제 값을 확인하세요.

마지막으로 두 가지 ‘업데이트’를 구분하세요. 클라이언트 업데이트는 프로그램과 코어를 교체하고, 구독 업데이트는 원격 설정을 가져옵니다. 클라이언트를 업데이트해도 만료된 구독이 반드시 복구되는 것은 아니며, 구독을 업데이트해도 프로그램 버전은 바뀌지 않습니다. 문제를 기록할 때 두 변경 사항을 구분하고, 장애 발생 전 마지막으로 연결에 성공했던 조건을 남겨 두세요. 다음 장에서 문제를 해결할 때 유용한 기준이 됩니다.

제2장 · 운영체제에 맞는 클라이언트 선택

기기를 확인한 뒤 인터페이스를 비교하세요

클라이언트는 운영체제와 프로세서 아키텍처, 트래픽을 처리해야 할 앱을 먼저 고려한 다음 인터페이스 취향을 살펴보세요. 처음 설치한다면 다운로드 페이지의 Clash Plus부터 시작하는 것을 권장합니다. 설정 관리 방식, 데스크톱 통합, 코어 설정 메뉴를 비교하고 싶다면 클라이언트 비교를 확인하세요. 특정 스크린샷에 나온 스위치를 찾으려고 네트워크 처리 도구를 여러 개 설치해 동시에 실행하지 마세요.

Windows에서는 ‘설정 → 시스템 → 시스템 정보’에서 시스템 종류를 확인해 프로세서 아키텍처를 파악하세요. macOS에서는 ‘이 Mac에 관하여’에서 칩 또는 프로세서 이름을 확인할 수 있습니다. Apple Silicon과 Intel용 설치 파일은 파일 크기만으로 구분할 수 없습니다. 다운로드 페이지에 표시된 아키텍처 중에서 선택하고, 기기와 맞지 않는다면 먼저 지원 여부를 확인하세요. 다른 플랫폼의 설치 파일 이름을 바꿔 실행하지 마세요.

외관보다 설정 호환성이 중요합니다

같은 플랫폼이라도 클라이언트마다 설정을 처리하는 방식이 다를 수 있습니다. 구독에 덮어쓰기 계층을 추가하는 클라이언트도 있고 로컬 파일을 직접 편집하는 클라이언트도 있으며, 특정 형식만 지원하는 경우도 있습니다. 특히 Surfboard가 같은 다운로드 페이지에 있다는 이유만으로 임의의 Clash YAML을 바로 읽을 수 있다고 가정하면 안 됩니다. 먼저 클라이언트의 지원 설정 형식을 확인하고, 설정 제공업체에서 호환되는 내용을 받으세요. 형식 오류를 네트워크 장애로 오인하지 않도록 주의하세요.

데스크톱에서는 설정을 자주 바꿔야 한다면 프록시 그룹 표시, 덮어쓰기 메뉴, 로그 내보내기, 종료 시 프록시 복원 방식을 비교할 수 있습니다. 모바일에서는 연결 상태를 화면에 표시하는지, 백그라운드 제한이 있는지, 앱별로 트래픽을 처리할 수 있는지가 더 중요합니다. 기능이 많다고 현재 기기에 더 적합한 것은 아닙니다. 설정 가져오기, 연결, 검증, 종료 후 복원을 안정적으로 할 수 있는 클라이언트를 이후 설정 실험의 기본 환경으로 삼으세요.

iPhone에서는 다운로드 페이지에서 Clash Plus의 App Store 페이지로 이동하거나 공식 웹사이트 clashplus.io에서 제품 안내를 확인할 수 있습니다. 설치한 뒤 먼저 설정 목록과 연결 메뉴를 살펴보고, 시스템에서 VPN 설정을 추가하도록 허용하세요. iOS의 백그라운드 실행과 네트워크 권한은 운영체제가 관리하므로 데스크톱의 서비스 설치, 시스템 트레이, 로컬 포트 설정을 휴대폰에 그대로 적용할 수는 없습니다.

유지 관리가 종료된 클라이언트와 독립 코어

Clash for Windows와 ClashX Meta는 이 사이트에서 유지 관리가 중단된 보관용 클라이언트로 소개합니다. 기존 환경의 호환성을 확인할 때 참고할 수 있지만 신규 설치용으로 권장하지는 않습니다. 예전 가이드에 해당 인터페이스가 나온다고 해서 현재도 같은 설치 절차를 따라야 한다는 뜻은 아닙니다. 새 기기에는 유지 관리 중인 클라이언트를 선택하고, 가이드에서 설명하는 개념을 현재 메뉴에 맞춰 적용하면 권한 및 설정 호환성 문제를 줄일 수 있습니다.

독립형 mihomo 코어는 프로세스, 설정 디렉터리, 네트워크 규칙을 직접 관리해야 하는 사용자를 위한 것입니다. 완전한 데스크톱 인터페이스를 대체하는 설치 파일이 아니며, 실행해도 모든 시스템 통합 기능이 자동으로 제공되지는 않습니다. 서버나 라우터 환경에서는 서비스 시작과 접근 제어도 설정해야 합니다. 일반 데스크톱 사용자는 그래픽 클라이언트를 쓰면 프로세스 관리나 시스템 라우팅의 세부 사항보다 설정 자체에 집중할 수 있습니다.

클라이언트를 옮길 때는 먼저 기존 클라이언트의 시스템 프록시와 TUN을 끄고 프로그램을 종료한 다음 새 클라이언트를 실행하세요. 이해하는 설정, 규칙, 덮어쓰기만 옮기고 의미를 알 수 없는 실행 디렉터리는 복사하지 마세요. 이전 후에는 포트, 프록시 그룹 선택, DNS 동작을 다시 확인하세요. 같은 구독이라도 클라이언트별 기본 설정이 다르게 적용될 수 있어 연결 결과가 완전히 같지 않을 수 있습니다.

제3장 · 설치, 권한, 첫 실행

설치 전에 기존 네트워크 설정 정리하기

설치를 시작하기 전에 기존 프록시 클라이언트를 종료하고 기본 네트워크에서 브라우저가 제대로 연결되는지 확인하세요. 기기에서 수동 프록시를 사용한 적이 있다면 주소와 포트를 기록한 뒤 끌지 결정합니다. 이렇게 하면 설치 후 문제가 생겼을 때 기존 네트워크 문제와 새 설정으로 인한 변화를 구분할 수 있습니다. 회사나 학교에서 관리하는 기기에서는 관리 규칙을 따르고, 조직의 설정을 우회해 시스템 서비스를 설치하지 마세요.

클라이언트 다운로드 페이지에서 운영체제와 아키텍처에 맞는 파일을 선택하세요. Windows에서는 설치 마법사를 완료한 뒤 시작 메뉴에서 실행합니다. macOS에서 디스크 이미지 파일을 받았다면 열고 안내에 따라 앱을 응용 프로그램 폴더로 옮긴 다음 그 위치에서 실행하세요. 임시 압축 해제 폴더나 디스크 이미지에서 계속 실행하면 업데이트, 보조 서비스 경로, 로그인 시 실행 설정에 문제가 생길 수 있습니다.

권한 요청을 필요한 기능과 연결해 확인하세요

처음 실행하면 메인 화면, 설정 목록, 로그 메뉴부터 확인하고 모든 권한을 바로 허용하지 마세요. 일반적인 설정 가져오기와 시스템 네트워크 처리를 위해 필요한 권한은 다릅니다. TUN이나 서비스 모드는 관리자 승인이 필요할 수 있고, 알림 권한은 주로 상태 안내에 영향을 줍니다. 권한을 허용하기 전에 시스템 창에 표시된 앱 이름과 작업 목적을 확인하세요. 모르는 프로그램이 요청한다면 취소하고 설치 경로와 진행 중인 작업을 확인하세요.

macOS에서 앱을 열 수 없거나 시스템 확장 관련 알림이 표시되면 먼저 파일 출처를 확인한 뒤, 시스템 설정의 개인정보 보호 및 보안 관련 화면에서 원인을 살펴보고 시스템이 안내하는 방법으로 처리하세요. 기기 전체의 보안 기능을 끄는 것을 일반적인 설치 절차로 삼지 마세요. 키체인이나 네트워크 확장 권한은 일반적인 구독 가져오기와 별개입니다. 같은 알림이 반복되면 앱이 원래 설치 위치에 있는지, 보조 구성 요소가 제대로 설치됐는지 확인하세요.

Android에 설치한 뒤 클라이언트에서 설정을 가져오고 연결을 누른 다음, 시스템에 표시되는 VPN 연결 확인 창을 읽어 보세요. 실행 중인 앱이 시스템에 의해 자주 종료된다면 배터리 및 백그라운드 관리에서 해당 앱의 제한을 확인하되, 처음부터 모든 절전 옵션을 바꿀 필요는 없습니다. 일부 시스템에서는 일반 VPN 서비스를 하나만 활성화할 수 있습니다. 다른 VPN 앱을 실행하면 현재 연결이 끊길 수 있으며, 이것이 반드시 클라이언트 자체의 문제는 아닙니다.

iOS에서도 시스템에서 VPN 설정 추가를 승인해야 합니다. 승인 후 클라이언트로 돌아와 설정이 선택됐는지 확인하고 연결하세요. Linux에서는 배포판에 맞는 패키지 형식을 확인한 뒤 데스크톱 설치 도구나 배포판 패키지 관리자로 설치하고, 종속성 누락 메시지를 살펴보세요. 데스크톱 앱 실행 문제와 코어 설정 오류는 따로 해결해야 합니다. 먼저 앱 시작 오류를 확인하고, 코어 설정 오류는 설정과 로그를 살펴보세요.

첫 실행 시 확인 순서 정하기

구독이 없을 때 메인 화면에 연결되지 않음이나 빈 프록시 그룹이 표시되는 것은 일반적입니다. 먼저 설정, 프록시, 연결, 로그 페이지를 찾아 프로그램이 설정을 정상적으로 저장하는지 확인하세요. 그런 다음 로컬 수신 포트를 확인하고 시스템 프록시와 TUN이 각각 켜져 있는지 기록합니다. 첫 테스트에서는 시스템 프록시만 켜고 다른 트래픽 처리 기능은 끄세요. 이렇게 하면 다음 장의 구독 검증에서 원인과 결과를 명확히 파악할 수 있습니다.

Windows에서는 PowerShell로 예시 포트의 수신 여부를 확인할 수 있습니다. 아래 숫자는 조회 대상 포트의 예시일 뿐이므로 클라이언트의 실제 설정에 맞춰 변경하세요. 프로세스가 검색되면 작업 관리자에서 어떤 프로그램인지 확인하고 정상적으로 종료하세요. 모르는 시스템 프로세스를 강제 종료하지 마세요. 포트에서 수신 대기 중인 항목이 없다고 해서 네트워크가 반드시 정상인 것은 아닙니다. 현재 조회 범위에서 해당 수신 항목을 찾지 못했다는 뜻일 뿐입니다.

Get-NetTCPConnection -LocalPort 7890 -State Listen

마지막으로 종료 후 복원을 테스트하세요. 시스템 프록시와 TUN을 끄고 클라이언트를 종료한 뒤, 일반 직접 연결이 예상대로 작동하는지 확인합니다. 종료 후 브라우저에서 프록시 서버를 사용할 수 없다는 메시지가 계속 표시되면 시스템에 로컬 프록시 설정이 남아 있는지 살펴보세요. 네트워크 진입점을 먼저 복구한 뒤 클라이언트를 다시 시작하세요. 연결 문제가 생긴 후 급히 스위치를 찾는 것보다 설치 단계에서 복원 절차까지 확인하는 편이 안전합니다.

제4장 · 구독 가져오기와 설정 적용

구독 링크와 실제 설정을 구분하세요

구독 링크는 보통 설정 서비스 제공업체가 발급하며 개인을 식별할 수 있는 정보가 포함될 수 있으므로 민감한 정보로 취급해야 합니다. 전체 링크를 공개 스크린샷, 온라인 변환 사이트, 문의 글에 올리지 마세요. 이 사이트에서는 설정 사용 방법을 안내하며 장기간 사용할 수 있는 공개 구독은 제공하지 않습니다. Clash 무료 노드를 검색할 때도 출처, 유효 기간, 데이터 위험을 먼저 평가하고, 임시로 받은 설정을 일상적인 연결의 안정적인 기반으로 삼지 마세요.

링크를 받은 뒤 클라이언트의 ‘설정’, ‘구독’ 또는 Profile 페이지를 열고 원격 설정 추가를 선택하세요. URL 입력란에 주소를 붙여 넣고 알아보기 쉬운 이름을 지정한 다음 가져오기 또는 다운로드를 누릅니다. 이름은 ‘일상 설정’처럼 용도를 나타내되 접근 식별 정보는 포함하지 마세요. 가져온 뒤에는 설정 항목, 업데이트 시간, 사용 가능한 프록시 그룹이 표시되어야 합니다. 다운로드 대기 중인 빈 항목만 보여서는 안 됩니다.

다운로드에 성공한 뒤 활성화해야 합니다

가져오기에 성공해도 실행 설정이 자동으로 전환된다는 뜻은 아닙니다. 설정 목록에서 방금 가져온 항목을 선택하고 활성화, 사용 또는 해당 선택 표시를 누른 뒤 프록시 페이지에서 그룹 이름과 선택지가 바뀌었는지 확인하세요. 일부 클라이언트는 코어를 자동으로 다시 불러오지만, 별도 확인이 필요한 경우도 있습니다. 이전 프록시 그룹이 계속 보인다면 설정 페이지로 돌아가 활성화 상태를 확인하세요. 클라이언트를 재설치하거나 같은 구독을 반복해서 추가할 필요는 없습니다.

로컬 YAML 가져오기는 이미 파일이 있거나 오프라인에서 편집해야 할 때 적합합니다. ‘파일에서 가져오기’를 선택한 다음 설정 파일 자체를 가져오는지 확인하세요. 압축 파일, 웹페이지로 저장된 파일, 스크린샷을 선택하면 안 됩니다. 원격 설정은 보통 업데이트를 가져올 수 있지만 로컬 파일은 사용자가 직접 관리해야 합니다. 디스크의 원본 파일 편집이 클라이언트에 반영되는지는 파일을 참조하는지 복사하는지에 따라 달라집니다. 작은 변경을 한 뒤 다시 불러와 확인하세요.

가져오기에 형식 오류가 표시되면 오류 위치와 응답 유형부터 살펴보세요. 구독 주소가 로그인 페이지, 접근 제한 안내, 서비스 만료 페이지를 반환할 수 있습니다. 이 내용은 YAML이 아니므로 브라우저에서 열리더라도 코어에서 사용할 수 없습니다. 붙여 넣을 때 공백, 줄바꿈, 전각 문장 부호가 섞이지 않았는지도 확인하세요. 구독 관리 웹페이지 주소와 실제 설정 주소는 다른 경우가 많으므로 혼동하지 마세요.

YAML의 구조 규칙 이해하기

YAML은 들여쓰기로 계층을 표현하며, 일반적으로 탭 대신 공백을 사용합니다. 같은 계층의 필드는 들여쓰기를 맞추고 목록 항목의 하이픈 위치도 일정하게 유지해야 합니다. 아래 예시는 기본 설정 일부만 보여 주며 사용할 수 있는 프록시는 포함하지 않으므로 완전한 구독 설정으로 단독 사용할 수 없습니다. 최상위 필드 구조를 파악하기 위한 예시입니다. 모드, 로그 수준, 수신 설정은 같은 계층에 있으며 특정 프록시 노드 안에 들여쓰면 안 됩니다.

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

구독을 업데이트하기 전에 클라이언트가 설정을 저장하는 방식을 이해하세요. 원격 설정의 규칙을 직접 수정하면 다음 업데이트에서 변경 사항이 덮어써질 수 있습니다. 오래 유지할 로컬 변경 사항은 클라이언트가 지원하는 덮어쓰기 또는 병합 기능에 넣어야 합니다. 초기에는 복잡한 덮어쓰기를 추가하지 말고 원본 구독을 불러와 연결할 수 있는지 확인한 뒤 사용자 설정을 하나씩 추가하세요. 매번 최종 적용 설정을 확인해야 편집 창에서만 바뀌고 실제로는 적용되지 않은 상황을 피할 수 있습니다.

자동 업데이트 간격은 지나치게 짧게 설정하지 말고 제공업체의 권장 값을 따르는 것이 좋습니다. 자주 업데이트해도 만료된 서비스가 복구되지는 않으며, 접근 제한이 발생할 수 있습니다. 업데이트에 실패해도 마지막으로 사용할 수 있었던 설정을 즉시 삭제하지 말고 내용을 보존한 상태에서 가져오기를 따로 테스트하세요. 시간 초과, 빈 응답, 형식 오류를 구분해야 한다면 구독 파싱 오류 자가 점검 목록을 참고해 단계별로 확인하세요.

같은 구독이 이전 클라이언트에서는 작동하지만 새 클라이언트에서 오류가 난다면 우선 코어가 지원하는 필드와 설정 형식을 비교하세요. 전체 설정을 공개해 도움을 요청하지 마세요. 노드 주소, 인증 정보, 구독 식별 정보를 가린 뒤 오류 주변의 구조와 메시지만 남겨 내보내면 들여쓰기, 알 수 없는 필드, 형식 비호환 문제를 판단하는 데 충분한 경우가 많습니다.

제5장 · 프록시 모드와 연결 확인

진입점과 출구를 나눠 확인하세요

클라이언트의 ‘규칙’, ‘전역’, ‘직접 연결’ 모드는 주로 트래픽이 코어에 들어온 뒤 출구를 선택하는 방식을 정합니다. 시스템 프록시와 TUN은 앱 트래픽이 코어에 들어올 수 있는지를 결정합니다. 모드를 전역으로 바꿔도 모든 앱의 트래픽이 자동으로 처리되는 것은 아닙니다. 확인할 때는 먼저 클라이언트의 연결 페이지를 열고 명확한 테스트 대상에 브라우저로 접속하세요. 새 연결이 표시되는지 확인한 다음 모드와 노드 선택을 살펴보세요.

일상적인 사용은 보통 규칙 모드부터 시작합니다. 프록시 페이지에서 주요 선택 그룹을 찾아 사용 가능한 노드를 하나 직접 선택한 다음 시스템 프록시를 켜세요. 테스트 중에는 브라우저와 테스트 주소를 그대로 유지하고 연결이 이루어지는지 먼저 확인합니다. 이후 연결 세부 정보에서 적용된 규칙과 실제 출구를 살펴보세요. 노드 테스트에 성공했다는 것은 특정 탐색 요청이 완료됐다는 뜻일 뿐, 모든 사이트와 프로토콜, 장시간 연결이 정상이라는 보장은 아닙니다.

전역 모드로 제한적인 비교 테스트하기

규칙 모드에서 특정 대상에 연결할 수 없다면 잠시 전역 모드로 전환하고 전역 그룹에서 실제로 어떤 노드를 선택했는지 확인할 수 있습니다. 같은 진입점과 노드에서 전역 연결은 되는데 규칙 모드만 실패한다면 규칙 적용 결과와 대상 정책 그룹을 살펴보세요. 두 모드 모두 실패하면 노드, DNS 응답, 상위 네트워크를 계속 점검합니다. 비교가 끝나면 규칙 모드로 되돌려 이후 테스트가 임시 설정으로 진행되지 않도록 하세요.

직접 연결 모드라고 해서 시스템 설정이 완전히 원래대로 돌아가는 것은 아닙니다. 앱은 여전히 로컬 프록시 포트를 통해 코어에 연결될 수 있으며 DNS와 트래픽 관찰 방식도 클라이언트의 영향을 받을 수 있습니다. 완전히 종료한 뒤의 네트워크를 확인하려면 먼저 시스템 프록시와 TUN을 끄고 클라이언트를 종료한 다음 별도로 테스트하세요. ‘코어의 직접 연결’과 ‘클라이언트 완전 종료’를 별개의 테스트 조건으로 구분해야 문제 범위를 잘못 판단하지 않습니다.

연결 기록이 없을 때 단계별로 확인하기

브라우저로 접속해도 새 기록이 없다면 시스템 프록시가 실제로 켜져 있는지, 프록시 주소가 현재 수신 포트를 가리키는지 확인하세요. 브라우저 확장 프로그램, 사용자 지정 프록시 설정, 앱 내부 네트워크 설정이 시스템 설정을 덮어쓸 수 있습니다. 다른 클라이언트가 시스템 프록시를 바꿨을 수도 있습니다. 불필요한 프록시 확장 기능을 잠시 끄고 클라이언트 하나만 실행한 뒤 요청을 다시 보내 연결 페이지에 변화가 있는지 살펴보세요.

기록은 생기지만 연결에 실패한다면 세부 정보를 열어 대상 도메인, 대상 포트, 정책 경로, 오류 메시지를 확인하세요. 시간 초과, 연결 거부, DNS 조회 실패는 서로 다른 계층의 문제이므로 모두 ‘노드 변경’으로 처리해서는 안 됩니다. 같은 대상을 두 개의 설정된 출구에서 비교하고, 같은 출구에서 두 개의 대상을 비교하세요. 한 번에 하나의 변수만 바꾸면 대상 서비스의 제한, 특정 노드 문제, 로컬 설정 문제를 더 명확하게 구분할 수 있습니다.

명령줄 프로그램은 데스크톱 시스템 프록시를 사용하지 않을 수도 있습니다. 로컬 HTTP 프록시를 별도로 확인하려면 아래 요청을 사용하고, 주소와 포트는 현재 실행 설정에 맞추세요. 예시 도메인은 테스트 방법을 설명하기 위한 것이므로 현재 네트워크에서 접속 가능하다고 보장하지 않습니다. 명령으로 응답을 받았다는 것은 이번 요청이 지정된 진입점을 통해 처리됐다는 뜻일 뿐, 브라우저나 다른 앱의 실제 연결 기록을 확인한 것과 같지는 않습니다.

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

모드나 노드를 바꿔도 기존 연결은 이전 출구를 계속 사용할 수 있습니다. 새 설정을 확인하려면 요청을 다시 보내세요. 필요하다면 관련 연결만 끊거나 테스트 앱을 다시 열면 되며 시스템 네트워크 설정 전체를 초기화할 필요는 없습니다. 브라우저 캐시, 연결 재사용, 오프라인 페이지 때문에 결과를 잘못 판단할 수도 있습니다. 이미 열려 있는 페이지가 계속 표시되는지만 보지 말고 새 연결이 만들어졌는지와 연결 시간을 확인하세요.

이 장을 마칠 때는 간단한 기준을 정리해 두세요. 어떤 클라이언트를 사용하는지, 어떤 설정을 활성화했는지, 어느 그룹과 노드를 선택했는지, 어떤 진입점으로 접속했는지, 어떤 대상에 연결됐는지를 기록합니다. 다음 장에서 규칙을 수정한 뒤 같은 조건으로 다시 테스트하세요. 특정 상황에서만 속도 문제가 생긴다면 연결 속도 단계별 문제 해결을 참고하세요. DNS, 모드, 구독 전체를 동시에 바꾸지 마세요.

제6장 · 규칙 기반 라우팅과 설정 순서

위에서부터 확인해 첫 번째 규칙을 적용합니다

규칙 모드는 연결을 위에서 아래로 확인하며 보통 처음 일치하는 규칙에서 정책을 결정합니다. 더 구체적인 예외는 범위가 넓은 규칙보다 앞에 놓고, 최종 기본 규칙은 목록 끝에 둡니다. 규칙을 추가해도 효과가 없다면 먼저 앞쪽에 먼저 일치하는 항목이 있는지 확인하고 대상 이름과 정책 그룹이 올바른지 살펴보세요. 같은 규칙을 목록 끝에 반복해서 복사해도 앞선 규칙이 이미 처리한 연결에는 영향을 주지 않습니다.

도메인 규칙은 서비스 이름에 따라 트래픽을 나눌 때 적합하고, IP 대역 규칙은 명확한 네트워크 범위를 처리할 때 유용합니다. 도메인 접미사 규칙은 지정한 도메인과 하위 도메인을 대상으로 합니다. 이를 키워드 규칙으로 단순히 바꾸면 매칭 범위가 넓어질 수 있습니다. 앱이 코어에 도메인을 전달하는지에 따라 도메인 규칙의 작동 여부도 달라집니다. 연결 페이지에 IP만 표시된다면 DNS 처리 방식도 함께 확인해야 하며, 규칙 문법 오류라고 곧바로 단정할 수 없습니다.

mode: rule
rules:
  - DOMAIN-SUFFIX,example.com,DIRECT
  - IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
  - MATCH,PROXY

이 규칙은 병합 예시이며 완전한 프록시 정의는 포함하지 않습니다. DIRECT는 내장된 직접 연결 정책입니다. PROXY는 실제 설정의 프록시 또는 프록시 그룹 이름과 정확히 일치해야 하며, 해당 이름이 없다면 기존 그룹 이름으로 바꿔야 합니다. 마지막 MATCH는 앞에서 일치하지 않은 연결을 처리하므로 다른 규칙보다 앞에 두면 안 됩니다. 복사하기 전에 자신의 그룹 이름을 확인하고, 예시의 형식이 완전하다는 이유만으로 전체 설정 파일을 덮어쓰지 마세요.

주소 규칙과 DNS 조회 범위

주소 대역 규칙의 접두사 길이는 네트워크 범위를 나타내며 포트 번호가 아닙니다. 예시의 사설 주소 대역은 로컬 네트워크를 직접 연결하는 방법을 보여 주지만 실제 가정이나 회사 네트워크가 같은 대역을 사용한다고 볼 수는 없습니다. 게이트웨이와 기기 주소를 확인해 적용하세요. 범위가 넓은 공인 IP 대역을 직접 연결 목록에 함부로 넣지 마세요. 너무 넓게 매칭하면 프록시가 필요한 대상이 먼저 일치해 일부 사이트가 간헐적으로 연결되지 않는 것처럼 보일 수 있습니다.

no-resolve는 규칙 매칭을 위해 도메인 조회를 능동적으로 실행하지 않는다는 뜻이지, 전체 DNS를 끄는 설정은 아닙니다. 연결에 대상 IP가 이미 있다면 주소 범위를 기준으로 계속 판단할 수 있습니다. 추가 여부는 규칙의 목적과 DNS 정책에 따라 결정하세요. 조회된 IP를 기준으로 트래픽을 나눠야 한다면 추가 DNS 조회의 영향을 이해해야 합니다. 원래 IP로 접속하는 요청만 처리하려는 경우 불필요한 조회 단계를 줄일 수 있습니다.

원격 규칙 세트와 로컬 덮어쓰기

규칙이 많아지면 코어에서 지원하는 규칙 프로바이더로 원격 또는 로컬 규칙 세트를 관리할 수 있습니다. 규칙 세트의 내용 형식은 지정된 동작 유형과 일치해야 합니다. 예를 들어 도메인 목록과 완전한 규칙 목록은 서로 바꿔 쓸 수 없습니다. 파일을 다운로드할 수 있다고 해서 반드시 파싱되는 것은 아닙니다. 참조 이름, 캐시 경로, 업데이트 시간도 확인하세요. 원격 가져오기가 실패했는데 이전 캐시를 새 규칙으로 착각할 수 있습니다.

그래픽 클라이언트는 구독 규칙, 로컬 덮어쓰기, 병합 스크립트를 조합해 최종 설정을 만들 수 있습니다. 편집기에 표시된 순서가 코어가 실제로 읽는 순서와 다를 수도 있습니다. 수정한 뒤에는 최종 설정이나 실행 설정 미리보기를 열고 대상 항목을 검색해 위치와 정책 이름을 확인하세요. 그런 다음 연결 페이지에서 실제 적용 결과를 살펴보세요. ‘편집, 미리보기, 다시 불러오기, 검증’ 과정을 거치는 편이 저장 완료 알림만 보는 것보다 확실합니다.

앱 로그인과 웹페이지 접속이 서로 다른 출구를 사용하는 것처럼 보이면 먼저 실제 대상 연결을 확인하세요. 한 번의 작업에서도 인증, 리소스, API 등 여러 도메인에 연결할 수 있으므로 주소창에 표시된 기본 도메인에만 규칙을 추가해서는 안 됩니다. 연결 기록에서 필요한 대상을 하나씩 확인하고 범위가 명확한 규칙을 우선하세요. 한 번의 실패를 해결하려고 모든 트래픽을 전역 모드로 바꾸면 규칙 누락의 원인을 해결하는 대신 감출 뿐입니다.

규칙 관리의 목표는 항목 수를 늘리는 것이 아니라 동작을 설명할 수 있게 만드는 것입니다. 사용자 지정 예외의 목적과 취소 조건을 기록하고 만료된 항목은 제때 정리하세요. 구독에 같은 규칙이 이미 포함돼 있다면 별도로 덮어써야 하는지 검토합니다. 이 장을 마치면 연결 대상, 적용된 규칙, 정책 경로를 바탕으로 출구를 설명할 수 있어야 합니다. 페이지가 열리는지만 보고 트래픽 분리 결과를 추측해서는 안 됩니다.

제7장 · TUN, DNS, 라우팅 처리

TUN을 켜야 하는 이유부터 확인하세요

TUN은 가상 네트워크 인터페이스를 통해 트래픽을 받아들이며, 시스템 프록시를 따르지 않는 앱에 주로 사용됩니다. 속도를 높이는 스위치도 아니고 사용할 수 없는 노드나 잘못된 구독을 고쳐 주지도 않습니다. 먼저 제5장의 시스템 프록시 기준이 정상적으로 작동하는지 확인한 다음 대상 앱이 실제로 코어에 들어오지 않는지 판단하세요. 브라우저 프록시 확장 설정만 잘못된 경우에는 진입점을 바로잡으면 됩니다. 가상 네트워크 인터페이스, 시스템 라우팅, DNS 처리를 한꺼번에 추가할 필요는 없습니다.

TUN을 켜기 전에 현재 네트워크 인터페이스, 다른 VPN 상태, 클라이언트를 종료하는 방법을 기록하세요. 데스크톱에서는 보조 서비스 설치나 권한 상승이 필요할 수 있으며, 모바일에서는 시스템 VPN 인터페이스로 관리됩니다. 클라이언트가 제공하는 TUN 스위치와 기본 설정을 우선 사용하세요. 그래픽 인터페이스의 트래픽 처리를 켜는 동시에 서버 설정 가이드를 따라 시스템 라우팅을 직접 추가하면 중복 규칙이 생기거나 원래대로 되돌리기 어려워질 수 있습니다.

서로 연동되는 설정으로 이해하세요

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

이 코드는 mihomo TUN 설정 일부로, 기존 설정에 병합해야 합니다. 완전한 DNS 및 프록시 설정을 대신하지 않습니다. auto-route는 자동 라우팅을 제어하고 auto-detect-interface는 출구 인터페이스를 자동으로 감지합니다. 프로토콜 스택 옵션은 현재 코어의 지원 여부에 맞춰야 합니다. 일부 클라이언트는 이 필드를 자동으로 생성하므로 파일 설정과 인터페이스 설정이 서로 덮어쓰지 않도록 가능하면 인터페이스에서 수정하세요.

dns-hijack의 예시는 조건에 맞는 일반 DNS 요청을 가로채는 설정이며, 모든 암호화된 DNS나 앱 자체의 DNS 처리를 다룬다는 뜻은 아닙니다. 브라우저의 보안 DNS, 앱 내 암호화 DNS, 기업 내부 도메인에 따라 실제 결과가 달라질 수 있습니다. 먼저 명확한 DNS 처리 방식을 하나 유지하고 도메인이 예상한 DNS 경로를 따르는지 확인하세요. DNS라는 문구가 보인다는 이유로 모든 DNS 서버를 동시에 바꾸지 마세요.

fake-ip와 로컬 DNS 조회 이해하기

fake-ip 모드에서는 도메인에 매핑된 주소를 반환하고 코어가 도메인과 연결의 대응 관계를 관리해 이후 트래픽을 분리합니다. 이 주소는 대상 서버의 실제 공인 IP가 아니므로 사이트 위치나 노드 경로를 판단하는 데 사용할 수 없습니다. 실제 주소, 로컬 기기 검색, 특정 검증 방식에 의존하는 일부 앱은 예외 처리가 필요할 수 있습니다. 클라이언트와 코어가 지원하는 필터 기능에 따라 처리하고 모든 트래픽 분리를 통째로 끄지는 마세요.

로컬 프린터, 파일 공유, 회사 내부 도메인은 별도로 테스트해야 합니다. 로컬 DNS, 특정 네트워크 대역 라우팅, 브로드캐스트 검색에 의존할 수 있어 공용 도메인 규칙 하나만으로 해결되지 않습니다. TUN을 켠 뒤 게이트웨이, 로컬 기기, 자주 사용하는 내부 서비스를 먼저 테스트하고 외부 대상은 그다음에 확인하세요. 내부 리소스만 문제가 있다면 직접 연결 라우팅과 DNS 경로를 점검하세요. 모든 프록시 노드를 원인으로 취급하지 마세요.

충돌 확인과 안전한 복구

다른 VPN, 가상 머신 네트워크, 컨테이너 브리지, 보안 소프트웨어도 라우팅을 바꿀 수 있습니다. 모든 앱의 연결이 끊기면 먼저 TUN을 끄고 기본 네트워크가 복구되는지 확인한 다음 충돌 요인을 하나씩 점검하세요. 네트워크 인터페이스가 여러 개인 환경에서는 자동 출구 감지가 예상과 다를 수 있습니다. 특히 유선과 무선 연결을 동시에 사용하는 경우 주의하세요. 인터페이스를 직접 지정해야 한다면 다른 기기의 예시를 복사하지 말고 현재 기기의 실제 이름을 사용하세요.

브라우저는 되는데 특정 앱만 실패한다면 해당 앱의 프로토콜과 대상 포트, 노드가 관련 전송 방식을 지원하는지 확인하세요. UDP 트래픽의 작동 여부는 노드 기능, 코어 설정, 상위 네트워크에도 영향을 받습니다. TUN이 부족한 기능을 자동으로 보완해 주지는 않습니다. 연결 세부 정보에서 요청이 들어왔는지, 어떤 프로토콜을 사용했는지, 어느 단계에서 오류가 났는지 확인해야 처리 범위를 조정할지 테스트 출구를 바꿀지 결정할 수 있습니다.

테스트가 끝나면 복구 절차를 한 번 확인하세요. TUN을 끄고 가상 인터페이스와 자동 라우팅 상태가 클라이언트의 예상과 일치하는지 확인한 다음 시스템 프록시 기준 설정을 복원합니다. 기기가 절전 모드에서 깨어나거나 무선 네트워크를 바꾸거나 유선 케이블을 뺐다 꽂은 뒤에도 출구 인터페이스와 DNS가 정상인지 다시 살펴보세요. 이런 일상적인 상황에서도 안정적일 때 TUN을 장기 사용 방식으로 선택하세요. 그렇지 않다면 더 단순한 진입점을 유지하는 편이 관리하기 쉽습니다.

제8장 · 업데이트, 백업, 문제 해결

복구할 수 있는 설정 기준을 저장하세요

안정적으로 작동하면 현재 클라이언트, 활성화된 설정, 주요 프록시 그룹 선택, 시스템 프록시 및 TUN 상태를 기록하고 필요한 로컬 덮어쓰기를 저장하세요. 백업은 구독 주소 하나를 복사하는 데 그치지 않습니다. 직접 작성한 규칙과 병합 방식도 포함해야 합니다. 원격 구독은 다시 가져올 수 있지만 로컬 변경 사항에는 다른 사본이 없을 수 있습니다. 클라이언트를 재설치해야 하는 경우 프로그램 파일을 처리하기 전에 해당 내용을 내보내세요.

백업에는 노드 인증 정보, 구독 식별 정보, 컨트롤 인터페이스 설정이 포함될 수 있으므로 접근을 통제할 수 있는 곳에 보관하세요. 공개 코드 저장소나 공개 클라우드 드라이브에 올리지 마세요. 스크린샷과 로그에도 접속 대상이나 기기 경로가 노출될 수 있으니 공유하기 전에 가리세요. 문제 해결에 필요한 것은 구조, 오류, 발생 순서이지 계정 정보 전체가 아닙니다. 필요한 내용만 남기면 문제 설명도 더 명확해집니다.

업데이트를 세 가지 작업으로 나누세요

클라이언트 업그레이드, 코어 업데이트, 구독 새로고침은 따로 진행하고 각각 검증해야 합니다. 현재 정상 상태를 기록한 뒤 한 번에 하나만 실행하고 설정을 불러올 수 있는지, 자주 사용하는 대상에 접속되는지 확인한 다음 다음 작업을 진행하세요. 프로그램, 코어, 구독, DNS를 한 번에 모두 바꾸면 문제가 완화되더라도 실제 원인을 알아내기 어렵고 다음에 비슷한 문제가 생겼을 때 복구도 더 어려워집니다.

업그레이드 전에 변경 사항을 읽고 특히 설정 필드, 서비스 모드, 기본 동작의 변경 여부를 확인하세요. 버전 번호만 보고 현재 환경에 적합한지 판단하지 말고 최신 버전을 쓰려고 클라이언트 코어 파일을 임의로 교체하지도 마세요. 일부 그래픽 클라이언트는 코어와 인터페이스가 함께 작동하도록 설계되어 수동으로 교체하면 컨트롤 인터페이스나 설정 생성 기능이 호환되지 않을 수 있습니다. 클라이언트가 공식적으로 제공하는 업데이트 경로를 우선 사용하고 복구에 필요한 로컬 설정을 보존하세요.

영향 범위를 좁혀 문제를 해결하세요

문제가 발생하면 먼저 영향 범위를 판단하세요. 모든 앱인지 특정 앱인지, 모든 대상인지 특정 도메인인지, 현재 네트워크에서만 발생하는지 네트워크를 바꾼 뒤에도 같은지 확인합니다. 그런 다음 제5장에서 기록한 기준으로 돌아가 설정과 출구를 고정한 채 비교하세요. 대상 하나만 실패한다면 규칙, 대상 서비스, 출구 제한을 살펴보세요. 요청 기록이 전혀 없다면 진입점과 프로세스를 확인하고, 기록에 DNS 오류가 집중되면 DNS를 점검하세요.

상세 로그가 필요하면 잠시 로그 수준을 높여 최소한의 작업을 한 번 재현하고 정확한 시간을 기록한 뒤 일상적인 수준으로 되돌리세요. 디버그 로그를 오래 유지하면 저장과 검색에 부담이 커지고 접속 정보가 더 많이 남을 수 있습니다. 몇 시간 분량의 로그를 그대로 관리자에게 보내지 말고 문제 전후의 관련 부분을 추려 예상 동작, 실제 동작, 이미 수행한 비교 테스트를 설명하세요.

속도 저하와 연결 실패는 구분해서 점검하세요. 다운로드 작업, 무선 신호, 기기 부하, 통신사 경로, 원격 서버의 혼잡이 모두 사용 경험에 영향을 줄 수 있습니다. 한 번의 노드 테스트로 지속적인 전송 속도를 판단할 수는 없습니다. 같은 테스트 대상과 비슷한 조건, 고정된 출구를 유지하며 노드나 네트워크를 바꿨을 때의 변화를 비교하세요. 자동 속도 측정 결과만 보고 계속 전환하면 장시간 연결이 끊길 수 있습니다.

복구 순서와 장기적인 정리

문제가 심각하면 먼저 TUN과 시스템 프록시를 끄고 기본 네트워크를 복구한 뒤 마지막으로 사용 가능한 설정을 불러오세요. 구독 업데이트가 원인이라면 보관해 둔 로컬 사본으로 비교 테스트하고, 사용자 지정 덮어쓰기 문제라면 클라이언트 전체를 삭제하지 말고 해당 계층만 잠시 비활성화하세요. 프로그램 파일이나 사용자 디렉터리 손상이 확인된 경우에만 재설치를 고려하고, 정리하기 전에 필요한 설정을 저장하세요.

사용하지 않는 구독 항목, 만료된 규칙, 중복 시작 항목을 정기적으로 삭제하고 이전 클라이언트가 백그라운드에서 실행 중인지 확인하세요. 여러 설정 파일의 용도, 전환 방법, 업데이트 정책이 궁금하다면 Profile 및 다중 설정 관리 노트를 참고하세요. 유지 관리의 목적은 매일 설정을 조정하는 것이 아니라 변경 내역을 기록하고, 문제의 근거를 남기며, 명확한 복구 경로를 마련하는 것입니다.

제9장 · 안정적인 설정에서 고급 관리로

설정 파일 전체를 복사하기보다 프록시 그룹부터 익히세요

고급 설정은 이미 검증을 마친 설정에서 시작해야 합니다. 먼저 프록시 그룹 간 참조 방식을 익힌 다음 자동 선택과 장애 전환을 살펴보세요. 알 수 없는 규칙, 스크립트, 원격 리소스가 많이 포함된 파일 전체를 바로 복사하지 마세요. 기능을 추가할 때마다 어떤 문제를 해결하는지, 어떤 조건이 필요한지, 어떻게 검증하고 취소할 수 있는지 설명할 수 있어야 합니다. 그렇지 않으면 복잡성만 늘어나 이후 문제 해결이 어려워집니다.

수동 선택 그룹은 출구를 직접 관리할 때 적합합니다. 자동 테스트 그룹은 지정한 테스트 대상을 기준으로 후보 노드를 비교하고, 장애 전환 그룹은 자체 기준에 따라 사용할 수 있는 항목을 찾습니다. 테스트 대상은 확인하려는 연결 상태를 대표해야 하지만 모든 서비스에 통용되는 주소는 없습니다. 노드 테스트는 정상인데 동영상, 게임, 업무 서비스가 안 된다면 실제 서비스 연결을 확인하세요. 테스트 결과 하나만으로 전체 상태가 정상이라고 판단할 수 없습니다.

proxy-groups:
  - name: PROXY
    type: select
    proxies:
      - AUTO
      - DIRECT
  - name: AUTO
    type: url-test
    use:
      - daily
    url: https://example.com/
    interval: 600

이 예시는 daily라는 이름의 프록시 프로바이더에 의존하므로 전체 설정에서 먼저 해당 프로바이더를 정의해야 합니다. 프록시 그룹 부분만 복사해도 노드가 자동으로 표시되지는 않습니다. 테스트 주소도 실제로 접속 가능한지와 사용 목적에 따라 조정하세요. PROXY가 AUTO를 참조하며 트래픽은 AUTO를 선택했을 때만 해당 그룹의 선택 결과를 따릅니다. 인터페이스에 자동 그룹이 표시된다고 해서 모든 연결이 자동으로 그 그룹을 사용하는 것은 아닙니다.

프로바이더와 덮어쓰기의 관리 범위 이해하기

프록시 프로바이더를 사용하면 노드 출처와 로컬 정책을 분리해 관리할 수 있고, 규칙 프로바이더를 사용하면 규칙 내용과 기본 설정을 따로 관리할 수 있습니다. 둘 다 원격 가져오기, 캐시, 형식 호환성 문제를 일으킬 수 있으므로 이름을 구분하고 용도를 명확히 하세요. 리소스 다운로드에 실패하면 먼저 로컬 캐시를 사용할 수 있는지 확인한 뒤 시작에 영향이 있는지 살펴보세요. 아직 준비되지 않은 동일한 프록시 경로에 모든 리소스를 의존하게 하면 시작 과정에 의존성 순환이 생길 수 있습니다.

덮어쓰기는 개인 정책을 보존할 때 적합하지만 병합 방식은 클라이언트마다 다릅니다. 목록을 교체할 수도 있고 추가할 수도 있으며, 스크립트가 병합 후 내용을 다시 바꾸기도 합니다. 모든 클라이언트가 같은 순서로 처리한다고 가정하지 마세요. 복잡한 설정을 조정하기 전에 알아보기 쉬운 그룹이나 규칙을 하나 추가하는 작은 실험을 하세요. 최종 설정에서 위치와 내용이 어떻게 되는지 확인한 뒤 정식 구성 방식을 결정하면 처음부터 검증하기 어려운 복잡한 로직을 작성하는 일을 피할 수 있습니다.

컨트롤 인터페이스와 로컬 네트워크 접근

외부 컨트롤 인터페이스는 코어를 관리하며 일반 프록시 진입점과는 다른 권한을 가집니다. 원격 관리가 필요 없다면 로컬에서만 접근할 수 있도록 유지하고 모든 네트워크 인터페이스에서 수신하도록 함부로 설정하지 마세요. 로컬 네트워크에서 관리해야 한다면 인증, 시스템 방화벽, 접속 출처 제한을 함께 설정하고 관리 페이지와 인터페이스의 보안 경계를 확인하세요. 관리 페이지가 열리지 않는다고 모든 접근 제어를 해제하거나 인터페이스를 공용 인터넷에 노출하지 마세요.

로컬 네트워크 프록시를 켤 때도 수신 주소, 포트, 접속 기기, 방화벽을 함께 고려해야 합니다. allow-lan만 바꾼다고 다른 기기에서 연결할 수 있는 것은 아니며 모든 네트워크에서 접근을 허용해야 한다는 뜻도 아닙니다. 신뢰할 수 있는 네트워크에서 기기 한 대로 테스트하고 프록시 진입점과 컨트롤 인터페이스를 구분하세요. 해당 네트워크를 벗어나거나 공용 Wi-Fi를 사용할 때는 더 이상 필요하지 않은 공유 기능을 끄세요.

반복 가능한 실험 방법 만들기

고급 설정을 실험할 때마다 원본 설정과 복사본, 변경 내용을 기록하고 일반 웹페이지, 규칙을 적용할 대상, 로컬 네트워크 서비스, 종료 후 복원을 포함한 고정 테스트를 준비하세요. DNS, 규칙, TUN 중 하나를 바꿀 때마다 같은 테스트를 반복하고 적용된 연결 규칙과 오류 변화를 기록합니다. 결과가 예상과 일치할 때만 변경 사항을 유지하세요. 페이지가 가끔 열린다는 사실만으로 설정이 올바르다고 판단하지 마세요.

이제 매개변수를 더 쌓을 필요는 없습니다. 새 기기에서 기본 절차를 다시 진행하려면 빠른 시작 가이드로 돌아가세요. 클라이언트를 바꾸려면 다운로드 페이지와 선택 가이드를 확인하세요. 구체적인 예외 상황은 기술 노트에서 찾아보세요. 안정적으로 작동하는 상태를 기반으로 삼고 목적이 분명한 변경만 더해야 설정을 오래 이해하고 관리할 수 있습니다.