Clash 사용 가이드:
설치부터 규칙 설정과 TUN까지

1. 핵심 개념과 연결 경로

클라이언트, 코어, 서비스를 구분하세요

Clash 생태계에서 클라이언트는 조작할 수 있는 인터페이스를 제공하고, 코어는 설정을 해석해 연결을 처리하고 규칙을 실행하며, 원격 서비스는 실제 출구를 제공합니다. 이 셋은 서로 다른 역할입니다. 클라이언트를 설치해도 사용할 노드가 자동으로 생기지는 않으며, 구독은 클라이언트 계정이 아닙니다. 문제가 생기면 먼저 인터페이스, 코어 설정, 원격 서비스 중 어디에 해당하는지 판단하세요. 모든 문제를 소프트웨어 설치 실패로 취급하지 않아도 됩니다.

많은 클라이언트가 mihomo 코어를 사용하지만, 실제 지원 여부는 앱에 포함된 코어 빌드, 시스템 권한, 클라이언트 구현에 따라 다릅니다. 파일을 가져올 수 있다고 해서 파일의 모든 항목이 적용되는 것은 아닙니다. 반대로 코어가 기능을 지원해도 클라이언트에 해당 설정 항목이 없을 수 있습니다. 이 문서의 YAML 예시는 일반적인 mihomo 문법을 바탕으로 하므로 적용 전에 현재 클라이언트에서 설정을 입력하는 위치를 확인하세요.

접속 과정을 네 단계로 나눠 보세요

브라우저에서 웹사이트에 접속할 때는 보통 도메인 이름을 확인한 다음 연결을 맺고, 암호화 핸드셰이크를 거쳐 애플리케이션 데이터를 주고받습니다. 프록시는 이 과정의 여러 단계에 관여할 수 있습니다. 시스템 프록시는 앱이 요청을 로컬 포트로 보내도록 하고, 규칙은 연결에 적용할 정책을 정하며, 원격 노드는 대상 사이트에 연결합니다. 어느 단계에서든 실패하면 웹페이지가 열리지 않을 수 있으므로 브라우저에 표시된 마지막 오류만으로는 원인을 파악하기 어렵습니다.

로컬 수신 주소는 보통 루프백 주소이며, 이 경우 기기 내부에서만 연결을 받습니다. 포트는 앱이 코어에 접속하는 입구입니다. 원격 노드의 서버 주소나 서비스 포트와는 전혀 다릅니다. 로컬 포트를 바꿨다면 브라우저나 터미널에 직접 입력한 프록시 주소도 함께 수정해야 합니다. 원격 노드 설정은 일반적으로 구독에서 제공하므로 로컬 포트 충돌을 해결하려고 임의로 바꾸지 마세요. 서로 다른 두 문제를 혼동할 수 있습니다.

정책 그룹은 연결 경로를 선택하는 기능이지 노드 자체가 아닙니다. 수동 선택 그룹에서는 구성원 중 하나를 직접 고르고, 자동 테스트 그룹은 설정된 테스트 조건에 따라 구성원을 선택하며, 장애 조치 그룹은 사용 가능 여부와 순서를 중시합니다. 규칙은 정책 그룹이나 직접 연결 같은 기본 동작을 지정할 수 있습니다. 그룹 이름만 보고 동작을 추측하지 말고 그룹 유형, 구성원, 현재 선택된 항목을 확인하세요.

트래픽 적용, 분기, DNS의 역할을 구분하세요

시스템 프록시, TUN, 규칙 모드는 서로 다른 문제를 해결합니다. 시스템 프록시와 TUN은 트래픽이 코어에 들어오는 경로를 정하고, 규칙 모드는 들어온 트래픽을 어디로 보낼지 결정합니다. DNS 설정은 도메인 이름을 조회하는 방식과 조회 정보를 규칙에 활용하는 방법에 영향을 줍니다. 이 설정들은 조합해서 사용할 수 있으며 서로를 대체하지 않습니다. TUN을 켠 상태에서도 규칙 모드를 사용할 수 있고, 시스템 프록시를 꺼도 모든 트래픽이 코어로 들어가지 않는다고 단정할 수는 없습니다.

설정에 지정된 DNS와 기기의 현재 네트워크가 제공하는 DNS가 동시에 존재할 수도 있습니다. 앱 자체의 암호화 DNS, 브라우저 내장 DNS, 로컬 네트워크 도메인까지 더해지면 경로가 복잡해집니다. 당장 DNS 구성을 바꿀 필요는 없지만 접속 결과가 이상할 때는 도메인 조회도 별도로 점검해야 합니다. IP 주소로 접속할 때와 도메인 이름으로 접속할 때 결과가 다르면 DNS 경로를 살펴볼 단서가 됩니다.

처음 검증할 때는 일반 웹페이지 하나를 대상으로 정하고 클라이언트의 연결 기록을 함께 확인하세요. 기록에서 대상 도메인이나 주소, 적용된 정책, 연결 상태를 확인할 수 있어야 합니다. 기록이 없다면 먼저 트래픽 적용 경로를 점검하고, 기록은 있지만 연결에 실패한다면 노드, DNS, 원격 오류를 살펴보세요. 먼저 문제의 경계를 확인한 뒤 범위를 좁히는 방법은 이후 모든 장에서 활용합니다. 효과가 있는 증거를 남기기에도 재설치 반복보다 낫습니다.

2. 플랫폼과 용도에 맞는 클라이언트 선택

기본 인터페이스를 정한 다음 기능을 비교하세요

일상적인 GUI 사용이라면 먼저 Clash Plus를 고려하고, 운영체제와 필요한 기능에 따라 다른 클라이언트와 비교하세요. 선택 기준은 기능 버튼의 개수가 아니라 구독 업데이트, 정책 선택, 연결 기록, 권한 안내가 이해하기 쉬운지 여부입니다. 설치 전 다운로드 센터에서 해당 플랫폼의 다운로드 경로를 확인하고 시스템 아키텍처와 설치 형식을 맞추세요. 여러 프로그램을 먼저 내려받은 뒤 비슷한 인터페이스 사이에서 설정을 옮기는 일을 피할 수 있습니다.

데스크톱에서는 Clash Verge Rev, FlClash, Clash Nyanpasu를 인터페이스와 작업 흐름이 다른 비교 대상으로 살펴볼 수 있습니다. 설정을 항목별로 그대로 옮길 수 있다고 전제하지 마세요. 구독 처리 기능, 서비스 모드, 코어 업데이트, 로그 위치가 다를 수 있습니다. 기기를 장기간 관리해야 한다면 처음 실행 화면만 비교하기보다 설정이 저장되는 위치와 복구 방법을 파악하는 것이 중요합니다.

이름보다 아키텍처와 시스템 통합 여부가 중요합니다

프로세서 아키텍처는 컴퓨터 브랜드가 아니라 시스템 정보에서 확인하세요. Apple Silicon용과 Intel용 macOS 설치 파일은 구분해야 하며, Windows 기기도 아키텍처가 다를 수 있습니다. Android 범용 패키지와 특정 아키텍처용 패키지는 지원 범위가 다릅니다. 다운로드 페이지에 표시된 항목 중에서 선택하고, 파일 이름의 규칙만 보고 존재하지 않는 설치 파일 주소를 추측하지 마세요.

Linux에서는 배포판별 패키지 관리 방식도 확인해야 합니다. Debian 계열용 패키지를 RPM 계열 배포판의 설치 파일로 사용할 수는 없습니다. GUI 클라이언트는 데스크톱 세션에서 사용하고, 명령줄 코어만 사용할 때는 설정 디렉터리, 서비스 시작, 로그 확인을 직접 관리해야 합니다. 서버에 그래픽 환경이 없다면 프록시를 쓰려고 데스크톱 전체를 추가로 설치할 필요는 없습니다. 코어와 서비스 관리자를 사용하는 편이 더 명확합니다.

모바일 기기는 대체로 시스템 VPN 인터페이스를 통해 트래픽을 처리하며, 관련 서비스를 한 번에 하나만 사용할 수 있는 경우가 많습니다. 다른 보안 도구, 업무용 프로필, 네트워크 가속 앱이 충돌을 일으킬 수 있습니다. 데스크톱에서도 가상 네트워크 어댑터와 라우팅이 서로 영향을 줄 수 있습니다. 기업 VPN이나 특수한 로컬 네트워크를 사용해야 한다면 모든 네트워크 도구가 동시에 작동한다고 가정하지 말고, 트래픽 적용 범위를 명확히 제어할 수 있는지 우선 확인하세요.

구독 호환성과 유지 관리 상태를 별도로 확인하세요

구독 가져오기를 지원한다고 표시되어 있어도 실제로 받을 수 있는 형식은 다를 수 있습니다. 전체 Clash YAML, 노드 목록만 있는 파일, 다른 클라이언트의 설정은 서로 다른 입력 형식입니다. 특히 Surfboard를 선택할 때는 서비스 제공자가 해당 형식을 지원하는지 먼저 확인하세요. 설정 파일 확장자만으로 호환성을 판단할 수 없습니다. 설정을 변환하면 규칙, 정책 그룹, 프로토콜 매개변수가 누락될 수 있으므로 변환 후에도 실제 연결 경로를 확인해야 합니다.

Clash for Windows와 ClashX Meta는 유지 관리가 중단된 아카이브 대상입니다. 기존 환경에서 꼭 필요하다면 이전을 위한 참고 자료로 사용할 수 있지만, 새 기기에는 현재도 유지 관리되는 대안을 우선 검토하세요. 예전 프로그램이 실행된다고 해서 새 구독의 프로토콜과 항목을 모두 이해하는 것은 아닙니다. 알 수 없는 항목, 누락된 노드, 코어 오류가 발생하면 구독이 잘못됐다고 바로 판단하지 말고 지원 기능의 차이부터 확인하세요.

iOS에서 Clash Plus를 사용할 때는 다운로드 센터에서 앱 스토어로 이동하고 공식 웹사이트 clashplus.io의 제품 안내도 확인할 수 있습니다. 같은 이름의 클라이언트를 여러 플랫폼에서 사용하더라도 데스크톱과 모바일의 권한이 동일하다고 가정하지 마세요. 선택이 끝나면 클라이언트 이름, 시스템 아키텍처, 설정 출처, 주요 용도를 기록해 두세요. 이후 문제를 해결할 때 유용한 환경 정보가 됩니다.

3. 설치, 권한, 기본 환경 확인

첫 실행에서는 변경을 최소화하세요

설치하기 전에 실행 중인 다른 프록시 도구를 종료하고 시스템 프록시 설정과 VPN 상태를 기록하세요. 두 프로그램이 시스템 프록시를 동시에 수정하면 나중에 실행된 프로그램이 설정을 덮어쓸 수 있고, 종료 순서에 따라 복구 결과도 달라집니다. 업무용 설정이 이미 있는 기기라면 먼저 백업하세요. 기존 프로그램을 삭제하는 것부터 이전을 시작하지 마세요. 새 프로그램에서 설정을 가져와 안정적으로 작동하는 것을 확인한 다음 기존 환경을 정리하면 쉽게 되돌릴 수 있습니다.

클라이언트를 열면 먼저 기본 화면, 설정 페이지, 로그 페이지가 정상적으로 표시되는지 확인하세요. 자동 시작, TUN, 복잡한 덮어쓰기 설정은 일단 켜지 마세요. 구독이나 노드가 없는 것은 처음에는 정상이며 설치 이상이 아닙니다. 프로그램이 시작하자마자 종료된다면 같은 파일을 계속 다시 내려받기보다 시스템 호환성, 아키텍처 일치 여부, 설치 디렉터리 권한, 보안 소프트웨어 차단 기록을 확인하세요.

권한 요청이 필요한 이유를 확인하세요

데스크톱 클라이언트는 시스템 서비스, 가상 네트워크 어댑터, 네트워크 확장에 추가 권한을 요청할 수 있습니다. 용도를 이해한 뒤 허용하세요. 그래픽 프로그램 전체를 항상 높은 권한으로 실행하는 것은 일반적인 해결 방법이 아닙니다. 시스템 프록시는 대개 현재 사용자 세션과 관련되고, TUN은 서비스 구성 요소와 라우팅 변경이 필요할 수 있습니다. 권한이 부족하다면 해당 기능의 클라이언트 설치 안내를 확인해 서비스가 없는 것인지, 서비스가 실행되지 않은 것인지 구분하세요.

macOS에서는 시스템 안내에 따라 네트워크 관련 권한을 부여하고 시스템 설정에서 해당 항목의 상태를 확인하세요. Android와 iOS에서는 처음 트래픽 적용을 시도할 때 VPN 권한 안내가 표시됩니다. 권한을 거부해도 앱 화면은 열릴 수 있지만 트래픽은 예상대로 코어에 들어가지 않습니다. 조직에서 관리하는 기기에서는 정책에 따라 권한이 제한될 수 있으므로 관리 지침을 따르세요. 제한을 피하려고 반복 설치하지 마세요.

설치가 끝나면 설정 디렉터리와 로그 위치를 찾아 클라이언트가 휴대용 디렉터리, 사용자 데이터 디렉터리, 별도 서비스 디렉터리 중 어디를 사용하는지 확인하세요. 화면에 보이는 설정 파일과 실제로 코어에 전달되는 파일이 다를 수 있습니다. 이후 혼동을 줄이려면 디렉터리 위치만 기록해 두고 파일 내용을 바로 수정하지 마세요. 생성된 파일을 직접 수정하면 다음 저장이나 시작 때 클라이언트가 덮어쓸 수 있습니다.

로컬 포트와 수신 범위

로컬 포트는 앱이 코어에 연결하는 입구입니다. 다른 프로그램이 포트를 사용 중이면 로그에 바인딩 실패나 주소 사용 중과 같은 메시지가 표시되는 경우가 많습니다. 점유 중인 프로그램을 종료하거나 클라이언트에서 지원하는 위치의 수신 포트를 변경한 다음, 직접 입력한 프록시 주소도 함께 수정하세요. 로컬 충돌을 피하려고 구독의 원격 서비스 포트를 바꾸지 마세요. 서로 다른 연결 구간에 영향을 줍니다.

# 로컬 진입점을 이해하기 위한 예시이며, 전체 연결 설정은 아닙니다
mixed-port: 7890
allow-lan: false
mode: rule
log-level: info

예시의 혼합 포트는 일반적인 HTTP와 SOCKS 프록시 요청을 받을 수 있지만, 실제 포트는 클라이언트에 표시된 실행 값을 기준으로 해야 합니다. 초기 문제 해결 중에는 LAN 접근을 꺼 두면 확인 범위를 기기 내부로 제한할 수 있습니다. 나중에 다른 기기에서 사용하려면 수신 주소, 방화벽, 접근 제어도 함께 검토해야 합니다. LAN 옵션만 켠다고 적절한 공유 환경이 만들어지는 것은 아닙니다.

기본 환경 점검의 목표는 특정 웹사이트에 접속하는 데 그치지 않습니다. 프로그램이 실행되고, 코어에 지속적인 오류가 없으며, 수신 경로가 명확하고, 종료 후 네트워크가 복구되어야 합니다. 그다음 구독을 가져오면 문제 범위를 더 쉽게 좁힐 수 있습니다. Linux에서 명령줄로 배포하려면 데스크톱 클라이언트와 systemd, 두 가지 배포 방법을 참고하세요. 데스크톱 자동 시작과 시스템 서비스를 같은 설정으로 취급하지 마세요.

4. 구독 가져오기, 업데이트, 설정 유지

먼저 어떤 항목을 가져오는지 확인하세요

구독은 보통 서비스 제공자가 관리하는 설정 주소이며, 클라이언트는 이를 통해 노드, 정책 그룹, 규칙 등을 가져옵니다. 주소에 개인 식별 정보가 포함될 수 있으므로 민감 정보로 취급하세요. 공개 스크린샷, 지원 요청 글, 공유 문서에 올리지 마세요. 가져오기 전에 제공자가 요구하는 클라이언트 유형과 형식을 확인하세요. 브라우저에서 주소가 열리는 것만으로 현재 코어에 적합한 콘텐츠라고 볼 수는 없습니다.

클라이언트에서 구독, 설정, 프로필 메뉴를 찾아 원격 설정을 추가하고 주소를 붙여 넣은 뒤 저장하세요. 업데이트가 끝나면 해당 설정을 현재 사용 설정으로 지정하고 정책 그룹과 노드가 표시되는지 확인해야 합니다. 클라이언트에 따라 다운로드와 활성화는 별도의 작업일 수 있습니다. 다운로드만 하면 코어가 이전 설정을 계속 사용할 수 있습니다. 설정 이름을 지정할 수 있다면 출처와 용도를 구분할 수 있는 이름을 사용하고 전체 주소는 넣지 마세요.

처음 가져온 뒤에는 성공 메시지만 보지 말고 업데이트 로그와 코어 실행 로그를 확인하세요. 다운로드 성공은 응답을 받았다는 뜻이고, 파싱 성공은 구조를 읽을 수 있다는 뜻이며, 코어 로드 성공은 설정이 실행 단계에 들어갔다는 의미입니다. 지원되지 않는 노드 프로토콜이 있으면 일부 구성원만 표시될 수 있습니다. 노드 수 변화와 경고 메시지를 비교해 누락된 노드를 제공자가 삭제한 것으로 오해하지 마세요.

업데이트 실패는 요청, 응답 내용, 로드 단계로 나눠 확인하세요

요청에 실패하면 먼저 주소가 온전히 복사됐는지 확인하세요. 끝부분 매개변수와 불필요한 공백도 살펴봐야 합니다. 다음으로 오류가 파싱 실패, 연결 시간 초과, 접근 거부, 리디렉션 문제 중 무엇인지 확인하세요. 네트워크는 연결되지만 구독 주소에 접근할 수 없다면 업데이트 요청이 사용하는 네트워크 경로가 원인일 수 있습니다. 업데이트 요청을 기존 프록시로 보내는지는 클라이언트마다 다르므로 관련 설정을 확인하고, 현재 정책 그룹을 자동으로 따른다고 가정하지 마세요.

콘텐츠를 가져온 뒤에도 실패하면 응답이 YAML인지, 다른 형식인지, 웹페이지 오류 안내인지 확인하세요. 계정 상태 페이지, 로그인 페이지, 사람 확인 페이지는 프록시 설정으로 불러올 수 없습니다. 서버가 일시적으로 잘못된 응답을 반환한다면 오류 페이지를 저장해 계속 수정하지 마세요. 기존의 정상 설정을 보존하고 출처가 복구될 때까지 기다리는 편이 안전합니다. 아직 사용할 수 있는 노드와 규칙도 잃지 않을 수 있습니다.

로드 단계에서 오류가 나면 먼저 오류가 가리키는 항목이나 줄 번호를 확인하세요. YAML은 들여쓰기로 계층을 표현하므로 탭 문자, 콜론 누락, 잘못된 목록 계층 때문에 파싱에 실패할 수 있습니다. YAML을 파싱할 수 있어도 존재하지 않는 정책 그룹을 규칙에서 참조하는 등 의미상 문제가 있을 수 있습니다. 텍스트 형식 오류와 코어 검증 오류를 구분하세요. 전자는 구조를, 후자는 지원 항목과 이름 참조를 확인해야 합니다.

원격 설정과 개인 설정을 분리하세요

구독에서 생성된 파일을 직접 수정하면 다음 업데이트 때 변경 사항이 사라지는 경우가 많습니다. 장기간 유지할 설정은 클라이언트가 제공하는 덮어쓰기, 병합, 패치, 로컬 확장 기능에 넣으세요. 메뉴 이름과 병합 순서는 현재 클라이언트에 따라 다릅니다. 로그 수준 변경처럼 작은 수정으로 설정이 유지되는지 확인한 다음, 구독을 직접 업데이트하고 코어를 다시 시작해 변경 사항이 실제 실행 설정에 남는지 확인하세요.

배열 병합은 특히 주의해야 합니다. 일부 덮어쓰기 기능은 규칙 하나만 추가하는 대신 규칙 목록 전체를 교체할 수 있으며, 같은 이름의 정책 그룹이 기존 항목을 덮어쓸 수도 있습니다. 적용 전 미리보기나 내보낸 최종 설정을 확인해 기존 노드, 정책 그룹, 기본 규칙이 남아 있는지 살펴보세요. 같은 항목을 화면의 토글, 로컬 파일, 원격 패치 세 곳에서 동시에 관리하면 실제 적용 값을 설명하기 어려워집니다.

업데이트 후 속도가 느려졌더라도 클라이언트 전체를 먼저 바꿀 필요는 없습니다. 업데이트 전후의 현재 노드, 정책 그룹 선택, 규칙 매칭이 달라졌는지 비교하세요. 노드 이름이 바뀌면 기존 수동 선택이 유효하지 않아 다른 구성원으로 돌아갈 수 있습니다. 간단한 사용 흐름은 입문 가이드의 구독 단계를 참고하세요. 이 장에서는 예약 업데이트를 설정하는 데 그치지 않고 업데이트를 확인하고 복구할 수 있는 유지 관리 작업으로 만드는 방법을 다룹니다.

5. 프록시 모드와 연결 확인

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

일상적인 사용은 규칙 모드부터 시작하세요. 코어에 들어온 연결은 규칙 목록에 따라 경로가 결정되므로, 직접 연결이 필요한 서비스는 유지하면서 특정 요청만 프록시로 보낼 수 있습니다. 전역 모드는 일반적으로 코어에 들어온 연결을 전역 정책으로 보내므로 짧은 비교 테스트에 적합합니다. 직접 연결 모드는 프록시 출구를 거치지 않는 경우를 확인할 때 사용합니다. 모드 이름은 코어 내부의 선택 방식만 나타내며 모든 앱의 트래픽이 이미 적용되었다는 뜻은 아닙니다.

전역 모드로 바꾸면 기기의 모든 통신이 프록시를 거친다고 오해하기 쉽습니다. 시스템 프록시를 사용하지 않는 앱의 연결은 코어에 들어오지 않을 수 있으므로 모드를 바꿔도 결과는 달라지지 않습니다. 문제를 해결할 때는 먼저 연결 기록에 요청이 있는지 확인하고, 다음으로 적용된 정책을 살핀 뒤 출구가 정상인지 판단하세요. 트래픽 적용 범위와 분기 방식은 서로 다른 설정입니다.

최소한의 연결 경로로 검증하세요

우선 TUN은 끈 채 시스템 프록시를 켜고 노드를 하나 선택해 테스트 웹페이지에 접속하세요. 동시에 연결 패널을 열어 대상 도메인으로 필터링하고 적용된 정책과 출구를 확인합니다. 브라우저 페이지가 열린 것은 첫 번째 증거일 뿐입니다. 연결 기록은 요청이 실제로 코어에 들어왔는지 보여 주고, 로그는 실패한 단계를 설명하는 데 도움이 됩니다. 출구 IP 확인 사이트를 사용하는 경우 해당 요청 자체가 예상한 경로를 거치는지도 확인하세요.

명령줄 도구는 데스크톱 시스템 프록시를 사용하지 않을 수 있으므로 로컬 진입점을 명시해 비교 테스트를 할 수 있습니다. 아래 명령은 클라이언트 혼합 포트가 실제로 7890이라고 가정합니다. 실행할 때는 화면에 표시된 포트로 바꾸세요. 테스트 대상은 공개 예제 사이트이며 모든 대상에 똑같이 접속할 수 있다는 뜻은 아닙니다. 요청이 한 번 성공하면 해당 경로가 대체로 작동한다는 의미일 뿐, 모든 프로토콜, 앱, 웹사이트가 정상이라는 보장은 아닙니다.

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

두 번째 명령은 대상 호스트 이름을 SOCKS 프록시에서 처리하므로 기기에서 먼저 DNS 조회를 하는 경로와 비교하기 좋습니다. 두 방식의 결과가 다르면 클라이언트 DNS, 노드 프로토콜, 로그를 함께 살펴보세요. 결과만 보고 특정 유형의 유출이 있다고 단정할 수는 없습니다. 비교할 수 있도록 테스트 명령, 시간, 모드, 노드를 기록해 같은 조건으로 다시 실행하세요.

지연 시간 테스트는 다운로드 속도를 보장하지 않습니다

클라이언트에 표시되는 테스트 값은 일반적으로 지정된 요청의 왕복 응답 시간을 나타내며, 구체적인 의미는 테스트 주소와 구현 방식에 따라 달라집니다. 값이 낮다고 파일 다운로드가 빠르거나 동영상, 게임, 특정 웹사이트가 안정적이라는 보장은 없습니다. 테스트 대상에 연결할 수 없어 실패해도 다른 대상에는 노드가 정상적으로 작동할 수 있습니다. 목록 순위만 보지 말고 실제 용도, 연결 성공률, 일정 시간 동안의 안정성을 함께 고려해 노드를 선택하세요.

브라우저는 정상이지만 다른 앱에서 실패한다면 해당 앱이 시스템 프록시를 지원하는지, 별도 프록시가 설정되어 있는지, 일부 트래픽에만 프록시를 쓰는지 확인하세요. 로그인 과정에서 시스템 구성 요소나 다른 프로세스를 호출하면 기본 창과 로그인 창의 연결 경로가 달라질 수 있습니다. 바로 전역 모드로 전환해 계속 사용하지 마세요. 실패한 연결을 찾은 뒤 앱 설정을 바꿀지, 규칙을 추가할지, 트래픽 적용 범위를 넓힐지 결정하세요.

노드나 모드를 바꾼 뒤에도 이미 연결된 장시간 세션은 이전 경로를 계속 사용할 수 있습니다. 새 설정을 검증하려면 대상 페이지를 다시 열고, 필요한 경우 해당 연결만 종료한 다음 요청을 보내세요. 테스트와 관계없는 모든 세션을 임의로 지우지는 마세요. 일부 앱은 DNS 결과와 연결 풀도 캐시하므로 종료 후 다시 시작해야 할 수 있습니다. 이전 연결을 새 설정의 결과로 착각하면 변경이 적용됐는데도 아무 변화가 없는 것처럼 보일 수 있습니다.

이 단계를 마치면 연결 성공 과정을 재현하고 사용한 모드, 진입 경로, 출구를 설명할 수 있어야 합니다. 첫 연결을 자세히 확인하려면 노드 선택, 테스트, 트래픽 경로 확인을 참고하세요. 최소 연결 경로가 안정적으로 작동해야 규칙과 TUN을 변경한 결과를 분명하게 확인할 수 있습니다.

6. 규칙 순서, 정책 그룹, 트래픽 분기 관리

첫 일치 규칙부터 기본 규칙까지

규칙 목록은 보통 위에서 아래로 확인하며 조건에 처음 일치하는 규칙이 연결 경로를 결정합니다. 따라서 규칙 내용뿐 아니라 순서도 중요합니다. 범위가 넓은 도메인 접미사 규칙이 앞에 있으면 뒤에 있는 정확한 도메인 규칙이 실행되지 않을 수 있습니다. 규칙을 추가하기 전에 기존에 적용되는 위치를 확인하세요. 파일 끝에만 규칙을 덧붙이지 마세요. 마지막에 기본 동작이 있는 경우 저장은 성공한 것처럼 보여도 새 규칙이 적용되지 않을 수 있습니다.

도메인 규칙은 웹사이트나 서비스 범위를 지정하는 데 적합하고, IP 대역 규칙은 명확한 네트워크 범위를 처리하며, 프로세스 규칙은 플랫폼, 권한, 식별 기능에 따라 달라집니다. 하나의 앱이 여러 도메인에 접속하거나 보조 프로세스를 통해 연결할 수 있으므로 대표 도메인 하나를 규칙에 넣었다고 앱의 모든 요청이 적용되는 것은 아닙니다. 앱 이름만 보고 서버를 추측하지 말고 실제 연결을 확인하세요.

# 설정 조각: 기존 설정에 추가하세요. 완전한 구독 설정이 아닙니다
# 이 예시에서는 중국 본토·해외와 같은 지역 구분을 사용하지 않습니다
rules:
  - DOMAIN,example.com,DIRECT
  - DOMAIN-SUFFIX,example.org,DIRECT
  - IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
  - MATCH,DIRECT

예시에서는 순서를 보여 주기 위해 기본 직접 연결 동작을 사용하며, 모든 사용자에게 적합한 실제 분기 설정은 아닙니다. 정확한 도메인 규칙은 지정한 이름에만 적용되고, 접미사 규칙은 해당 도메인과 하위 도메인에 적용됩니다. IP 대역 규칙의 추가 옵션을 사용하면 해당 주소를 매칭하기 위해 DNS 조회를 강제로 시작하지 않을 수 있습니다. 마지막 기본 규칙은 앞의 규칙에 일치하지 않은 연결을 처리합니다. 실제로 프록시를 사용하려면 대상 이름이 현재 설정에 존재하는 정책 그룹과 일치해야 합니다.

그룹 유형을 확인한 뒤 구성원을 조정하세요

수동 정책 그룹은 직접 선택할 때 적합하고, 자동 테스트 그룹은 설정된 검사 결과에 따라 구성원을 선택하며, 장애 조치 그룹은 순서와 사용 가능 여부를 더 중요하게 봅니다. 테스트 대상, 간격, 허용 오차가 전환 동작에 영향을 줍니다. 자동이라는 이름만 보고 실제 사용에 가장 적합한 노드를 항상 고른다고 생각하지 마세요. 연결 유지가 중요한 앱에서는 전환으로 기존 연결이 끊기거나 다시 수립되는지도 살펴야 합니다.

정책 그룹끼리 서로 참조할 수 있지만 이름이 정확해야 하며 순환 참조는 피해야 합니다. 구독 업데이트로 그룹 이름이 바뀌면 로컬 규칙에서 예전 이름을 참조해 로드에 실패할 수 있습니다. 수정하기 전에 규칙의 대상, 그룹 구성원, 최종 노드의 관계를 정리하고 각 경로가 사용 가능한 출구에 도달하는지 확인하세요. 복잡한 설정에서 가장 찾기 어려운 문제는 규칙 문법보다 이름이 비슷한 여러 그룹 중 실제로 무엇이 선택됐는지 확인하는 일입니다.

추측하지 말고 연결 기록으로 규칙을 확인하세요

트래픽 분기는 명확한 대상 하나부터 추가하세요. 변경 전 적용된 규칙과 출구를 기록하고, 범위가 좁은 규칙을 적절한 위치에 넣은 다음 새 연결을 만들어 결과를 확인합니다. 변화가 없다면 현재 설정이 맞는지, 덮어쓰기가 실제로 병합됐는지, 규칙이 더 넓은 범위의 항목보다 앞에 있는지, 대상 요청이 기존 연결인지 차례로 확인하세요. 이 네 가지를 살펴본 뒤에야 규칙 유형이 맞지 않는지 검토하세요.

주소 매칭과 도메인 매칭 결과는 DNS 동작의 영향을 받을 수 있습니다. 코어가 원래 도메인 이름을 확인할 수 없으면 보유한 정보로만 규칙을 적용합니다. 반대로 fake-ip 매핑은 도메인과 연결의 연관성을 유지하는 데 도움이 되지만 전체 트래픽 경로가 일치해야 합니다. 모든 문제를 오래된 규칙 목록 탓으로 돌리지 마세요. 먼저 연결 기록에 도메인과 주소 중 무엇이 표시되는지 확인한 뒤 도메인 규칙, 주소 규칙, DNS 경로 중 무엇을 수정할지 결정하세요.

규칙 집합은 계속 업데이트되는 조건을 재사용할 때 유용하지만, 동작 유형, 저장 위치, 규칙에서 참조하는 방법을 명확히 해야 합니다. 다운로드에 성공했다고 참조까지 완료된 것은 아니며, 파일 형식도 서로 바꿔 사용할 수 없습니다. 외부 규칙 집합을 도입하기 전에 업데이트 출처와 실패 시 영향을 파악하고 마지막으로 정상 작동한 콘텐츠를 보관하세요. 적용 범위를 넓히려고 서로 겹치는 규칙을 많이 추가하지 마세요. 중복이 늘면 어떤 규칙이 매칭됐는지 설명하기 더 어려워집니다.

한동안 사용한 뒤에는 더 이상 필요하지 않은 예외를 정리하세요. 특히 임시 테스트를 위해 추가한 강제 직접 연결이나 강제 프록시 규칙을 확인해야 합니다. 이런 항목은 나중에 구독 규칙을 무효화해도 화면에서 쉽게 발견하기 어렵습니다. 안정적인 규칙 설정은 항목이 많다고 좋은 것이 아닙니다. 문제가 생겼을 때 연결 경로를 빠르게 설명하고 최근 변경을 안전하게 되돌릴 수 있어야 합니다.

7. TUN 적용과 DNS 연동

트래픽 적용 범위를 넓혀야 할 때 사용하세요

TUN은 가상 네트워크 인터페이스로 시스템 트래픽을 받아 시스템 프록시를 따르지 않는 앱을 처리하는 데 적합합니다. 새로운 원격 출구를 제공하거나 작동하지 않는 노드를 자동으로 복구하지는 않습니다. 사용하기 전에 시스템 프록시로 구독과 노드가 정상인지 확인하고 현재 설정을 저장하세요. 그래야 TUN을 켠 뒤 문제가 발생했을 때 권한, 라우팅, DNS, 가상 인터페이스를 집중적으로 살펴볼 수 있습니다. 연결 전체를 처음부터 의심할 필요가 없습니다.

데스크톱에서는 보통 관련 서비스 권한이나 네트워크 구성 요소가 필요하며, 모바일에서는 주로 시스템 VPN 인터페이스의 관리 방식에 영향을 받습니다. 기업 VPN, 보안 도구, 다른 가상 네트워크 소프트웨어를 사용 중이라면 기본 경로나 DNS도 변경하는지 확인하세요. 도구 각각은 정상이어도 함께 사용하면 경로를 두고 충돌할 수 있습니다. 테스트하는 동안에는 트래픽을 적용하는 도구를 하나만 남기고, 반드시 접속해야 하는 로컬 네트워크 리소스를 기록해 하나씩 확인하세요.

# mihomo 설정 조각입니다. 유효한 노드, 규칙, DNS 설정과 병합해야 합니다
tun:
  enable: true
  stack: mixed
  auto-route: true
  auto-detect-interface: true
  dns-hijack:
    - any:53

예시는 일반적인 항목 간 관계를 보여 주며 모든 클라이언트와 시스템에서 사용할 수 있는 것은 아닙니다. 자동 라우팅은 코어가 관련 경로를 설정할지 결정하고, 기본 인터페이스 자동 감지는 실제 네트워크 출구를 선택하는 데 쓰이며, 네트워크 스택 옵션은 시스템 호환성과 관련됩니다. 클라이언트가 화면에서 이 항목을 생성할 수도 있습니다. 파일을 직접 수정해도 덮어써진다면 서로 충돌하는 두 설정을 관리하지 말고 클라이언트가 제공하는 정식 설정 경로에서 변경하세요.

DNS는 부가 설정이 아닙니다

DNS 하이재킹은 보통 트래픽 적용 경로를 거치는 일반 DNS 요청을 대상으로 합니다. 이를 근거로 앱 내장 암호화 DNS까지 모두 가로챈다고 단정할 수는 없습니다. 브라우저의 보안 DNS, 앱 자체 DNS, 기업 내부 도메인은 서로 다른 경로를 사용할 수 있습니다. 문제를 진단할 때는 일반 웹사이트, 로컬 네트워크 이름, 특정 DNS 서비스에 의존하는 앱을 각각 확인하세요. 공개 도메인 하나의 결과를 전체 네트워크의 상태로 일반화하지 마세요.

fake-ip 모드는 앱에 매핑용 주소를 반환한 뒤 이후 연결에서 원래 도메인을 연결합니다. 도메인 기반 분기에 유용하지만 매핑과 연결 경로가 일관되어야 합니다. redir-host는 실제 DNS 조회 주소를 반환하는 방식에 가깝지만 별도의 매칭 및 캐시 조건이 있습니다. 어느 방식이든 모든 상황에서 절대적으로 더 낫다고 할 수 없습니다. 로컬 네트워크 서비스에 문제가 생기면 DNS 모드를 바로 바꾸지 말고 도메인과 앱의 요구 사항부터 확인하세요.

코어의 상위 DNS, 프록시 서버 도메인 조회, 직접 연결용 도메인 조회는 서로 다른 역할을 할 수 있습니다. 합리적으로 보이는 암호화 DNS 주소라도 아직 만들어지지 않은 프록시 연결에 의존해야 한다면 시작 과정에서 의존성 순환이 발생할 수 있습니다. 노드 서버가 도메인 이름을 사용하는 경우 이를 조회하는 경로도 정상이어야 합니다. 항목 간 관계는 nameserver, fallback, fake-ip 설정 해설에서 더 알아보세요.

활성화 후 단계별로 확인하고 문제가 생기면 되돌리세요

먼저 브라우저를 테스트하고, 다음으로 원래 시스템 프록시를 사용하지 않던 앱을 확인한 뒤 프린터, 네트워크 저장 장치, 원격 데스크톱 같은 로컬 네트워크 서비스를 점검하세요. 각 단계에서 연결 기록과 라우팅 관련 로그를 확인합니다. 로컬 네트워크에 문제가 있으면 대상 주소가 우회해야 하는 범위에 속하는지, DNS 조회 결과가 올바른지 확인하세요. 시스템 방화벽을 먼저 끄지 마세요. 변경 범위가 커지고 실제 원인을 가릴 수 있습니다.

Wi-Fi에서 유선 네트워크나 핫스팟으로 전환하거나 절전 모드에서 복귀하면 출구 인터페이스와 기본 경로가 달라질 수 있습니다. 전환 전에는 작동하던 TUN이 이후 작동하지 않는다면 인터페이스 감지와 서비스 상태부터 확인한 다음 해당 연결을 다시 시작하세요. 환경에 따라 가상 인터페이스를 다시 만들어야 할 수 있지만 매번 클라이언트를 재설치해야 한다는 뜻은 아닙니다. 전환 전후의 로그를 보관하면 인터페이스 변경, 노드 재연결, DNS 캐시 문제를 구분할 수 있습니다.

출구 확인과 DNS 테스트는 상태를 살펴보는 데 도움이 되지만 웹페이지 하나로 기기의 모든 앱이 같은 경로를 사용한다고 증명할 수는 없습니다. 실제로 테스트한 앱과 요청 유형에 한정해 결론을 내리세요. TUN 설정의 목표는 필요한 앱의 트래픽이 적용되고, 로컬 네트워크를 계속 쓸 수 있으며, 네트워크 전환 뒤에도 복구되는 상태입니다. 설정을 완성해 보이게 하려고 모든 고급 옵션을 계속 켜 둘 필요는 없습니다.

8. 유지 관리, 백업, 문제 해결

정상 작동 상태를 기준으로 기록하세요

연결이 안정되면 클라이언트 이름, 코어 정보, 현재 설정, 구독 출처, 트래픽 적용 방식, 필요한 로컬 예외를 기록하세요. 백업에는 개인 덮어쓰기와 필요한 정책 선택을 포함하되 접근 식별 정보가 있는 주소를 공개하지 마세요. 기본 화면을 캡처한 이미지 한 장만으로는 실행 환경을 복원하기 어렵습니다. 서비스 설정, DNS, 로컬 확장 설정에 중요한 항목이 있을 수 있습니다.

백업 파일은 본인이나 권한이 있는 사람만 접근할 수 있는 위치에 저장하세요. 기기를 옮기기 전에 클라이언트가 지원하는 설정을 내보내고, 구독 인증 정보와 로컬 경로가 포함되는지 확인하세요. 데스크톱 경로가 모바일에 적합하지 않을 수 있고 일부 화면 설정은 운영체제 간에 복원되지 않을 수 있습니다. 이전을 성공적으로 마쳤다는 기준은 파일 가져오기 중 오류가 없다는 것이 아니라 새 기기에서 원하는 연결을 다시 구성할 수 있는지 여부입니다.

업데이트를 나눠 적용하고 확인 시간을 두세요

클라이언트, 코어, 구독, 규칙 집합은 서로 다른 업데이트 대상입니다. 같은 시점에 모두 바꾸면 문제가 생겼을 때 원인을 파악하기 어렵습니다. 구독을 먼저 업데이트해 확인하고, 다음에 클라이언트나 코어를 업데이트한 뒤 개인 규칙을 점검하세요. 매번 되돌릴 수 있는 상태를 보관하세요. 특히 중요한 작업을 앞두고 권한, 네트워크 확장, 라우팅을 크게 변경하는 것은 피해야 합니다.

업데이트 로그에 표시된 기능 변경은 현재 사용하는 설정과 관련 있는지 확인하세요. 새 프로토콜 지원이 사용 중인 환경과 무관하다면 즉시 옮길 필요는 없습니다. 기존 항목의 동작이 바뀌었다면 복사본에서 먼저 검증하세요. GUI 클라이언트 업데이트도 설정 병합 순서나 기본값을 바꿀 수 있으므로 기존 버튼이 켜져 있는지만 보지 말고 최종 실행 설정을 다시 확인하세요.

문제 범위에 따라 점검 위치를 정하세요

먼저 문제가 대상 하나, 앱 하나, 전체 연결 중 어디에 영향을 주는지 확인하세요. 웹사이트 하나에서만 문제가 생기면 대상 서비스 상태와 개별 규칙을 먼저 확인하는 편이 좋습니다. 모든 노드에서 동시에 실패한다면 로컬 진입점, DNS, 현재 네트워크 제한을 살펴보세요. 특정 노드만 문제라면 해당 노드의 연결 오류에 집중하세요. 범위 판단만으로 결론을 내릴 수는 없지만 근거 없는 작업을 반복하는 일을 크게 줄일 수 있습니다.

오류가 발생한 시각 전후의 로그부터 읽고 가장 먼저 나온 관련 실패를 찾은 뒤 이어지는 오류를 확인하세요. DNS 조회 실패가 이후 연결의 시간 초과로 이어질 수 있고, 로컬 포트 바인딩 실패가 화면의 연결 오류를 일으킬 수도 있습니다. 마지막 줄만 캡처하지 마세요. 문제 해결을 위해 로그 상세 수준을 일시적으로 높였다면 작업 후 일상적인 수준으로 되돌리세요. 기록이 계속 쌓이면 저장 공간을 차지하고 불필요한 접속 정보가 노출될 수 있습니다.

자동 시작과 절전 복귀를 별도로 테스트하세요

클라이언트 자동 시작, 코어 서비스 시작, 시스템 프록시 자동 활성화는 각각 별도의 설정일 수 있습니다. 설정 후 실제로 한 번 재부팅해 로그인 전후의 서비스 상태와 네트워크 연결이 준비되기 전에 구독 업데이트가 어떻게 처리되는지 확인하세요. 시작 프로그램 목록에 앱이 있다는 이유만으로 프록시가 정상 작동한다고 판단할 수는 없습니다. 암호 입력이나 사용자 확인이 필요한 환경에서는 자동 연결에 시간이 더 걸릴 수 있습니다.

절전 복귀와 네트워크 전환도 유지 관리 점검에 포함하세요. 복귀 후 이전 세션만 실패한다면 연결을 다시 만드는 것으로 충분할 수 있습니다. 모든 요청 기록이 없다면 트래픽 적용 경로와 서비스를 확인하고, 기록은 있지만 DNS 조회가 계속 실패하면 DNS와 출구를 살펴보세요. 단계별로 점검하면 정상인 부분을 유지할 수 있으며, 일시적인 증거를 지우려고 매번 기기 전체를 재부팅하지 않아도 됩니다.

클라이언트에 연결됨으로 표시되는데도 접속에 문제가 있으면 이 가이드의 최소 검증 경로를 다시 테스트하고 결과에 맞는 점검 절차를 따르세요. 변경 결과를 설명하기 어렵다면 마지막으로 정상 작동했던 상태로 되돌리고 한 번에 하나씩 다시 적용하세요. 유지 관리의 목표는 오류 메시지를 전부 외우는 것이 아닙니다. 기록 방식을 정립해 다음에 같은 문제가 생겼을 때 더 빨리 원인을 찾고 임시 해결책이 장기적인 문제로 남지 않게 하는 것입니다.

9. 작동하는 설정에서 유지 관리 가능한 고급 구성으로

먼저 최종 설정을 확인하는 법을 익히세요

고급 설정의 첫 단계는 항목을 더 추가하는 것이 아니라 현재 실행 설정이 어디서 만들어졌는지 설명하는 것입니다. 구독, 클라이언트 기본값, 화면 설정, 로컬 덮어쓰기가 함께 병합될 수 있습니다. 미리보기, 내보내기, 실행 설정 메뉴를 찾아 수신 포트, 모드, DNS, 정책 그룹, 규칙 순서를 확인하세요. 파일의 값과 화면에 표시된 값이 다르면 어느 설정이 우선 적용되는지 파악한 뒤 수정할 위치를 정하세요.

실험 전용 설정 복사본을 만들고 일상적으로 쓰는 설정은 기준 상태로 남겨 두세요. 한 번에 하나만 변경하고 예상 결과와 검증 방법을 적으세요. 예를 들어 규칙 집합을 추가할 때는 먼저 파일이 업데이트되는지, 규칙에서 참조하는지, 테스트 연결에 실제로 매칭되는지 차례대로 확인합니다. 실험에 실패해도 어느 단계에서 문제가 생겼는지 파악할 수 있으므로 설정 전체가 작동하지 않는다는 결론에 그치지 않습니다.

의존 관계에 따라 기능을 확장하세요

먼저 규칙 집합을 익힌 다음 노드 제공자를 살펴보고 DNS 분기와 복잡한 정책 그룹을 차례로 알아볼 수 있습니다. 규칙 집합은 조건을 재사용하고 노드 제공자는 노드 출처를 관리하는 기능으로 서로 다릅니다. 사용하기 전에 콘텐츠 형식, 동작 유형, 업데이트 위치, 참조 방법을 확인하세요. 어떤 출처에서 콘텐츠를 내려받을 수 있어도 기존 규칙이나 정책 그룹에 자동으로 추가되는 것은 아닙니다. 참조 관계를 명시해야 합니다.

예약 업데이트, 상태 확인, 자동 정책 선택도 하나의 의존 관계로 이해해야 합니다. 노드 목록 업데이트로 구성원이 바뀔 수 있고, 상태 확인은 사용 가능 정보를 제공하며, 정책 그룹은 유형에 따라 구성원을 선택합니다. 어느 한 단계의 업데이트가 실패해도 화면에는 이전 결과가 남아 있을 수 있습니다. 자동 선택이 이상하다면 테스트 간격을 바로 줄이지 말고 구성원이 최신인지, 상태 확인이 성공했는지, 그다음 선택 로직은 어떻게 동작하는지 확인하세요.

프로토콜을 사용하려면 코어와 클라이언트의 설정 지원, 서버 매개변수가 모두 맞아야 합니다. 문서에 프로토콜 이름이 나온다고 해서 현재 설치된 코어에서도 사용할 수 있다는 뜻은 아닙니다. 기존 설정을 옮기려면 mihomo와 원본 Clash 코어의 차이를 참고하고, 소프트웨어 이름만으로 설정 호환성을 판단하지 말고 항목과 프로토콜을 확인하세요.

터미널과 서비스 환경은 따로 관리하세요

터미널 환경 변수는 보통 현재 세션과 그 하위 프로세스에만 적용되며 모든 데스크톱 앱에 프록시를 자동 설정하지 않습니다. 도구마다 지원 방식도 다릅니다. 잠깐 테스트할 때는 명령 자체의 프록시 옵션을 우선 사용하고, 세션 단위 설정이 꼭 필요할 때 환경 변수를 사용하세요. 여러 시작 파일에 로컬 주소를 장기간 기록해 두고 출처를 잊지 마세요. 클라이언트를 종료한 뒤에도 터미널이 작동하지 않는 포트를 계속 가리킬 수 있습니다.

# POSIX 셸: 현재 세션과 하위 프로세스에만 설정
# 포트는 클라이언트의 실제 수신 포트와 일치해야 합니다
export http_proxy="http://127.0.0.1:7890"
export https_proxy="http://127.0.0.1:7890"

# 테스트가 끝나면 예시 설정을 해제합니다
unset http_proxy https_proxy

서비스 관리자가 시작한 프로세스는 대화형 터미널의 환경 변수를 모두 상속하지 않는 경우가 많습니다. 서버에 배포할 때는 자동 시작을 설정하기 전에 설정 파일 경로, 작업 디렉터리, 실행 사용자, 로그 위치를 명확히 정하세요. 터미널에서 실행된다고 해서 시스템 서비스도 올바르게 설정된 것은 아닙니다. 클라이언트 API나 제어판을 사용한다면 수신 범위를 제한하고 접근 제어를 설정해 불필요한 네트워크에 관리 기능이 노출되지 않도록 하세요.

설정의 복잡성 대신 검수 목록을 사용하세요

고급 설정은 최소한 다음 항목을 통과해야 합니다. 일반 웹페이지가 열리고, 프록시가 필요한 앱에 연결 기록이 있으며, 로컬 네트워크 서비스를 사용할 수 있고, 구독 업데이트가 개인 규칙을 덮어쓰지 않으며, 네트워크 전환 후 복구되고, 프로그램을 종료한 뒤 시스템 네트워크가 예상 상태로 돌아와야 합니다. 이는 특정 인터페이스에 좌우되지 않는 실제 사용 결과입니다. 새 기능 때문에 하나라도 충족하지 못하면 기능을 더 추가하기 전에 경계 문제부터 해결하세요.

우회 게이트웨이, 라우터, 여러 기기 공유를 구성하면 영향을 받는 범위가 한 기기에서 다른 기기로 확대됩니다. 이때는 게이트웨이, 전달, 방화벽, 응답 경로도 이해해야 하며 데스크톱 TUN 예시를 그대로 적용해서는 안 됩니다. 별도 기기나 격리된 네트워크에서 먼저 테스트하고 기존 게이트웨이와 DNS를 복구하는 방법을 마련하세요. 현재 지식 범위를 넘어선다면 안정적인 단일 기기 구성에서 멈추는 것이 기능 부족이 아니라 영향 범위를 적절히 제한하는 방법입니다.

주요 작업 흐름을 다시 따라가려면 입문 가이드로 돌아가세요. 기기나 클라이언트를 바꾸려면 다운로드 센터에서 플랫폼을 선택하세요. 특정 설정 문제가 있다면 기술 노트에서 주제별로 더 살펴볼 수 있습니다. 체계적인 참고 자료의 가치는 모든 항목을 한 번에 읽는 데 있지 않습니다. 설정을 바꾸기 전에 목표, 조건, 확인할 증거, 되돌릴 방법을 파악하는 데 있습니다.