V2Ray 고급 설정
체계적인 설정 가이드

설정 계층과 수정 순서

고급 설정에서 가장 흔한 문제는 특정 매개변수가 틀린 것이 아니라 서로 다른 계층의 역할을 뒤섞는 데서 발생합니다. 예를 들어 서버 필터링은 클라이언트 목록에서 선택하기 쉬운 항목을 정할 뿐, 브라우저 트래픽이 프록시를 통과하는지 직접 결정하지 않습니다. 라우팅 규칙은 커널에 들어온 연결을 여러 아웃바운드로 배분하지만 시스템 프록시를 따르지 않는 앱의 트래픽까지 가로채지는 못합니다. TUN은 전환 범위를 넓힐 수 있지만 잘못된 DNS 서버나 사용할 수 없는 노드를 자동으로 수정하지 않습니다. 설정을 입력, 선택, 전환, 확인, 판정, 아웃바운드의 여섯 계층으로 나누면 문제 해결 경로를 크게 줄일 수 있습니다.

입력부터 아웃바운드까지의 전체 흐름

입력 계층에는 구독 주소, 단일 공유 링크 및 수동 설정이 포함됩니다. 클라이언트가 구독을 업데이트하면 원격 콘텐츠를 로컬 서버 항목으로 변환합니다. 선택 계층은 현재 활성 서버, 서버 그룹 및 필터 결과를 관리합니다. 전환 계층은 어떤 앱 트래픽을 커널로 보낼지 결정합니다. 시스템 프록시는 일반적으로 시스템 프록시 설정을 따르는 프로그램에 적용되고, TUN은 가상 네트워크 인터페이스를 통해 더 폭넓은 IP 트래픽을 수신합니다. 확인 계층은 도메인을 주소로 변환하고, 라우팅 계층은 도메인, 주소, 포트, 프로토콜 등의 조건으로 규칙을 매칭합니다. 마지막으로 프록시, 직접 연결, 차단 또는 사용자 지정 아웃바운드가 연결을 완료합니다.

이 흐름에는 분명한 선후 관계가 있습니다. 브라우저가 시스템 프록시에 연결되지 않았다면 라우팅 규칙을 바꿔도 결과는 달라지지 않습니다. 운영체제에서 DNS가 먼저 확인되었다면 도메인 규칙만으로는 예상한 매칭을 얻지 못할 수 있습니다. 라우팅이 프록시 아웃바운드에 도달했더라도 현재 서버를 사용할 수 없으면 연결은 실패합니다. 따라서 설정을 수정할 때마다 두 가지를 확인해야 합니다. 변경이 어느 계층에서 발생했는지, 그리고 적용 여부를 입증할 관찰 지점이 무엇인지입니다. 검증 지점과 변경 계층을 연결해야 여러 옵션을 동시에 바꾼 뒤 원인을 판단하지 못하는 상황을 피할 수 있습니다.

폴백 가능한 기준 설정 만들기

고급 설정을 조정하기 전에 정상적으로 연결되는 기준 설정을 하나 보존하세요. 기준 설정은 복잡할 필요가 없습니다. 검증된 서버 하나, 기본 라우팅, 명확한 DNS 설정, 현재 사용하는 시스템 프록시 또는 TUN 상태를 남겨 두면 됩니다. 이후에는 한 번에 하나의 주제만 변경하세요. 예를 들어 먼저 구독 그룹을 구성하고 서버 선택에 영향이 없는지 확인한 뒤 라우팅 설정으로 넘어갑니다. 클라이언트에 설정 백업이나 내보내기 기능이 있다면 중요한 단계마다 스냅샷을 저장하세요. 인터페이스 옵션, 규칙 순서 및 테스트 결과를 기록해 두는 것도 기억에만 의존하지 않고 복구하는 데 도움이 됩니다.

기준 설정을 검증할 때 웹페이지 하나만 테스트하지 마세요. 최소한 직접 연결이 예상되는 도메인 하나, 프록시가 예상되는 도메인 하나, 순수 IP 연결 상황 하나, DNS 조회 한 번을 포함해야 합니다. 테스트 결과는 ‘클라이언트에 들어오지 않음’, ‘들어온 뒤 라우팅 오류’, ‘DNS 반환 이상’, ‘선택한 서버 사용 불가’를 구분할 수 있어야 합니다. Windows에서는 작업 관리자, 시스템 프록시 설정 및 클라이언트 로그를 함께 확인할 수 있습니다. macOS와 Linux에서는 현재 라우팅, 프록시 설정 및 확인 상태를 살펴보세요. Android의 v2rayNG 또는 v2flyNG에서는 연결 로그, 가상 네트워크 권한 상태 및 대상 앱의 동작을 중심으로 확인합니다.

클라이언트의 메뉴 이름은 버전과 플랫폼에 따라 조금씩 다를 수 있지만 핵심 관계는 변하지 않습니다. v2rayN은 데스크톱 플랫폼에서 우선적으로 사용하는 관리 클라이언트로, 구독·라우팅·아웃바운드를 통합 관리하기에 적합합니다. Android에서는 v2rayNG가 Xray 커널 체계를 사용하고, v2flyNG는 V2Fly 커널을 중심으로 선택합니다. 플랫폼을 옮길 때는 메뉴 위치와 모든 필드가 완전히 같다고 가정하기보다 ‘설정 의도’를 옮겨야 합니다. 먼저 대상 플랫폼이 필요한 기능을 지원하는지 확인한 다음 계층별로 설정을 다시 구성하는 편이 거대한 설정을 그대로 복사하는 것보다 호환성 경계를 찾기 쉽습니다.

구독 그룹 및 서버 필터링

구독 항목이 늘어난 뒤 실제 사용 효율을 좌우하는 것은 목록의 길이 자체가 아니라 현재 작업에 맞는 서버를 안정적으로 찾을 수 있는지입니다. 그룹은 서버의 장기적인 소속을 정하고, 필터는 특정 선택 시 후보 범위를 좁힙니다. 두 기능은 분리해서 설계해야 합니다. 그룹은 출처, 용도 또는 관리 경계를 표현하고 필터는 이름 매칭 조건을 표현합니다. 필터 결과를 영구 분류로 사용하면 구독 이름이 바뀐 뒤 작동하지 않을 수 있습니다. 반대로 모든 항목을 하나의 그룹에 넣으면 업데이트, 속도 측정 및 장애 분석이 서로 방해받습니다.

출처 기준인가, 용도 기준인가

출처별 그룹은 가장 관리하기 쉽습니다. 각 구독 주소에 하나의 그룹을 연결하면 업데이트 실패 시 출처를 바로 찾을 수 있고, 다른 항목에 영향을 주지 않고 특정 구독을 철회할 수도 있습니다. 용도별 그룹은 일관된 이름 규칙이 이미 있는 환경에 적합합니다. 예를 들어 일상 검색, 개발 테스트 및 임시 예비용을 나눌 수 있습니다. 실제 설정에서는 보통 두 단계로 구성합니다. 하위 계층에는 출처 경계를 유지하고, 상위 계층에서는 필터나 즐겨찾기로 용도별 화면을 만듭니다. 이렇게 하면 항목의 출처를 추적하면서 일상적인 선택 과정의 정보 잡음을 줄일 수 있습니다.

그룹 이름은 안정적이고 짧으며 알아보기 쉬워야 합니다. 업데이트 날짜나 임시 상태를 장기 이름에 넣지 마세요. 업데이트 날짜는 로그 정보이고, 회선 상태는 실제 연결 테스트로 판단해야 합니다. 여러 구독에 같은 서버 이름이 나타난다면 가져오기 단계에서 출처 접두사를 추가하거나 그룹이 출처를 구분하도록 하세요. 서버 이름에 태그를 너무 많이 쌓으면 정규식 필터가 잘못 매칭되기 쉽고, 이후 구독 제공자가 이름을 바꿨을 때 호환도 어려워집니다.

관리하기 쉬운 필터 표현식 만들기

서버 필터는 보통 메모 이름에 텍스트 또는 정규식 매칭을 적용합니다. 먼저 안정적인 키워드 하나만 매칭하는 최소 조건으로 시작한 뒤 동의어 표기를 단계적으로 추가하세요. 정방향 필터는 많은 항목에서 특정 지역, 용도 또는 회선 식별자를 고르는 데 적합하고, 역방향 필터는 테스트 항목, 만료 표시 또는 명확히 맞지 않는 아키텍처를 제외하는 데 적합합니다. 필터 표현식은 ‘몇 번째 문자’처럼 취약한 위치에 의존하지 말고 상대적으로 안정적인 완전한 단어와 구분자를 기준으로 작성해야 합니다.

자주 쓰는 필터 방식:

다음 키워드 중 하나 포함:
(업무|개발|예비)

이름 앞부분의 출처 표시 매칭:
^(출처A|출처B)[-_ ]

임시 또는 만료 표시가 있는 항목 제외:
^(?!.*(임시|만료)).*$

두 조건을 동시에 요구:
^(?=.*개발)(?=.*TCP).*$

정규식에서 괄호는 그룹을 만들고, 세로줄은 여러 후보를 뜻합니다. 점과 별표를 조합하면 임의 길이의 텍스트를 나타낼 수 있으며, 전방 탐색은 특정 조건의 요구 또는 제외에 사용할 수 있습니다. 표현식을 입력하기 전에 클라이언트의 해당 입력란에서 정규식 모드가 활성화되어 있는지 확인하세요. 일반 텍스트 검색이라면 특수 기호가 문자 그대로 처리됩니다. 필터링 후에는 목록의 앞뒤 항목과 경계 이름을 직접 확인해 동음이의어, 약어 또는 포함된 단어가 잘못 들어오지 않았는지 점검해야 합니다.

필터 결과를 연결 품질 판단의 대체 수단으로 사용하지 마세요. 이름은 구독 제공자가 붙인 태그일 뿐 실시간 사용 가능성을 증명하지 않으며 현재 네트워크 경로를 나타내지도 않습니다. 필터링을 마친 뒤에는 후보 집합에서 실제 연결 테스트를 수행해야 합니다. 단순한 도달 가능성만 보지 말고 실제 대상에 접속해 핸드셰이크 결과를 확인하세요. 모든 테스트가 실패하면 먼저 필터를 해제하고 원본 목록이 정상인지 확인해야 ‘표현식이 항목과 매칭되지 않음’과 ‘매칭된 항목 자체가 연결되지 않음’을 구분할 수 있습니다.

업데이트 후 선택 상태 유지

구독 업데이트로 항목이 추가, 삭제 또는 이름 변경될 수 있습니다. 현재 선택한 서버가 삭제되면 클라이언트가 다른 항목으로 돌아갈 수도 있고, 더 이상 사용할 수 없는 이전 참조를 유지할 수도 있습니다. 업데이트 후에는 현재 선택이 대상 그룹에 속해 있는지 확인하고 실제 연결을 다시 테스트하세요. 고정 작업용 설정에서는 목록 순번에만 의존하지 않는 것이 좋습니다. 정렬이 바뀌면 첫 번째 항목이 다른 서버가 되기 때문입니다. 더 안정적인 방법은 고유하고 일관된 이름 규칙을 사용하거나 업데이트 후 활성 항목을 직접 확인하는 것입니다.

필터 조건으로 갑자기 빈 목록이 나오면 먼저 필터링하지 않은 원본 그룹을 확인하세요. 원본 그룹도 비어 있다면 구독 업데이트 또는 확인 문제입니다. 원본 그룹에는 내용이 있지만 필터 결과가 비어 있다면 이름 변경 또는 표현식 문제입니다. 필터 결과는 있지만 연결되지 않는 경우에야 노드, 네트워크, DNS 또는 전송 설정을 의심해야 합니다. 이 세 가지 분기를 나누어 처리하면 목록이 비었다는 이유만으로 라우팅이나 TUN을 잘못 수정하는 일을 피할 수 있습니다. 최초 선택과 실제 연결 테스트 순서는 v2rayN 최초 연결 단계도 함께 참고하세요.

그룹 규칙이 안정되면 짧은 관리 규칙으로 문서화하세요. 출처별 접두사, 용도 필터에 사용할 수 있는 키워드, 제외할 임시 태그, 업데이트 후 수행할 점검 항목을 명시하면 됩니다. 이 규칙은 복잡한 표현식 자체보다 중요합니다. 이후 새 구독을 추가해도 같은 구조에 편입할 수 있기 때문입니다. 규칙을 만든 사람만 이해할 수 있다면 이름이 바뀌는 순간 그룹은 다시 무질서한 목록으로 변합니다.

다중 구독 관리와 업데이트 경계

다중 구독 관리의 목적은 더 많은 주소를 한곳에 가져오는 것이 아니라 출처 사이에 식별 가능하고, 비활성화할 수 있으며, 복구 가능한 경계를 만드는 것입니다. 각 구독은 독립적인 업데이트 주기, 이름 규칙 및 서버 필드를 가질 수 있습니다. 모든 출처를 표시 없는 하나의 목록에 섞으면 중복 항목, 일괄적인 무효화 또는 이름 충돌이 발생했을 때 어느 입력을 수정해야 할지 판단하기 어렵습니다. 올바른 다중 구독 구조는 먼저 출처를 격리하고, 그다음 통합 필터와 일상적인 사용 편의성을 고려해야 합니다.

각 출처에 독립적인 수명 주기 부여

구독을 추가할 때는 먼저 용도, 출처 식별자 및 예상 업데이트 방식을 기록한 뒤 최초 업데이트를 실행하세요. 업데이트 성공은 클라이언트가 콘텐츠를 가져와 확인했다는 뜻일 뿐입니다. 서버 수 변화, 주요 필드 및 실제 연결 하나 이상을 추가로 확인해야 합니다. 특정 출처에 일시적인 문제가 생기면 즉시 삭제하기보다 해당 출처를 비활성화하거나 자동 업데이트를 일시 중지하세요. 비활성화하면 기존 설정과 문제 해결 단서를 보존할 수 있습니다. 더 이상 사용하지 않는 것이 확인된 뒤 제거하면 실수로 인한 복구 비용을 줄일 수 있습니다.

자동 업데이트 간격은 무조건 짧게 설정할 필요가 없습니다. 지나치게 잦은 업데이트는 불필요한 요청을 늘리고 작업 중인 목록을 바꿀 수 있습니다. 안정적인 출처는 확인하기 쉬운 고정 시간대에 업데이트하고, 임시 출처는 수동 업데이트로 유지할 수 있습니다. 클라이언트가 시작 시 업데이트를 지원한다면 시작 빈도와 네트워크 환경을 고려하세요. 기기가 깨어날 때마다 업데이트하면 상태가 계속 바뀔 수 있고, 너무 오랫동안 재시작하지 않으면 변경 사항을 놓칠 수 있습니다. 중요한 것은 모든 출처에 같은 간격을 적용하는 것이 아니라 언제 업데이트가 발생하는지, 업데이트 후 검증했는지를 아는 것입니다.

중복 항목과 이름 충돌 처리

서로 다른 구독에 같은 서버가 포함될 수도 있고, 이름만 같을 뿐 실제 매개변수는 다를 수도 있습니다. 메모 이름만으로 중복 여부를 판단해서는 안 됩니다. 주소, 포트, 프로토콜, 전송, 보안 설정 및 서버 식별자 등 주요 필드를 비교하세요. 이름은 같지만 전송 매개변수가 다르면 서로 다른 진입점일 수 있습니다. 이름은 다르지만 연결 필드가 완전히 같다면 출처만 다른 중복 게시일 수 있습니다. 중복 항목을 남겨 두면 선택 시 잡음이 늘어나지만 성급하게 병합하면 업데이트 출처를 잃을 수 있습니다.

안전한 방법은 출처별 그룹을 유지하고, 일상적인 용도 화면에서는 주요 항목 하나만 필터링하거나 즐겨찾기에 추가하는 것입니다. 주요 출처의 업데이트가 실패해도 다른 출처로 돌아가 같은 유형의 설정을 확인할 수 있습니다. 이름을 바꿔야 한다면 구독 내부의 주요 필드를 직접 수정하지 말고 클라이언트의 로컬 메모 기능을 사용하세요. 다음 업데이트에서 로컬 이름이 유지되는지는 클라이언트의 병합 방식에 따라 다르므로, 이름을 바꾸기 전에 업데이트 동작을 확인해야 합니다. 덮어써질 수 있는 수동 이름에 중요한 분류를 전부 의존하지도 마세요.

업데이트 실패의 계층별 판단

구독 업데이트가 실패하면 먼저 가져오기 실패와 확인 실패를 구분하세요. 가져오기 실패는 보통 연결을 설정할 수 없거나, 반환 상태가 비정상적이거나, 시간이 초과되는 형태로 나타납니다. 이때는 구독 주소가 완전한지, 현재 네트워크에서 접근 가능한지, 시스템 프록시가 순환을 만들고 있지 않은지 확인해야 합니다. 확인 실패는 콘텐츠를 가져왔지만 클라이언트가 예상한 형식과 맞지 않는 경우입니다. 웹페이지 안내가 반환되었거나 인코딩이 바뀌었거나 구독 유형을 잘못 선택했을 수 있습니다. 반환 유형을 확인하지 않은 채 반복해서 새로고침해도 형식 문제는 해결되지 않습니다.

구독 주소가 프록시를 켜야만 접근 가능하다면 업데이트 요청이 어느 아웃바운드를 사용하는지 명확히 하세요. 일부 설정에서는 클라이언트가 자체 구독을 업데이트할 때 현재 프록시를 통과합니다. 활성 서버가 이미 무효화되었다면 ‘새 항목을 얻으려면 업데이트해야 하지만 업데이트가 기존 항목에 의존하는’ 순환이 생깁니다. 이때는 일시적으로 사용할 수 있는 출처를 선택하거나 구독 업데이트의 프록시 정책을 조정하거나 직접 연결 가능한 환경에서 업데이트를 완료하세요. 수정 후에는 원래 정책을 복원하고 원인을 기록해 다음 업데이트에서 같은 문제가 반복되지 않게 해야 합니다.

구독 형식의 차이도 여러 출처를 병합할 때 영향을 줍니다. Base64 목록, 단일 공유 링크 및 원시 JSON 설정은 담을 수 있는 정보 범위가 다르므로 변환 과정에서 라우팅, DNS 또는 사용자 지정 아웃바운드 같은 전역 설정이 빠질 수 있습니다. 서버 구독은 주로 서버 항목 배포를 담당하고, 클라이언트의 전역 라우팅과 DNS는 로컬 설정으로 관리해야 합니다. 단일 공유 링크 하나가 전체 클라이언트 정책을 완전히 표현한다고 기대하지 마세요. 형식의 범위와 변환 필드는 V2Ray 구독 형식 가이드에서 확인할 수 있습니다.

완성도 높은 다중 구독 구성은 세 가지 질문에 답할 수 있어야 합니다. 특정 서버가 어디에서 왔는지, 특정 출처가 실패하면 어떤 용도에 영향을 주는지, 복구 후 어떻게 검증할지입니다. 장기간 비활성화된 출처는 정기적으로 정리하되, 정리 전에 필요한 설정을 내보내고 라우팅 규칙이나 즐겨찾기 항목이 해당 이름에 의존하지 않는지 확인하세요. 기기를 옮길 때는 먼저 출처와 그룹을 이전하고, 다음으로 용도별 필터를 옮기세요. 기본 항목이 안정된 뒤 마지막으로 라우팅과 사용자 지정 아웃바운드를 복원하면 입력 문제와 고급 정책 문제를 명확히 분리할 수 있습니다.

라우팅 규칙 실전과 매칭 순서

라우팅 규칙은 커널에 들어온 연결의 아웃바운드를 선택합니다. 일반적인 조건으로는 도메인, 대상 IP, 포트, 네트워크 유형, 프로토콜 및 프로세스 정보가 있으며, 결과는 프록시, 직접 연결, 차단 또는 사용자 지정 아웃바운드입니다. 규칙 시스템은 보통 정해진 순서대로 매칭하며, 실행 가능한 규칙 하나에 연결이 매칭되면 이후 규칙을 계속 확인하지 않습니다. 따라서 라우팅 설정의 핵심은 규칙 수가 아니라 조건이 서로 겹치지 않는지, 순서가 명확한지, 기본 트래픽이 최종적으로 어디로 향하는지입니다.

결과를 먼저 정한 뒤 조건 작성

규칙을 작성하기 전에 예상 결과를 먼저 나열하세요. 예를 들면 로컬 네트워크와 로컬 주소는 직접 연결, 명확한 업무 도메인은 지정 프록시 사용, 특정 업데이트 서비스는 직접 연결, 나머지는 기본 프록시 사용과 같습니다. 결과가 정해지면 각 트래픽 유형에 가장 안정적인 판단 조건을 선택합니다. 도메인 규칙은 읽기 쉽지만 커널이 도메인 정보를 얻을 수 있어야 합니다. IP 규칙은 주소 범위가 안정적인 대상에 적합하고, 포트 규칙은 범위가 넓으므로 보조 조건으로만 사용하는 편이 좋습니다. 프로세스 규칙은 플랫폼별 차이가 있어 모든 기기에 그대로 복사하기 어렵습니다.

포괄적인 조건은 구체적인 조건 뒤에 배치해야 합니다. 첫 번째 규칙에서 모든 TCP와 UDP를 프록시로 보내면 이후의 로컬 네트워크 직접 연결 규칙은 적용될 기회가 없습니다. 반대로 너무 넓은 직접 연결 도메인 접미사를 먼저 배치하면 프록시로 보내야 할 하위 도메인도 먼저 직접 연결될 수 있습니다. 규칙 순서를 점검할 때는 대상 도메인을 잠시 맨 앞에 두고 식별하기 쉬운 아웃바운드를 지정해 보세요. 매칭을 확인한 뒤 다른 규칙을 단계적으로 복원하면서 어떤 규칙이 덮어쓰기를 일으키는지 관찰합니다.

{
  "routing": {
    "domainStrategy": "IPIfNonMatch",
    "rules": [
      {
        "type": "field",
        "ip": [
          "geoip:private"
        ],
        "outboundTag": "direct"
      },
      {
        "type": "field",
        "domain": [
          "full:docs.example.com",
          "domain:example.net"
        ],
        "outboundTag": "proxy"
      },
      {
        "type": "field",
        "network": "tcp,udp",
        "outboundTag": "proxy"
      }
    ]
  }
}

예시의 full:은 전체 도메인 매칭을 뜻하고, domain:은 일반적으로 해당 도메인과 하위 도메인을 포함합니다. geoip:private는 사설 주소 범위를 식별하는 데 사용합니다. 마지막 네트워크 규칙은 기본 출구를 담당하므로 구체적인 규칙 뒤에 있어야 합니다. 예시 도메인은 구조 설명용이므로 실제 설정에서는 제어하려는 대상으로 바꾸세요. 클라이언트에 그래픽 라우팅 편집기가 있다면 같은 조건을 해당 필드에 나누어 입력해야 하며, 전체 JSON을 완전한 설정을 받지 않는 입력란에 붙여 넣어서는 안 됩니다.

도메인 정책과 확인 시점 이해

domainStrategy는 도메인 규칙이 매칭되지 않았을 때 IP를 계속 확인하고 IP 규칙을 시도할지 결정합니다. AsIs는 원래 도메인을 유지한 채 매칭하는 경향이 있으며 라우팅을 위해 적극적으로 확인하지 않습니다. IPIfNonMatch는 도메인 규칙이 매칭되지 않으면 확인을 수행한 뒤 IP 규칙을 계속 검사합니다. 일부 커널은 더 적극적인 확인 정책도 제공합니다. 정책이 적극적일수록 IP 규칙의 적용 범위는 넓어지지만 DNS 조회가 늘고 확인 경로가 라우팅 결과에 직접적인 영향을 줄 수 있습니다.

앱이 이미 자체적으로 도메인을 확인한 뒤 대상 IP만 커널에 전달한다면 도메인 규칙은 원래 이름을 얻지 못할 수 있습니다. TUN 스니핑, FakeDNS 또는 앱 프록시 방식에 따라 도메인 정보가 보이는지가 달라집니다. ‘도메인 규칙은 맞아 보이는데 매칭되지 않는’ 상황에서는 먼저 로그에서 대상이 도메인으로 표시되는지 IP로 표시되는지 확인하세요. 그다음 확인 정책을 조정하거나 적절한 스니핑을 활성화하거나 IP 조건을 추가합니다. 커널이 도메인을 얻지 못한 문제는 도메인 접미사를 무작정 더 추가해도 해결되지 않습니다.

최소 규칙 집합을 만든 뒤 단계적으로 확장

사설 주소 직접 연결, 소수의 명확한 대상을 필요에 따라 분기, 나머지는 기본 아웃바운드로 보내는 세 부분의 규칙부터 시작하는 것이 좋습니다. 안정성을 확인한 뒤 업데이트 서비스, 개발 환경 또는 특정 프로세스 규칙을 추가하세요. 규칙 그룹을 하나 추가할 때마다 정방향 테스트와 역방향 테스트를 준비해야 합니다. 하나는 매칭되어야 하는 대상이고 다른 하나는 매칭되면 안 되는 유사 대상입니다. 예를 들어 domain:example.net을 설정했다면 루트 도메인, 하위 도메인 하나, 이름에 비슷한 문자열만 포함한 다른 도메인을 함께 테스트하세요.

라우팅 문제를 해결할 때는 연결 로그의 대상, 매칭된 규칙 및 아웃바운드 태그를 먼저 확인하세요. 로그에 연결 실패만 표시되고 규칙 정보가 없다면 테스트 중에만 클라이언트 로그 수준을 높였다가 완료 후 되돌리세요. 올바른 아웃바운드에 매칭되었는데도 실패한다면 문제는 이미 라우팅 계층을 벗어난 것이므로 서버, DNS 또는 전송 연결을 확인해야 합니다. 대상이 어떤 로그에도 나타나지 않는다면 먼저 시스템 프록시, TUN 또는 앱 자체 프록시 설정을 점검하세요.

시스템 프록시, 전체 모드 및 규칙 기반 분기는 서로 다른 차원을 제어합니다. 시스템 프록시는 일부 앱이 요청을 클라이언트에 전달할지 결정하고, 라우팅 모드는 커널이 연결을 받은 뒤 출구를 선택하는 방식을 결정합니다. 두 관계를 다시 확인해야 한다면 V2Ray 시스템 프록시 선택 방법을 참고하세요. 네트워크에 따라 규칙 결과가 달라진다면 DNS가 반환한 주소가 바뀌었는지도 확인해야 합니다. IP 범위에 의존하는 규칙은 확인 결과에 따라 다른 출구로 매칭될 수 있습니다.

DNS 설정 최적화와 확인 경로

DNS 설정의 핵심은 서버 주소 하나를 단순히 바꾸는 것이 아니라 누가 조회를 시작하고, 어떤 아웃바운드를 거치며, 어느 계층이 반환 결과를 사용하는지 정하는 데 있습니다. 운영체제, 브라우저, 클라이언트 커널 및 원격 서버가 모두 확인 과정에 참여할 수 있습니다. 같은 도메인이 여러 계층에서 반복 확인되면 서로 다른 주소가 반환될 수 있고 라우팅 판단도 달라집니다. DNS를 최적화하기 전에 조회 경로를 그려 로컬 확인, 커널 확인 및 원격 확인의 경계를 명확히 하세요.

시스템 DNS와 커널 DNS 구분

시스템 DNS는 클라이언트가 전환하지 않은 일반 프로그램에 사용되며, 앱이 프록시에 들어가기 전에 확인을 완료할 수도 있습니다. 커널 DNS는 라우팅, TUN 또는 커널 자체 연결에 사용됩니다. 시스템 프록시 모드에서 도메인 프록시를 지원하는 앱은 도메인을 프록시 커널에 직접 전달할 수도 있고 로컬에서 먼저 확인할 수도 있습니다. 구체적인 동작은 앱과 프록시 유형에 따라 달라집니다. TUN 모드에서는 클라이언트가 DNS 트래픽을 가로챌 기회가 더 많지만 DNS 하이재킹, 라우팅 및 제외 항목을 올바르게 설정해야 합니다.

진단할 때 운영체제 DNS만 바꾼 뒤 웹페이지를 관찰하지 마세요. 시스템 조회와 클라이언트 로그를 따로 확인해야 합니다. Windows에서는 ipconfig /flushdns로 시스템 캐시를 지운 뒤 nslookup 또는 PowerShell 조회를 실행할 수 있습니다. macOS에서는 scutil --dns로 확인자 순서를 확인하고, Linux에서는 시스템 환경에 따라 resolvectl status로 현재 상위 DNS를 점검할 수 있습니다. 캐시 삭제는 오래된 결과를 배제하기 위한 조치일 뿐 장기적인 해결책으로 사용해서는 안 됩니다.

Windows:
ipconfig /flushdns
nslookup docs.example.com

macOS:
scutil --dns
dscacheutil -q host -a name docs.example.com

Linux:
resolvectl status
resolvectl query docs.example.com

도메인별 확인 서버 선택

복잡한 환경에서는 도메인별로 서로 다른 DNS 서버를 선택할 수 있습니다. 로컬 네트워크 도메인은 로컬 확인자에 맡기고, 공용 도메인은 일반 상위 DNS로 보내며, 특정 대상은 프록시 아웃바운드를 통해 조회하는 방식입니다. DNS 분기의 가치는 내부 이름을 확인할 수 있게 유지하고 외부 조회 경로를 라우팅 의도와 일치시키는 데 있습니다. 설정할 때는 구체적인 도메인 규칙을 먼저 배치하고 기본 서버를 뒤에 두어 기본 항목이 먼저 덮어쓰지 않게 하세요. 로컬 확인자에는 명확한 주소 범위를 지정해 실수로 프록시를 통해 접근하지 않도록 해야 합니다.

{
  "dns": {
    "hosts": {
      "router.internal": "192.168.1.1"
    },
    "servers": [
      {
        "address": "192.168.1.1",
        "domains": [
          "domain:internal"
        ],
        "skipFallback": true
      },
      "1.1.1.1",
      "8.8.8.8"
    ],
    "queryStrategy": "UseIP"
  }
}

hosts는 소수의 고정 매핑에 적합하며 자주 바뀌는 대규모 도메인 집합을 관리하는 용도에는 맞지 않습니다. domains가 있는 서버는 매칭 범위만 처리하고, skipFallback은 실패 후 다른 후보로 넘어갈지 제어합니다. queryStrategy는 조회할 주소 계열의 우선순위를 정하므로 현재 네트워크에서 IPv4 또는 IPv6 연결이 안정적인지에 맞춰 선택해야 합니다. 사용할 수 없는 주소 계열만 강제로 조회하면 도메인은 보이지만 연결은 계속 시간 초과될 수 있습니다.

캐시, 폴백 및 조회 순환

DNS 캐시는 반복 조회를 줄여 주지만 설정을 바꾼 뒤에도 오래된 결과가 남게 할 수 있습니다. 확인 서버, 도메인 규칙 또는 FakeDNS를 조정할 때는 운영체제 캐시, 브라우저 캐시 및 커널 캐시를 함께 고려해야 합니다. 프록시를 껐다 켜는 것만으로 모든 계층의 캐시가 삭제되지는 않습니다. 테스트할 때는 이전에 조회하지 않은 하위 도메인을 사용하거나 플랫폼에 맞는 캐시를 정리하세요. 캐시를 지운 직후에는 잠시 정상이고 다시 문제가 생긴다면 여러 확인자가 번갈아 다른 결과를 반환하는지 점검해야 합니다.

폴백 메커니즘에는 명확한 경계가 필요합니다. 기본 서버 조회가 실패했을 때 예비 서버로 전환하면 가용성이 높아질 수 있지만, 서버마다 다른 분기 의도를 갖고 있다면 무조건적인 폴백으로 인해 내부 도메인이 부적절한 상위 DNS로 전송되거나 라우팅과 맞지 않는 주소를 받을 수 있습니다. 내부 도메인은 일반적으로 공용 상위 DNS로 폴백하지 않도록 하고, 일반 공용 도메인에는 순서가 있는 후보를 설정할 수 있습니다. 폴백 발생 여부는 최종 주소만 보지 말고 로그에서 실제 조회 서버를 확인해야 합니다.

조회 순환은 DNS 요청이 프록시로 라우팅되는데 프록시 서버의 도메인 자체도 같은 프록시 DNS를 통해 확인해야 할 때 자주 발생합니다. 해결 방법은 서버 주소에 시작 경로를 만드는 것입니다. 알려진 IP를 우선 사용하거나 서버 도메인에 직접 접근 가능한 확인자를 별도로 지정하거나, 해당 DNS 요청을 현재 프록시에 의존하지 않는 아웃바운드로 보내세요. 수정할 때는 최소한의 직접 연결 확인 능력을 남겨야 합니다. 그렇지 않으면 클라이언트가 시작 단계에서 프록시 서버 주소를 얻지 못할 수 있습니다.

연결 속도가 느려지거나 일부 도메인이 간헐적으로 실패할 때 DNS는 가능한 원인 중 하나일 뿐입니다. 서버 상태, 네트워크 회선, 프록시 모드 및 로컬 리소스 사용량도 함께 확인해 모든 변동을 DNS 탓으로 돌리지 마세요. V2Ray 속도 저하 계층별 점검의 순서에 따라 먼저 장애 계층을 정한 뒤 DNS 조정 여부를 결정할 수 있습니다. 설정 최적화의 기준은 상위 DNS를 최대한 많이 쌓는 것이 아니라 경로를 설명할 수 있고 결과를 재현할 수 있는지입니다.

TUN 모드의 전환 범위와 제외 항목

TUN 모드는 가상 네트워크 인터페이스를 통해 시스템 트래픽을 수신하므로 시스템 프록시를 따르지 않거나 독립적인 네트워크 스택을 사용하거나 더 많은 UDP 트래픽을 처리해야 하는 프로그램에 적합합니다. TUN이 바꾸는 것은 트래픽이 클라이언트에 들어오는 방식이며 구독 선택, DNS 및 라우팅을 자동으로 대체하지는 않습니다. TUN을 활성화하면 이전에는 로그에 나타나지 않던 앱이 커널에서 처리되기 시작하고 잘못된 라우팅이나 DNS 문제도 더 뚜렷해질 수 있습니다. 사용하기 전에 일반 프록시 모드가 안정적으로 연결되는지 먼저 확인하세요.

시스템 프록시와 TUN 선택

일상적인 검색과 시스템 프록시 설정을 따르는 데스크톱 앱에는 보통 시스템 프록시를 먼저 사용합니다. 설정이 간단하고 영향 범위를 제어하기 쉽기 때문입니다. 앱이 시스템 프록시를 무시하거나 특정 UDP 연결을 가로채야 하거나 앱별 차이를 통합하고 싶을 때 TUN을 고려하세요. 웹사이트 하나가 열리지 않는다는 이유만으로 곧바로 TUN으로 전환하지 마세요. 원인이 서버 사용 불가나 라우팅 오류라면 전환 방식만 바꿔 새로운 변수를 추가하게 됩니다. 먼저 대상 요청이 클라이언트 로그에 나타나는지 확인하세요. 이미 나타난다면 문제는 보통 전환 계층에 있지 않습니다.

TUN은 가상 인터페이스를 만들고 시스템 라우팅을 조정해야 하므로 Windows, macOS 및 Linux에서 필요한 권한과 네트워크 구성 요소가 다를 수 있습니다. v2rayN 인터페이스는 플랫폼에 따라 해당 진입점을 제공하며 권한 안내는 시스템 요구 사항에 따라 완료해야 합니다. Android의 v2rayNG와 v2flyNG는 시스템이 제공하는 가상 네트워크 권한으로 트래픽을 전환하므로 데스크톱 설정 진입점과 동작 방식이 다릅니다. 플랫폼 간에 참고할 때는 전환 대상, DNS 흐름 및 제외 규칙을 비교하고 기기 이름이나 인터페이스 번호를 그대로 복사하지 마세요.

라우팅 테이블, MTU 및 네트워크 순환

TUN을 활성화하면 클라이언트가 시스템 라우팅을 추가하거나 조정해 대상 트래픽을 가상 인터페이스로 보냅니다. 기본 라우트, 물리 네트워크 카드 라우트 및 가상 인터페이스의 우선순위가 충돌하면 연결이 되돌아가거나 로컬 네트워크에 접근할 수 없거나 클라이언트의 서버 트래픽 자체가 다시 TUN으로 들어갈 수 있습니다. 문제를 확인할 때는 먼저 시스템 라우팅 테이블을 살펴보고 프록시 서버 주소, 로컬 네트워크 주소 및 DNS 상위 서버의 경로를 확인하세요. 프록시 서버 연결은 실제 네트워크 인터페이스에서 나가야 하며 같은 TUN이 다시 가로채서는 안 됩니다.

MTU는 인터페이스에서 하나의 네트워크 패킷이 가질 수 있는 최대 크기입니다. 너무 크게 설정하면 일부 경로에서 조각화나 패킷 손실이 발생해 작은 요청은 정상인데 큰 페이지나 파일 전송이 멈출 수 있습니다. 너무 작으면 패킷 수와 추가 오버헤드가 늘어납니다. 핸드셰이크는 정상인데 지속적인 전송에 문제가 있다면 MTU를 점검 항목으로 삼을 수 있지만, 근거 없이 임의로 바꾸지는 마세요. 먼저 네트워크 환경, 대상 및 프로토콜별 동작을 비교한 뒤 조금씩 조정하고 결과를 기록해야 합니다.

네트워크 순환은 앱 자체 프록시와 TUN이 동시에 적용될 때도 발생할 수 있습니다. 어떤 프로그램이 로컬 프록시 포트를 수동으로 설정하면 연결이 먼저 로컬 프록시로 들어가고, 프록시 아웃바운드가 다시 TUN에 포착될 수 있습니다. 제외 규칙이 불완전하면 같은 경로로 반복 진입합니다. 해결할 때는 단일 진입점을 선택하세요. 앱이 로컬 프록시를 사용하도록 하고 클라이언트 프로세스를 제외하거나, 앱의 수동 프록시를 해제하고 TUN이 직접 전환하도록 해야 합니다. 클라이언트 핵심 프로세스, 업데이트 요청 및 필요한 로컬 수신 주소는 보통 명시적으로 제외해야 합니다.

로컬 네트워크와 핵심 프로세스 제외

로컬 네트워크 프린터, 파일 공유, 라우터 관리 및 로컬 개발 서비스는 보통 직접 연결로 유지해야 합니다. 라우팅 계층에서는 사설 주소 규칙으로 직접 연결을 지정할 수 있고, TUN 계층에서는 우회 주소나 앱 목록을 제공할 수도 있습니다. 두 계층의 규칙은 일관되어야 합니다. TUN이 전환 전에 특정 주소 범위를 제외하면 커널 라우팅에는 해당 연결이 보이지 않습니다. TUN이 전환한 뒤 커널에서 직접 연결하면 로그에서 매칭 결과를 관찰할 수 있습니다. 어떤 방식을 선택할지는 해당 트래픽을 기록하고 제어할 필요가 있는지에 따라 달라집니다.

프로세스 제외는 클라이언트 자체의 순환이나 명확히 전환하지 않을 앱을 처리하는 데 유용하지만, 프로세스 이름은 런처, 하위 프로세스 및 플랫폼에 따라 달라질 수 있습니다. 주 프로그램만 제외한다고 해서 생성된 네트워크 서비스까지 모두 제외되는 것은 아닙니다. 더 안정적인 방법은 먼저 주소와 라우팅 경계에서 처리한 뒤 프로세스 제외를 보완책으로 사용하는 것입니다. 앱을 업데이트한 뒤 전환 동작이 바뀌었다면 기존 이름이 여전히 유효하다고 가정하지 말고 실제로 네트워크 연결을 시작한 프로세스를 다시 확인하세요.

TUN 문제는 ‘인터페이스 생성 여부, 라우팅 기록 여부, DNS가 예상 경로로 들어가는지, 대상이 규칙에 매칭되는지, 아웃바운드에 연결할 수 있는지’ 순서로 점검할 수 있습니다. TUN을 끄자마자 복구된다면 문제는 가상 인터페이스, 라우팅 또는 DNS 전환에 집중되어 있을 가능성이 큽니다. 끈 뒤에도 이상이 지속된다면 시스템 프록시가 남아 있는지, 클라이언트 프로세스가 계속 실행 중인지, 운영체제 라우팅이 복구되었는지 확인하세요. 필요하면 먼저 클라이언트를 종료하고 물리 네트워크에 다시 연결해 깨끗한 상태에서 기본 네트워크를 검증하세요.

FakeDNS 매핑 원리와 적용 범위

FakeDNS의 핵심 방식은 클라이언트가 도메인 조회를 받은 뒤 실제 대상 주소를 즉시 앱에 반환하지 않고 전용 주소 풀에서 임시 매핑 주소를 할당하는 것입니다. 앱이 이 주소에 연결하면 커널이 매핑 테이블을 통해 원래 도메인을 복원한 뒤 도메인 라우팅과 원격 확인을 수행합니다. 따라서 앱이 IP 연결만 시작하더라도 커널은 도메인 정보를 유지할 수 있습니다. FakeDNS는 주로 TUN 환경에서 도메인 정보가 사라지거나 로컬에서 먼저 확인되는 문제를 해결하며 모든 연결 속도를 높이는 만능 스위치는 아닙니다.

조회 한 번과 연결이 완료되는 과정

앱은 먼저 DNS에 service.example.com을 요청합니다. FakeDNS는 주소 풀에서 매핑 주소를 반환하는 동시에 ‘매핑 주소가 원래 도메인에 대응한다’는 정보를 기록합니다. 앱이 해당 주소로 연결을 시작하면 TUN이 트래픽을 커널에 전달하고, 커널은 테이블을 조회해 도메인을 복원한 뒤 도메인 규칙으로 아웃바운드를 선택합니다. 프록시 프로토콜과 서버가 원격 확인을 지원하면 실제 DNS 조회는 이후 경로에서 수행될 수 있습니다. 매핑 테이블에는 용량과 수명이 있으므로 만료된 주소가 같은 관계를 무한히 유지하지는 않습니다.

이 과정이 작동하려면 DNS 조회와 이후 연결이 같은 커널로 들어가야 합니다. 브라우저의 독립적인 암호화 확인이 DNS를 우회하고 연결만 TUN으로 들어가면 커널에는 실제 IP만 보이므로 FakeDNS가 참여하지 않습니다. 반대로 DNS가 매핑 주소를 반환했는데 연결이 TUN을 우회해 물리 네트워크로 직접 나가면 해당 주소는 공용 네트워크에서 올바르게 응답하지 않습니다. 활성화하기 전에 조회와 연결 경로가 일치하는지 반드시 확인하세요. 그렇지 않으면 도메인 확인은 주소를 반환하지만 모든 연결이 즉시 실패하는 형태로 나타납니다.

{
  "dns": {
    "servers": [
      "fakedns",
      "1.1.1.1"
    ]
  },
  "fakedns": [
    {
      "ipPool": "198.18.0.0/15",
      "poolSize": 65535
    }
  ]
}

198.18.0.0/15는 벤치마크 테스트와 매핑 용도로 자주 사용하는 예약 주소 범위이며 실제 로컬 네트워크 주소와 겹치면 안 됩니다. poolSize는 할당 가능한 매핑 수를 제어하고, 실제 지원 방식은 사용하는 커널과 클라이언트가 생성한 설정에 따라 달라집니다. 그래픽 클라이언트에 FakeDNS 옵션이 있다면 필요한 DNS, 스니핑 및 라우팅 관계를 함께 생성할 수 있도록 인터페이스에서 설정하는 것이 좋습니다. 일부 JSON만 직접 삽입할 때는 최종 설정에 중복 필드나 상호 덮어쓰기가 없는지 확인하세요.

주소 풀 충돌과 우회 연결

주소 풀을 선택할 때는 기업 네트워크, 가상 머신, 컨테이너 및 다른 네트워크 소프트웨어가 같은 범위를 이미 사용하고 있는지 확인해야 합니다. 주소 충돌이 발생하면 시스템이 매핑 트래픽을 잘못된 인터페이스로 보내거나 실제 내부 주소를 FakeDNS 결과로 오인할 수 있습니다. 활성화하기 전에 라우팅 테이블을 확인해 해당 네트워크에 더 구체적인 기존 경로가 없는지 살펴보세요. 충돌을 피할 수 없다면 커널 지원 범위 안에서 다른 예약 주소 대역을 선택하고 TUN 라우팅 및 제외 설정도 함께 업데이트해야 합니다.

일부 앱은 DNS 주소를 오랫동안 캐시하고 네트워크가 바뀐 뒤에도 이전 매핑을 계속 사용할 수 있습니다. 클라이언트를 재시작하면 매핑 테이블이 바뀌었는데 앱이 이전 주소를 계속 보유해 해당 앱만 실패하는 상황이 생길 수 있습니다. 이때는 대상 앱도 함께 재시작하거나 앱의 DNS 캐시를 삭제해야 합니다. FakeDNS를 자주 켜고 끄면 캐시 상태를 판단하기 어려워지므로 테스트 중에는 설정을 고정하고 조회, 연결 및 재시작 검증을 한 차례 완료한 뒤 유지 여부를 결정하세요.

로컬 네트워크 도메인, 프린터 검색, 기기 브로드캐스트 및 실제 IP가 필요한 앱은 일반적으로 FakeDNS에 넣지 않는 것이 좋습니다. 내부 도메인은 로컬 네트워크 DNS에 맡기고 도메인 규칙으로 매핑을 건너뛸 수 있습니다. 사설 주소는 직접 연결로 유지해야 합니다. 반환 주소를 이용한 접근 제어 또는 인증서 바인딩에 의존하는 프로그램은 매핑이 동작을 방해하지 않는지도 확인하세요. FakeDNS는 TUN에서 공용 도메인 정보를 복원해야 하는 일반 TCP 및 UDP 연결에 더 적합합니다.

스니핑 및 도메인 라우팅과의 조합

스니핑은 일부 애플리케이션 계층 프로토콜에서 대상 도메인을 복원할 수 있고, FakeDNS는 DNS 매핑 관계에서 도메인을 복원합니다. 두 기능은 단순한 대체 관계가 아닙니다. 스니핑은 프로토콜 내용을 식별할 수 있어야 하므로 암호화되었거나 비표준인 트래픽에서는 항상 효과적이지 않습니다. FakeDNS는 조회와 연결이 모두 커널을 통과해야 합니다. 트래픽 유형에 따라 함께 사용할 수 있지만 모든 대상을 스니핑 결과로 강제 덮어쓰지는 마세요. 로그에서는 원래 대상, 스니핑 대상 및 FakeDNS 매핑 대상을 구분할 수 있어야 합니다.

FakeDNS를 검증할 때는 먼저 캐시되지 않은 도메인을 조회해 반환 주소가 매핑 풀에 속하는지 확인하세요. 이어서 즉시 해당 도메인에 연결하고 로그에서 원래 이름이 복원되어 예상한 도메인 규칙에 매칭되는지 점검합니다. 마지막으로 로컬 네트워크 도메인을 테스트해 내부 DNS가 실제 주소를 반환하는지 확인하세요. 세 단계가 모두 통과해야 매핑, 복원 및 제외 관계가 완성되었다고 볼 수 있습니다. 예약 주소가 보인다는 사실만으로는 설정 성공을 증명할 수 없습니다. 이후 연결이 TUN에 포착되지 않았을 수도 있기 때문입니다.

FakeDNS 활성화 여부는 실제 문제에 따라 결정해야 합니다. 일반 DNS와 도메인 라우팅이 이미 안정적이고 앱이 도메인을 클라이언트에 전달할 수 있다면 설정을 복잡하게 만들면서까지 전환할 필요는 없습니다. TUN 환경에서 많은 연결이 IP로만 표시되고 도메인 분기가 안정적으로 작동하지 않을 때 FakeDNS를 검토하세요. 적용 전에는 브라우저, 일상 앱, 로컬 네트워크 리소스 및 네트워크 전환을 테스트하고 비활성화 후 돌아갈 수 있는 방법도 남겨 두어야 합니다.

사용자 지정 아웃바운드, 체인형 연결 및 최종 검증

아웃바운드는 라우팅 판정 후 실행되는 대상입니다. 기본 설정에는 보통 프록시, 직접 연결 및 차단 세 가지 아웃바운드가 포함되며, 고급 환경에서는 인터페이스별 직접 연결, 지정 DNS 아웃바운드, 체인형 프록시 또는 특정 트래픽을 위한 독립 연결 매개변수가 필요할 수 있습니다. 사용자 지정 아웃바운드의 가치는 계층을 늘리는 데 있지 않고 네트워크 경로를 명확하게 표현하는 데 있습니다. 아웃바운드를 하나 추가할 때마다 고유한 태그, 이를 호출하는 명확한 라우팅 규칙 및 단독으로 검증할 수 있는 대상이 있어야 합니다.

안정적이고 읽기 쉬운 태그 사용

아웃바운드 태그는 라우팅 규칙, DNS 설정 및 체인 관계에서 참조됩니다. 태그는 proxy-main, direct-lan, dns-direct처럼 짧고 안정적인 영문 또는 숫자 조합을 사용하세요. 서버 이름처럼 변경될 수 있는 설명은 피하는 것이 좋습니다. 태그를 수정할 때는 모든 참조를 함께 확인해야 합니다. 태그 철자가 일치하지 않으면 설정 로드 단계에서 오류가 발생하거나 규칙이 기본 아웃바운드로 폴백할 수 있습니다. 그래픽 클라이언트가 자동 생성한 태그는 함부로 덮어쓰지 말고 어떤 필드를 확장할 수 있는지 먼저 확인하세요.

{
  "outbounds": [
    {
      "protocol": "freedom",
      "tag": "direct-lan",
      "settings": {
        "domainStrategy": "UseIP"
      }
    },
    {
      "protocol": "blackhole",
      "tag": "blocked"
    }
  ],
  "routing": {
    "rules": [
      {
        "type": "field",
        "ip": [
          "geoip:private"
        ],
        "outboundTag": "direct-lan"
      },
      {
        "type": "field",
        "domain": [
          "domain:blocked.example"
        ],
        "outboundTag": "blocked"
      }
    ]
  }
}

freedom은 로컬에서 직접 연결을 설정한다는 뜻이고, blackhole은 매칭된 트래픽을 거부하는 데 사용합니다. 차단 규칙은 명확한 대상에만 적용하고 너무 넓은 조건으로 정상 서비스를 방해하지 않도록 하세요. 이 예시는 서버 설정을 포함하지 않고 아웃바운드와 라우팅 참조 관계만 보여 줍니다. v2rayN에 사용자 지정 아웃바운드를 추가하려면 현재 설정 템플릿의 병합 방식을 먼저 확인해야 합니다. 일부 인터페이스는 저장할 때 핵심 설정을 다시 생성하므로 생성 파일을 수동으로 수정하면 서버 전환 후 덮어써질 수 있습니다.

체인형 연결의 의존 관계

체인형 연결은 하나의 프록시 아웃바운드가 다른 아웃바운드를 통해 하위 연결을 설정하는 방식입니다. 중간 경로가 실제로 필요한 환경에 적합하지만 계층마다 장애 지점이 늘어납니다. 설정하기 전에 선행 아웃바운드와 대상 아웃바운드가 각각 독립적으로 작동하는지 확인한 뒤 체인을 구성하세요. 선행 계층이 실패하면 이후 계층의 로그에는 핸드셰이크 시간 초과만 나타날 수 있습니다. 반대로 이후 계층의 매개변수가 잘못되어도 선행 계층은 정상 연결처럼 보일 수 있습니다. 문제를 해결하려면 체인을 분리해 각 구간을 따로 테스트할 수 있어야 합니다.

체인형 설정에서는 순환도 방지해야 합니다. 아웃바운드 A가 아웃바운드 B를 통해 연결되는데 라우팅 규칙 때문에 B가 다시 A로 보내지면 완료되지 않는 순환이 생깁니다. 체인 관계를 만들 때 서버 주소의 확인과 연결에 어느 하위 출구를 사용할지 명확히 정하고, 필요한 주소에는 체인에 의존하지 않는 시작 규칙을 설정하세요. DNS도 아직 생성되지 않은 최종 아웃바운드에 의존하지 않도록 해야 합니다. 그렇지 않으면 클라이언트 시작 시 어느 계층의 서버도 확인할 수 없습니다.

서버 목록의 여러 일반 항목을 자동 체인형 연결로 오해하지 마세요. 클라이언트에서 현재 서버를 바꾸는 것은 보통 주요 프록시 아웃바운드를 교체하는 작업일 뿐입니다. 트래픽이 여러 아웃바운드를 차례로 통과하려면 프록시 전달 관계를 명시적으로 설정해야 합니다. 체인이 길다고 연결 품질이 높아지는 것은 아닙니다. 실제 결과는 각 구간의 네트워크 경로, 프로토콜 오버헤드 및 장애 복구 방식에 따라 달라집니다. 명확한 요구가 없다면 단독으로 검증 가능한 프록시 아웃바운드 하나가 관리하기 쉽습니다.

네트워크 인터페이스 또는 주소 계열별 직접 연결

여러 네트워크 카드를 사용하는 기기는 유선, 무선, 가상 네트워크 및 기업 네트워크에 동시에 연결될 수 있습니다. 사용자 지정 직접 연결 아웃바운드는 로컬 주소나 인터페이스를 지정해 특정 트래픽이 예상한 네트워크에서 나가도록 할 수 있습니다. 설정하기 전에 인터페이스 이름과 로컬 주소가 안정적인지 확인하세요. 자동 할당 주소가 바뀌면 고정 바인딩이 작동하지 않을 수 있습니다. Linux와 macOS는 시스템 라우팅 및 정책 라우팅으로 인터페이스를 제어하는 경우가 많고, Windows에서는 인터페이스 메트릭과 클라이언트 아웃바운드 바인딩을 함께 살펴봐야 합니다.

주소 계열 정책도 아웃바운드의 경계에 포함됩니다. 특정 네트워크에서 IPv4 연결만 안정적이라면 사용자 지정 아웃바운드가 도달할 수 없는 IPv6를 강제해서는 안 됩니다. 반대의 경우도 마찬가지입니다. DNS가 반환하는 주소 계열, 라우팅 규칙 및 아웃바운드 연결 정책이 서로 일치해야 합니다. 도메인에 여러 주소가 있는데 일부 네트워크에서만 연결이 실패한다면 서버만 바꾸지 말고 주소 계열별로 따로 테스트하세요. 수정 후에는 직접 연결과 프록시 아웃바운드가 같은 정책을 사용하는지도 확인해 같은 도메인이 두 출구에서 다르게 동작하지 않게 해야 합니다.

저장, 다시 로드 및 최종 검수

사용자 지정 아웃바운드를 완성한 뒤에는 먼저 커널이 설정을 로드할 수 있는지 확인하세요. 문법 오류, 알 수 없는 태그 또는 지원되지 않는 필드는 보통 시작 로그에 나타납니다. 로드에 성공했다고 경로까지 올바른 것은 아닙니다. 다음으로 각 아웃바운드에 명확한 테스트 대상을 선택하세요. 로컬 네트워크 주소로 직접 연결을 검증하고, 지정 도메인으로 주요 프록시를 검증하며, 차단 대상으로 거부 규칙을 검증합니다. 사용자 지정 체인은 각 구간을 단계적으로 확인하세요. 대상, 매칭 규칙, 아웃바운드 태그 및 결과를 기록해 반복 가능한 검수표를 만드세요.

그래픽 클라이언트는 서버 전환, 구독 업데이트 또는 라우팅 방식을 변경할 때 실행 설정을 다시 생성할 수 있습니다. 사용자 지정 내용을 저장한 뒤에는 클라이언트를 재시작하고, 테스트 구독 하나를 업데이트하고, 서버를 전환하고, 라우팅을 다시 로드한 다음 확장 설정이 남아 있는지 확인하는 전체 과정을 실행하세요. 내용이 덮어써진다면 임시 실행 파일을 반복해서 편집하지 말고 클라이언트가 지원하는 사용자 지정 설정 진입점, 템플릿 또는 병합 기능을 사용해야 합니다. 장기적으로 사용할 설정은 클라이언트가 인정하는 영구 저장 위치에 두세요.

완성도 높은 고급 설정은 ‘입력을 추적할 수 있고, 규칙을 설명할 수 있으며, DNS를 관찰할 수 있고, 전환을 되돌릴 수 있으며, 아웃바운드를 개별 테스트할 수 있는’ 상태를 유지해야 합니다. 연결에 문제가 생기면 먼저 요청이 어느 계층에서 멈췄는지 찾고 해당 계층의 로그와 시스템 상태를 확인하세요. 최소 환경을 다시 만들어야 한다면 빠른 시작 기본 흐름으로 돌아가 기본 연결을 완료한 뒤 장별로 고급 기능을 복원할 수 있습니다. 클라이언트 설치 또는 플랫폼 선택 문제는 설치 파일 페이지에서 확인하세요. 최소 기준에서 계층별로 복원하는 방법이 구독, 라우팅, DNS 및 TUN을 동시에 다시 구성하는 것보다 확실한 결론을 얻기 쉽습니다.