Clash 설정 입문부터 고급 활용까지
클라이언트와 규칙 설정

1. 핵심 개념: 코어, 클라이언트, 설정

인터페이스와 실행 계층 구분하기

Clash 생태계에서 클라이언트와 코어는 서로 다른 계층입니다. 클라이언트는 설정 관리, 정책 선택, 시스템 프록시 전환, 로그 표시를 담당하고, 코어는 연결을 수신하고 요청을 분석해 규칙을 적용한 뒤 실제 외부 연결을 설정합니다. mihomo는 이 생태계에서 지속적으로 개발되는 코어 프로젝트로, GUI 클라이언트에 통합되는 경우가 많습니다. 비슷한 Clash 인터페이스를 사용하더라도 두 클라이언트가 같은 필드를 모두 지원하거나, 같은 코어와 설정 처리 방식을 사용하는 것은 아닙니다.

한 번의 접속은 네 단계로 나눠 이해할 수 있습니다. 앱이 요청을 만들고, 시스템이나 앱이 요청을 프록시 진입점으로 전달하면, 코어가 설정에 따라 처리 방식을 결정하고, 마지막으로 직결 또는 프록시를 통해 목적지에 접속합니다. 웹페이지가 열렸다는 사실은 해당 경로가 작동했다는 뜻일 뿐입니다. 다른 앱은 시스템 프록시를 따르지 않을 수 있고, 다른 도메인은 다른 규칙에 걸릴 수 있습니다. 따라서 문제를 확인할 때는 전체 스위치의 켜짐 여부만 볼 것이 아니라 진입점, 규칙 적용 결과, 외부 연결을 함께 확인해야 합니다.

노드, 프록시 그룹, 규칙은 각각 무엇을 하는가

노드는 프록시 연결에 필요한 프로토콜, 서버 주소, 포트, 인증 정보를 나타냅니다. 프록시 그룹은 노드나 다른 외부 연결 대상을 하나의 참조 객체로 묶어 수동 선택이나 정해진 방식의 전환을 가능하게 합니다. 규칙은 특정 요청을 어디로 보낼지 지정합니다. 규칙이 프록시 그룹을 참조하고, 그룹이 노드를 선택하는 구조입니다. 규칙에서 내장된 DIRECT 또는 REJECT를 직접 참조할 수도 있으며, 각각 직결과 차단을 뜻합니다.

구독은 보통 업데이트할 수 있는 원격 설정 소스지만, 제공되는 내용은 일정하지 않습니다. 전체 설정을 반환해 노드, 규칙, 프록시 그룹을 모두 포함하는 구독이 있는가 하면, 노드 목록만 반환해 클라이언트 템플릿으로 나머지를 채워야 하는 구독도 있습니다. 노드 목록을 전체 설정처럼 사용하면 선택할 프록시 그룹이 없거나, 노드는 있지만 규칙에서 참조하지 않는 문제가 생길 수 있습니다. 가져오기 전에 콘텐츠 유형부터 확인하는 편이 모드를 계속 바꿔 보는 것보다 효과적입니다.

YAML 파일과 실제 적용되는 설정

설정은 보통 config.yaml 파일로 저장합니다. YAML은 들여쓰기로 구조를 나타내므로 같은 계층의 키는 정렬하고, 목록 항목은 하이픈으로 시작해야 합니다. 공백 대신 탭을 사용할 수 없습니다. 콜론 뒤에는 보통 공백이 필요하며, 특수 문자가 포함된 문자열은 따옴표로 묶는 것이 좋습니다. 구문 분석에 성공해도 프록시 그룹 참조, 파일 경로, 네트워크 권한 등 실행 조건까지 모두 올바르다는 뜻은 아닙니다. 수정 후에는 코어가 설정을 받아들였는지 확인하고 실제 요청의 규칙 적용 기록도 살펴보세요.

GUI 클라이언트는 구독 원문, 템플릿, 덮어쓰기 조각, 실행 시 생성되는 파일을 함께 저장할 수 있습니다. 디스크에서 방금 수정한 파일을 코어가 읽고 있다는 보장은 없고, 다음 구독 업데이트에서 수동 수정 내용이 덮어써질 수도 있습니다. 클라이언트의 설정 미리보기나 실행 설정 경로를 확인해 최종 필드의 출처를 파악하고, 인터페이스의 스위치가 더 높은 우선순위로 적용되는지도 기록하세요. 이후 예제는 구독 전체를 무작정 바꾸기보다 관리되는 덮어쓰기 계층에 병합하는 것이 좋습니다.

소프트웨어와 네트워크 서비스도 구분해야 합니다. 클라이언트를 설치한다고 사용할 수 있는 서버가 자동으로 생기지는 않으며, 소스 코드가 공개되어 있다고 연결 리소스까지 제공되는 것도 아닙니다. 서비스 이용 가능 여부, 트래픽 한도, 서비스 계정 상태는 별개의 문제입니다. 구독에 접속 인증 정보가 포함될 수 있으므로 계정 정보처럼 안전하게 보관하고 공개 게시물, 온라인 변환 사이트, 스크린샷에 노출하지 마세요. 출처를 알 수 없는 설정은 가져오기 전에 원격 리소스, 수신 주소, 제어 인터페이스부터 확인하세요.

2. 클라이언트 선택: 플랫폼과 사용 범위

기기를 먼저 확인한 다음 인터페이스와 기능 비교하기

처음 설치한다면 Clash Plus를 먼저 살펴보고, 플랫폼, 데스크톱 환경, 기존 사용 습관에 따라 다른 클라이언트도 비교해 보세요. 선택의 첫 단계는 인터페이스 스크린샷 비교가 아니라 운영체제, 프로세서 아키텍처, 설치 파일 형식 확인입니다. 데스크톱 클라이언트는 설정 관리와 연결 확인에 적합하고, 모바일 앱은 보통 시스템 VPN 인터페이스로 트래픽을 처리합니다. 서버에서 코어만 실행할 때는 설정과 프로세스를 직접 관리해야 합니다. 사용 방식이 서로 다르므로 같은 권한 설정 절차를 그대로 적용할 수 없습니다.

다운로드 페이지에서 플랫폼을 선택하면 이용 가능한 클라이언트와 사용 조건을 한곳에서 확인할 수 있습니다. 초보자는 유지 관리가 계속되고 정상적으로 실행되며 기기 조건에 맞는 클라이언트 하나를 선택해 최소한의 연결 경로부터 완성한 뒤 추가 기능을 비교하는 것이 좋습니다. 클라이언트를 자주 바꾸면 설정 병합 방식, DNS 기본값, 시스템 트래픽 처리 방식이 함께 달라집니다. 같은 문제를 여러 소프트웨어의 오류로 오해하거나 남은 프록시 설정을 찾기 어려워질 수 있습니다.

플랫폼별 대체 클라이언트

Windows에서는 Clash Verge Rev, FlClash, Clash Nyanpasu를 비교해 볼 수 있고, macOS에서는 Clash Verge Rev와 FlClash를 살펴볼 수 있습니다. Linux에서는 Clash Verge Rev와 FlClash를 중심으로 확인하고 배포판에 맞는 패키지 형식을 선택하세요. Android에서는 Clash Meta for Android, FlClash, Surfboard를 비교할 수 있습니다. 다만 Surfboard의 설정 형식은 Clash YAML과 동일하다고 볼 수 없으므로 자체 가져오기 안내를 따라야 합니다. 구독 주소가 같다는 이유만으로 모든 클라이언트가 설정을 해석할 수 있다고 단정하지 마세요.

iOS에서는 Clash Plus의 스토어 정보와 기기 호환성을 먼저 확인하세요. 제품 웹사이트는 clashplus.io입니다. 모바일 시스템에 VPN 표시가 나타나는 것은 관련 네트워크 인터페이스가 켜져 있다는 뜻일 뿐, 모든 목적지에 프록시가 적용된다는 의미는 아닙니다. 실제 동작은 클라이언트가 지원하는 규칙, 제외 범위, 외부 연결 설정에 따라 달라집니다. 상태 표시줄 아이콘만으로 판단하지 말고 실제 앱과 목적지를 정해 연결을 확인하세요.

유지 관리 상태와 설정 이전

Clash for Windows와 ClashX Meta는 개발이 중단된 보관용 선택지이므로 새 기기의 기본 선택으로 권장하지 않습니다. 보관된 소프트웨어가 실행되더라도 최신 시스템의 권한, 프로토콜 지원, 설정 필드에서 제약이 생길 수 있습니다. 이전하기 전 설정 출처와 수동 규칙을 내보내고 기존 환경을 백업한 다음 새 클라이언트로 가져오세요. 데이터베이스 구조, 경로, 암호화 저장 방식이 다를 수 있으므로 앱 데이터 폴더 전체를 그대로 복사하지 마세요.

기능을 비교할 때는 실제 필요한 항목을 하나씩 확인하세요. 사용하는 구독 형식을 지원하는지, 적용 설정을 미리 볼 수 있는지, 안정적인 덮어쓰기 기능을 제공하는지, TUN에 별도 서비스가 필요한지, 로그를 쉽게 필터링할 수 있는지 살펴보면 됩니다. 한 클라이언트에 버튼이 있다고 해서 다른 플랫폼에도 같은 방식으로 구현된다는 보장은 없습니다. 특히 데스크톱 시스템 프록시, 서비스 모드, 모바일 VPN 트래픽 처리는 각각 따로 이해해야 합니다. 이름이 같다고 동작도 같으리라 추측하지 마세요.

일반적인 데스크톱 사용자는 mihomo 코어를 따로 다운로드할 필요가 없는 경우가 많습니다. 클라이언트가 코어 실행, 설정 경로, 일부 권한을 관리하므로 코어를 직접 교체하면 제어 인터페이스가 맞지 않거나 실행 인수가 어긋날 수 있습니다. 서버나 라우터를 운영하거나 프로세스를 직접 관리해야 하는 경우에 코어를 직접 실행하는 편이 적합하며, 서비스 관리와 네트워크 격리도 직접 책임져야 합니다. 클라이언트와 설정 출처를 정했다면 다음 단계에서 재현할 수 있도록 환경을 고정하세요.

3. 설치 및 권한: 되돌릴 수 있는 실행 환경 만들기

설치 전에 현재 네트워크 상태 기록하기

설치를 시작하기 전에 다른 프록시, VPN, 트래픽 필터, 보안 소프트웨어가 실행 중인지 확인하세요. 현재 시스템 프록시와 기존 VPN 설정, 필요한 회사 네트워크 요구 사항을 기록해 여러 프로그램이 같은 설정을 동시에 바꾸지 않도록 합니다. 이전 클라이언트를 옮길 때는 먼저 시스템 프록시와 TUN을 정상적으로 끄고 프로세스를 종료하세요. 앱 파일만 삭제해도 시스템 프록시, 서비스, 가상 네트워크 어댑터가 남을 수 있으므로 앱을 제거했다는 사실만으로 네트워크가 복구됐다고 판단하면 안 됩니다.

설치 파일은 이 사이트의 다운로드 경로와 해당 프로젝트의 공식 채널에서 받고, 플랫폼과 아키텍처를 확인하세요. Windows는 운영체제 비트 수와 프로세서 종류, macOS는 칩 종류, Android는 명령어 집합, Linux는 패키지 형식에 따라 사용할 파일이 달라집니다. 압축을 풀 수 있다고 실행할 수 있는 것은 아닙니다. 아키텍처 불일치 메시지가 나오면 파일 확장자를 바꾸거나 반복해서 압축을 풀지 말고 다운로드 페이지에서 다시 선택하세요. 나중에 업데이트하거나 되돌릴 수 있도록 설치 출처도 기록해 두세요.

데스크톱: 설치 권한과 네트워크 권한 구분하기

Windows에서 처음 실행한 뒤에는 먼저 기본 화면과 코어가 정상 작동하는지 확인하고, 클라이언트가 제공하는 서비스 구성 요소를 설치할지 결정하세요. 시스템 프록시는 보통 현재 사용자 설정과 관련되고, TUN이나 백그라운드 서비스에는 더 높은 권한이 필요할 수 있습니다. 방화벽 안내가 표시되면 프로그램 경로, 사용하는 네트워크, 수신 범위를 확인하세요. 알림을 없애려고 모든 인바운드 연결을 허용하지 마세요. 이 기기에서만 사용할 경우 로컬 루프백 주소로 수신하고 LAN 접속은 끄는 편이 안전합니다.

macOS에서는 설치 파일의 안내에 따라 앱을 적절한 위치로 옮긴 뒤, 시스템 설정에서 명확한 최초 실행 안내를 처리하세요. 네트워크 확장, 보조 구성 요소, 시스템 프록시, 키체인 권한은 서로 다르므로 모든 팝업을 같은 종류의 오류로 취급하지 마세요. 앱이 권한을 반복해서 요청한다면 설치 위치와 같은 이름의 기존 앱이 있는지 먼저 확인해 이전 복사본이 동시에 실행되지 않도록 합니다. 자세한 내용은 macOS 네트워크 확장 및 키체인 권한 안내를 참고하세요. 시스템 보안 기능 전체를 끄는 방법은 권장하지 않습니다.

Linux 데스크톱에서는 패키지 설치 성공, GUI 실행 성공, 코어의 네트워크 권한 확보를 각각 구분해야 합니다. 데스크톱 의존성이 없으면 창이 열리지 않을 수 있고, 권한 부족은 TUN에만 영향을 줄 수 있습니다. 시스템 프록시를 적용할 수 있는지는 데스크톱 환경에 따라 다릅니다. 배포판 안내에 맞는 형식을 설치하고 먼저 일반 권한으로 실행해 확인하세요. 기능 권한이나 서비스 모드가 필요하다면 클라이언트가 제공하는 방식을 사용하세요. GUI 프로그램 전체를 항상 높은 권한으로 실행하는 것은 기본 해결책이 아닙니다.

모바일: VPN 권한과 백그라운드 실행

Android와 iOS는 보통 처음 연결할 때 VPN 설정 추가 또는 활성화를 요청합니다. 안내가 현재 설치한 클라이언트에서 표시된 것인지 확인한 뒤 권한을 허용하세요. Android에서는 배터리 최적화, 백그라운드 실행, 시스템의 자동 종료 설정도 살펴봐야 합니다. 화면을 잠근 뒤 연결이 끊기거나 앱을 전환한 후 갱신이 멈춘다면 노드 설정 오류가 아니라 프로세스 제한이 원인일 수 있습니다. 먼저 앱을 전면에 둔 채 연결을 확인하고 필요한 백그라운드 권한만 조정하세요. 관계없는 권한을 한꺼번에 켜지 마세요.

처음 실행할 때 여러 네트워크 트래픽 처리 방식을 한꺼번에 활성화하지 마세요. 설정을 가져온 뒤 클라이언트 로그에서 코어가 정상적으로 불러와졌는지 확인합니다. 데스크톱에서는 그다음 시스템 프록시를 켜고, 모바일에서는 일반적인 연결 절차에 따라 권한을 허용하세요. 테스트를 마친 뒤에는 정상 종료도 연습하세요. 트래픽 처리를 끄고 시스템 프록시가 복구됐는지 확인한 다음 클라이언트를 종료하고 직결 네트워크를 테스트합니다. 정상적으로 종료하고 복구할 수 있어야 이후 TUN과 복잡한 규칙을 안전하게 시도할 수 있습니다. 켜는 방법만 시험해서는 충분하지 않습니다.

4. 구독 가져오기: 출처, 업데이트, 설정 덮어쓰기

받은 항목이 링크인지 파일인지 확인하기

구독은 보통 원격 주소, 로컬 파일, 텍스트 붙여넣기의 세 가지 방식으로 가져옵니다. 원격 주소는 정기 업데이트에, 로컬 파일은 백업이나 고정 설정에, 텍스트 붙여넣기는 임시 확인에 적합합니다. 콘텐츠에 맞는 가져오기 방식을 선택하세요. 웹페이지 안내 주소를 구독으로 등록하거나 YAML을 URL만 받는 입력란에 붙여 넣지 마세요. 주소에 계정 정보가 포함될 수 있으므로 원본은 안전하게 보관하되 공개하거나 공용 기기에 장기간 남기지 마세요.

설정 관리 화면에서 새 설정을 만들고 구분하기 쉬운 이름을 입력한 뒤 콘텐츠를 가져와 다운로드와 분석이 끝날 때까지 기다리세요. 완료 후 해당 설정을 현재 사용 항목으로 지정해야 합니다. 목록에 보이는 것만으로 코어가 전환됐다고 볼 수는 없습니다. 이어서 프록시 그룹이 나타나는지, 노드를 선택할 수 있는지, 로그에 로드 성공이 표시되는지 확인하세요. 로드에 실패하면 오류가 난 줄과 필드 이름부터 확인하고 콘텐츠 형식을 먼저 바로잡으세요. 아직 적용되지 않은 설정을 감추려고 연결 버튼을 반복해서 누르지 마세요.

다운로드 실패, 파싱 실패, 연결 실패 구분하기

구독 다운로드 실패는 설정을 가져오는 단계에서 발생하며, 도메인 이름 해석, 계정 상태, 접근 제한, 구독 서버 응답이 원인일 수 있습니다. 파싱 실패는 콘텐츠는 받았지만 로그인 페이지나 오류 페이지, 다른 클라이언트 형식이 반환됐거나 YAML 들여쓰기가 잘못된 경우입니다. 노드 연결 실패는 설정을 불러온 다음 발생하므로 서버 접근성과 인증 정보를 확인해야 합니다. 세 오류는 발생 단계가 다르므로 먼저 어느 단계에서 실패했는지 파악한 뒤 해당 경로를 점검하세요.

구독이 전체 설정을 반환하면 기본 프록시 그룹과 규칙을 우선 유지한 채 기본 동작을 확인하세요. 노드만 반환한다면 클라이언트가 지원하는 템플릿이나 제공업체 안내를 사용해 나머지 설정을 채워야 합니다. 출처를 알 수 없는 템플릿을 임의로 조합하지 마세요. 템플릿의 프록시 그룹 이름과 규칙에서 참조하는 이름이 일치해야 하고 노드도 올바르게 연결되어야 합니다. '프록시 그룹이 없음' 같은 오류가 발생하면 목록에 노드가 있는지만 확인하지 말고 이름, 대소문자, 병합 순서를 점검하세요.

덮어쓰기와 구독 업데이트의 경계

수동 설정은 가능한 한 클라이언트가 지원하는 덮어쓰기 또는 병합 계층에 넣으세요. 다운로드한 구독 원문을 직접 수정하면 다음 업데이트에서 사라질 수 있고, 실행 중인 파일을 직접 수정하면 재시작 시 새로 생성될 수 있습니다. 클라이언트마다 목록을 교체하거나 추가하거나 앞에 삽입하는 방식이 다르므로 최종 rules, proxy-groups, dns 결과를 확인해야 합니다. 한 클라이언트에서 사용한 병합 방식을 다른 클라이언트에도 그대로 적용하지 마세요.

다음은 최상위 설정 일부로, 로컬 설정과 노드 정보를 분리해야 한다는 점을 설명합니다. 노드와 프록시 그룹이 없으므로 이 조각만으로는 프록시 연결을 만들 수 없습니다. 클라이언트가 이미 인터페이스에서 해당 항목을 관리한다면 관련 스위치를 우선 사용하고 설정 미리보기에서 결과를 확인하세요. 인터페이스와 파일 양쪽에 같은 값을 지정하면 실행 후 포트나 모드가 다시 바뀌는 덮어쓰기 문제가 생길 수 있습니다.

# 최상위 설정 예제 조각; 기존의 전체 설정과 병합해 사용
mixed-port: 7890
allow-lan: false
mode: rule
log-level: info

구독을 업데이트하기 전에 현재 작동하는 설정과 필요한 수동 선택을 저장하세요. 업데이트 후에는 프록시 그룹 이름, 노드 수의 변화, 로그를 비교합니다. 이전에 선택한 노드가 사라졌다고 해서 구독 전체가 손상됐다고 단정할 필요는 없습니다. 제공업체가 노드를 삭제하거나 이름을 바꾸면 클라이언트가 기본 선택으로 돌아갈 수 있습니다. 사용 가능한 외부 연결을 다시 선택하고 자주 사용하는 목적지에 접속해 확인하세요. 자동 업데이트 간격은 제공업체 제한과 실제 필요에 맞추세요. 짧은 시간에 계속 새로고침한다고 서버 품질이 좋아지지는 않습니다.

기존 프록시를 통해야 구독 주소에 접근할 수 있다면 클라이언트가 지원하는 업데이트 다운로드 방식을 사용하거나 우선 작동하는 연결 경로를 복구하세요. 구독 업데이트를 위해 모든 트래픽을 장시간 전역 모드로 돌리지 마세요. 문제를 공유할 때는 주소 원문을 공개하지 말고 민감 정보를 지운 오류 내용, 가져오기 방식, 설정 유형만 제공하세요. 출처와 구독 오류에 관한 안내는 구독 관련 문제 해결에서 확인한 뒤 오류가 발생한 단계에 맞춰 계속 점검할 수 있습니다.

5. 프록시 모드: 진입과 처리 방식을 따로 설정하기

규칙, 전역, 직결은 요청 처리 방식

규칙 모드는 설정 순서에 따라 각 요청의 외부 연결을 선택하므로 일상적인 사용에 적합합니다. 전역 모드는 코어에 들어온 요청을 전역 정책에 따라 처리하고, 직결 모드는 코어에 들어온 요청을 목적지에 직접 연결합니다. 모드는 요청이 코어에 들어온 뒤 처리하는 방식을 바꿀 뿐, 모든 앱이 코어로 요청을 전달하도록 보장하지는 않습니다. 따라서 전역 모드라고 해서 기기의 모든 트래픽이 처리되는 것은 아니며, 시스템 프록시를 따르지 않는 앱은 여전히 우회할 수 있습니다.

일상적인 사용에는 규칙 모드를 먼저 사용하고, 규칙 차이를 확인할 때만 잠시 전역 모드와 비교하는 것이 좋습니다. 같은 목적지가 전역 모드에서는 연결되는데 규칙 모드에서는 연결되지 않는다면 전역 모드를 계속 해결책으로 쓰기보다 적용된 규칙과 선택된 외부 연결을 확인하세요. 직결 모드도 클라이언트가 완전히 종료됐다는 뜻은 아닙니다. 코어, 수신 포트, VPN 인터페이스가 여전히 실행 중일 수 있습니다. 시스템 네트워크를 완전히 복구하려면 관련 트래픽 처리 진입점도 꺼야 합니다.

시스템 프록시: 앱이 설정을 따르는지에 따라 적용 범위가 달라집니다

시스템 프록시는 보통 운영체제에서 지원하는 프록시 설정을 로컬 수신 포트로 연결합니다. 브라우저와 일부 앱은 이 설정을 읽지만 명령줄 도구, 게임, 자체 네트워크 스택을 사용하는 프로그램은 무시할 수 있습니다. 앱마다 별도 프록시 설정이 있을 수 있으므로 앱 내부에서 설정하거나 환경 변수로 지정해야 할 수도 있습니다. 브라우저는 되지만 다른 프로그램이 연결되지 않는다면 먼저 해당 프로그램의 연결이 코어 목록에 나타나는지 확인한 다음 규칙과 노드를 살펴보세요. 진입점이 빠진 문제를 연결 경로 오류로 오해하지 않도록 합니다.

환경 변수는 이를 읽는 프로세스에만 영향을 주며 도구 자체 설정이 우선 적용될 수도 있습니다. 아래 명령은 Unix 계열 터미널에서 이번 요청에만 프록시를 지정하는 예시이며, 로컬 혼합 포트가 예시 값으로 설정되어 있다고 가정합니다. Windows PowerShell에서 같은 방법으로 확인하려면 curl.exe를 명시적으로 호출하세요. 요청이 성공해도 해당 명령이 지정된 진입점을 사용했다는 뜻일 뿐, 다른 앱에도 같은 설정이 적용됐다는 의미는 아닙니다.

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

포트 설정: 수신 주소, 유형, 충돌

mixed-port는 HTTP와 SOCKS 연결을 모두 제공하고, port와 socks-port는 각각 별도의 진입점을 설정합니다. 포트 번호는 실제 적용된 설정을 기준으로 확인하세요. 예제 숫자가 모든 클라이언트의 고정 기본값은 아닙니다. 로그에 주소가 이미 사용 중이라고 나오면 다른 클라이언트나 이전 코어 프로세스가 있는지 먼저 확인한 뒤 해당 프로그램을 종료하거나 포트를 바꾸세요. 포트를 변경한 후에는 시스템 프록시와 앱 내부의 수동 설정도 함께 수정해야 합니다.

수신 주소는 누가 진입점에 연결할 수 있는지를 결정합니다. 이 기기에서만 사용할 경우 LAN 접속을 꺼 두고 실제 바인딩 범위를 확인하세요. allow-lan을 켜면 바인딩 주소, 방화벽, 네트워크 환경을 함께 고려해 접근을 제한해야 합니다. 보호되지 않은 프록시 진입점을 공용 네트워크에 노출하지 마세요. LAN 기기에서 입력할 주소는 클라이언트가 실행 중인 기기의 LAN 주소여야 합니다. 해당 기기 자체의 루프백 주소를 사용해서는 안 되며 네트워크 격리와 기기의 절전 상태도 고려해야 합니다.

연결 기록으로 모드 검증하기

검증할 때는 목적지를 하나 정하고 기존 연결을 닫거나 새 명령 요청을 보낸 뒤 연결 목록에서 도메인, 적용 규칙, 정책 경로, 외부 연결을 확인하세요. 오래 유지되는 연결, 브라우저 연결 풀, 캐시 때문에 모드를 바꾼 효과가 늦게 나타날 수 있으며 기존 연결이 즉시 다시 설정되지 않을 수도 있습니다. 로그에서 기록을 찾기 쉽도록 현재 모드와 테스트 시간을 함께 남기세요. 연결에 문제가 있으면 연결 문제 안내를 참고해 단계별로 점검할 수 있습니다.

일부 클라이언트에서는 시스템 프록시와 TUN을 함께 사용할 수 있지만, 처음 문제를 확인할 때는 진입점을 하나만 명확하게 두는 것이 좋습니다. 두 가지를 동시에 설정하면 일부 요청이 앱 프록시를 거친 뒤 가상 네트워크 어댑터에도 잡혀 동작을 파악하기 어려워질 수 있습니다. 먼저 시스템 프록시로 설정과 외부 연결을 확인하고, 다음 단계에서 필요한 트래픽 범위만 처리하세요. 진입점, 모드, 테스트 목적지가 명확해야 문제가 트래픽 처리, 규칙 적용, 외부 네트워크 중 어디에서 발생했는지 판단할 수 있습니다.

6. 규칙 분류: 매칭 순서와 프록시 그룹

위에서 아래로 확인하고, 일치하면 처리를 멈춥니다

규칙은 보통 위에서 아래 순서로 확인하며 요청이 규칙 하나와 일치하면 해당 규칙이 지정한 외부 연결로 처리됩니다. 규칙끼리 투표하거나 더 구체적인 항목을 자동으로 선택하지 않습니다. 따라서 특정 도메인 예외는 포괄적인 규칙보다 위에 두고, LAN 주소 같은 기본 직결 규칙이 마지막 프록시 규칙에 덮이지 않게 하세요. 최종 MATCH 규칙은 맨 아래에 둡니다. 목록 아래쪽에 규칙을 추가하기만 하면 해당 규칙이 적용될 기회가 없을 수 있습니다.

DOMAIN은 전체 도메인과 일치하고, DOMAIN-SUFFIX는 도메인 접미사와 하위 도메인을 일치시킵니다. DOMAIN-KEYWORD는 특정 키워드가 들어 있는 도메인과 일치합니다. 키워드 규칙은 예상보다 범위가 넓어질 수 있으므로 짧은 단어로 서비스를 대략 지정하지 마세요. IP-CIDR은 IP 주소 대역을 기준으로 하고, GEOIP는 IP 지리 데이터베이스를 사용합니다. GEOSITE는 도메인 분류 데이터에 의존합니다. 관련 규칙을 불러오려면 데이터베이스가 있고 해당 태그를 사용할 수 있어야 합니다.

먼저 참조할 프록시 그룹 정의하기

프록시 그룹 이름은 설정 간 연결에 사용되므로 규칙에서 쓴 이름과 정의된 이름이 일치해야 합니다. 아래 예제는 Proxy라는 수동 선택 그룹을 정의하고, 구조와 규칙 참조를 확인하기 위해 내장 직결 연결만 포함합니다. 이 상태로는 프록시 기능을 사용할 수 없습니다. 실제로 사용하려면 proxies에 정의된 노드 이름이나 올바르게 설정한 노드 출처를 그룹에 추가하세요. 예제 그룹에 직결이 표시된다고 해서 프록시 노드가 선택된 것은 아닙니다.

# 구조 예제 조각: Proxy에는 현재 DIRECT만 포함
proxy-groups:
  - name: Proxy
    type: select
    proxies:
      - DIRECT

rules:
  - DOMAIN-SUFFIX,github.com,Proxy
  - IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
  - IP-CIDR,10.0.0.0/8,DIRECT,no-resolve
  - MATCH,Proxy

select는 직접 선택할 때 적합하고, url-test는 탐지 결과에 따라 후보를 선택합니다. fallback은 순서에 따라 사용 가능한 외부 연결을 유지하는 데 중점을 두며, load-balance는 설정된 방식으로 연결을 분산합니다. 자동 탐지는 지정된 테스트 주소에 접속하므로 결과가 모든 웹사이트의 체감이나 다운로드 속도를 뜻하지는 않습니다. 자동 선택을 추가하기 전에 후보 목록과 전환 조건을 이해하세요. 여러 그룹을 중첩하면 최종 외부 연결을 추적하기 어려워질 수 있습니다.

도메인 규칙과 IP 규칙의 범위

일부 IP 규칙은 목적지 주소를 확인하기 위해 먼저 도메인을 해석해야 합니다. no-resolve는 해당 IP 규칙을 적용하려고 적극적으로 도메인을 해석하지 않도록 하지만, 전체 접속 과정에서 DNS를 더 이상 사용하지 않는다는 뜻은 아닙니다. 요청에 이미 IP 주소가 포함돼 있으면 주소 규칙을 적용할 수 있습니다. 도메인 정보를 가져올 수 있는지는 앱의 진입점, DNS 모드, 스니핑 설정에도 달려 있습니다. 도메인 규칙이 적용되지 않는다면 항목을 더 추가하기 전에 연결 기록에 도메인이 실제로 표시되는지 확인하세요.

rule-providers를 사용하면 큰 규칙 모음을 기본 설정에서 분리할 수 있지만 출처, 캐시 경로, 형식, 매칭 동작을 올바르게 설정해야 합니다. 도메인 목록, IP 목록, 클래식 규칙 형식은 임의로 혼용할 수 없습니다. RULE-SET으로 참조할 때도 이름이 정확히 일치해야 합니다. 먼저 몇 개의 로컬 규칙으로 분류 동작을 확인한 다음 원격 목록을 추가하세요. 원격 업데이트에 실패하면 사용 가능한 캐시가 있는지, 현재 불러온 콘텐츠가 예상과 맞는지도 확인해야 합니다.

규칙 개수가 아니라 개별 목적지로 검증하기

규칙을 추가하기 전에 어떤 도메인이나 주소를 어떤 그룹으로 보낼지, 예외가 필요한 이유가 무엇인지 정리하세요. 저장한 뒤 새 테스트 연결을 만들고 적용된 항목과 최종 외부 연결을 확인합니다. 결과가 예상과 다르면 더 위에 있는 규칙을 살펴보고 클라이언트가 덮어쓰기 규칙을 기본 규칙 뒤에 추가했는지도 확인하세요. 규칙이 많다고 반드시 정확해지는 것은 아닙니다. 중복되거나 서로 가리는 항목은 오히려 유지 관리를 어렵게 합니다. 규칙을 계속 늘리기보다 용도 주석과 복구 기록을 남기는 편이 중요합니다.

중국 본토에서는 직결하고 그 외 목적지는 프록시로 보내는 설정을 다루려면 규칙 분류 설정 실전 가이드를 참고하세요. 지리 데이터베이스를 서비스의 소속 지역을 판단하는 절대 기준으로 삼지 마세요. 콘텐츠 전송 네트워크, 공유 인프라, 여러 지역에 걸친 서비스에서는 예외가 생길 수 있습니다. 필요한 서비스에는 이유를 설명할 수 있는 도메인 예외를 설정하고 규칙과 DNS를 함께 확인해야 유지 관리가 가능한 분류 결과를 만들 수 있습니다.

7. TUN과 DNS: 트래픽 처리 범위 확장

먼저 일반 진입점이 작동하는지 확인하기

TUN은 가상 네트워크 인터페이스를 통해 해당 인터페이스로 라우팅되는 패킷을 받아 시스템 프록시를 따르지 않는 앱의 트래픽을 처리합니다. TUN은 트래픽이 코어로 들어오는 방식을 바꾸지만 작동하지 않는 노드, 잘못된 인증 정보, 문제가 있는 규칙을 자동으로 해결하지는 않습니다. 사용하기 전에 명확한 프록시 진입점으로 접속을 확인해 설정과 외부 연결이 정상인지 검증하세요. 기본 경로가 작동하지 않는데 라우팅과 DNS를 동시에 바꾸면 변수가 늘어나 문제를 찾기 어려워집니다.

TUN 구현은 운영체제, 코어 기능, 클라이언트 권한에 따라 달라집니다. 데스크톱에서는 서비스 구성 요소나 관리자 권한이 필요할 수 있고, 모바일에서는 보통 시스템 VPN 인터페이스로 비슷한 기능을 처리하므로 데스크톱 YAML 조각을 그대로 적용할 수 없습니다. 가상 네트워크 어댑터 생성이나 라우트 설정에 실패하면 먼저 권한과 클라이언트 서비스 상태를 확인하세요. 이때 노드를 계속 바꾸어도 로컬 인터페이스 초기화 결과는 달라지지 않습니다.

라우팅 처리와 DNS 가로채기의 역할

auto-route는 관련 라우트를 자동으로 설정하고, auto-detect-interface는 외부 연결 인터페이스를 자동으로 감지하며, dns-hijack은 지정한 DNS 요청을 내장 DNS 처리기로 보냅니다. 다음은 데스크톱용 mihomo의 일부 구조 예시입니다. 유효한 외부 연결 설정과 병합하고 클라이언트에서 권한을 올바르게 관리해야 합니다. 인터페이스에서 TUN과 DNS 스위치를 이미 제공한다면 생성된 결과를 확인하고 서로 덮어쓰는 설정을 두 벌로 관리하지 마세요.

# 데스크톱 TUN / DNS 예제 조각; 클라이언트가 이 필드를 지원하는지 먼저 확인
tun:
  enable: true
  stack: mixed
  auto-route: true
  auto-detect-interface: true
  dns-hijack:
    - any:53

dns:
  enable: true
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  nameserver:
    - https://dns.alidns.com/dns-query

DNS 덮어쓰기와 fake-ip의 의미

DNS 설정은 도메인 해석 방식을 결정하며 이후 규칙 판단과 연결 설정에도 영향을 줍니다. fake-ip 모드는 도메인에 내부 매핑용 주소를 할당하고, 코어가 매핑을 이용해 도메인을 다시 확인한 뒤 연결을 처리합니다. 이 주소는 대상 웹사이트의 실제 서버 주소가 아닙니다. 앱이 코어를 우회해 해당 주소를 직접 사용하거나 이전 캐시에 이미 만료된 매핑이 남으면 특정 앱에서 연결이 안 될 수 있습니다. 따라서 DNS 모드를 바꾼 뒤에는 새 연결로 테스트하고 필요하면 시스템과 앱의 캐시도 정리하세요.

일부 LAN 서비스, 기기 검색 기능, 실제 DNS 결과에 의존하는 앱은 fake-ip-filter나 클라이언트 호환 설정으로 처리해야 할 수 있습니다. 문제가 생겼다고 모든 도메인을 필터에 넣거나 주소 풀 전체를 임의로 바꾸지 마세요. 먼저 어떤 대상에서 실패했는지, LAN 서비스인지, 특정 앱에서만 문제가 발생하는지 확인한 뒤 범위를 최소화한 예외를 추가하세요. 필터 동작은 설정 모드에 따라 달라질 수 있으므로 사용하는 코어의 안내와 최종 적용 필드를 확인하세요.

일반 DNS 포트를 가로채도 모든 암호화 DNS까지 처리할 수 있는 것은 아닙니다. 브라우저나 앱에 내장된 DoH, DoT는 별도 연결을 사용할 수 있고 운영체제 전용 DNS가 실제 경로를 바꿀 수도 있습니다. 먼저 어느 구성 요소가 DNS를 처리하는지 확인한 다음 코어로 통합할지 앱 자체 설정을 유지할지 결정하세요. 원격 DNS 주소에 접근할 경로도 필요합니다. DNS 서버를 도메인으로 지정한다면 초기 도메인 해석 방식도 고려해 순환 참조가 생기지 않도록 하세요.

라우팅, DNS, 외부 연결 순서로 점검하기

활성화한 뒤 일반 도메인에 접속하고, 이어서 시스템 프록시를 따르지 않던 앱을 테스트한 다음 LAN 기기와 절전 복귀 상태를 확인하세요. 문제가 생기면 연결이 코어에 들어왔는지 살펴봅니다. 기록이 전혀 없다면 라우팅, 제외 범위, 권한을 먼저 확인하세요. 기록은 있지만 도메인 해석에 실패하면 DNS를 점검하고, 외부 연결이 선택된 뒤 접속에 실패한다면 노드와 목적지를 확인합니다. 점검을 마친 후 TUN을 끄고 기존 네트워크가 복구됐는지 확인해 남은 라우트를 지속적인 서비스 오류로 오해하지 않도록 하세요.

다른 VPN, 컨테이너 네트워크, 가상 머신, 회사 터널은 TUN의 라우팅 범위와 충돌할 수 있습니다. 모르는 시스템 라우트를 바로 삭제하지 말고 이번에 추가한 트래픽 처리를 중지한 뒤 동작을 비교하세요. 필요한 경우 클라이언트가 제공하는 라우트 제외 기능을 사용하고 제외된 트래픽은 현재 코어를 우회한다는 점을 명확히 하세요. TUN은 진입점의 적용 범위를 보완하는 기능이지 설정의 경계를 없애는 기능이 아닙니다. 어떤 트래픽이 처리되고 무엇이 제외되는지 설명할 수 있어야 이 단계를 마친 것입니다.

8. 일상적인 유지 관리: 로그, 백업, 업데이트

시간을 기준으로 요청과 오류 연결하기

유지 관리의 기본은 재현 가능한 기록입니다. 문제가 생기면 발생 시각, 사용 중인 네트워크, 목적지 도메인, 클라이언트 모드, 당시 선택한 정책을 기록한 뒤 명확한 요청을 한 번 보내세요. 로그 오류는 주변 상황과 함께 해석해야 합니다. 연결 시간 초과, 도메인 해석 실패, 원격 연결 종료, 설정 파싱 오류는 서로 다른 단계의 문제입니다. 마지막 한 줄만 캡처하면 실제 원인이 된 앞선 기록을 놓치기 쉽고 정상적인 재시도를 지속적인 오류로 오해할 수도 있습니다.

일상적인 사용에서는 로그 수준을 적절히 유지하고 문제를 재현할 때만 잠시 상세도를 높이세요. 상세 로그에는 도메인, 주소, 프로세스 이름, 설정 관련 정보가 포함될 수 있으므로 저장과 공유 범위를 제한해야 합니다. 재현을 마친 뒤에는 평소 로그 수준으로 되돌려 불필요한 접속 정보가 장기간 기록되지 않도록 하세요. 자주 발생하는 오류를 읽는 방법은 Clash 실행 로그로 문제 위치 찾기를 참고하세요. 오류 단어만 검색하기보다 발생한 단계를 살펴보는 것이 중요합니다.

속도가 느릴 때는 측정 대상을 나눠 보기

연결에 성공했다고 해서 기대한 속도가 나온다는 뜻은 아닙니다. 속도 저하는 대상 서비스, 프록시 서버 부하, 외부 경로, 로컬 무선 네트워크, 앱 자체 동작 때문에 생길 수 있습니다. 먼저 같은 기기에서 직결과 프록시 경로를 비교하고, 같은 설정에서 외부 연결을 바꿔 비교한 뒤 로컬 네트워크와 다른 앱의 사용량을 확인하세요. 프록시 그룹 탐지는 테스트 주소의 응답만 보여 줄 뿐 대용량 다운로드 속도를 직접 나타내거나 하루 종일의 상태를 대표하지 않습니다.

테스트에서는 목적지, 시간, 네트워크 조건을 가능한 한 동일하게 유지하세요. 노드를 바꾸고 DNS를 전환하고 TUN을 켜고 규칙까지 수정하면 무엇이 개선에 영향을 줬는지 알 수 없습니다. 속도 저하 단계별 점검 방법에 따라 항목을 하나씩 비교하고 필요한 결과를 기록하세요. 특정 웹사이트에서만 문제가 생긴다면 클라이언트를 바로 재설치하거나 설정 전체를 초기화하기보다 적용 규칙, 콘텐츠 전송 경로, 연결 재사용부터 확인하세요.

백업에는 출처와 덮어쓰기 설정도 포함하기

쓸 수 있는 백업은 YAML 파일 하나만 저장하는 것으로 충분하지 않습니다. 구독 출처, 클라이언트 설정 병합 방식, 수동 규칙, 프록시 그룹 선택, 필요한 시스템 트래픽 처리 설정도 기록해야 합니다. 민감한 정보는 보호된 위치에 저장하고 공개 저장소나 신뢰할 수 없는 공유 폴더에 넣지 마세요. 백업 후에는 각 파일의 용도를 구분할 수 있는지 확인하고 변경 전에 새로운 복구 지점을 만드세요. 실제 적용 파일을 파악할 수 없는 백업은 복원할 때도 다시 점검해야 합니다.

클라이언트 업데이트와 구독 업데이트는 별개의 작업입니다. 클라이언트 업데이트는 인터페이스, 코어, 권한 관리 방식을 바꿀 수 있고, 구독 업데이트는 원격 설정 내용을 바꿉니다. 두 작업을 나누어 진행하세요. 하나를 업데이트한 뒤 실행, 설정 로드, 자주 사용하는 목적지, LAN 연결을 확인하고 나서 다른 항목을 업데이트합니다. 인터페이스가 바뀌었다고 코어도 업데이트됐다고 추측하지 말고, 호환성을 무시한 채 앱 내부 파일을 직접 교체하지 마세요. 되돌릴 때는 기존 설치 출처와 저장해 둔 설정을 사용하세요.

네트워크 전환, 절전 복귀, 정상 종료

유선에서 무선으로 바꾸거나 집 네트워크에서 모바일 핫스팟으로 전환하거나 절전 모드에서 복귀하면 외부 인터페이스, DNS, 라우팅이 바뀔 수 있습니다. 먼저 클라이언트가 인터페이스를 다시 감지했는지 확인하고 정상적으로 트래픽 처리를 중지한 뒤 다시 활성화해 보세요. 특정 네트워크에서만 실패한다면 로컬 규칙을 전부 삭제하기보다 해당 네트워크의 인증 페이지, 접근 제한, 다른 VPN을 비교하세요. 모바일에서는 백그라운드 프로세스가 시스템에 의해 종료되지 않았는지도 확인해야 합니다.

정상적으로 종료하기 전에 시스템 프록시나 VPN 트래픽 처리를 끄고, 앱이 중지됐다고 표시하는지 확인한 다음 프로그램을 종료하세요. 비정상 종료 후 네트워크를 사용할 수 없다면 시스템이 중지된 로컬 프록시 포트를 계속 가리키는지 확인하고 클라이언트가 제공하는 복구 방법으로 서비스나 라우트를 정리하세요. 앱을 제거하기 전에도 같은 절차를 완료해야 합니다. 유지 관리의 목표는 프로그램이 절대 종료되지 않게 하는 것이 아니라 시작, 종료, 오류 발생이 시스템 네트워크에 미치는 영향을 예측하고 관리하는 것입니다.

9. 고급 설정: 재사용 가능한 설정과 실행 범위

기본 파일을 계속 키우기보다 역할별로 나누기

기본 연결을 익힌 뒤에는 설정 구조부터 정리하세요. 원격 노드 출처, 정책 선택, 서비스별 규칙, 로컬 환경 설정을 분리해 관리합니다. 노드는 구독에 따라 바뀌고, 프록시 그룹은 선택 방식을, 규칙은 트래픽의 목적지를, 로컬 덮어쓰기는 포트와 DNS 및 트래픽 처리를 담당합니다. 이렇게 나누면 구독을 바꿔도 모든 규칙을 다시 작성할 필요가 없고, 기기를 옮길 때 네트워크 환경에 종속된 필드도 구분하기 쉽습니다. 파일을 여러 개로 나누는 것만으로는 부족하며 클라이언트의 병합 방식을 이해해야 합니다.

proxy-providers와 rule-providers는 각각 프록시 출처와 규칙 출처를 관리하며 서로 대체할 수 없습니다. 도입하기 전에 콘텐츠 형식, 업데이트 경로, 캐시 위치, 참조 이름을 확인하고 첫 다운로드가 실패했을 때의 동작도 살펴보세요. 원격 리소스는 시작 시 필요한 조건을 늘리므로, 아직 연결되지 않은 프록시를 통해서만 기본 설정을 가져오는 상황은 피해야 합니다. 캐시가 있다고 콘텐츠가 계속 유효한 것은 아니므로 명확한 업데이트 및 복구 경로를 마련하세요.

조합 정책에 따르는 비용 이해하기

중첩 프록시 그룹을 사용하면 서비스별 선택과 개별 노드 선택을 분리할 수 있지만 계층이 깊어질수록 최종 외부 연결이 보이지 않게 됩니다. 먼저 명확한 수동 선택 그룹을 만들고 실제 필요에 따라 자동 탐지나 장애 조치 기능을 추가하세요. 계층을 하나 추가할 때마다 후보 목록, 테스트 경로, 기본 선택을 확인해야 합니다. 자동 전환은 보통 새 연결에 적용되며 기존 연결이 전혀 끊기지 않는다고 보장할 수 없습니다. 오래 유지되는 연결을 사용하는 앱은 그룹에 표시된 이름만 보지 말고 실제로 사용해 검증하세요.

규칙 목록을 관리할 때도 검토 절차를 유지하세요. 서드파티 목록의 범위, 업데이트 주기, 분류 방식이 로컬 요구에 맞지 않을 수 있고 지나치게 큰 목록은 시작과 유지 관리에 부담을 줍니다. 필요한 로컬 예외를 남기고 원격 목록 앞에 둘지 뒤에 둘지 명확히 한 다음 분류를 점차 추가하세요. 중요한 서비스에는 예상되는 외부 연결과 검증 방법을 기록해 원격 규칙이 바뀐 뒤에도 경험에만 의존하지 않고 원인을 확인할 수 있게 하세요.

외부 제어 인터페이스: 필요한 범위만 열기

외부 제어 인터페이스는 클라이언트나 관리 도구가 상태를 읽고 정책을 전환하거나 설정을 업데이트하는 데 사용하며, 일반 프록시 진입점보다 높은 권한을 가집니다. 이 기기에서만 사용할 경우 루프백에 바인딩하고 편리하게 접속하려고 공용 네트워크에 노출하지 마세요. 아래는 최상위 필드 하나의 구조를 보여 주는 예시이며, 인터페이스를 직접 켜라는 뜻이 아닙니다. GUI 클라이언트가 주소와 인증을 이미 관리할 수 있으므로 직접 수정하면 인터페이스 연결이 끊기거나 제어 충돌이 생길 수 있습니다. 먼저 클라이언트 안내를 확인하세요.

# 루프백 바인딩 형식만 표시; 인증 및 접근 제어를 대신하지 않음
external-controller: 127.0.0.1:9090

다른 기기에서 관리해야 한다면 수신 주소만 바꾸지 말고 보호된 접속 경로, 인증, 방화벽, 최소 개방 범위를 먼저 설계하세요. 프록시 진입점, 제어 인터페이스, DNS 수신은 서로 다른 서비스이므로 바인딩 범위와 권한을 각각 확인해야 합니다. 제어 인터페이스 인증 정보를 공개 예제, 스크린샷, 문제 보고서에 넣지 마세요. 로컬 루프백 바인딩을 사용하더라도 이 기기에서 실행되는 앱과 스크립트를 신뢰할 수 있는지는 별도로 판단해야 합니다.

데스크톱 클라이언트에서 코어 단독 실행으로 전환하기

서버와 라우터 환경에서는 실행 인수, 설정 경로, 파일 권한, 로그 순환, 서비스 복구를 직접 관리해야 합니다. 중요하지 않은 환경에서 검증된 설정으로 먼저 실행해 경로와 수신 범위를 확인한 다음 부팅 시 자동 실행을 설정하세요. 특히 원격 관리 중인 기기에서는 첫 실행부터 기기의 기본 라우트를 전부 바꾸지 마세요. 트래픽 처리 설정이 잘못되면 현재 관리 연결이 끊길 수 있습니다. 별도의 복구 경로를 유지하고 재시작, 네트워크 전환, 리소스 다운로드 실패 시 동작도 확인하세요.

코어만 실행하는 설정은 해당 코어의 테스트 모드로 로드 조건을 확인할 수 있지만 먼저 사용하는 실행 파일의 도움말에서 지원 인수를 확인하고 테스트 범위를 이해해야 합니다. 구문과 참조 검사에 통과해도 원격 서버에 연결할 수 있는지, 라우팅 권한이 있는지, 시스템 DNS 경로가 올바른지는 보장되지 않습니다. 실제 실행에서는 진입, DNS 해석, 규칙 적용, 외부 연결을 단계별로 검증해야 합니다. 클라이언트가 생성한 파일을 서버로 복사할 때 상대 경로, 캐시 디렉터리, 플랫폼 차이를 무시하지 마세요.

설명할 수 있는 결과를 고급 설정의 기준으로 삼기

이 단계를 마치면 특정 요청이 어디로 들어오고, 어떤 구성 요소가 DNS를 처리하며, 어느 규칙과 프록시 그룹을 거치는지, 문제가 생겼을 때 어떻게 원래 상태로 복구하는지 설명할 수 있어야 합니다. 분명한 필요가 없는 고급 옵션은 기본값으로 두어도 됩니다. 설정을 길게 만들기 위해 복잡성을 더할 필요는 없습니다. 빠른 사용 방법은 사용 안내를, 개별 문제 해결은 문제 해결을 참고하세요. 확인 결과를 유지 관리 기록에 추가해 기기와 네트워크 환경에 맞는 설정을 차근차근 만들어 가세요.