V2Ray 고급 설정 가이드

CHAPTER 01 / BASELINE

설정 기준선: 클라이언트·코어·시스템 네트워크 구분하기

고급 설정에서 가장 흔한 문제는 특정 매개변수의 오타가 아니라 서로 다른 계층의 설정을 뒤섞는 데서 발생합니다. v2rayN, v2rayNG, v2flyNG는 구독을 가져오고 서버를 선택하며 설정을 생성하고 연결 상태를 제어하는 그래픽 클라이언트입니다. Xray와 V2Fly 같은 코어는 프로토콜, 라우팅, DNS 및 아웃바운드 로직을 실행합니다. 시스템 프록시, 가상 네트워크 어댑터, 애플리케이션 자체의 네트워크 옵션은 트래픽이 실제로 코어에 들어가는지를 결정합니다. 문제를 해결할 때는 먼저 어느 계층에서 장애가 발생했는지 확인해야 합니다. 그렇지 않으면 서버를 계속 바꿔도 현상만 가려질 뿐입니다.

복구 가능한 설정 출발점 만들기

조정을 시작하기 전에 클라이언트에서 현재 작동하는 설정을 내보내거나 구독 출처, 활성 서버, 프록시 모드, 라우팅 방식과 DNS 설정을 기록하세요. v2rayN의 구독 정보, 서버 목록과 라우팅 방식은 클라이언트가 관리하는 데이터입니다. 반면 코어 실행 중 생성되는 설정은 인터페이스 옵션에 따라 달라질 수 있으므로, 임시 JSON 일부만 복사해 전체 백업으로 사용해서는 안 됩니다. 모바일에서는 VPN 서비스, 앱별 프록시, 로컬 네트워크 우회가 활성화되어 있는지도 기록해야 합니다. 이러한 옵션이 실제 트래픽 범위를 바꾸기 때문입니다.

설정 기준선은 다음 세 조건을 충족해야 합니다. 일반 브라우저가 예상대로 인터넷에 접속되고, 클라이언트 로그에 시작 오류가 계속 반복되지 않으며, 선택한 서버 항목에 주소, 포트, 사용자 식별자, 전송 방식과 보안 매개변수가 모두 포함되어야 합니다. 기준선이 작동해야 이후의 분기 라우팅과 DNS 비교도 의미가 있습니다. 기본 연결이 아직 완료되지 않았다면 빠른 시작 안내로 돌아가 구독 가져오기, 서버 선택, 연결 시작, 트래픽 확인 순서로 진행하세요.

로그를 읽을 때는 첫 번째 오류부터 찾기

코어 로그는 하나의 장애가 발생한 뒤 여러 메시지를 연속해서 출력하는 경우가 많습니다. 실제로 중요한 것은 시작 직후 나타난 첫 번째 설정 오류, 해석 오류 또는 연결 오류입니다. 예를 들어 라우팅 규칙이 존재하지 않는 아웃바운드 태그를 참조하면 이후 모든 연결이 실패할 수 있습니다. DNS 서버에 연결할 수 없으면 뒤이어 도메인 시간 초과로 나타날 수 있고, 시스템 프록시가 적용되지 않으면 클라이언트 로그에 해당 요청이 전혀 남지 않을 수도 있습니다. 마지막 줄만 보거나 일반적인 연결 종료 기록을 원인으로 오해하지 마세요.

다음 순서로 확인하는 것이 좋습니다. 클라이언트가 코어를 시작했는가 → 요청이 로컬 인바운드로 들어왔는가 → 도메인이 해석되었는가 → 라우팅이 예상 규칙과 일치했는가 → 대상 아웃바운드가 연결되었는가. 클라이언트가 코어를 시작하지 못했다면 설정 생성과 포트 점유를 확인하세요. 요청이 로컬 인바운드에 들어오지 않는다면 시스템 프록시, 브라우저의 독립 프록시 또는 TUN 상태를 점검하세요. 도메인만 실패하고 IP 직접 접속은 응답한다면 DNS를 우선 확인하세요. 일부 사이트만 잘못된 경로로 연결되면 라우팅 순서와 도메인 목록을 다시 살펴보세요.

매개변수 출처와 우선순위

구독은 서버 연결 매개변수를 제공하고, 클라이언트는 로컬 덮어쓰기 설정을 저장하며, 라우팅과 DNS 방식은 실행 로직을 결정하고, 시스템 네트워크는 트래픽 진입점을 결정합니다. 구독 업데이트로 서버 항목이 다시 생성될 수 있으므로 장기적으로 사용할 규칙을 특정 서버의 메모 하나에만 기록해서는 안 됩니다. 계속 유지해야 하는 그룹, 필터와 라우팅 정책은 클라이언트의 구독 설정, 라우팅 방식 또는 별도 설정에 저장하세요. 원본 설정을 직접 편집해야 한다면 다음 시작 때 클라이언트가 이를 덮어쓰지 않는지 먼저 확인하세요.

이 장을 마치면 현재 문제가 데이터 관리, 코어 실행 또는 시스템 트래픽 가로채기 중 어디에 속하는지 명확히 판단할 수 있어야 합니다. 이 판단에 따라 다음 도구가 달라집니다. 서버 항목이 뒤섞였다면 구독을 정리하고, 접속 방향이 잘못되었다면 라우팅을 조정하며, 도메인에 이상이 있다면 DNS를 확인하세요. 시스템 프록시를 따르지 않는 프로그램만 연결되지 않을 때 TUN을 고려하면 됩니다. 계층을 분리하는 것이 이 가이드의 설정을 안정적으로 재현하기 위한 전제입니다.

CHAPTER 02 / GROUPS

구독 그룹과 서버 필터링

하나의 구독에도 많은 항목이 포함될 수 있습니다. 모든 서버를 하나의 목록에 펼쳐 놓으면 선택, 업데이트와 문제 추적이 점점 어려워집니다. 그룹의 목적은 복잡한 계층을 만드는 것이 아니라 ‘데이터의 출처’, ‘항목의 용도’, ‘일시적으로 숨길 내용’을 분리해 표현하는 데 있습니다. v2rayN은 데스크톱에서 여러 구독을 한곳에 정리하기에 적합하고, v2rayNG와 v2flyNG는 모바일 환경에서 의미가 분명한 소수의 그룹만 유지해 전환 비용을 줄이는 편이 좋습니다.

먼저 출처별로 그룹화한 뒤 용도에 따라 필터링하기

구독 출처는 가장 안정적인 첫 번째 경계입니다. 각 출처에 ‘일상 회선’, ‘테스트 회선’, ‘예비 회선’처럼 알아보기 쉬운 이름을 붙이세요. 지역, 프로토콜, 배율과 용도를 하나의 그룹명에 모두 넣지는 않는 것이 좋습니다. 출처별 그룹은 어느 데이터 묶음에서 업데이트가 실패했는지 파악하고 문제가 있는 출처를 개별적으로 중지하는 데 도움이 됩니다. 용도는 메모 키워드와 필터 조건으로 처리하는 편이 적합합니다. 예를 들어 이름에 ‘업무’ 또는 ‘저배율’이 포함된 항목은 유지하고, ‘만료’, ‘잔여’, ‘공식 사이트’처럼 알림 성격의 단어가 포함된 항목은 숨길 수 있습니다.

필터는 보통 유지와 제외라는 두 방향으로 구성됩니다. 유지 규칙은 ‘일본’ 또는 ‘싱가포르’가 포함된 서버만 표시하는 것처럼 범위가 명확한 소규모 집합에 적합합니다. 제외 규칙은 알림 항목이나 당장 사용하지 않을 프로토콜을 정리하는 데 유용합니다. 두 종류를 함께 사용할 때는 클라이언트의 처리 순서를 먼저 이해하세요. 일반적으로 구독에서 전체 항목을 가져온 뒤 필터 조건을 적용합니다. 필터는 클라이언트의 목록 표시나 가져오기 결과만 바꾸며 원격 구독 자체는 변경하지 않습니다.

정규식 필터를 안전하게 작성하는 법

일반 키워드만으로 조건을 표현하기 어려울 때는 정규식을 사용할 수 있습니다. 여러 지역명은 세로 막대(|)로 ‘이 중 하나’를 나타낼 수 있고, 제외할 알림 단어도 하나로 묶을 수 있습니다. 정규식은 짧게 유지하고 먼저 적은 수의 항목에서 검증하세요. 지나치게 복잡한 전방 탐색이나 역추적 조건은 유지 관리가 어렵고, 클라이언트마다 정규식 구현이 달라 결과가 달라질 수도 있습니다.

유지 예시:
일본|도쿄|싱가포르|미국

제외 예시:
만료|잔여|공지|웹사이트|트래픽

일반적인 지역 접두사를 정확히 매칭:
^(일본|싱가포르|미국)[-_ ]

메모에는 중국어, 영문 약어와 국기 기호가 함께 표시될 수 있습니다. 구독 이름이 통일되어 있지 않다면 먼저 전체 목록을 확인한 뒤 키워드를 정하세요. 인터넷에서 찾은 긴 정규식을 바로 적용하지 마세요. 필터 적용 후 항목이 갑자기 모두 사라지면 조건을 먼저 비워 원본 구독이 정상인지 확인한 다음 정규식을 일부씩 복원하세요. 일부 이름만 매칭되지 않는다면 전각 공백, 하이픈과 대소문자 차이를 점검하세요.

속도 측정 결과가 곧 사용 가능성은 아니다

서버 필터링은 속도 측정과 함께 자주 사용되지만, 지연 시간 테스트는 특정 탐색 요청이 도달했는지만 보여줄 뿐 실제 프로토콜 연결, 대상 사이트 접속 또는 지속적인 전송 성능을 완전히 대변하지는 않습니다. TCP 탐색에 응답한다고 인증 매개변수가 올바른 것은 아니며, 한 번의 지연 시간이 낮다고 피크 시간대에도 안정적이라는 뜻은 아닙니다. 필터링할 때는 명백히 연결되지 않는 항목을 먼저 제외한 뒤 실제 접속으로 후보 회선을 검증하세요. 하나의 숫자만으로 영구적으로 정렬해서는 안 됩니다.

더 안정적인 절차는 다음과 같습니다. 구독 하나를 업데이트하고 항목 수와 메모 구조를 확인합니다. 제외 규칙을 적용해 알림 항목을 정리합니다. 소수의 후보 서버를 골라 연결성 테스트를 수행합니다. 그중 하나를 시작해 자주 사용하는 대상에 접속합니다. 마지막으로 현재 네트워크에 적합한 순서를 저장합니다. 네트워크 환경이 바뀌면 다시 테스트하고, 이전 결과를 고정된 속성처럼 사용하지 마세요. 노드 속도 측정의 왜곡과 판단 방법은 사이트 글 목록의 문제 해결 콘텐츠에서 더 확인할 수 있습니다.

업데이트 후 변경 사항 확인

구독을 업데이트한 뒤 최소한 세 가지를 확인하세요. 출처 이름이 여전히 원래 그룹과 일치하는지, 서버 메모가 바뀌어 필터 규칙이 무효화되지 않았는지, 현재 활성 서버가 교체되거나 삭제되지 않았는지 점검합니다. 구독 제공자가 이름 형식을 바꾸면 기존 키워드가 새 항목을 전부 제외할 수 있습니다. 이때는 먼저 필터를 끄고 원본 결과를 확인한 다음 정규식을 업데이트하세요. 특정 출처의 업데이트가 실패했다고 곧바로 모든 구독을 덮어써서 업데이트하지 마세요. 해당 링크의 상태, 기존 연결을 통해 업데이트해야 하는지, 반환 내용이 클라이언트가 인식할 수 있는 형식인지부터 개별적으로 확인하세요.

그룹 구성이 끝났다는 기준은 목록이 깔끔해 보이는 것이 아니라 세 가지 질문에 답할 수 있는지입니다. 현재 서버는 어느 구독에서 왔는가, 왜 이 필터 결과에 표시되었는가, 업데이트에 실패하면 어느 출처를 조작해야 하는가. 이 세 가지가 분명하면 이후의 다중 구독 관리와 라우팅 연결에도 안정적인 기반이 생깁니다.

CHAPTER 03 / MULTI-SUBSCRIPTION

다중 구독 관리와 업데이트 전략

여러 구독을 동시에 사용할 때의 핵심 위험은 항목 수가 아니라 출처 간 덮어쓰기, 이름 중복과 업데이트 일정 충돌입니다. 합리적인 다중 구독 구조에서는 각 출처를 독립적으로 업데이트하고 중지하며 문제를 해결할 수 있어야 하고, 불필요한 곳에 구독 주소를 복사하지 않아야 합니다. 데스크톱에서는 보통 v2rayN을 통합 관리 창구로 사용합니다. Android에서는 휴대에 필요한 출처만 가져와 매번 업데이트할 때 중복 서버를 대량으로 처리하지 않도록 하는 편이 좋습니다.

각 출처에 독립적인 식별자 만들기

구독을 추가할 때 이름은 전체 주소를 드러내기보다 용도를 표현해야 합니다. 예를 들면 ‘주요 데스크톱’, ‘모바일 예비’, ‘프로토콜 테스트’처럼 지정할 수 있습니다. 두 출처에 같은 이름의 서버가 포함될 수 있다면 구독 이름에 짧은 접두사를 붙이고 클라이언트가 제공하는 출처 식별자도 유지하세요. 서버 메모는 바뀔 수 있지만 구독의 정체성은 바뀌지 않아야 합니다. ‘구독 1’, ‘구독 2’처럼 출처를 떠올리기 어려운 이름이나 현재 날짜를 장기 이름으로 사용하지 마세요.

하나의 주소를 여러 그룹에 중복 추가해서는 안 됩니다. 중복 출처는 업데이트 후 비슷한 항목을 만들기 때문에 실제 소속을 판단하기 어려워집니다. 중복을 발견하면 먼저 구독 주소와 업데이트 시간을 비교한 뒤 관리 기록 하나만 남기세요. 클라이언트가 구독 단위로 서버를 제거하는 기능을 제공한다면 전체 목록에서 하나씩 삭제하지 말고 출처 단위 작업을 사용하세요. 다음 업데이트 때 다시 가져올 수 있기 때문입니다.

업데이트 순서와 실패 격리 계획하기

안정적인 방법은 현재 사용하는 주요 출처를 먼저 업데이트하고, 연결이 되는지 확인한 뒤 예비 출처를 차례로 업데이트하는 것입니다. 모두 병렬로 업데이트하면 조작 횟수는 줄지만 어느 출처가 비정상적인 내용을 반환했는지 찾기 어려워집니다. 자동 업데이트 간격은 지나치게 짧게 설정하지 마세요. 구독 내용은 보통 실시간 상태 스트림이 아니므로 자주 요청해도 회선 자체가 더 안정적이 되지 않습니다. 자동 업데이트가 필요하다면 일상적인 변경을 반영할 수 있는 주기를 선택하고, 장애 복구를 위한 수동 업데이트 기능도 남겨 두세요.

업데이트 실패는 네 가지 방향으로 판단할 수 있습니다. 주소 자체가 만료되었는지, 현재 네트워크에서 구독 주소에 직접 접근할 수 없는지, 서버가 요청 특성에 따라 반환을 거부했는지, 반환 형식이 클라이언트와 호환되지 않는지 확인하세요. 첫 단계로 클라이언트에서 해당 출처만 업데이트하며 안내를 확인합니다. 두 번째로 기존의 작동하는 연결을 통해 프록시 업데이트를 시도합니다. 세 번째로 주소를 복사할 때 불필요한 공백, 줄바꿈 또는 잘림이 없었는지 확인합니다. 네 번째로 반환된 것이 구독 데이터인지 일반 웹페이지인지 점검합니다. 더 자세한 분기는 구독 업데이트 실패 문제 해결 및 자동 업데이트 설정을 참고하세요.

병합·변환과 로컬 규칙의 경계

구독 변환은 클라이언트 형식 차이, 필터 필드와 병합 출력을 처리하는 데 적합하지만 변환 단계가 길어질수록 문제를 찾기 어려워집니다. v2rayN, v2rayNG 또는 v2flyNG가 원본 출처를 직접 인식할 수 있다면 우선 직접 가져오세요. 변환이 꼭 필요하다면 변환 과정이 포장 형식만 바꾸는지, 아니면 프로토콜 매개변수, 서버 이름과 라우팅 규칙까지 다시 작성하는지 명확히 확인해야 합니다. 연결 매개변수를 바꾸는 단계는 원본 구독은 작동하지만 변환 결과는 실패하게 만들 수 있습니다.

원격 구독의 임시 메모에 로컬 장기 라우팅 규칙을 의존하지 마세요. 메모는 서버 필터링에 사용할 수 있지만 도메인 분기 조건으로는 적합하지 않습니다. 라우팅은 대상 도메인, IP, 포트, 프로세스 또는 인바운드 태그를 기준으로 작성하고 서버 목록의 출처와 분리하세요. 그러면 구독을 바꿔도 접속 정책이 유지됩니다. 특정 대상 유형을 특정 서버로 고정해야 할 때만 라우팅 규칙을 안정적인 아웃바운드 태그와 연결하세요.

모바일과 데스크톱 간 동기화의 선택

여러 기기의 서버 목록을 완전히 같게 만들 필요는 없습니다. 데스크톱은 여러 아웃바운드, 복잡한 라우팅과 TUN 가로채기가 필요할 수 있지만, 모바일은 출처와 앱별 규칙을 간소화하는 편이 적합합니다. 구독 출처 이름과 핵심 필터 원칙은 동기화할 수 있지만 시스템 관련 설정은 기기별로 저장하세요. 특히 로컬 수신 포트, 프로세스 규칙과 데스크톱 DNS 주소가 포함된 전체 설정을 모바일에 그대로 복사하지 마세요.

이전 출처를 정리하는 순서

출처를 중지할 때는 먼저 자동 업데이트를 취소하고, 검증된 다른 서버로 전환한 다음 해당 출처에서 서버를 제거하고 마지막으로 구독 기록을 삭제하세요. 현재 활성 출처를 바로 삭제하면 클라이언트에 이전 연결 상태가 계속 표시되지만 다음 시작 때 복구되지 않을 수 있습니다. 정리 후 활성 서버, 기본 아웃바운드와 라우팅 태그를 다시 확인하고 삭제한 객체를 참조하는 규칙이 남아 있지 않은지 점검하세요.

다중 구독 관리가 안정되면 각 출처에 명확한 용도와 업데이트 방식이 있어야 합니다. 어느 한 출처에 장애가 생겨도 다른 출처가 중단되지 않아야 하며, 라우팅과 DNS가 임시 서버 메모에 의존해서는 안 됩니다. 데스크톱과 모바일은 필요한 데이터만 공유해야 합니다. 이러한 구조가 단순히 하나의 매우 긴 구독으로 합치는 것보다 유지 관리가 쉽고, 이후 사용자 지정 아웃바운드를 추가하기에도 적합합니다.

CHAPTER 04 / ROUTING

라우팅 규칙 실전: 매칭 조건·순서와 아웃바운드

라우팅은 코어에 들어온 연결을 대상 도메인, 대상 IP, 포트, 네트워크 유형, 프로세스 또는 인바운드 태그에 따라 지정된 아웃바운드로 보내는 기능입니다. 애플리케이션 트래픽이 자동으로 클라이언트에 들어오게 하거나 서버 연결 매개변수를 수정해 주지는 않습니다. 시스템 프록시 또는 TUN이 진입점을 담당하고, 라우팅은 진입 이후의 방향을 선택합니다. 이 경계를 이해하면 ‘애플리케이션이 클라이언트를 거치지 않았다’는 문제를 ‘분기 규칙이 매칭되지 않았다’고 잘못 판단하는 일을 피할 수 있습니다.

세 가지 아웃바운드부터 시작하기

일반적인 기본 구조에는 프록시 아웃바운드, 직접 연결 아웃바운드와 차단 아웃바운드가 포함됩니다. 프록시 아웃바운드는 현재 선택한 서버 또는 사용자 지정 프록시 체인을 가리키고, 직접 연결 아웃바운드는 로컬 네트워크로 대상에 직접 접속하며, 차단 아웃바운드는 명확히 필요하지 않은 연결을 거부합니다. 각 아웃바운드에는 proxy, direct, block처럼 안정적이고 의미가 분명한 태그를 지정하세요. 라우팅 규칙은 태그로 아웃바운드를 참조하므로 태그를 변경하면 모든 참조도 함께 수정해야 합니다.

규칙 순서는 보통 구체적인 조건에서 일반적인 조건으로 배치합니다. 명확한 차단, 내부망 직접 연결, 특정 도메인 또는 프로세스 규칙을 먼저 두고, 그다음 큰 도메인·IP 집합을 배치하며, 마지막에는 기본 아웃바운드가 매칭되지 않은 트래픽을 처리하게 합니다. 범위가 넓은 규칙을 앞에 두면 뒤의 정확한 규칙은 실행될 기회를 잃습니다. 예를 들어 모든 TCP 트래픽을 먼저 프록시로 보내고 특정 도메인 직접 연결 규칙을 뒤에 작성하면 직접 연결 규칙이 작동하지 않을 수 있습니다.

{
  "routing": {
    "domainStrategy": "IPIfNonMatch",
    "rules": [
      {
        "type": "field",
        "ip": ["geoip:private"],
        "outboundTag": "direct"
      },
      {
        "type": "field",
        "domain": ["domain:example.cn", "geosite:cn"],
        "outboundTag": "direct"
      },
      {
        "type": "field",
        "domain": ["domain:example.net"],
        "outboundTag": "proxy"
      }
    ]
  }
}

위 예시는 사설 주소를 먼저 직접 연결한 뒤 특정 도메인과 도메인 집합을 처리합니다. domain:은 해당 도메인과 하위 도메인을 매칭하고, full:은 완전한 호스트 이름만 매칭할 때 적합하며, keyword:는 지정한 문자열이 포함된 도메인을 매칭하므로 범위가 가장 넓고 오매칭 위험도 높습니다. 규칙의 의미는 코어 설정 형식에 따라 달라질 수 있습니다. 일상적인 관리에는 클라이언트 인터페이스가 생성한 방식을 사용하는 편이 좋으며, JSON을 직접 편집할 때는 해당 필드가 현재 코어가 지원하는 설정 구조에 속하는지 확인하세요.

도메인과 IP 매칭은 어떻게 연결되는가

라우팅이 도메인을 직접 받는 경우 도메인 규칙으로 바로 판단할 수 있습니다. 반대로 규칙이 IP 집합을 기준으로 매칭해야 한다면 코어가 먼저 도메인을 해석해야 할 수 있습니다. domainStrategy는 이 작업을 수행하는 시점을 결정합니다. 도메인 규칙만 사용할 때는 불필요한 추가 해석을 피할 수 있고, ‘도메인 규칙이 매칭되지 않은 뒤 IP로 다시 판단’해야 할 때는 그에 맞는 필요 시 해석 전략을 사용할 수 있습니다. 모든 도메인을 무조건 먼저 해석하면 DNS 요청이 늘고, 라우팅이 사용하는 해석 결과가 애플리케이션의 예상과 달라질 수도 있습니다.

GeoSite은 도메인 집합이고 GeoIP는 IP 주소 집합입니다. 둘 다 로컬 데이터 파일에 의존하므로 규칙을 올바르게 작성해도 데이터가 오래되면 새 도메인이 누락되거나 주소 분류가 바뀔 수 있습니다. 업데이트 후에는 코어를 재시작해 실행 설정이 데이터를 다시 불러오게 하세요. 구체적인 업데이트 방법과 잘못된 분기 문제는 GeoIP 및 GeoSite 데이터베이스 업데이트 가이드를 참고하세요.

내부망·로컬 네트워크와 사설 주소

가정용 라우터, 프린터, 파일 공유와 로컬 개발 서비스는 보통 사설 주소를 사용하므로 우선 직접 연결해야 합니다. 그렇지 않으면 로컬 기기 접속이 원격 아웃바운드로 전송되어 실패할 수 있습니다. 사설 IP 집합 외에도 localhost, .local 이름과 기업 내부 도메인을 확인하세요. 내부 도메인은 로컬 네트워크 DNS로만 해석되는 경우가 많으므로 DNS 분기에서 로컬 해석 서버를 지정하고 라우팅에서는 직접 연결로 설정해야 합니다.

TUN 모드에서는 클라이언트가 더 넓은 범위를 가로채므로 내부망 직접 연결 규칙이 특히 중요합니다. TUN을 켠 뒤 라우터 관리 페이지에 접속할 수 없다면 먼저 사설 주소가 프록시를 우회하는지, 가상 네트워크 어댑터의 라우팅이 로컬 네트워크 대역을 덮어쓰는지 확인한 다음 시스템 방화벽을 점검하세요. 로컬 주소 하나를 복구하려고 전체 라우팅 규칙을 끄지 말고, 직접 연결 대상을 정확히 추가하는 편이 검증하기 쉽습니다.

규칙이 적용되지 않을 때 단계별 점검

먼저 요청이 실제로 코어에 들어갔는지 확인하고, 로그에서 대상이 도메인인지 IP인지 관찰하세요. IP만 보인다면 순수 도메인 규칙이 매칭되지 않을 수 있습니다. 대상 도메인이 앞의 범위 넓은 규칙에 이미 매칭되었다면 순서를 조정하세요. GeoSite 또는 GeoIP를 참조한다면 데이터 파일이 로드되었는지 확인하세요. 규칙이 사용자 지정 아웃바운드를 가리킨다면 태그가 완전히 일치하는지 점검하세요. 클라이언트에 ‘로컬 네트워크 우회’, ‘전역’, ‘규칙’ 같은 모드가 있다면 현재 모드가 사용자 지정 방식을 덮어쓰지 않는지도 확인해야 합니다.

검증할 때는 하나의 대상을 골라 직접 연결, 프록시와 차단이라는 세 가지 관찰 가능한 결과를 각각 테스트하세요. 여러 사이트를 동시에 기준으로 삼지 마세요. 웹페이지는 주 리소스, 이미지와 API를 서로 다른 도메인에서 불러올 수 있어 하나의 요청이 여러 경로를 거친 것처럼 보일 수 있습니다. 브라우저 캐시와 지속 연결도 결과에 영향을 주므로 규칙을 변경한 뒤 코어를 재시작하고 새 연결을 만들어야 합니다. 라우팅의 안정성은 특정 새로고침이 우연히 성공하는 것이 아니라 규칙 의도, 매칭 순서와 아웃바운드 태그를 하나씩 설명할 수 있는지로 판단합니다.

CHAPTER 05 / DNS

DNS 설정 최적화: 조회 경로·분기와 누수 점검

DNS는 도메인을 주소로 변환하는 방식을 결정하고, 라우팅이 도메인 또는 IP를 올바르게 매칭할 수 있는지에도 영향을 줍니다. 고급 설정에서 가장 흔한 혼란은 시스템 DNS, 애플리케이션 내장 DNS, 클라이언트 DNS와 원격 아웃바운드 해석이 동시에 존재하면서 어느 계층이 어떤 도메인을 담당하는지 정하지 않는 것입니다. 최적화의 목표는 서버를 많이 추가하는 것이 아니라 설명 가능한 조회 경로를 만드는 데 있습니다. 요청이 어디에서 들어오고, 어느 서버가 해석하며, 조회 자체가 어느 아웃바운드로 나가고, 결과가 어떤 라우팅에 전달되는지 명확해야 합니다.

시스템 조회와 코어 조회 구분하기

일반 시스템 프록시 모드에서는 일부 애플리케이션이 먼저 시스템에서 도메인을 해석한 뒤 IP를 프록시에 전달할 수 있고, 프록시 프로토콜을 지원하는 애플리케이션은 도메인을 클라이언트에 전달할 수 있습니다. TUN 모드는 더 많은 DNS 트래픽을 가로챌 수 있지만, 애플리케이션이 암호화 DNS나 자체 해석기를 사용하는 경우도 있습니다. 로그에 대상 IP만 나타난다면 도메인 정보가 코어에 들어오기 전에 이미 사라졌을 가능성이 있으며, 이 경우 도메인 기반 분기의 효과가 제한됩니다.

코어 DNS 서버는 일반 IP 주소를 사용할 수도 있고 암호화 전송을 지원하는 서비스 주소를 사용할 수도 있습니다. 구체적인 기능은 코어와 클라이언트의 설정 생성 방식에 따라 달라집니다. 선택할 때는 접근 가능성과 아웃바운드 경로를 함께 고려하세요. 해석 서버 자체는 프록시로 접근해야 하는데 라우팅은 그 해석 결과에 의존한다면 순환 의존성이 생길 수 있습니다. 기본 해석 진입점은 현재 네트워크에서 확실히 접근 가능해야 하며, 특정 도메인에 대해서만 다른 서버를 지정하세요.

{
  "dns": {
    "queryStrategy": "UseIP",
    "servers": [
      {
        "address": "223.5.5.5",
        "domains": ["geosite:cn"],
        "expectIPs": ["geoip:cn"]
      },
      {
        "address": "https://1.1.1.1/dns-query",
        "domains": ["geosite:geolocation-!cn"]
      },
      "localhost"
    ]
  }
}

이 예시는 도메인별로 해석 서버를 선택하는 방식을 보여줄 뿐 모든 네트워크에서 그대로 사용하라는 뜻은 아닙니다. domains는 해당 서버가 담당할 도메인 집합을 제한하고, expectIPs는 반환 주소가 예상 범위에 맞는지 확인하는 데 사용할 수 있으며, queryStrategy는 조회할 주소 유형의 우선 경향을 결정합니다. 현재 네트워크에서 특정 해석 진입점에 접근할 수 없다면 시간 초과 재시도를 계속 늘리지 말고 접근 가능한 서비스로 교체하세요.

DNS 분기와 라우팅 분기를 일치시키기

도메인을 직접 연결할 예정이라면 일반적으로 로컬 네트워크에 적합한 해석 경로를 사용해야 합니다. 도메인을 프록시 아웃바운드로 보낼 예정이라면 조회도 같은 아웃바운드를 통과하게 해 해석 위치와 접속 위치의 차이를 줄일 수 있습니다. 두 규칙을 하나씩 완전히 반복할 필요는 없지만 큰 방향은 일치해야 합니다. 라우팅은 특정 도메인을 직접 연결하는데 DNS 조회는 원격 아웃바운드로 강제하면 연결 자체는 작동할 수 있어도 지연과 문제 해결 난도가 커집니다.

내부 도메인은 분기를 명확히 해야 하는 대표적인 상황입니다. 기업 또는 가정용 로컬 네트워크의 내부 이름은 보통 로컬 DNS만 응답할 수 있으므로 해당 도메인 접미사에 로컬 해석 서버를 지정하고 라우팅에서는 관련 주소를 직접 연결해야 합니다. 공용 DNS가 존재하지 않는다고 응답하면 클라이언트가 내부 서버에 다시 질의해야 한다는 사실을 자동으로 알 수 없습니다. 반대로 공용 도메인을 모두 로컬 네트워크에서만 유효한 서버에 맡기면 현재 네트워크를 벗어났을 때 전체가 작동하지 않습니다.

캐시·TTL과 전환 후 이전 연결

DNS 결과는 애플리케이션, 시스템, 클라이언트와 코어에 각각 캐시될 수 있습니다. 해석 설정을 바꾼 직후 페이지를 새로 고쳐도 새 조회가 발생한다는 보장은 없습니다. 이미 연결된 세션도 DNS 변경만으로 자동 이전되지 않습니다. 검증할 때는 기존 연결을 닫고 코어를 재시작하며, 필요하면 시스템 DNS 캐시를 삭제하세요. ‘실시간’ 반영을 위해 캐시 시간을 지나치게 짧게 설정하지 마세요. 조회 수만 늘고 서버 자체가 잘못된 결과를 반환하는 문제는 해결하지 못합니다.

주소가 자주 바뀌는 서비스는 합리적인 TTL을 따르고 실패 시 재시도하도록 구성하세요. 고정된 내부 서비스는 적절한 캐시를 유지해도 됩니다. 같은 도메인이 네트워크마다 다른 주소를 반환한다면 네트워크를 전환한 뒤 이전 캐시에 특히 주의하세요. 모바일에서 Wi-Fi와 셀룰러 네트워크를 전환할 때는 모든 캐시가 자연스럽게 만료되기를 기다리기보다 연결을 다시 시작하는 편이 예측하기 쉽습니다.

DNS 누수 판단과 해결

DNS 누수의 핵심은 지정한 경로를 거쳐야 하는 조회가 시스템 또는 다른 애플리케이션에 의해 계획하지 않은 해석 서버로 전송되는 것입니다. 판단할 때는 웹페이지에 표시된 DNS 주소 몇 개만 보지 말고 현재 네트워크, 프록시 모드와 예상 경로를 함께 확인해야 합니다. 시스템 프록시 모드가 모든 애플리케이션의 DNS를 자동으로 가로채는 것은 아닙니다. TUN 모드는 더 넓은 범위를 처리하지만 DNS 트래픽을 올바르게 가로채야 합니다. 브라우저에서 독립적인 암호화 DNS를 사용하면 시스템과 클라이언트 설정을 우회할 수도 있습니다.

해결 순서는 먼저 예상 경로를 정한 다음 우회 경로를 줄이는 것입니다. 애플리케이션 자체의 해석기를 끄거나 조정하고, 시스템 DNS 요청이 클라이언트로 들어오게 하며, 코어 DNS에 명확한 아웃바운드를 지정하세요. 라우팅이 조회를 잘못된 방향으로 보내지 않는지도 확인한 뒤 다시 테스트합니다. 특정 애플리케이션에서만 발생한다면 전체 시스템을 변경하기보다 해당 애플리케이션 설정을 우선 점검하세요. 전체 절차는 DNS 누수 검사 및 해결 실전 가이드에서 확인할 수 있습니다.

DNS 설정이 완료되었다는 기준은 각 도메인 유형을 누가 해석하는지, 조회가 어느 아웃바운드로 나가는지, 결과가 라우팅에 어떻게 참여하는지 설명할 수 있고 로그에서 그 과정을 확인할 수 있는 것입니다. 서버 수가 많다고 더 좋은 것은 아닙니다. 짧고 명확한 조회 체인이 무작위 예비 주소 여러 개보다 안정적인 경우가 많습니다.

CHAPTER 06 / TUN

TUN 모드: 시스템 트래픽 가로채기와 경계 제어

TUN 모드는 가상 네트워크 인터페이스를 통해 시스템 트래픽을 수신하므로 시스템 프록시를 따르지 않거나 프록시를 개별 설정할 수 없거나 UDP 요청을 포함한 프로그램에 적합합니다. TUN이 해결하는 것은 트래픽 진입점의 범위이며, 올바른 서버를 자동으로 선택하거나 라우팅과 DNS를 대신하지는 않습니다. 활성화하면 클라이언트가 가상 네트워크 어댑터, 시스템 라우팅과 DNS 가로채기를 설정하므로 장애 범위가 단일 애플리케이션에서 전체 시스템 네트워크로 넓어집니다. 일반 프록시 모드가 안정적으로 작동한 뒤 활성화해야 합니다.

활성화 전 점검

먼저 v2rayN 또는 Android 클라이언트가 일반 모드에서 현재 서버를 사용할 수 있는지 확인하고 기존 설정을 저장하세요. 데스크톱에서는 가상 네트워크 어댑터를 만들고 라우팅을 조정하는 데 필요한 시스템 권한이 있어야 합니다. 보안 프로그램이나 기업 정책이 이러한 작업을 제한할 수도 있습니다. 로컬 네트워크 대역, 사용 중인 VPN 계열 프로그램, 가상 머신 네트워크와 컨테이너 네트워크도 기록하세요. 여러 가상 인터페이스가 기본 라우팅을 두고 경쟁할 수 있기 때문입니다.

TUN을 시작하기 전에 시스템 라우팅을 변경하는 다른 연결 도구를 종료해 동시에 가로채지 않도록 하세요. 함께 사용해야 한다면 각 인터페이스의 라우팅 우선순위와 대상 네트워크를 명확히 정하고 시작 순서에 의존하지 마세요. 클라이언트가 비정상 종료된 뒤 네트워크가 끊기면 먼저 관련 프로세스를 종료하고 시스템 네트워크를 복구한 다음 남은 가상 인터페이스와 DNS를 확인하세요. 브라우저를 반복해서 재시작하는 것만으로 해결하려 하지 마세요.

스택 모드와 MTU

클라이언트와 코어에 따라 system, gVisor 또는 mixed 같은 네트워크 스택 옵션이 제공될 수 있습니다. 시스템 스택은 운영체제의 네트워크 동작에 가까우며 호환성과 성능은 플랫폼 구현의 영향을 받습니다. 사용자 공간 스택은 클라이언트 내부에서 패킷을 처리하기 쉬워 특정 환경에서 더 안정적일 수 있지만 일부 프로토콜이나 애플리케이션과 차이가 생길 수도 있습니다. 명확한 장애가 없다면 클라이언트 권장값을 사용하세요. UDP, 로컬 네트워크 또는 특정 애플리케이션에 문제가 생길 때만 바꿔 비교하는 것이 좋습니다.

MTU는 개별 패킷의 최대 크기를 결정합니다. 너무 크게 설정하면 복잡한 네트워크 경로에서 단편화나 패킷 손실이 발생해 웹페이지는 열리지만 업로드, 동영상 또는 일부 API가 멈출 수 있습니다. 너무 작으면 불필요한 오버헤드가 늘어납니다. 연결이 느리다는 이유만으로 MTU를 임의로 낮추지 마세요. 문제가 TUN에서만 발생하는지 먼저 확인한 뒤 단계적으로 조정하고, 각 변경 후 새 연결을 만들어 비교하세요. 기본값으로 되돌린 결과도 대조군으로 삼아야 합니다.

로컬 네트워크 및 예약 주소 우회

TUN이 트래픽을 가로챈 뒤에는 사설 주소, 루프백 주소와 현재 로컬 네트워크에서 직접 연결해야 하는 대역을 명확히 우회해야 합니다. 프린터, 네트워크 저장 장치, 라우터 관리 페이지와 로컬 개발 서비스가 이에 의존합니다. ‘로컬 네트워크 우회’ 스위치만으로 부족하다면 실제 주소 범위를 확인하고 정확한 IP 또는 네트워크 대역 규칙을 추가하세요. 기업 네트워크에는 비표준 내부 주소가 있을 수 있으므로 실제 라우팅 테이블에 따라 처리해야 합니다.

로컬 기기를 호스트 이름으로 접속한다면 내부 DNS도 함께 설정해야 합니다. 대상 IP만 직접 연결하고 도메인은 공용 해석 서버에 맡기면 존재하지 않거나 잘못된 주소를 받을 수 있습니다. 로컬 네트워크 문제는 ‘이름을 해석할 수 있는가’와 ‘주소에 직접 연결할 수 있는가’로 나누어 확인하세요. 먼저 IP로 연결을 테스트하고 그다음 도메인을 테스트하면 문제가 DNS인지 라우팅인지 판단할 수 있습니다.

앱별 제어와 UDP

모바일에서는 앱별 프록시로 어떤 프로그램을 연결에 포함할지 제어하는 경우가 많습니다. 포함 모드는 소수의 앱만 연결에 넣을 때 적합하고, 제외 모드는 대부분의 앱을 연결에 포함하되 로컬 서비스를 직접 연결할 때 적합합니다. 애플리케이션을 업데이트하거나 패키지 이름을 바꾸면 기존 선택이 무효화될 수 있으므로 목록을 정기적으로 확인하세요. 데스크톱의 프로세스 라우팅은 코어와 권한에 의존하며 같은 프로세스 이름도 경로가 다를 수 있으므로 실제 로그에서 규칙을 검증해야 합니다.

UDP 트래픽에는 일부 DNS, 실시간 통신과 새로운 전송 프로토콜이 포함됩니다. 서버와 프로토콜 체인이 해당 UDP 동작을 지원하지 않으면 TUN이 패킷을 수신해도 대상에 도달한다고 보장할 수 없습니다. 문제를 해결할 때는 모든 UDP가 실패하는지, 특정 애플리케이션 또는 대상만 실패하는지 먼저 판단하세요. 그다음 아웃바운드 기능, 라우팅과 MTU를 확인합니다. UDP 장애를 가상 네트워크 어댑터의 문제로 단정하지 마세요.

종료 후 네트워크 복구

클라이언트를 정상 종료하면 자동 라우팅과 DNS도 함께 복구되어야 합니다. 비정상 종료 후에도 네트워크를 사용할 수 없다면 먼저 TUN 인터페이스가 남아 있는지 확인한 다음 기본 라우팅과 시스템 DNS에 임시 값이 남아 있는지 점검하세요. 클라이언트를 다시 연 뒤 정상 시작과 정상 중지를 한 번 수행하면 정리 절차가 실행되는 경우가 있습니다. 그래도 복구되지 않으면 시스템 네트워크 재설정 기능을 사용한 뒤 현재 네트워크에 다시 연결하세요.

TUN의 안정성 기준은 ‘모든 트래픽을 가로채는가’가 아니라 예상한 범위만 가로채고, 로컬 네트워크 경계가 분명하며, DNS가 우회되지 않고, 종료 후 시스템이 복구되는가입니다. 브라우저와 시스템 프록시를 지원하는 애플리케이션만 사용하는 환경이라면 일반 프록시 모드가 더 간단합니다. 진입점 범위를 넓혀야 할 때만 TUN을 사용하세요.

CHAPTER 07 / FAKEDNS

FakeDNS: 가상 IP 매핑·적용 조건과 호환성

FakeDNS는 애플리케이션에 도메인의 실제 주소를 직접 반환하지 않고 예약된 주소 풀에서 가상 IP를 할당한 뒤 내부에 ‘가상 IP—원래 도메인’ 매핑을 저장합니다. 애플리케이션이 이 가상 주소로 연결하면 코어가 매핑을 통해 도메인을 복원하고 도메인 라우팅과 실제 해석을 수행합니다. 주요 목적은 TUN 환경에서 도메인 정보를 유지하는 것입니다. 애플리케이션이 실제 IP를 먼저 받아 코어가 주소만 기준으로 판단하게 되는 상황을 피할 수 있습니다.

매핑 과정은 어떻게 작동하는가

애플리케이션이 DNS를 조회하면 요청이 TUN 또는 DNS 하이재킹 규칙을 통해 코어로 전달됩니다. FakeDNS는 도메인에 가상 주소를 할당해 반환하고, 애플리케이션은 이 주소를 대상으로 연결을 만듭니다. 코어는 해당 주소가 FakeDNS 풀에 속하는지 확인하고 매핑 테이블에서 도메인을 가져온 뒤 도메인 규칙에 따라 아웃바운드를 선택합니다. 필요하면 대상 아웃바운드를 통해 실제 주소를 다시 해석합니다. 이 전체 과정이 작동하려면 DNS 요청과 이후 연결이 같은 매핑 인식 코어 인스턴스를 통과해야 합니다.

DNS 요청은 FakeDNS로 들어갔지만 애플리케이션 연결이 TUN을 우회하면 시스템은 공용 인터넷에 존재하지 않는 가상 주소로 접속을 시도하게 됩니다. 반대로 연결은 TUN으로 들어오지만 DNS를 애플리케이션 자체 해석기가 처리하면 코어에는 실제 IP만 보일 수 있어 FakeDNS가 참여하지 못합니다. 활성화하기 전에 DNS 가로채기와 트래픽 가로채기가 완전한 순환 구조를 이루는지 확인해야 합니다.

{
  "dns": {
    "servers": [
      {
        "address": "fakedns",
        "domains": ["geosite:geolocation-!cn"]
      },
      "223.5.5.5"
    ],
    "fakedns": [
      {
        "ipPool": "198.18.0.0/15",
        "poolSize": 65535
      }
    ]
  }
}

이 예시는 테스트 목적의 예약 주소 대역을 가상 풀로 사용하는 방법을 보여주며, 지정한 도메인 집합에만 FakeDNS를 적용합니다. 실제 필드와 배치 위치는 코어 설정 형식과 클라이언트의 생성 방식에 따라 다르므로 클라이언트가 제공하는 스위치와 템플릿을 우선 사용하세요. 주소 풀은 로컬 네트워크, 기업 네트워크, 다른 가상 인터페이스 또는 기존 라우팅과 겹치면 안 됩니다. 풀은 클수록 좋은 것이 아니며 정상 사용 중 발생하는 활성 매핑을 감당할 정도면 충분합니다.

활성화하기 적합한 환경

TUN이 안정적으로 작동하고 도메인 규칙이 많으며 애플리케이션이 로컬에서 도메인을 먼저 해석하는 경우 FakeDNS는 코어가 도메인 의미를 유지하도록 도울 수 있습니다. 실제 해석에 앞서 도메인으로 라우팅을 선택해야 하는 환경에도 적합합니다. 라우팅이 먼저 도메인을 기준으로 아웃바운드를 선택하고 대상 경로에서 실제 해석을 수행하게 하면 로컬 해석 결과가 너무 일찍 대상 주소를 결정하는 일을 피할 수 있습니다.

주로 원격 해석을 지원하는 시스템 프록시를 사용하고 로그에 이미 전체 도메인이 표시된다면 FakeDNS의 이점은 제한적입니다. 단순한 네트워크에서 매개변수가 많다는 이유만으로 활성화할 필요는 없습니다. FakeDNS는 도메인 정보 손실을 해결하는 도구이지 범용 가속 스위치가 아니며, 서버 자체의 연결 품질도 개선하지 않습니다.

바로 활성화하기에 적합하지 않은 환경

실제 IP 표시, 주소 허용 목록, 로컬 네트워크 검색 또는 DNS 결과의 직접 비교에 의존하는 애플리케이션은 가상 주소를 허용하지 않을 수 있습니다. 일부 보안 프로그램은 예약 주소 대역 연결을 비정상으로 판단할 수 있고, 일부 게임·기기 제어 프로그램·기업용 클라이언트는 시스템 DNS를 우회해 매핑 체인을 불완전하게 만들 수 있습니다. 내부 도메인은 일반적으로 계속 로컬 네트워크 DNS에 맡기고 실제 주소로 직접 연결해야 하며 FakeDNS에 넣지 않는 것이 좋습니다.

IP 규칙으로 정밀하게 제어해야 하는 대상도 주의해야 합니다. 도메인을 복원하기 전에 라우팅이 가상 IP를 일반 주소로 처리하면 잘못된 규칙에 매칭될 수 있습니다. 설정에서는 FakeDNS 주소 인식이 올바른 단계에서 이루어지는지 확인하고, 가상 주소 풀에 일반적인 직접 연결 규칙을 작성하지 마세요. 작동 원리, 적용 범위와 애플리케이션 호환성은 FakeDNS 작동 원리 자세히 알아보기에서 확인할 수 있습니다.

캐시 및 매핑 무효화

애플리케이션이 가상 IP를 캐시할 수 있지만 코어가 재시작되면 매핑 테이블은 이미 비워집니다. 이때 애플리케이션이 이전 가상 주소로 계속 연결하면 코어가 원래 도메인을 복원하지 못해 클라이언트 재시작 직후 일부 사이트가 실패할 수 있습니다. 기존 연결을 닫고 애플리케이션 DNS 캐시를 삭제하거나 애플리케이션을 재시작하면 대개 복구됩니다. 코어를 자주 재시작하면 이런 현상이 늘어날 수 있으므로 디버깅할 때는 변경할 때마다 전체 조회를 새로 수행하세요.

주소 풀이 소진되거나 매핑 수가 비정상적으로 증가하면 프로그램이 무작위 하위 도메인 조회를 계속 생성하는지 확인하세요. 풀을 무작정 늘리는 것은 문제를 늦출 뿐입니다. 먼저 요청 출처를 확인하고 필요하면 해당 유형의 도메인에서 FakeDNS를 우회하거나 애플리케이션 가로채기 범위를 제한하세요. 활성화 후에는 일반 도메인, 내부 도메인, IP로만 접속하는 대상과 재시작 후 캐시 복구를 각각 검증해야 합니다. 이 네 가지 동작을 모두 설명할 수 있어야 FakeDNS가 안정적으로 연결된 것입니다.

CHAPTER 08 / OUTBOUNDS

사용자 지정 아웃바운드·프록시 체인과 종합 문제 해결 절차

사용자 지정 아웃바운드는 서로 다른 대상을 서로 다른 연결 경로로 보내거나 직접 연결, 프록시와 차단 외에 DNS 전용, 프런트 프록시와 특정 서버 아웃바운드를 추가할 때 사용합니다. 이는 앞서 설정한 구독, 라우팅과 DNS가 만나는 지점입니다. 서버 매개변수는 아웃바운드의 연결 가능 여부를 결정하고, 라우팅 태그는 어떤 요청이 들어갈지 결정하며, DNS 경로는 대상의 해석 방식을 결정합니다. 사용자 지정 아웃바운드가 많아질수록 태그와 의존 관계를 명확히 기록해야 합니다.

태그는 설정 사이의 인터페이스

각 아웃바운드에는 고유하고 안정적이며 용도만 표현하는 태그를 사용하세요. 서버 주소, 지역과 날짜를 태그에 모두 넣지 마세요. 구독 업데이트 후 이런 정보가 쉽게 바뀔 수 있습니다. proxy-main, proxy-backup, direct, block, dns-out 같은 이름을 사용할 수 있습니다. 라우팅 규칙, DNS 서버와 프록시 체인은 태그로만 참조하고 표시 이름은 더 자세하게 작성해도 됩니다.

아웃바운드를 삭제하거나 이름을 바꾸기 전에 모든 참조 위치를 검색하세요. 설정을 파싱할 수 있다고 해서 참조가 유효하다는 뜻은 아닙니다. 일부 오류는 해당 규칙이 처음 매칭될 때만 나타납니다. 가장 안전한 방법은 먼저 새 아웃바운드를 추가해 개별 테스트하고, 정확한 도메인 규칙 하나를 새 아웃바운드로 전환한 뒤 성공을 확인하면서 범위를 단계적으로 넓히고 마지막에 이전 아웃바운드를 삭제하는 것입니다.

{
  "outbounds": [
    {
      "tag": "direct",
      "protocol": "freedom",
      "settings": {}
    },
    {
      "tag": "block",
      "protocol": "blackhole",
      "settings": {}
    },
    {
      "tag": "dns-out",
      "protocol": "dns",
      "settings": {
        "address": "1.1.1.1",
        "port": 53,
        "network": "tcp"
      }
    }
  ]
}

이 예시는 직접 연결, 차단과 DNS 아웃바운드의 기본적인 태그 관계를 보여줍니다. 프록시 서버 아웃바운드는 보통 구독과 클라이언트가 생성하므로 인증 매개변수를 여러 로컬 설정에 반복해서 붙여 넣지 않는 것이 좋습니다. 클라이언트가 현재 서버를 기본 프록시 아웃바운드로 사용할 수 있다면 이 동적 참조를 유지하세요. 서버를 바꿀 때 라우팅을 다시 작성하지 않아도 됩니다. 특정 회선을 고정해야 할 때만 독립 아웃바운드를 만드세요.

프록시 체인의 방향과 의존 관계

프록시 체인은 하나의 아웃바운드가 다른 아웃바운드를 통해 연결을 수립하는 구조입니다. 예를 들어 대상 트래픽이 먼저 업무용 아웃바운드로 들어간 뒤, 해당 아웃바운드가 프런트 아웃바운드를 전송 경로로 지정할 수 있습니다. 설정할 때는 ‘누가 누구를 통해 연결하는가’를 구분해 방향을 반대로 작성하지 마세요. 체인의 각 계층은 연결 수립 단계와 문제 해결 범위를 늘리므로 프런트 경로가 명확히 필요할 때만 사용하세요.

프록시 체인에서 가장 흔한 장애는 순환 의존성입니다. 아웃바운드 A가 B를 통하고 B가 다시 A를 통하는 경우, 또는 A의 서버 주소를 해석하려면 A 자체를 거쳐야 하는 경우가 이에 해당합니다. 체인은 직접 연결을 수립할 수 있는 출구에서 끝나야 하며, 직접 해석하거나 고정적으로 접근 가능한 서버 주소를 사용하는 편이 좋습니다. 검증할 때는 가장 바깥의 기본 아웃바운드를 먼저 테스트하고 한 계층씩 추가하세요. 체인 전체를 한 번에 활성화하지 마세요.

인바운드·포트·프로세스별 아웃바운드 선택

도메인과 IP 외에도 인바운드 태그, 대상 포트, 네트워크 유형 또는 프로세스를 기준으로 분기할 수 있습니다. 인바운드 태그는 서로 다른 로컬 수신 포트를 서로 다른 아웃바운드에 연결할 때 적합합니다. 예를 들어 한 포트는 주요 회선을 사용하고 다른 포트는 예비 회선을 테스트할 수 있습니다. 포트 규칙은 명확한 프로토콜 서비스에 유용하지만 최신 애플리케이션은 하나의 포트에서 여러 업무를 처리하는 경우가 많으므로 포트만으로 내용을 판단해서는 안 됩니다. 프로세스 규칙은 데스크톱에서 애플리케이션별로 제어하는 데 적합하지만 실제 지원 범위와 권한은 코어와 시스템에 따라 다릅니다.

규칙을 조합할 때는 범위가 겹치지 않도록 하세요. 특정 프로세스 규칙과 도메인 규칙이 동시에 존재한다면 순서가 결과를 결정합니다. 가장 명확한 인바운드 또는 프로세스 규칙을 먼저 작성하고, 그다음 대상 도메인 규칙을 배치한 뒤 마지막에 공통 집합을 두는 것이 좋습니다. 각 규칙 옆에 용도를 기록하면 복잡한 이름에만 의존하는 것보다 관리하기 쉽습니다. 클라이언트 인터페이스가 메모를 지원한다면 매칭 조건과 대상 아웃바운드를 적어 두세요.

반복 가능한 문제 해결 절차

첫 단계는 최소 설정으로 복구하는 것입니다. 검증된 서버 하나, 프록시 아웃바운드 하나와 직접 연결 아웃바운드 하나만 사용하고 복잡한 라우팅, TUN과 FakeDNS는 활성화하지 않습니다. 기본 연결을 확인한 뒤 두 번째 단계에서 DNS 설정을 불러와 도메인 해석을 검증합니다. 세 번째 단계에서는 정확한 라우팅 규칙 하나를 추가해 매칭을 관찰합니다. 네 번째 단계에서 TUN을 활성화해 시스템 트래픽과 로컬 네트워크를 확인하고, 다섯 번째 단계에서야 FakeDNS 또는 프록시 체인을 추가합니다. 각 단계의 로그와 결과를 남기세요.

문제가 구독 업데이트 후에만 발생한다면 먼저 활성 서버와 프로토콜 매개변수를 비교하고 라우팅부터 바꾸지 마세요. 특정 유형의 도메인만 실패한다면 DNS 분기와 GeoSite 데이터를 확인하세요. 시스템 프록시를 지원하지 않는 애플리케이션만 실패한다면 TUN 진입점을 점검하세요. FakeDNS를 켠 뒤 광범위한 장애가 발생하면 실제 DNS로 복구하고 매핑 순환 구조를 확인하세요. 사용자 지정 아웃바운드가 실패한다면 먼저 정확한 규칙으로 해당 아웃바운드를 테스트하고 전체 트래픽을 그쪽으로 전환하지 마세요.

로그에는 작업 시간, 변경 항목, 현재 모드와 첫 번째 오류를 기록해야 합니다. 반복되는 연결 종료 정보는 대량으로 저장할 필요가 없습니다. 두 설정을 비교할 때는 실제로 변경된 부분만 비교하세요. DNS, 라우팅과 아웃바운드를 동시에 조정하면 차이를 파악하기 어려워집니다. 용어나 인터페이스 의미가 불분명하면 먼저 설정 및 문제 해결 문서를 확인하고, 클라이언트를 다시 설치해야 한다면 다운로드 페이지에서 Windows, macOS, Android 또는 Linux 버전을 선택하세요.

장기 유지 관리를 위한 최소 점검 목록

정기 유지 관리를 위해 매일 설정을 처음부터 다시 만들 필요는 없습니다. 구독 계층에서는 출처가 여전히 유효한지와 필터가 잘못 제외하지 않는지 확인하세요. 라우팅 계층에서는 GeoIP·GeoSite 데이터와 태그 참조를 점검하고, DNS 계층에서는 해석 서버의 접근성과 애플리케이션 우회를 확인하세요. TUN 계층에서는 가상 인터페이스, 로컬 네트워크 우회와 종료 후 복구를 점검하고, FakeDNS 계층에서는 주소 풀 충돌과 애플리케이션 호환성을 확인하세요. 아웃바운드 계층에서는 체인이 여전히 필요한지도 살펴보세요. 코어를 바꿀 때는 설정 필드와 프로토콜 기능이 호환되는지도 확인해야 합니다. Xray와 V2Fly의 차이는 Xray 코어와 V2Fly 코어 차이 비교에서 확인할 수 있습니다.

유지 관리가 쉬운 고급 설정은 각 구성 요소의 역할을 짧은 문장으로 설명할 수 있어야 합니다. 구독은 서버를 제공하고, 그룹은 출처를 관리하며, 필터는 불필요한 항목을 줄이고, DNS는 주소를 제공하고, 라우팅은 방향을 선택하며, TUN은 진입 범위를 넓히고, FakeDNS는 도메인을 보존하며, 사용자 지정 아웃바운드는 대상 경로를 구성합니다. 용도를 설명할 수 없거나 단독으로 검증할 수 없거나 삭제해도 영향이 없는 규칙은 다시 검토해야 합니다. 설정이 이러한 명확한 구조에 가까울수록 클라이언트 업데이트, 서버 전환과 기기 이전 과정이 통제에서 벗어날 가능성도 줄어듭니다.