V2Ray 고급 설정 가이드

클라이언트 설정, 커널 설정, 시스템 네트워크 상태를 구분하기

고급 설정에서 가장 흔한 문제는 특정 매개변수를 완전히 잘못 입력한 경우보다 여러 계층을 동시에 변경했을 때 발생합니다. v2rayN의 인터페이스는 구독, 서버 선택, 시스템 프록시, TUN 스위치와 설정 생성을 담당합니다. Xray 또는 V2Fly 커널은 인바운드, 아웃바운드, DNS와 라우팅을 실행하고, 운영체제는 기본 라우팅, 네트워크 인터페이스, 이름 해석 순서와 애플리케이션의 프록시 우회 여부를 결정합니다. 세 계층은 서로 영향을 주지만, 문제를 확인할 때는 반드시 분리해야 합니다. “클라이언트가 실행 중”이라는 표시만으로는 프로세스가 실행 상태에 들어갔다는 뜻일 뿐, 시스템 트래픽이 예상대로 커널에 유입되고 있다고 단정할 수 없습니다.

변경을 시작하기 전에 정상 작동이 확인된 일반 시스템 프록시 설정을 하나 보존하세요. 정상적으로 연결되는 서버를 선택하고 기본 라우팅 모드를 사용하며 TUN과 FakeDNS를 끈 뒤, 브라우저와 자주 사용하는 데스크톱 프로그램에서 대상 사이트에 접속되는지 확인합니다. 그런 다음 현재 구독 그룹, 활성 서버, 시스템 프록시 상태, DNS 설정과 라우팅 모드를 기록하세요. 이렇게 하면 비교 기준이 생깁니다. 이후 특정 기능을 켠 뒤 문제가 발생해도 여러 미지의 변수 사이에서 시행착오를 반복하지 않고 즉시 기준선으로 되돌릴 수 있습니다.

설정 파일은 역할별로 이해해야 합니다. 일반적인 구조에서 inbounds는 시스템 프록시 또는 TUN에서 들어오는 트래픽을 받고, outbounds는 프록시, 직접 연결, 차단 등의 출구를 정의하며, routing.rules는 트래픽이 어느 출구로 갈지 결정합니다. dns는 도메인을 어떻게 해석할지 정합니다. 라우팅 규칙의 outboundTag는 아웃바운드의 tag와 완전히 일치해야 하며, DNS 서버 선택도 라우팅 규칙의 영향을 받을 수 있습니다. 관련 태그를 무시한 채 일부만 복사하면 불러오기는 되지만 동작이 불완전한 설정이 되기 쉽습니다.

최소 변경으로 문제 범위 확인하기

“구독 정리 → 라우팅 → DNS → TUN → FakeDNS → 사용자 지정 아웃바운드” 순서로 진행하는 것을 권장합니다. 구독과 서버 필터링은 선택 가능한 서버 집합만 바꾸므로 위험이 낮습니다. 라우팅과 DNS는 요청의 목적지를 바꾸고, TUN은 더 넓은 범위를 가로채며, FakeDNS는 TUN 또는 투명 프록시 경로에 의존합니다. 순서를 뒤집으면 도메인 해석이나 네트워크 인터페이스에 문제가 생겼을 때 원인이 서버, 라우팅, DNS 또는 가상 네트워크 카드 중 어디에 있는지 판단하기 어렵습니다.

변경할 때마다 최소 세 가지를 확인하세요. 첫째는 도메인 접속으로, 명확한 웹페이지를 선택해 HTTP와 TLS 연결을 확인합니다. 둘째는 직접 IP 연결로, DNS 문제와 전송 문제를 구분합니다. 셋째는 애플리케이션 적용 범위로, 시스템 프록시를 따르는 프로그램과 시스템 프록시를 읽지 않는 프로그램을 각각 점검합니다. 도메인만 실패하고 직접 IP가 정상이라면 먼저 DNS를 확인하세요. 브라우저는 정상인데 다른 프로그램이 실패한다면 해당 프로그램이 시스템 프록시 또는 TUN에 들어가는지 판단해야 합니다. 모두 실패하면 현재 서버, 아웃바운드 태그와 커널 로그를 확인하세요.

로그를 볼 때도 명확한 목표가 있어야 합니다. 시작 단계에서는 설정 파싱, 포트 점유, 권한과 가상 네트워크 카드 오류를 찾고, 연결 단계에서는 도메인, 대상 포트, 매칭된 아웃바운드 태그와 상위 서버 핸드셰이크 결과를 확인합니다. 중지 단계에서는 시스템 프록시와 라우팅이 복구되었는지 확인하세요. 로그 수준을 장기간 가장 상세하게 유지하면 정상 연결 기록이 핵심 오류를 가릴 수 있습니다. 점검이 끝나면 일반 수준으로 되돌리고, 문제가 발생하기 전후의 짧은 문맥만 보관하면 충분합니다.

구독 출처와 사용 목적을 분리해 표현하기

구독 그룹은 “서버가 어디에서 오는가”를, 서버 필터링은 “현재 어떤 서버를 볼 것인가”를 해결합니다. 두 개념을 하나의 이름에 섞어서는 안 됩니다. 그룹 이름에는 “일상용 구독”, “테스트 구독”, “예비 회선”처럼 출처나 용도를 적는 것이 좋습니다. 서버 이름은 지역, 프로토콜 또는 제공업체의 기존 정보를 유지하세요. 이렇게 하면 구독을 업데이트해 서버 이름이 바뀌어도 전체 구조가 흐트러지지 않습니다. 그룹 이름은 짧고 안정적으로 유지하고 만료일, 임시 상태와 긴 설명을 모두 넣지 마세요.

v2rayN에서 구독을 추가할 때는 먼저 각 링크에 독립적인 그룹을 만든 다음 단일 그룹 업데이트를 실행하세요. 처음부터 전체 업데이트를 선택하지 마세요. 형식이 잘못된 구독 하나 때문에 결과를 판단하기 어려워질 수 있습니다. 업데이트가 끝나면 서버 수가 예상과 맞는지 확인하고, 몇 개를 무작위로 열어 주소, 포트, 프로토콜과 전송 필드가 완전한지 살펴보세요. 구독은 서버 설정을 전달할 뿐, 라우팅 전략이나 시스템 프록시 모드, DNS 방식을 자동으로 결정하지 않습니다.

필터는 이름에 안정적인 표식이 있는 서버를 다룰 때 유용합니다. 예를 들어 이름에 “저배율” 또는 특정 지역 약어가 포함된 항목만 표시하거나, “점검”, “잔여 트래픽”처럼 연결용이 아닌 항목을 제외할 수 있습니다. 정규식은 더 유연하지만 잘못 선택할 가능성도 큽니다. 표현식을 적용하기 전에 일반 키워드로 범위를 좁히고, 정말 필요한 경우에만 정규식을 사용하세요. 괄호, 전각 기호, 공백과 대소문자 차이도 매칭 결과에 영향을 줄 수 있습니다.

키워드 중 하나라도 포함
HK|SG|JP

상태를 나타내는 이름 제외
점검|만료|잔여 트래픽|공식 사이트

이름 시작 부분의 지역 표식 매칭
^(HK|SG|JP)[-_ ]

위 표현식은 필터링 방식만 보여 주는 예시이며, 실제 이름은 현재 구독 내용을 기준으로 해야 합니다. 필터는 서버 자체를 수정하지 않고 목록 결과나 일괄 작업 범위만 바꿉니다. 필터 적용 후 목록이 비어 있다면 먼저 조건을 지운 뒤 이름에 다른 약어가 사용되었는지 확인하세요. 필터를 작동시키려고 많은 서버의 이름을 하나씩 수동으로 바꾸지는 마세요. 다음 업데이트에서 목록이 다시 생성되며 수동 이름이 원본 데이터와의 대응 관계를 잃을 수 있습니다.

업데이트, 중복 제거 및 만료 항목 처리

같은 서버가 여러 구독에서 중복으로 제공되는 경우가 있습니다. 중복 여부는 표시 이름만 보지 말고 주소, 포트, 프로토콜과 전송 계층 매개변수도 비교해야 합니다. 이름이 같아도 서로 다른 진입점일 수 있고, 이름이 달라도 같은 연결 정보일 수 있습니다. 가장 안전한 방법은 그룹별 출처 경계를 유지하고 가져온 뒤 그룹 간 대규모 병합을 하지 않는 것입니다. 일상 목록을 단순화하려면 구독 구조를 훼손하지 말고 필터 보기나 고정 즐겨찾기를 사용하세요.

구독 업데이트 후 서버가 사라졌다면 먼저 원본 구독에서 제거된 것인지, 필터 조건으로 숨겨진 것인지, 다른 그룹으로 들어간 것인지 확인하세요. 업데이트 후 항목이 완전히 사라졌다면 구독 링크가 온전한지, 네트워크 요청이 성공했는지, 반환된 내용을 클라이언트가 인식할 수 있는지 점검해야 합니다. 기본 조작은 입문 가이드에서 다시 확인할 수 있습니다. 일부 서버만 연결되지 않는다면 서버 설정이나 네트워크 경로 문제로 분류하고, 전체 구독을 반복해서 삭제하거나 다시 추가하지 마세요.

서버 정렬에도 목적이 분명해야 합니다. 이름순 정렬은 고정된 지역 표식을 비교할 때 적합하고, 그룹순 정렬은 출처를 구분할 때 유용합니다. 속도 측정 결과는 측정 시점과 대상만 반영하며 모든 서비스의 실제 체감 속도를 의미하지 않습니다. 테스트 전에는 시스템에서 대량 다운로드가 실행 중이지 않은지 확인하고 같은 방법으로 비교하세요. 테스트에 실패했다고 바로 서버를 삭제할 필요도 없습니다. ICMP, TCP 탐색과 실제 프로토콜 연결은 서로 다른 과정을 거치므로 일부 서버는 특정 탐색에 응답하지 않아도 정상 연결을 수립할 수 있습니다.

Android에서는 v2rayNG와 v2flyNG의 인터페이스 구성이 데스크톱과 다르지만 원칙은 같습니다. 구독 출처를 독립적으로 유지하고, 업데이트 전에 대상 그룹을 확인하며, 업데이트 후 현재 선택한 설정이 계속 존재하는지 점검하세요. 모바일에서는 시스템 백그라운드 제한도 주의해야 합니다. 구독 업데이트 중단과 백그라운드 연결 중지는 서로 다른 문제입니다. VpnService 권한과 배터리 절전 예외 목록은 v2rayNG Android 사용 팁에서 더 확인할 수 있습니다.

주 사용, 예비, 실험 출처를 분리하기

다중 구독 관리의 핵심은 구독을 많이 추가하는 것이 아니라 서로 다른 출처가 덮어쓰지 않도록 하는 것입니다. 최소한 주 사용, 예비, 실험의 세 가지 역할로 나누는 것이 좋습니다. 주 사용 구독은 일상 연결을 담당하므로 변경 빈도를 가장 낮게 유지합니다. 예비 구독은 주 사용 출처에 문제가 생겼을 때만 활성화하고, 실험 구독은 새 프로토콜이나 임시 설정을 관찰하는 용도로 사용하며 일상 서버 목록에 바로 섞지 않습니다. 역할을 정한 뒤 업데이트, 필터링과 삭제는 그룹 단위로 진행하세요.

각 구독에는 안정적인 이름과 분명한 용도가 있어야 합니다. 그룹 이름에 출처 약칭과 역할을 적을 수 있지만 접속 자격 증명, 전체 링크 또는 기타 민감한 정보는 기록하지 마세요. 구독 링크는 클라이언트의 구독 설정에만 보관하고 스크린샷, 공개 로그나 공유 설정 예시에 복사하지 않아야 합니다. 기기를 옮길 때는 로컬 상태, 과거 로그와 인터페이스 설정이 포함된 전체 데이터 폴더를 복사하기보다 새 기기에서 구독을 다시 추가하는 편이 안전합니다.

업데이트 계획은 출처의 안정성을 고려해야 합니다. 자주 수동 새로 고침을 해도 회선 자체가 빨라지지는 않으며, 오히려 원본 서비스가 잠시 불안정할 때 기존 결과를 덮어쓸 수 있습니다. 일상적으로는 주 사용 구독 하나를 먼저 업데이트하고 반환 내용이 정상인지 확인한 뒤 다른 그룹을 업데이트하세요. 클라이언트가 업데이트 전 내용을 보존하는 기능을 지원한다면 실패 보호를 켜세요. 해당 옵션이 없다면 중요한 변경 전에 구독 자격 증명을 제외한 로컬 서버 설정을 내보내거나 현재 사용 가능한 항목을 기록하세요.

동일 이름, 이름 변경 및 출처 이전 처리

구독 제공업체가 이름 규칙을 바꾸면 즐겨찾기, 필터 표현식과 수동 메모가 작동하지 않을 수 있습니다. 표시 이름만 보지 말고 주소, 포트, 프로토콜과 전송 조합처럼 안정적인 필드로 서버를 다시 식별하세요. 같은 연결 설정임을 확인한 뒤 필터 조건을 업데이트합니다. 출처 전체가 새 구독 링크로 이전했다면 새 링크를 새 그룹으로 추가하고 한 번 업데이트한 뒤 서버가 사용 가능한지 확인하세요. 그 후 기존 그룹을 비활성화하면 교체 과정에서 되돌릴 수 있는 경로를 잃지 않습니다.

같은 연결이 여러 그룹에서 제공되더라도 즉시 중복으로 간주하지 않는 것이 좋습니다. 구독마다 업데이트 주기, 세부 매개변수 또는 사용 범위가 다를 수 있습니다. 먼저 이름 필터에서 중복 항목을 숨기고 여러 차례 업데이트를 통해 내용이 계속 같은지 확인한 뒤 출처를 제거할지 결정하세요. 구독 설정을 삭제하기 전에는 “구독 진입점 삭제”와 “가져온 서버 삭제”를 구분해야 합니다. 일부 클라이언트는 두 작업을 পৃথ개로 처리합니다.

일괄 작업 전에 먼저 그룹을 제한하세요. 일괄 속도 측정, 삭제와 수정은 다른 출처에 영향을 주기 쉽습니다. 특히 필터가 적용된 상태에서는 화면에 보이는 범위가 실제 작업 범위와 다를 수 있습니다. 실행 전 현재 그룹, 필터 조건과 선택 수를 명확히 확인하세요. 구독의 경로, 호스트 이름, TLS, REALITY 공개 키와 짧은 식별자는 서버 측 대응 관계가 있으므로 전송 매개변수의 일괄 수정은 일반적으로 권장하지 않습니다. 이름이 비슷하다는 이유만으로 서로 바꿀 수 없습니다.

유지 관리 가능한 변경 기록 만들기

다중 구독 환경에서는 복잡한 백업보다 간단한 변경 기록이 더 실용적입니다. 매번 날짜, 수정한 모듈, 수정 전 상태, 수정 후 상태와 검증 결과만 기록하세요. 예를 들어 “주 사용 그룹의 지역 필터를 활성화했으며 라우팅은 변경하지 않음. 브라우저와 데스크톱 프로그램 연결 정상”처럼 적으면 됩니다. 문제가 발생했을 때 영향 범위가 컸던 마지막 변경을 빠르게 찾을 수 있습니다. 기록에는 전체 구독 링크, 서버 키 또는 그대로 재사용할 수 있는 인증 필드를 저장하지 마세요.

서버 목록이 갑자기 늘거나 줄었다면 먼저 각 그룹의 업데이트 시간과 반환 상태를 비교한 뒤 필터 조건을 확인하세요. 한 출처만 문제가 있다면 해당 출처의 자동 업데이트를 일시 중지하고 전체 설정을 즉시 다시 만들지 마세요. 모든 출처가 업데이트되지 않지만 기존 서버는 연결된다면 구독 요청, 시스템 프록시 또는 DNS 경로 문제일 가능성이 큽니다. 업데이트는 정상인데 모든 서버가 동시에 연결되지 않는다면 로컬 네트워크, 활성 아웃바운드와 시스템 시간을 추가로 확인하세요.

입구, 조건과 출구부터 이해하기

라우팅 규칙은 세 가지 질문에 답합니다. 트래픽이 어느 입구로 들어오는지, 어떤 조건을 만족하는지, 최종적으로 어느 출구로 전달되는지입니다. 자주 사용하는 조건에는 도메인, IP, 대상 포트, 네트워크 유형, 인바운드 태그와 프로세스 정보가 있습니다. 출구에는 일반적으로 프록시, 직접 연결과 차단이 포함됩니다. 클라이언트는 규칙을 위에서 아래로 읽고 처음 매칭된 결과로 출구를 결정하므로, 더 구체적인 규칙을 앞에 두고 포괄적인 기본 규칙을 뒤에 배치해야 합니다.

도메인 규칙은 커널이 도메인을 얻을 수 있을 때만 적용됩니다. 애플리케이션이 먼저 로컬에서 해석한 뒤 프록시에 IP만 전달한다면 단순한 도메인 규칙이 매칭되지 않을 수 있습니다. 반대로 IP 규칙에는 해석 결과나 직접 지정한 IP 대상이 필요합니다. domainStrategy는 라우팅 모듈이 도메인에 대해 IP 판단을 보완할지, 보완한다면 언제 수행할지를 결정합니다. 일반적인 방법은 먼저 도메인 규칙을 사용하고 IP 규칙 매칭이 필요할 때 해석하는 것입니다. 항상 IP만 기준으로 처리하도록 설정하면 일부 도메인 규칙의 가독성과 제어력이 떨어집니다.

규칙 설계는 많은 목록을 쌓기보다 업무 목적에서 시작해야 합니다. 먼저 반드시 직접 연결할 로컬 주소와 LAN을 정리하고, 그다음 명확하게 프록시가 필요한 도메인 그룹을 작성합니다. 이어서 특정 IP 범위를 처리하고 마지막에 기본 출구를 설정하세요. 차단 규칙은 연결을 만들 필요가 없는 대상이나 프로토콜 유형에만 사용합니다. 규칙이 많을수록 이름, 주석과 순서를 안정적으로 유지해야 나중에 특정 트래픽이 왜 특정 출구에 매칭되었는지 판단할 수 있습니다.

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

domain:은 일반적으로 지정한 도메인과 하위 도메인을 매칭하고, full:은 완전한 도메인 매칭에 사용됩니다. 일반 문자열 규칙의 구체적인 의미는 커널 형식에 따라 다릅니다. 명확한 단일 호스트에는 완전 일치를 우선 사용하고, 하나의 서비스에 속한 여러 하위 도메인에는 도메인 접미사 매칭을 사용하세요. 예를 들어 흔한 단어 하나만 입력하는 식의 지나치게 짧은 키워드로 광범위하게 매칭하지 마세요.

간단한 3단계 구조에서 점진적으로 확장하기

첫 단계에서는 “사설 주소는 직접 연결, 명확한 도메인은 프록시, 나머지는 기본 출구”의 세 단계만 유지하세요. 결과를 확인한 뒤 직접 연결할 업무 도메인이나 특정 UDP 처리를 추가합니다. 클라이언트가 사전 정의 라우팅 방식을 제공한다면 먼저 복사본을 만든 뒤 수정하고, 유일한 설정을 반복해서 덮어쓰지 마세요. 각 규칙에는 명확한 검증 목표가 있어야 합니다. 예를 들어 완전한 도메인 규칙을 하나 추가했다면 해당 도메인과 영향을 받지 않아야 하는 비교 도메인 하나만 테스트합니다.

프로세스 라우팅은 클라이언트, 커널과 운영체제의 기능에 의존하므로 모든 플랫폼에서 동일한 기본 규칙으로 사용할 수 없습니다. 프로세스 이름도 설치 방식이나 하위 프로세스 구조에 따라 달라질 수 있습니다. 애플리케이션이 자체적으로 프록시를 설정할 수 있다면 먼저 앱 안에서 명확히 설정하세요. 프록시를 읽지 않는 앱을 가로채야 할 때 TUN과 프로세스 조건을 검토합니다. Android의 앱별 프록시는 시스템 VPN이 가로채는 범위에 속하며 데스크톱의 프로세스 라우팅과 같은 구현이 아닙니다.

포트 규칙은 프로토콜이 명확한 경우에 적합하지만 “자주 쓰이는 포트”만으로 업무를 추측해서는 안 됩니다. 최신 애플리케이션은 443을 재사용하거나 동적 포트를 사용할 수 있어 포트만으로 서비스를 정확히 구분하기 어렵습니다. UDP도 무조건 차단해서는 안 됩니다. DNS, 실시간 통신과 일부 전송에서 UDP를 사용하기 때문입니다. 어떤 규칙 때문에 웹페이지는 열리지만 미디어, 음성 또는 로그인 기능에 문제가 생긴다면 UDP, QUIC 또는 관련 도메인을 잘못 처리했는지 확인하세요.

라우팅이 적용되었는지 판단할 때 출구 IP만 보지 마세요. 커널 로그의 대상, 규칙 조건과 아웃바운드 태그를 함께 확인하는 방법이 더 정확합니다. 로그에 대상이 잘못된 출구로 들어간 것으로 나타나면 규칙 순서와 태그를 확인하세요. 관련 연결 기록 자체가 없다면 트래픽이 해당 인바운드로 들어오지 않았을 수 있습니다. IP만 보이고 도메인이 보이지 않는다면 애플리케이션의 해석 방식, 스니핑 설정 또는 FakeDNS 경로를 추가로 확인해야 합니다. 라우팅과 DNS는 밀접하게 연결되어 있으므로 현재 라우팅이 안정된 뒤 다음 장을 진행하세요.

도메인을 실제로 해석하는 주체 확인하기

DNS 설정의 첫 단계는 서버를 바로 바꾸는 것이 아니라 해석이 어디에서 발생하는지 확인하는 것입니다. 브라우저가 자체 암호화 DNS를 사용할 수도 있고, 운영체제에는 시스템 리졸버가 있으며, 클라이언트 커널에도 독립 DNS를 설정할 수 있습니다. 세 경로가 동시에 존재하면 실제 요청이 방금 수정한 계층을 우회할 수 있습니다. 문제를 확인할 때는 일시적으로 경로를 통일하세요. 브라우저의 독립 해석을 끄거나 상태를 명확히 기록하고 테스트 도메인이 클라이언트 커널로 들어가게 한 뒤 로그에서 조회와 반환 결과를 관찰합니다.

DNS 문제는 보통 도메인이 열리지 않거나 직접 IP로는 연결되며, 같은 도메인의 결과가 앱마다 다르게 나타나는 방식으로 드러납니다. 연결 시간 초과가 항상 DNS 문제를 의미하지는 않습니다. 도메인이 올바르게 해석되었지만 대상 연결이 TLS 또는 전송 단계에서 실패했다면 서버와 라우팅을 계속 확인해야 합니다. 반대로 주소가 반환되었다고 해서 현재 네트워크에 적합하다는 뜻도 아닙니다. 캐시, 잘못된 상위 서버 또는 분기 경로 때문에 예상하지 않은 주소로 연결될 수 있습니다.

상위 DNS는 목적별로 나누는 것이 좋으며 여러 주소를 순서 없이 목록에 넣지 마세요. 시스템 DNS는 LAN 호스트와 로컬 네트워크 관련 도메인을 처리하고, 지정한 일반 DNS 또는 DoH는 그 밖의 조회를 처리할 수 있습니다. 도메인별로 상위 서버를 배정해야 한다면 각 서버의 domains 범위를 명확하게 설정하세요. DNS 조회 자체에도 올바른 출구가 필요합니다. 직접 연결 상위 서버는 직접 연결 출구를 통해 접근하고, 프록시가 필요한 상위 서버는 라우팅 규칙으로 프록시 출구에 보내야 합니다.

{
  "dns": {
    "queryStrategy": "UseIP",
    "servers": [
      {
        "address": "https://dns.example.com/dns-query",
        "domains": [
          "domain:example.net"
        ],
        "skipFallback": true
      },
      "localhost"
    ]
  }
}

예시의 도메인은 구조 설명용일 뿐이므로 실제 설정에서는 사용 가능한 DNS 서비스 주소로 바꿔야 합니다. queryStrategy는 IPv4, IPv6 또는 양쪽을 조회할지 결정하며 현재 네트워크 성능과 맞아야 합니다. 안정적인 IPv6 경로가 없는데 IPv6 주소를 우선 반환하면 앱이 실패를 기다린 뒤 폴백하면서 첫 연결이 느려질 수 있습니다. 특정 주소 유형을 무조건 비활성화하는 것도 정답은 아닙니다. 먼저 시스템에 사용 가능한 경로가 있는지 확인한 뒤 조회 전략을 결정하세요.

라우팅별 해석, 캐시와 폴백의 관계

라우팅별 해석의 목표는 도메인마다 적합한 상위 서버를 사용하고 올바른 출구로 요청을 보내는 것입니다. 도메인 규칙은 가능한 한 정확하게 작성해 같은 도메인이 여러 겹치는 범위에 동시에 들어가지 않도록 하세요. 폴백 서버는 기본 매칭에서 결과를 얻지 못했거나 설정상 추가 조회가 허용된 경우에 사용하며, 무작위 부하 분산 용도로 보면 안 됩니다. skipFallback을 설정했다면 해당 도메인이 정말 현재 상위 서버에서만 처리 가능한지 확인하세요. 그렇지 않으면 기본 상위 서버가 잠시 실패해도 다른 서버로 자동 전환되지 않습니다.

캐시 때문에 설정을 바꿔도 결과가 그대로인 것처럼 보일 수 있습니다. 커널, 운영체제와 브라우저가 각각 DNS를 캐시할 수 있습니다. 설정을 수정한 뒤 먼저 커널을 재시작하거나 다시 불러오고, 시스템과 앱 수준의 캐시를 정리한 다음 최근에 접속하지 않은 하위 도메인으로 비교하세요. 짧은 시간에 여러 상위 서버를 반복 전환하면서 같은 도메인 하나만 테스트하면 새 결과와 기존 캐시를 구분하기 어렵습니다.

DoH는 DNS 조회를 HTTPS 연결 안에 넣어 전송 방식을 통일할 수 있지만, DoH 서버의 도메인 자체는 여전히 해석해야 하므로 초기 해석 문제가 생깁니다. 일반적인 방법은 DoH 서비스에 직접 도달할 수 있는 부트스트랩 주소를 준비하거나 시스템 리졸버로 해당 호스트를 먼저 해석하는 것입니다. 라우팅이 DoH 호스트를 동일한 DNS에 의존하는 순환 경로로 보내면 커널이 조회를 기다리는 상태가 될 수 있습니다. DNS 서버 주소, 라우팅 규칙과 아웃바운드 태그 사이에 재귀 의존성이 있는지 확인하세요.

중국 본토와 해외의 라우팅별 DNS 해석, DoH와 오염 문제를 더 자세히 확인하려면 V2Ray DNS 설정 해설을 읽어 보세요. 실제 변경은 현재 네트워크와 커널 로그를 기준으로 해야 하며, 하나의 상위 서버 주소 목록을 모든 기기에 그대로 복사해서는 안 됩니다. 데스크톱 광대역, 모바일 네트워크와 기업 네트워크는 해석 제한이 다르므로 안정적인 구성은 서버 수보다 명확한 역할 분담에서 나오는 경우가 많습니다.

TUN과 시스템 프록시는 서로 다른 문제를 해결합니다

시스템 프록시는 애플리케이션이 프록시 설정을 직접 읽어야 하므로 브라우저와 운영체제 프록시를 따르는 대부분의 데스크톱 소프트웨어에 적합합니다. TUN 모드는 가상 네트워크 인터페이스를 통해 더 넓은 범위의 IP 트래픽을 받아 시스템 프록시를 읽지 않는 프로그램까지 처리할 수 있습니다. 두 방식은 단순한 “일반 모드”와 “강화 모드”가 아니라 서로 다른 연결 방식입니다. 브라우저 프록시만 필요하다면 시스템 프록시가 관리하기 쉽고, 독립 네트워크 스택, 게임 런처 또는 명령줄 프로그램을 처리해야 할 때 TUN을 검토하세요.

TUN을 켜기 전에 일반 시스템 프록시가 안정적이고 현재 서버가 정상적으로 연결되며 DNS와 라우팅 규칙도 단독으로 작동하는지 확인하세요. 그다음 충돌할 수 있는 다른 가상 네트워크 카드 소프트웨어를 끄고 시스템의 기존 기본 라우팅과 DNS 상태를 기록합니다. v2rayN에서 TUN을 활성화하려면 가상 인터페이스 생성, 라우팅 설정과 DNS 변경을 위해 운영체제 권한이 필요할 수 있습니다. 권한이 거부되면 인터페이스 스위치는 바뀌었어도 가상 인터페이스가 실제로 생성되지 않을 수 있으므로 클라이언트 상태와 시스템 네트워크 인터페이스를 함께 확인해야 합니다.

TUN은 네트워크 계층의 트래픽을 받지만 커널이 이를 변환해 라우팅과 아웃바운드로 전달해야 합니다. 일반적인 설정에는 인터페이스 주소, MTU, 자동 라우팅, 엄격한 라우팅과 프로토콜 스택 구현이 포함됩니다. 자동 라우팅은 대상 트래픽을 가상 인터페이스로 보내고, 엄격한 라우팅은 우회 경로를 줄이지만 LAN, 컨테이너와 가상 머신 네트워크에 영향을 줄 수 있습니다. 처음 활성화할 때는 기본 매개변수를 유지하고 명확한 호환성 문제가 발견될 때만 조정하세요.

LAN, 가상 머신 및 컨테이너 처리

LAN 주소는 일반적으로 직접 연결해야 하며 포괄적인 프록시 규칙보다 앞에 배치해야 합니다. 그렇지 않으면 프린터, 라우터 관리 페이지, 파일 공유 또는 로컬 개발 서비스가 프록시 출구로 전송될 수 있습니다. 일반적인 사설 주소 범위는 커널이 제공하는 geoip:private 규칙으로 처리할 수 있지만, 로컬에서 사용하는 특수 네트워크 대역, 가상 머신 브리지 대역과 컨테이너 네트워크도 확인해야 합니다. 기업 네트워크는 추가 내부 주소와 도메인을 사용할 수 있으므로 실제 환경에 맞게 추가하세요.

가상 머신이 NAT, 브리지 또는 호스트 전용 네트워크를 사용하면 트래픽 입구와 출발지 주소가 달라집니다. 호스트의 TUN이 브리지 가상 머신의 모든 트래픽을 자동으로 가로채는 것은 아니며, 컨테이너 트래픽이 데스크톱 앱과 같은 경로를 따른다고 가정해서도 안 됩니다. 먼저 호스트에서 테스트한 다음 가상 환경 내부에서 DNS, 기본 라우팅과 출구를 테스트하세요. 가상 환경에서만 실패한다면 호스트 라우팅 규칙을 바로 확대하지 말고 해당 환경의 네트워크 설정을 확인해야 합니다.

MTU가 적절하지 않으면 작은 페이지는 열리지만 대용량 파일, 이미지 또는 TLS 핸드셰이크가 특정 단계에서 멈추는 현상이 나타날 수 있습니다. 연결이 느리다고 바로 MTU를 낮추지 마세요. 문제가 TUN에서만 발생하는지, 특정 네트워크와 관련 있는지 먼저 확인한 뒤 변경 폭을 작게 유지하며 단계적으로 조정하세요. 수정 후에는 웹페이지, 다운로드와 UDP 앱을 테스트하고 단일 사이트만 확인하지 마세요.

Windows에서 인터페이스와 라우팅 확인
ipconfig /all
route print

macOS에서 인터페이스와 기본 라우팅 확인
ifconfig
route -n get default

Linux에서 주소와 라우팅 확인
ip address
ip route

이 명령은 시스템 상태를 관찰하기 위한 것이며 설정을 직접 복구하지는 않습니다. 가상 인터페이스가 존재하는지, 기본 라우팅이 예상과 맞는지, LAN 경로에 계속 도달할 수 있는지, TUN을 끈 뒤 관련 항목이 복구되는지를 확인하세요. 용도를 모르는 상태에서 라우팅 테이블 전체를 수동으로 삭제하지 마세요. 클라이언트를 중지한 뒤에도 네트워크가 이상하면 먼저 클라이언트를 완전히 종료하고 현재 네트워크에 다시 연결한 뒤 남은 인터페이스와 DNS를 확인하세요.

트래픽 순환과 제어 연결 가로채기 방지

TUN에서 가장 중요한 경계는 프록시 프로세스 자체와 서버 연결을 우회하는 것입니다. 프록시 서버로 연결하는 트래픽이 다시 TUN으로 들어가 동일한 프록시 아웃바운드로 라우팅되면 순환이 발생합니다. 일반적인 클라이언트는 서버 주소, 프로세스 또는 인터페이스 우회를 자동으로 처리하지만 사용자 지정 규칙이 이 보호를 깨뜨릴 수 있습니다. 시작 직후 연결이 끊기거나 로그에 같은 대상에 대한 연결이 반복되고 트래픽이 빠르게 누적되면 먼저 순환 여부를 확인하세요.

DNS도 비슷한 순환을 만들 수 있습니다. TUN이 DNS 요청을 커널로 보내고, 커널이 DoH 서버에 접근할 때 아직 완료되지 않은 해석에 다시 의존하는 경우입니다. 부트스트랩 해석, DNS 출구와 TUN 제외 범위를 명확히 설정하세요. 호환성을 높이기 위해 여러 시스템 VPN 또는 투명 가로채기 도구를 동시에 켜지 마세요. 기본 라우팅, DNS와 가상 인터페이스를 서로 차지하려 하므로 결과가 불안정해집니다.

Android의 VpnService도 시스템 수준의 가로채기를 설정하지만 조작 방식, 권한 모델과 데스크톱 TUN은 완전히 같지 않습니다. v2rayNG 또는 v2flyNG로 처음 연결할 때 시스템 권한을 승인하고 필요에 따라 앱별 프록시를 설정해야 합니다. 백그라운드에서 자주 중지된다면 데스크톱 TUN 매개변수를 바꾸기보다 배터리 절전 정책을 확인하세요.

도메인에 가상 주소를 할당하는 이유

일부 애플리케이션은 먼저 스스로 도메인을 해석한 뒤 대상 IP만 시스템 네트워크에 전달합니다. TUN에 들어오면 커널이 보는 것은 IP이고 원래 도메인은 이미 사라져 도메인 기반 라우팅 규칙이 매칭되기 어렵습니다. FakeDNS는 조회 결과로 가상 주소를 반환하는 동시에 “가상 주소와 원래 도메인”의 매핑을 저장합니다. 앱이 이 가상 주소에 연결하면 트래픽이 TUN으로 회수되고, 커널은 원래 도메인을 복원한 뒤 도메인 라우팅을 실행합니다.

따라서 FakeDNS는 일반 공용 DNS를 대체하지 않으며 단독으로 켠다고 작동하는 가속 기능도 아닙니다. 전체 경로에는 최소한 앱의 조회가 커널 DNS로 들어가고, FakeDNS가 가상 주소를 반환하며, 앱이 연결을 시작하고, 연결이 제어되는 인바운드로 들어가고, 커널이 가상 주소를 식별해 도메인을 복원하고, 라우팅이 실제 아웃바운드를 선택하며, 아웃바운드 측에서 실제 해석 또는 연결을 완료하는 단계가 포함됩니다. 어느 한 단계라도 클라이언트를 우회하면 가상 주소를 복원하지 못하거나 도메인 규칙이 작동하지 않습니다.

활성화하기 전에 TUN과 일반 DNS가 각각 안정적으로 작동하도록 해야 합니다. 그다음 LAN, 가상 머신, 컨테이너와 기업 네트워크와 충돌하지 않는 가상 주소 풀을 선택하세요. 주소 풀은 로컬 매핑에만 사용하며 실제 네트워크로 전송해서는 안 됩니다. 라우팅이 가상 주소를 잘못 직접 연결하면 앱이 계속 시간 초과를 일으킬 수 있습니다. 주소 풀의 용량은 활성 도메인 수를 감당해야 하지만 기존 네트워크와 겹칠 정도로 무리하게 확장할 필요는 없습니다.

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

198.18.0.0/15는 벤치마크 테스트 네트워크에 자주 사용되며 가상 주소 풀의 예시로 쓸 수 있지만, 현재 네트워크가 해당 범위를 이미 사용 중인지 확인해야 합니다. 설정 필드는 커널 설정 방식에 따라 달라질 수 있으므로 클라이언트가 생성한 구조를 바탕으로 하고, 호환되지 않는 설정에 조각을 그대로 교체하지 마세요. FakeDNS는 DNS 서버 순서와도 관련이 있습니다. 모든 도메인이 가상 주소를 반환해야 하는 것은 아니며, 로컬 도메인, LAN 호스트와 실제 IP가 필요한 앱은 일반 해석을 유지할 수 있습니다.

가상 주소 누출과 매핑 실패 식별하기

앱이 가상 주소를 받은 뒤 연결이 TUN으로 들어가지 않고 시스템에서 물리 네트워크로 직접 전송되면 가상 주소 누출이 발생합니다. 도메인 해석은 성공한 것처럼 보이지만 연결이 계속 시간 초과되고 커널 로그에서도 해당 요청을 찾을 수 없는 경우가 많습니다. 이때 상위 DNS를 계속 바꾸지 말고 앱이 TUN에 의해 가로채지는지, 앱별 규칙에서 제외되지 않았는지, 자동 라우팅이 작동하는지, 가상 주소 대역을 다른 라우팅이 먼저 처리하지 않는지 확인하세요.

커널 재시작, 캐시 유지 또는 주소 풀 재사용 후 매핑이 실패할 수 있습니다. 앱은 이전 가상 주소를 계속 캐시하지만 새 커널에는 기존 매핑이 없어 도메인을 복원할 수 없습니다. 설정을 다시 불러오고 앱과 시스템 DNS 캐시를 정리해 앱이 다시 조회하도록 하세요. 장시간 실행한 뒤에만 문제가 발생한다면 주소 풀 용량, 캐시 수명과 단기간 도메인 요청이 과도하게 발생하는지도 확인해야 합니다.

일부 앱은 반환 주소를 검증하거나 내장 DNS를 사용하고, 고정 IP에 직접 연결하거나 앱 내부에서 암호화된 해석 경로를 만들기도 합니다. 이러한 트래픽은 FakeDNS에 적합하지 않을 수 있습니다. 특정 앱 하나에서만 문제가 발생한다면 먼저 해당 앱을 FakeDNS 테스트 범위에서 제외하고 실제 해석을 사용한 뒤 IP 또는 프로세스 규칙으로 처리해 보세요. 특수한 앱 하나 때문에 모든 도메인을 더 복잡한 경로로 바꾸지는 마세요.

FakeDNS를 활성화할 가치가 있는지는 TUN 환경에서 도메인 정보를 유지해야 하는지에 달려 있습니다. 일반 시스템 프록시가 이미 도메인을 전달할 수 있다면 추가로 켜도 뚜렷한 이점이 없는 경우가 많습니다. 설정을 마친 뒤에는 LAN 호스트, 자주 사용하는 웹페이지, 장시간 연결과 절전 모드 복귀를 테스트해 가상 매핑이 실제 로컬 해석에 영향을 주지 않는지 확인하세요. 기능 수보다 안정성이 우선입니다.

직접 연결, 차단과 로컬 프록시부터 시작하기

사용자 지정 아웃바운드는 트래픽이 커널을 빠져나가는 방식을 설명합니다. 가장 기본적인 설정에는 프록시 아웃바운드, 직접 연결 아웃바운드와 차단 아웃바운드가 포함됩니다. 구독 서버에서 생성된 프록시 아웃바운드는 클라이언트가 관리하므로 로컬 규칙에서는 태그로 참조하기만 하면 됩니다. 아웃바운드를 추가할 때는 태그가 고유하고 의미가 분명해야 하며 클라이언트가 자동 생성하는 태그와 충돌하지 않도록 하세요. direct, block, local-socks처럼 역할을 나타내는 이름을 사용하고 “회선 1”, “임시 2”처럼 장기적으로 이해하기 어려운 태그는 피하는 것이 좋습니다.

직접 연결 아웃바운드는 트래픽을 로컬 네트워크로 전달하며 시스템 라우팅과 DNS 기능의 영향을 받습니다. 차단 아웃바운드는 매칭된 트래픽을 명시적으로 거부합니다. 로컬 SOCKS 아웃바운드는 로컬 또는 신뢰할 수 있는 LAN에서 실행 중인 다른 프록시 서비스로 트래픽을 전달할 수 있습니다. 사용자 지정 체인 출구는 장애 지점을 늘리므로 상위 역할이 명확하고 각각 독립적으로 검증할 수 있을 때만 사용하세요. 일반 구독 서버로 충분하다면 여러 단계의 전달을 추가할 필요가 없습니다.

{
  "outbounds": [
    {
      "protocol": "freedom",
      "tag": "direct"
    },
    {
      "protocol": "blackhole",
      "tag": "block"
    },
    {
      "protocol": "socks",
      "tag": "local-socks",
      "settings": {
        "servers": [
          {
            "address": "127.0.0.1",
            "port": 1081
          }
        ]
      }
    }
  ]
}

예시의 로컬 포트는 다른 SOCKS 서비스가 실제로 127.0.0.1:1081에서 수신 중일 때만 사용할 수 있습니다. 추가한 뒤 먼저 포트가 수신 중인지 확인하고, 테스트 도메인 하나만 매칭하는 라우팅 규칙을 작성해 local-socks로 보내세요. 기본 트래픽 전체를 곧바로 이 경로로 전환하면 상위 서비스가 실행되지 않을 때 모든 연결이 실패해 규칙 문제인지 상위 서비스 문제인지도 판단하기 어렵습니다.

아웃바운드 경로의 DNS와 순환 이해하기

사용자 지정 아웃바운드가 도메인에 접근할 때도 해석이 필요합니다. 로컬 시스템, 커널 DNS와 상위 프록시 중 누가 해석하는지 확인하세요. 상위 프록시가 도메인을 해석하게 하려면 도메인 형식을 유지하고 원격 해석을 지원하는 연결 방식을 사용해야 합니다. 커널이 먼저 해석한다면 라우팅과 DNS 전략이 반환 주소에 영향을 줍니다. 이 내용을 설정 설명에 기록하면 “라우팅은 올바른 태그에 매칭되었지만 잘못된 주소로 연결되는” 상황을 예방할 수 있습니다.

로컬 체인 프록시는 특히 순환이 발생하기 쉽습니다. 예를 들어 v2rayN의 아웃바운드가 로컬 1081을 가리키는데 1081을 같은 설정의 인바운드가 사용하거나, 상위 프로그램의 트래픽이 다시 TUN에 잡혀 현재 아웃바운드로 되돌아오는 경우입니다. 문제를 확인할 때 포트를 소유한 프로세스, 인바운드 수신 주소와 TUN 우회 범위를 확인하세요. 하나의 포트는 하나의 프로세스만 안정적으로 수신해야 하며 인바운드와 아웃바운드 대상이 폐쇄 루프를 만들면 안 됩니다.

서버 아웃바운드의 프로토콜, 전송, TLS와 REALITY 매개변수는 실제 서버 설정 또는 구독 내용에서 가져와야 합니다. 프로토콜 이름만 보고 매개변수를 조합해서는 안 됩니다. VLESS, VMess, Trojan 등은 인증과 전송 구성의 서로 다른 계층을 담당하며 WebSocket, gRPC, TCP 등의 전송에는 경로, 서비스 이름 또는 호스트 정보가 포함될 수 있습니다. REALITY와 XTLS Vision의 관계는 REALITY와 XTLS Vision 원리 해설을 참고할 수 있지만, 설정값은 여전히 서버 측과 항목별로 일치해야 합니다.

“입구—해석—라우팅—출구” 순서로 장애 위치 찾기

체계적인 문제 해결은 항상 트래픽 방향을 따라야 합니다. 첫째 입구를 확인합니다. 앱이 시스템 프록시를 읽는지, 트래픽이 TUN으로 들어가는지 확인하세요. 둘째 해석을 확인합니다. 로그에 도메인이 남아 있는지, DNS가 사용 가능한 결과를 반환하는지 봅니다. 셋째 라우팅을 확인합니다. 대상이 어느 규칙과 아웃바운드 태그에 매칭되었는지 확인하세요. 넷째 출구를 확인합니다. 상위 주소, 포트, 프로토콜과 전송으로 연결을 수립할 수 있는지 점검합니다. 입구가 가로채지 못하는 상태에서 서버만 반복해서 바꿔도 현상은 달라지지 않으므로 마지막 단계부터 시작하지 마세요.

커널이 시작되지 않으면 먼저 최근에 정상 작동한 설정으로 되돌리고 JSON 문법, 태그 참조, 포트 충돌과 권한을 확인하세요. 시작은 되지만 연결 기록이 없다면 시스템 프록시, TUN과 앱 설정을 중점적으로 확인합니다. 연결 기록은 있지만 규칙이 잘못되었다면 일단 3단계 라우팅으로 줄이세요. 규칙은 올바른데 DNS가 실패한다면 단순한 상위 서버로 전환하고 FakeDNS를 끄세요. 해석과 라우팅이 모두 정상인데 아웃바운드가 실패하면 서버 설정, 시스템 시간과 로컬 네트워크를 다시 확인합니다.

문제 해결이 끝나면 임시 로그 수준, 테스트 규칙과 테스트 아웃바운드를 일상 설정으로 되돌리세요. 기준선 하나, 현재 사용하는 구성 하나와 간단한 변경 기록만 보관하면 충분하며 거의 같은 설정 사본을 장기간 쌓아 둘 필요는 없습니다. 클라이언트를 다시 선택하거나 플랫폼에 맞는 버전을 설치해야 한다면 클라이언트 다운로드 페이지로 이동하세요. 데스크톱에서는 v2rayN을 우선 사용하고, Android에서는 커널 요구 사항에 따라 v2rayNG 또는 v2flyNG를 선택할 수 있습니다.