v2rayN 고급 설정 가이드: 구독, 라우팅, DNS 및 TUN

설정 모델과 되돌릴 수 있는 변경 방법

먼저 네 가지 설정 계층을 구분하세요

v2rayN의 화면 설정은 최종적으로 코어 실행 설정으로 조합됩니다. 문제를 진단하기 전에는 서버, 구독, 클라이언트 동작과 코어 설정이라는 네 계층을 먼저 구분해야 합니다. 서버 기록에는 주소, 포트, 사용자 식별자, 전송 방식과 보안 매개변수가 포함됩니다. 구독은 서버 기록을 일괄 제공하고 갱신합니다. 클라이언트 동작에는 시스템 프록시, 트레이 작업, 자동 업데이트와 화면 필터가 포함됩니다. 코어 설정은 인바운드 리스닝, DNS, 라우팅과 아웃바운드를 처리합니다. 어떤 노드가 지연 시간 테스트를 통과했다고 해서 시스템 프록시, DNS 또는 라우팅까지 반드시 올바른 것은 아닙니다. 이 단계들은 노드 연결 외부에 있기 때문입니다.

그래픽 인터페이스의 “현재 서버”는 보통 기본 프록시 아웃바운드의 출처일 뿐입니다. 라우팅 규칙은 일부 요청을 직접 연결이나 차단 아웃바운드로 보낼 수 있고, TUN은 원래 시스템 프록시를 사용하지 않는 프로그램의 트래픽까지 인계할 수 있습니다. 따라서 설정이 적용되었는지 판단할 때 노드 색상이나 트레이 아이콘 변화만 봐서는 안 됩니다. 클라이언트 실행 상태, 프록시 모드, 대상 프로그램의 연결 방식과 규칙 일치 결과를 함께 확인해야 합니다.

최소 사용 가능 기준선 만들기

고급 조정을 시작하기 전에 반복 검증할 수 있는 기준선을 만드세요. 연결 가능한 것으로 확인된 서버 하나를 남기고, 라우팅을 단순한 규칙으로 되돌린 다음 TUN과 FakeDNS를 잠시 끄고 시스템 프록시만 활성화합니다. 이후 브라우저로 일반 HTTPS 페이지에 접속합니다. 이 상태가 작동하면 “구독 필터 → 라우팅 → DNS → TUN → FakeDNS” 순서로 설정을 한 계층씩 추가하세요. 한 번에 하나의 계층만 변경하고 변경 직후 다시 테스트하면 원인 범위를 크게 줄일 수 있습니다.

매번 네 가지를 기록하는 것이 좋습니다. 무엇을 변경했는지, 변경 전 값, 예상 결과와 실제 결과입니다. 복잡한 도구는 필요 없고 로컬 텍스트 한 단락이면 충분합니다. 연결할 수 없을 때는 노드 전환, DNS 변경, 클라이언트 재설치와 시스템 네트워크 정리를 동시에 하기보다 마지막 변경부터 되돌리세요. 여러 작업을 한꺼번에 수행하면 재현성이 사라지고 실제 원인도 확인할 수 없습니다.

생성된 설정과 수동 작성 설정의 경계 이해하기

v2rayN은 화면에서 일반적인 매개변수를 관리하기에 적합하며, 화면에서 생성한 설정은 서버를 전환할 때 자동으로 갱신하기도 쉽습니다. 수동 JSON 작성은 추가 아웃바운드, 특수 DNS 정책 또는 세밀한 라우팅이 필요한 경우에 유용하지만, 클라이언트가 설정을 다시 생성할 때 변경 내용이 덮어써지는지 반드시 확인해야 합니다. 라우팅 설정, DNS 설정 또는 사용자 지정 설정 진입점에서 처리할 수 있는 기능이라면 해당 진입점을 우선 사용하고 임시 실행 파일을 직접 수정하지 마세요.

설정 조각은 JSON 문법을 완전하게 유지해야 합니다. 속성명과 문자열에는 반각 큰따옴표를 사용하고, 배열 항목 사이에는 쉼표를 넣되 마지막 항목 뒤에는 쉼표를 추가하지 않습니다. 도메인, 경로와 정규 표현식에는 백슬래시 이스케이프가 필요할 수도 있습니다. 저장 직후 코어가 종료되면 로그에서 가장 먼저 나타난 구문 분석 오류를 우선 확인하세요. 이후 연결 실패는 앞선 구문 분석 오류의 연쇄 결과인 경우가 많습니다.

{
  "routing": {
    "domainStrategy": "AsIs",
    "rules": [
      {
        "type": "field",
        "ip": ["geoip:private"],
        "outboundTag": "direct"
      }
    ]
  }
}

현상에 따라 점검 지점을 정하세요

브라우저는 되지만 다른 프로그램이 안 되면 먼저 해당 프로그램이 시스템 프록시를 사용하는지 확인한 뒤 TUN을 검토하세요. 도메인은 열리지 않지만 대상 주소에 직접 접속하면 응답하는 경우에는 DNS를 먼저 확인합니다. 일부 웹사이트만 이상하면 라우팅 순서와 도메인 규칙을 확인하세요. 구독 업데이트 후 노드가 사라지면 필터 표현식과 그룹을 확인합니다. FakeDNS 활성화 후 로컬 네트워크 이름에 문제가 생기면 제외 범위와 DNS 인계 경계를 점검하세요. 모든 설정을 처음부터 초기화하는 것보다 현상에 맞는 진입점을 선택하는 편이 안정적입니다.

안정적인 설정을 완성한 뒤에는 설정 내보내기 파일이나 화면 캡처를 보관하고 사용한 모드도 기록하세요. 설정 백업은 로컬 설정만 저장하며 구독 서비스 자체를 백업하는 것은 아닙니다. 구독 주소가 만료되면 백업으로 새 서버 기록을 만들 수 없습니다. 구독 주소, 서버 인증 정보와 사용자 지정 설정 파일은 민감 정보로 취급하고 공개 문서에 넣지 마세요. 실행 로그도 원문 그대로 공개 영역에 보내지 않는 것이 좋습니다.

구독 그룹과 서버 필터

그룹은 관리 문제를 해결합니다

구독 그룹은 프로토콜 자체를 바꾸는 기능이 아니라 서버의 출처, 용도와 업데이트 주기를 구분하는 기능입니다. 여러 구독을 가져온 뒤 모든 서버가 하나의 목록에 섞이면 노드 이름 중복, 지역 표기 불일치와 배율 정보 때문에 필터 결과를 판단하기 어려워집니다. 출처별로 그룹을 만들고 각 구독에 명확한 메모를 지정한 다음 필터 조건으로 임시 보기를 만드는 방법이 안정적입니다. 그룹 이름은 출처나 용도를 설명해야 하며, 쉽게 바뀌는 노드 수에 의존하지 마세요.

구독 주소는 클라이언트의 구독 그룹 설정을 통해 저장하세요. 추가한 뒤에는 먼저 수동 업데이트를 한 번 실행해 서버 기록이 정상적으로 파싱되는지 확인하고 자동 업데이트 주기를 설정합니다. 첫 업데이트에 실패하면 주소가 완전한지, 복사 과정에서 공백이 들어갔는지, 네트워크가 구독 엔드포인트에 접근할 수 있는지부터 확인하세요. 첫 실패 직후 같은 그룹을 여러 개 연속으로 만들지 마세요. 이후 업데이트에서 중복 서버가 생겨 정리 비용이 커집니다.

메모, 그룹 이름과 서버 이름은 용도가 다릅니다

그룹 메모는 사용자가 관리하며 출처를 표시하기에 적합합니다. 그룹 이름은 목록을 분류하는 데 사용되고, 서버 이름은 보통 구독 제공자가 생성하므로 업데이트 때 바뀔 수 있습니다. 장기간 안정적으로 필터링하려면 전체 서버 이름에만 의존하지 말고 지역 약어, 프로토콜명이나 용도 태그처럼 비교적 안정적인 키워드 조합을 선택하세요. 구독 제공자가 이름 규칙을 바꾸면 필터 결과도 달라지므로 대규모 업데이트 후에는 필터 보기에 예상한 서버가 여전히 포함되어 있는지 확인해야 합니다.

서버 필터는 보통 포함과 제외 두 유형으로 나뉩니다. 포함 조건은 특정 지역 표기가 있는 이름만 표시하는 것처럼 표시 범위를 좁힙니다. 제외 조건은 유지보수, 잔여 트래픽, 만료 안내처럼 서버가 아닌 항목을 제거하는 데 사용합니다. 필터가 보기만 바꾸는 경우 원본 기록은 삭제되지 않지만, 삭제 작업은 로컬 서버를 직접 제거합니다. 일괄 삭제를 실행하기 전에는 현재 작업 대상이 필터 결과인지 전체 그룹인지 확인하세요.

간단한 조건부터 필터 표현식 만들기

클라이언트 진입점에서 정규 표현식을 지원한다면 먼저 일반 키워드로 범위를 확인한 뒤 조합 조건을 단계적으로 추가하세요. 정규 표현식의 괄호, 대괄호, 마침표와 더하기 기호에는 특수한 의미가 있으므로 서버 이름을 그대로 복사하면 일치 결과가 달라질 수 있습니다. 여러 일반 키워드 중 하나를 일치시키려면 세로 막대를 사용할 수 있습니다. 예: HK|SG|JP. “잔여 트래픽”, “요금제 만료” 같은 안내 항목을 제외할 때는 각 키워드를 따로 테스트한 뒤 조건을 합치세요.

포함 예시:
HK|SG|JP

제외 예시:
잔여 트래픽|요금제 만료|공식 사이트|유지보수

프로토콜 필터 예시:
VMess|VLESS|Trojan

필터 조건은 자동 경로 선택까지 담당해서는 안 됩니다. 보이는 목록을 좁히는 데는 적합하지만 노드 품질을 지속적으로 판단하거나 실제 연결 지연 테스트를 대신하지는 않습니다. 필터링 후 대상 집합에서 실제 연결 지연 테스트를 실행해 핸드셰이크에 실패한 기록을 제외하고, 실제 다운로드나 웹페이지 접속 결과를 함께 고려해 서버를 선택하세요. ICMP Ping, 실제 연결 지연과 다운로드 속도 측정의 차이는 지연 시간 테스트 안내에서 확인할 수 있습니다.

업데이트, 덮어쓰기와 제거 전략

구독 업데이트는 보통 그룹별로 기록을 새로 고칩니다. 업데이트 후 중복 항목이 많이 생기면 먼저 같은 주소를 여러 그룹으로 가져왔는지 확인하고, 클라이언트가 기존 기록을 덮어쓰는지 수동 변경을 보존하는지 확인하세요. 구독으로 생성된 서버의 이름이나 매개변수를 직접 바꾸면 다음 업데이트에서 덮어써질 수 있습니다. 장기간 보존할 수동 서버는 별도 그룹에 두고 자동 업데이트 구독과 섞지 마세요.

구독을 제거할 때는 “구독 설정 삭제”와 “해당 구독으로 생성된 서버 삭제”를 구분해야 합니다. 구독 주소만 삭제하면 기존 서버가 남을 수 있으며, 이 기록은 더 이상 매개변수 업데이트를 받지 못합니다. 서버만 삭제하고 구독을 남겨 두면 다음 업데이트에서 다시 생성됩니다. 특정 출처를 중지할 때는 먼저 자동 업데이트를 중지하고, 해당 서버를 삭제한 다음 구독 그룹을 제거하세요. 작업 후 현재 활성 서버가 이미 삭제된 기록을 가리키고 있지 않은지도 확인해야 합니다.

v2rayNG 또는 v2flyNG에서는 구독 관리 진입점과 데스크톱 레이아웃이 다르지만 처리 순서는 같습니다. 출처에 메모를 지정하고 개별 업데이트를 실행한 뒤 파싱 결과를 확인하고 활성 설정을 선택하세요. 모바일 네트워크 전환이 잦다면 자동 업데이트 주기를 너무 짧게 설정하지 않는 것이 좋습니다. 업데이트에 실패하면 기존 서버를 유지한 상태에서 네트워크가 일시적으로 연결되지 않은 것인지 구독 주소 자체가 바뀐 것인지 먼저 판단하세요.

라우팅 규칙 실전: 일치 조건, 순서와 아웃바운드

규칙 순서에 따라 아웃바운드가 결정됩니다

라우팅의 핵심은 연결을 지정한 아웃바운드로 넘기는 것입니다. 일반적인 아웃바운드는 프록시, 직접 연결과 차단이며, 사용자 지정 설정으로 다른 프록시 체인을 추가할 수도 있습니다. 규칙은 일치 조건과 대상 아웃바운드로 구성됩니다. 도메인, 주소, 포트, 네트워크 유형 또는 인바운드 태그가 조건을 만족하면 연결을 해당 outboundTag로 전달합니다. 대부분의 구현은 위에서 아래로 규칙을 비교하므로 더 구체적인 규칙을 일반적인 규칙보다 앞에 배치해야 합니다. 그렇지 않으면 앞의 넓은 조건이 요청을 먼저 가져갑니다.

관리하기 쉬운 기본 순서는 명확히 차단해야 하는 대상을 먼저 처리하고, 사설 네트워크와 개인 주소를 직접 연결한 다음, 업무상 분명한 도메인이나 주소 규칙을 배치하고 마지막에 기본 동작을 설정하는 것입니다. 기본 아웃바운드가 예외 처리를 맡을 수 있으므로 모든 대상을 덮는 규칙을 반드시 작성할 필요는 없습니다. 규칙 상단에 지나치게 넓은 도메인 일치 조건을 두면 이후 분기 항목이 적용될 기회를 잃습니다.

도메인 일치와 주소 일치는 서로 다른 단계입니다

도메인 규칙은 연결에 도메인 정보가 남아 있을 때 가장 명확합니다. 예를 들어 domain:example.com은 해당 도메인과 하위 도메인 범위에 일치하고, full:example.com은 정확한 호스트 이름에 사용하며, regexp:는 실제로 패턴 일치가 필요한 경우에 적합합니다. 정규 표현식은 처리 비용과 유지보수 비용이 더 높으므로 일반 도메인으로 표현할 수 있다면 우선 사용하지 마세요. 사이트가 여러 정적 리소스 도메인에 의존한다면 하나씩 확인하고 홈페이지 도메인만 보고 모든 요청이 같은 규칙에 일치한다고 추정하지 마세요.

주소 규칙은 대상이 이미 IP로 해석된 경우 사용하며 단일 주소, CIDR 네트워크 또는 내장 분류에 일치시킬 수 있습니다. geoip:private는 사설 주소를 직접 연결하는 데 자주 사용되어 로컬 네트워크 프린터, 저장 장치와 라우터 관리 페이지가 프록시로 전송되는 것을 막습니다. 도메인 해석 결과는 시간과 지역에 따라 달라질 수 있으므로 동적 사이트의 현재 주소를 영구 규칙으로 저장하는 방식은 불안정합니다. 도메인으로 표현할 수 있는 업무 조건은 도메인 규칙을 우선 사용하세요.

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

domainStrategy가 일치 과정을 바꾸는 방식

AsIs는 요청에 포함된 원래 도메인을 우선 사용하며 라우팅 일치를 위해 주소를 능동적으로 해석하지 않습니다. IPIfNonMatch는 도메인 규칙에 일치하지 않을 때 주소를 해석한 뒤 주소 규칙을 시도합니다. IPOnDemand는 규칙 판단에 주소가 필요할 때 더 일찍 해석을 시작합니다. 전략을 선택할 때는 DNS 설정도 함께 고려해야 합니다. 라우팅이 주소 분류에 의존하는데 전략이 주소를 전혀 해석하지 않으면 해당 규칙이 일치하지 않을 수 있습니다. 반대로 너무 일찍 해석하면 DNS 조회가 늘어나거나 도메인 분기 경로가 바뀔 수 있습니다.

일반적인 환경에서는 AsIs부터 시작하고, 해석된 주소를 기반으로 추가 판단이 분명히 필요할 때만 IPIfNonMatch를 사용하세요. 변경 후에는 같은 도메인에서 서로 다른 DNS 요청이 발생하는지, 예상한 아웃바운드에 일치하는지 중점적으로 확인합니다. 전략 이름을 “속도 단계”로 이해해서는 안 됩니다. 이는 일치 단계와 해석 시점을 바꾸는 것이며 모든 네트워크 환경에서 특정 값이 더 빠르다는 보장은 없습니다.

규칙 검증에서는 전체 요청을 관찰해야 함

라우팅 검증은 홈페이지가 열리는지만 테스트해서는 안 됩니다. 한 페이지가 메인 사이트, 이미지, API와 인증 도메인에 동시에 요청할 수 있고, 각 요청은 서로 다른 아웃바운드를 사용할 수 있습니다. 먼저 구체적인 대상 하나로 단일 규칙을 만들고 코어를 재시작한 뒤 로그에서 대상, 일치 결과와 아웃바운드 태그를 확인하세요. 단일 규칙이 유효한 것을 확인한 후 도메인 범위를 넓히세요. 로그에 도메인 없이 주소만 표시된다면 DNS와 스니핑 설정으로 돌아가 도메인 정보를 계속 얻을 수 있는지 확인해야 합니다.

규칙이 적용되지 않을 때는 네 가지를 순서대로 확인하세요. 규칙이 올바른 순서에 있는지, 일치 문법이 코어 형식에 맞는지, 대상 아웃바운드 태그가 존재하는지, 실제 연결이 현재 코어에서 처리되는지입니다. 브라우저 자체의 보안 DNS, 애플리케이션 내장 프록시 또는 이미 연결된 장기 연결이 방금 수정한 경로를 우회할 수 있습니다. 테스트 전 대상 프로그램을 종료했다가 다시 열고, 필요하면 연결 캐시를 정리하세요. 페이지만 새로 고치는 것으로는 충분하지 않습니다.

라우팅 규칙은 읽기 쉽게 유지해야 합니다. 흩어진 도메인 수십 개보다 업무별로 분류한 소수의 규칙이 검토하기 쉽고 앞뒤 덮어쓰기 문제도 적습니다. 설정을 마친 뒤 위에서부터 “무엇에 일치하는가, 어느 아웃바운드로 보내는가, 왜 여기에 있어야 하는가”를 하나씩 답해 보세요. 명확히 답할 수 없는 항목은 보통 분리하거나 이름을 바꾸거나 제거해야 합니다.

DNS 설정 최적화와 해석 경로 점검

먼저 누가 조회를 시작하는지 명확히 하세요

DNS 문제는 노드 장애로 오해하기 쉽습니다. 실제 경로에는 시스템 리졸버, 브라우저 보안 DNS, v2rayN 코어 DNS, TUN DNS 인계와 원격 해석이 포함될 수 있습니다. 프로그램마다 서로 다른 해석 진입점을 사용하면 같은 도메인에서도 다른 결과를 얻을 수 있습니다. 최적화하기 전에 대상 프로그램이 시스템 해석을 사용하는지, 조회가 코어에 들어오는지, 코어가 어느 서버로 요청을 보내는지, 해석 결과가 라우팅에 어떻게 참여하는지 확인하세요.

시스템 프록시만 활성화한 경우 브라우저가 직접 도메인을 해석할 수도 있고, 프록시 진입점에 도메인을 전달할 수도 있습니다. 이는 프록시 유형과 프로그램 구현에 따라 다릅니다. TUN을 활성화하면 시스템 DNS 요청을 통합적으로 인계하기 쉬워지지만 DNS 주소, 라우팅과 제외 항목을 올바르게 설정해야 합니다. 브라우저에서 보안 DNS를 별도로 활성화하면 조회가 일반 HTTPS 트래픽으로 전송될 수 있어 겉으로는 기존 53번 포트 요청이 보이지 않을 수 있습니다.

코어 DNS의 서버와 조회 규칙

코어 DNS 설정에서는 여러 서버를 정의하고 도메인 범위에 따라 선택할 수 있습니다. 일반 UDP DNS는 설정이 간단하지만 요청 경로는 네트워크와 라우팅에 좌우됩니다. HTTPS 기반 DNS는 HTTPS 연결을 통해 조회하므로 서버 도메인의 초기 해석 문제를 먼저 해결해야 합니다. 고정 주소를 사용하면 시작 단계의 의존성을 줄일 수 있지만 주소가 바뀌면 관리가 필요합니다. 방식은 이름만 보고 판단하지 말고 접근 가능성과 의존 관계를 함께 고려해 선택하세요.

DNS 서버에는 도메인 필터 조건도 지정할 수 있습니다. 이는 보통 특정 도메인을 지정한 해석기로 보내기 위한 것이지 모든 조회를 여러 서버에 무작위로 분배하기 위한 것이 아닙니다. 여러 서버의 도메인 범위가 겹친다면 우선순위를 명확히 하세요. 기본 서버는 특별한 요구가 없는 도메인을 처리하고 전용 서버는 필요한 범위만 담당하게 하면 설정을 검증하기 쉽습니다.

{
  "dns": {
    "hosts": {
      "router.internal": "192.168.1.1"
    },
    "servers": [
      {
        "address": "https://dns.example/dns-query",
        "domains": ["domain:service.example"]
      },
      "1.1.1.1",
      "localhost"
    ],
    "queryStrategy": "UseIP"
  }
}

예시의 도메인은 구조를 보여 주기 위한 것이므로 실제 설정에서는 접근 가능한 해석 서비스로 바꿔야 합니다. hosts는 소수의 고정 매핑에 사용하며 로컬 장치나 테스트 환경에 적합하지만 공개 인터넷 도메인을 대량으로 관리하기에는 적합하지 않습니다. 잘못된 고정 매핑은 정상적인 업데이트를 우회하므로 설정 후 용도를 기록하세요. localhost는 시스템 리졸버로 돌아갑니다. 시스템 리졸버가 다시 요청을 코어로 넘기면 순환이 발생할 수 있으므로 사용 전에 경로 방향을 확인해야 합니다.

조회 전략과 주소 체계

queryStrategy는 반환할 주소 유형을 제어합니다. UseIP는 환경에 맞는 사용 가능한 주소를 가져오고, UseIPv4는 IPv4만 요청하며, UseIPv6는 IPv6만 요청합니다. 해당 연결 능력이 실제 네트워크에 있을 때만 반환된 주소가 의미가 있습니다. 시스템이 IPv6 주소를 받았다고 해서 아웃바운드 경로가 모든 IPv6 대상에 안정적으로 접근할 수 있다는 뜻은 아닙니다. 일부 사이트가 기다린 뒤 연결을 재시도한다면 일시적으로 IPv4만 사용하도록 제한해 주소 체계와 관련 있는지 확인할 수 있습니다.

주소 체계 문제는 일반적인 해결책으로 특정 주소 유형을 영구적으로 끄기보다 대조 테스트로 확인해야 합니다. 해석 결과, 연결 대상과 실패 단계를 각각 기록하세요. DNS가 주소를 반환했지만 TCP 또는 UDP 연결 수립에 실패한다면 문제는 해석 이후 단계에 있습니다. 특정 해석기만 시간 초과가 발생한다면 해당 해석기로 가는 경로를 확인하세요. 로그의 “해석 실패”와 “연결 거부”는 서로 다른 단계이므로 분리해서 처리해야 합니다.

캐시 정리는 검증 목적으로만 사용

DNS를 변경한 뒤에도 시스템, 브라우저와 코어가 이전 결과를 보관할 수 있습니다. Windows에서는 터미널에서 ipconfig /flushdns를 실행해 시스템 캐시를 정리할 수 있지만 이 명령은 브라우저 자체 캐시를 지우거나 기존 연결을 종료하지 않습니다. 더 안정적인 테스트 절차는 설정을 저장하고 코어를 재시작한 뒤 대상 프로그램을 종료하고 필요한 캐시를 정리한 다음 요청을 새로 시작하는 것입니다. 캐시를 반복해서 지우는 것은 잘못된 설정을 고치지 못하며 이전 결과이 계속 영향을 주는지 확인할 때만 사용하세요.

ipconfig /flushdns

nslookup example.com

nslookup example.com 1.1.1.1

nslookup은 시스템 기본 해석기와 지정한 해석기의 결과를 비교하는 데 적합하지만, 애플리케이션이 실제로 사용하는 코어 DNS 경로를 반드시 거치는 것은 아닙니다. 따라서 명령 결과는 정상인데 브라우저가 계속 실패한다면 브라우저와 프록시 진입점을 계속 확인해야 합니다. TUN 또는 FakeDNS가 활성화되어 있으면 일반 조회 도구에서 보이는 결과가 인계 후 매핑 주소일 수도 있으므로 관련 장의 내용을 함께 이해해야 하며, 기존 DNS 결과만으로 판단해서는 안 됩니다.

v2rayN TUN 모드: 인계 범위와 시스템별 차이

TUN은 어떤 프로그램의 프록시 미사용 문제를 해결하나요

시스템 프록시는 애플리케이션이 프록시 설정을 직접 읽는 것을 전제로 합니다. 브라우저와 일부 데스크톱 프로그램은 보통 이를 지원하지만 게임 런처, 명령줄 도구, 백그라운드 서비스 또는 사용자 지정 네트워크 스택을 사용하는 프로그램은 직접 연결할 수 있습니다. TUN 모드는 가상 네트워크 인터페이스를 통해 시스템 트래픽을 인계하여 이런 프로그램의 연결도 코어로 들어오게 합니다. 이는 트래픽 진입점을 바꾸는 기능이지 서버 프로토콜을 바꾸는 기능이 아니며, 원래 작동하지 않던 노드를 다시 연결해 주지도 않습니다.

TUN 활성화 여부는 애플리케이션 요구에 따라 결정해야 합니다. 시스템 프록시를 올바르게 읽는 프로그램만 사용한다면 시스템 프록시 설정이 더 간단하고 문제 해결 범위도 작습니다. 특정 프로그램이 프록시 진입점을 거치지 않는 것이 확인되었거나 TCP, UDP와 DNS를 통합적으로 처리해야 할 때만 TUN을 활성화하세요. TUN을 기본 문제 해결 동작으로 사용하면 라우팅, 권한, 가상 인터페이스와 DNS 문제가 동시에 추가될 수 있습니다.

활성화 전 권한과 충돌 항목 확인

TUN은 가상 네트워크 인터페이스를 만들거나 제어하고 라우팅을 조정해야 합니다. Windows 환경에서는 권한 상승이 필요할 수 있고, macOS와 Linux도 해당 네트워크 작업을 시스템에서 허용해야 합니다. 클라이언트에서 인터페이스 생성에 실패했다고 표시되면 노드를 계속 전환하지 말고 권한과 드라이버 상태부터 확인하세요. 기업 네트워크 관리 소프트웨어, 다른 가상 네트워크 도구와 이미 실행 중인 유사 프록시 프로그램이 동시에 라우팅을 변경할 수 있으므로 테스트할 때는 인계 주체를 하나만 남겨야 합니다.

활성화 전에 시스템 기본 게이트웨이와 DNS를 기록하고 다른 네트워크 인계 도구를 종료한 다음 v2rayN의 TUN 모드를 시작하세요. 성공하면 먼저 일반 웹페이지를 테스트한 뒤 원래 시스템 프록시를 사용하지 않던 프로그램을 테스트합니다. 모든 네트워크가 즉시 끊기면 먼저 TUN을 꺼서 기본 연결을 복구하고, 가상 인터페이스 생성 여부, 기본 경로 변경 여부와 DNS가 예상한 진입점을 가리키는지 확인하세요. 네트워크가 끊긴 상태에서 FakeDNS와 복잡한 라우팅을 계속 추가하지 마세요.

엄격한 라우팅, 자동 라우팅과 MTU

자동 라우팅은 인계가 필요한 트래픽을 TUN 인터페이스로 보냅니다. 엄격한 라우팅은 일반적으로 이 인터페이스를 우회할 수 있는 경로를 더 제한합니다. 구체적인 옵션 이름은 빌드에 따라 달라질 수 있지만 판단 원칙은 같습니다. 먼저 기본 자동 라우팅으로 기본 인계를 확인한 뒤 누수 경로나 로컬 네트워크 요구에 따라 엄격도를 조정하세요. 엄격한 라우팅을 활성화한 뒤 로컬 네트워크 리소스에 접근할 수 없다면 전역 프록시 규칙을 바로 추가하지 말고 사설 네트워크가 직접 연결로 유지되는지 확인하세요.

MTU는 가상 인터페이스가 전달할 수 있는 패킷 크기를 결정합니다. 값이 너무 크면 일부 경로에서 웹페이지 일부만 로드되거나 업로드가 멈추거나 특정 연결이 시간 초과될 수 있고, 너무 작으면 단편화와 추가 오버헤드가 늘어납니다. “연결은 되지만 큰 요청이 실패하는” 경우 원래 값을 기록한 뒤 MTU를 단계적으로 낮춰 비교해 보세요. 한 번의 속도 측정만으로 판단하지 말고 작은 웹페이지, 큰 파일 전송과 지속 연결이 필요한 애플리케이션을 최소한 테스트하세요.

로컬 네트워크와 클라이언트 자체 트래픽 제외

TUN 라우팅에서는 보통 사설 네트워크가 직접 연결로 유지되어야 합니다. 그렇지 않으면 프린터, 게이트웨이 관리 페이지와 로컬 네트워크 서비스가 잘못 프록시로 전송될 수 있습니다. 일반적인 사설 주소 범위는 geoip:private 규칙으로 통합 처리할 수 있습니다. 로컬 네트워크가 비표준 주소 범위를 사용한다면 실제 네트워크에 맞춰 추가해야 합니다. 로컬 네트워크 서비스가 도메인으로 제공되는 경우에는 로컬 DNS도 필요하므로 주소만 직접 연결하고 DNS를 원격에서 해석하면 이름을 여전히 사용할 수 없습니다.

클라이언트에서 프록시 서버로 연결하는 트래픽도 같은 프록시 아웃바운드에 다시 들어가지 않도록 해야 합니다. 일반적인 기본 설정은 이를 처리하지만 사용자 지정 라우팅이나 아웃바운드를 사용할 때는 서버 주소가 직접 연결 경로를 사용하는지 확인해야 합니다. 코어 시작 후 계속 재연결하고 로그에 같은 서버 대상이 반복된다면 자체 프록시 순환이 발생했는지 점검하세요.

TUN을 끈 후 복구 확인

클라이언트를 정상적으로 종료하면 가상 인터페이스와 임시 라우팅도 함께 제거되어야 합니다. 비정상 종료 후에도 네트워크를 사용할 수 없다면 클라이언트를 다시 열어 TUN을 정상적으로 끈 뒤 시스템 기본 경로와 DNS가 복구되었는지 확인하세요. 시스템 재시작으로 일부 임시 상태를 정리할 수 있지만 원인 분석을 대신해서는 안 됩니다. 잔존 문제가 반복되면 여러 네트워크 도구가 인터페이스를 동시에 관리하는지 확인하고 로그에서 종료 단계의 오류 여부를 확인하세요.

모바일 환경의 v2rayNG와 v2flyNG는 시스템이 제공하는 네트워크 인계 인터페이스를 통해 작동하므로 애플리케이션 제외 설정, 백그라운드 제한과 절전 정책이 지속 연결에 직접 영향을 줍니다. 데스크톱 TUN 설정을 Android에 그대로 적용할 수는 없지만 라우팅과 DNS를 분석하는 방법은 같습니다. 먼저 트래픽이 클라이언트로 들어오는지 확인하고, 다음으로 규칙 일치와 아웃바운드를 확인한 뒤, 마지막으로 시스템이 백그라운드에서 연결을 종료하는지 점검하세요.

FakeDNS의 작동 방식, 적합한 상황과 한계

FakeDNS는 도메인과 연결의 대응 관계를 저장합니다

FakeDNS는 DNS 조회를 인계한 뒤 도메인에 임시 주소를 반환하고 해당 주소와 원래 도메인의 매핑을 기록합니다. 애플리케이션이 이 임시 주소에 연결하면 코어가 매핑을 통해 도메인을 복원한 다음 도메인 라우팅과 원격 연결을 수행합니다. 주요 목적은 로컬에서 먼저 해석한 뒤 주소만 포함해 연결하는 프로그램에서도 도메인 정보를 유지하여 도메인 규칙이 적용될 기회를 제공하는 것입니다.

FakeDNS가 반환하는 주소는 대상 서버의 실제 공인 주소가 아니므로 코어 없이 단독으로 사용할 수 없습니다. 조회와 이후 연결이 같은 인계 경로로 들어와야 매핑이 성립합니다. DNS 조회는 FakeDNS를 거쳤지만 연결이 TUN을 우회하면 애플리케이션은 임시 주소에 직접 접속하려다 실패합니다. 반대로 연결은 TUN으로 들어오지만 조회를 다른 해석기가 처리하면 매핑으로 도메인을 복원할 수 없습니다.

활성화하기에 적합한 상황

TUN이 안정적으로 작동하지만 로그에 주소만 표시되는 연결이 많고 도메인 라우팅이 잘 적용되지 않을 때 FakeDNS를 고려할 수 있습니다. 로컬에서 실제 해석을 줄이고 프록시 경로에서 도메인을 계속 처리하려는 상황에도 적합합니다. 활성화하기 전에는 일반 TUN, DNS 인계와 기본 라우팅이 먼저 작동하는지 확인해야 합니다. 그렇지 않으면 주소 풀과 매핑 메커니즘이 추가되어 장애 현상을 해석하기 더 어려워집니다.

일반적인 시스템 프록시 환경에서는 “더 빠르게” 만들기 위해 FakeDNS를 따로 활성화할 필요가 보통 없습니다. 많은 프록시 진입점이 원래 도메인을 받을 수 있어 도메인 정보가 사라지지 않기 때문입니다. FakeDNS는 캐시 가속기도 아니며 핵심 기능은 매핑과 복원입니다. 연결 개선 여부는 기존 도메인 처리 문제에 달려 있으므로 모든 환경에서 활성화해야 하는 성능 옵션으로 간주해서는 안 됩니다.

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

예시는 일반적인 구조를 보여 줄 뿐이며 실제 지원 방식은 클라이언트가 사용하는 코어와 설정 진입점에 따라 달라집니다. 198.18.0.0/15는 벤치마크에 자주 사용되는 예약 네트워크로 매핑 풀로 사용할 수 있지만, 로컬 네트워크, 다른 가상 네트워크 또는 기업 라우팅에서 같은 범위를 사용하지 않는지 확인해야 합니다. 주소 풀이 충돌하면 특정 내부 네트워크 서비스에 연결할 수 없거나 라우팅이 실제 대상을 FakeDNS 주소로 잘못 인식할 수 있습니다.

로컬 네트워크, 트래픽 분기와 제외

로컬 네트워크 이름, 프린터 검색과 라우터 내부 도메인은 보통 로컬 DNS에 의존하므로 FakeDNS에 일괄 위임하기에 적합하지 않습니다. 사설 도메인과 로컬 도메인 접미사는 로컬 해석을 사용하게 하고 사설 주소는 직접 연결해야 합니다. 로컬 네트워크가 사용자 지정 접미사를 사용한다면 제외 범위에 명시적으로 추가하세요. 사설 주소만 제외하는 것으로는 충분하지 않을 수 있습니다. 이름 해석은 주소를 얻기 전에 이루어지기 때문입니다.

FakeDNS를 도메인 분기와 함께 사용할 때는 도메인이 복원된 후 규칙이 판단되어야 합니다. 연결 로그에 계속 매핑 주소만 표시된다면 복원 경로가 완료되지 않은 것입니다. DNS 조회와 연결을 같은 인스턴스가 처리하는지, 주소 풀이 일치하는지, TUN이 대상 애플리케이션을 인계하는지 확인하세요. 매핑 주소 대역에 프록시 규칙을 추가해 문제를 가리지 마세요. 그러면 모든 임시 주소가 프록시로 들어가면서도 원래 도메인의 규칙 가치는 잃게 됩니다.

캐시 수명과 테스트 방법

FakeDNS 매핑에는 용량과 수명이 있습니다. 애플리케이션이 오래된 매핑 주소를 계속 사용하는데 코어가 재시작되었거나 매핑 기록이 교체되면 기존 연결이 실패할 수 있습니다. 설정 변경을 테스트할 때는 대상 프로그램을 재시작하고 필요하면 DNS 캐시를 정리해 조회와 연결을 같은 실행 주기에서 다시 만들도록 하세요. 코어만 재시작하고 애플리케이션의 기존 연결을 유지하면 일관되지 않은 결과가 나올 수 있습니다.

검증할 때는 명확한 도메인 규칙이 있는 테스트 대상을 하나 선택할 수 있습니다. 먼저 FakeDNS를 끈 상태에서 로그에 표시되는 대상 형식을 기록한 다음 FakeDNS를 켜고 완전히 새로운 연결을 시작하세요. DNS가 매핑 주소를 반환하고, 코어가 도메인을 복원하며, 규칙이 예상한 아웃바운드에 일치하는 세 단계가 모두 나타나는지 확인합니다. 어느 한 단계라도 빠지면 규칙을 계속 추가하지 말고 해당 단계부터 수정하세요.

FakeDNS를 끈 뒤에는 관련 DNS 서버 설정도 함께 복구하고 애플리케이션이 도메인을 다시 해석하도록 해야 합니다. 주소 풀만 제거하고 fakedns 해석 진입점을 남겨 두면 설정이 불완전해집니다. 활성화와 비활성화를 장기간 반복해야 한다면 여러 옵션을 매번 수동으로 바꾸기보다 완전한 설정 두 세트를 보관하는 것이 좋습니다.

다중 구독 관리, 업데이트 주기와 충돌 처리

각 출처의 수명 주기를 독립적으로 유지

다중 구독 관리의 목적은 더 많은 서버를 하나의 목록에 쌓는 것이 아니라 서로 다른 출처를 독립적으로 업데이트하고 중지하며 검토하는 것입니다. 각 구독에는 고유한 메모와 그룹을 사용하고 두 주소를 같은 이름으로 설정하지 마세요. 그러면 특정 출처의 업데이트가 실패하거나 노드 이름이 바뀌거나 일시 중지가 필요할 때 다른 검증된 서버에 영향을 주지 않고 해당 그룹만 처리할 수 있습니다.

수동 서버는 “로컬 관리” 그룹에 별도로 두는 것이 좋습니다. 구독 업데이트는 보통 원격 콘텐츠를 기준으로 하므로 구독으로 생성된 서버를 직접 수정하면 다음 새로 고침에서 덮어써질 수 있습니다. 특정 매개변수를 임시로 조정해야 한다면 먼저 서버를 수동 그룹에 복사한 뒤 수정하고 이름에 용도를 표시하세요. 원본 구독 기록은 그대로 두어 원격 매개변수와 비교할 수 있게 합니다.

빈번한 폴링 대신 업데이트 시점을 분산하세요

자동 업데이트 주기는 구독 변경 빈도에 맞춰 설정해야 합니다. 주기가 너무 짧으면 불필요한 요청이 늘고 네트워크 전환 중 연속 실패가 기록될 수 있습니다. 여러 구독을 같은 시각에 업데이트할 필요는 없습니다. 각 출처가 독립적으로 업데이트되는지 수동으로 확인한 뒤 적절한 주기를 활성화하세요. 노트북이 절전 모드에서 복귀했거나 네트워크가 방금 전환되었거나 프록시 코어가 아직 연결되지 않은 상태에서는 첫 자동 업데이트가 실패할 수 있으므로 네트워크가 안정된 후 수동으로 다시 시도하세요.

구독을 업데이트할 때 구독 요청 자체가 직접 연결로 나갈지 프록시를 사용할지는 클라이언트 설정과 현재 네트워크에 따라 달라집니다. 특정 구독이 현재 프록시를 통해서만 접근 가능하다면 기존에 사용 가능한 노드에 의존하게 됩니다. 이 경우 업데이트 전에 삭제되지 않을 검증된 서버를 최소 하나 남겨 두세요. 새 콘텐츠를 받기 전에 기존 기록을 모두 삭제하면 일시적인 업데이트 실패 한 번으로 복구 경로를 잃을 수 있습니다.

동일한 서버 이름과 중복 콘텐츠 처리

서로 다른 출처에서 같은 서버 이름을 사용하거나 매개변수가 동일한 기록을 제공할 수 있습니다. 이름이 같다고 설정이 같은 것은 아니므로 표시 텍스트만 보고 일괄 삭제해서는 안 됩니다. 그룹, 주소, 포트, 프로토콜과 전송 매개변수를 함께 확인하세요. 클라이언트가 그룹별 보기를 지원한다면 먼저 한 출처로 범위를 제한해 작업하세요. 그룹 간 중복 제거 전에는 중복 기록이 예비 출처 역할을 하는지 확인해야 합니다.

같은 구독을 중복으로 가져오면 업데이트할 때마다 비슷한 기록이 두 묶음씩 생기는 현상이 가장 뚜렷합니다. 처리 전 관련 그룹의 자동 업데이트를 일시 중지하고 유지할 구독 설정을 확인한 다음 불필요한 그룹과 그로 인해 생성된 서버를 삭제하세요. 완료 후 유지할 그룹을 다시 업데이트하고 현재 활성 서버가 여전히 존재하는지 확인합니다. 전체 목록에서 항목을 하나씩 직접 삭제하는 것으로는 중복 구독의 근본 원인을 해결할 수 없습니다.

서버 선택과 그룹 관리는 분리해야 함

그룹은 출처 관리에 사용하고, 지연 시간 테스트는 연결 단계를 판단하며, 실제 사용에서는 대역폭, 안정성과 대상 서비스를 함께 고려해야 합니다. 특정 그룹이 최근 업데이트되었다고 해서 그 안의 모든 서버가 사용 가능하다고 가정하지 마세요. 업데이트 후에는 먼저 실제 연결 지연 테스트를 실행해 프록시 핸드셰이크를 완료하지 못하는 기록을 제외한 다음 소수의 후보로 실제 접속을 테스트하세요. 구체적인 선택 방법은 노드 선택 안내를 참고하세요.

자동 선택 기능이 정기 테스트에 의존한다면 테스트 대상, 시간 초과와 전환 조건을 이해해야 합니다. 테스트 주소에 접근할 수 없으면 모든 서버가 잘못 판단될 수 있고, 시간 초과가 너무 짧으면 지연은 높지만 사용 가능한 회선이 제외되며, 전환이 너무 잦으면 기존 연결이 끊깁니다. 먼저 여러 서버를 통해 테스트 대상에 접근할 수 있는지 수동으로 확인한 뒤 자동화를 고려하세요. 지속적인 세션이 필요한 애플리케이션은 매번 가장 낮은 단일 지연보다 안정성을 더 중요하게 보는 경우가 많습니다.

구독 이전과 로컬 기록

장치를 변경할 때는 구독 주소, 수동 서버, 라우팅 규칙과 DNS 설정을 각각 처리해야 합니다. 구독만 이전하면 원격 서버를 다시 생성할 수 있지만 로컬 사용자 지정 규칙은 자동으로 가져오지 않습니다. 실행 설정만 복사하면 임시로 생성된 내용이 포함되어 이후 업데이트가 어려울 수 있습니다. 이전 후에는 출처별로 하나씩 업데이트하고 그룹과 서버 수가 적절한지 확인한 다음 사용자 지정 규칙을 가져오세요.

구독 주소와 서버 인증 정보는 모두 민감한 설정입니다. 문제 해결용 스크린샷에는 전체 주소, 사용자 식별자와 토큰을 숨겨야 합니다. 로그를 제출하기 전에도 요청 매개변수와 서버 정보를 확인하세요. 공개 예시에는 https://example.com/sub?token=xxxx처럼 명확한 가짜 값을 사용하고 실제 구독 내용을 스크립트, 웹페이지나 공유 노트에 기록하지 마세요.

다중 구독 체계가 안정되면 일상적인 유지보수에서는 업데이트 실패, 비정상적인 중복과 장기간 사용할 수 없는 기록만 확인하면 됩니다. 목록을 깔끔하게 보이게 하려고 모든 그룹을 자주 다시 만들지 마세요. 명확한 출처 경계, 되돌릴 수 있는 활성 서버와 소수의 설명을 유지하는 편이 완전한 자동화를 추구하는 것보다 장기간 관리하기 쉽습니다.

사용자 지정 아웃바운드, 체인 연결과 전체 진단

아웃바운드 태그는 라우팅과 연결 방식의 인터페이스입니다

코어는 아웃바운드를 통해 연결이 로컬 장치를 어떻게 빠져나갈지 정의합니다. 일반적인 proxy, direct와 block은 각각 현재 프록시 서버 사용, 직접 연결과 차단을 뜻합니다. 사용자 지정 아웃바운드로 로컬 SOCKS 서비스, 특정 직접 연결 매개변수 또는 지원되는 다른 프로토콜을 추가한 뒤 라우팅 규칙에서 태그로 선택할 수 있습니다. 태그는 고유해야 하며 규칙의 outboundTag는 아웃바운드의 tag와 완전히 일치해야 합니다.

아웃바운드를 추가하기 전에 용도를 명확히 하세요. 특정 요청을 로컬의 다른 서비스에 넘길 것인지, 특정 대상에 독립적인 연결 경로를 설정할 것인지 결정해야 합니다. 대응하는 라우팅 규칙이 없는 사용자 지정 아웃바운드는 트래픽을 자동으로 인계하지 않습니다. 태그 철자가 틀리면 코어가 설정 로드를 거부하거나 요청 단계에서 오류를 보고할 수 있습니다. 이름은 안정적이고 읽기 쉬운 짧은 영어 단어를 사용하고, 구독 업데이트에 따라 바뀔 수 있는 서버 이름을 태그로 사용하지 마세요.

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

예시는 특정 트래픽을 로컬 127.0.0.1:1081의 SOCKS 서비스로 전달합니다. 사용하기 전에 해당 포트에서 실제로 서비스가 수신 중인지, 트래픽이 현재 v2rayN 인바운드로 다시 돌아가지 않는지 확인해야 합니다. 두 로컬 서비스가 서로를 가리키면 순환이 발생하여 연결이 계속 수립되다가 즉시 실패합니다. 사용자 지정 포트도 v2rayN이 이미 사용하는 로컬 HTTP, SOCKS 또는 API 포트와 충돌하지 않게 하세요.

체인 연결에서는 각 홉을 명확히 해야 합니다

체인 연결은 장애 지점과 핸드셰이크 비용을 늘리므로 명확한 필요가 있을 때만 설정해야 합니다. 각 홉은 개별적으로 검증할 수 있어야 합니다. 첫 번째 홉은 로컬에서 중간 아웃바운드까지 접근 가능해야 하고, 중간 아웃바운드는 다음 대상에 접근할 수 있어야 하며, DNS 해석은 예상한 위치에서 이루어져야 합니다. 체인의 어느 홉이 이전 홉의 DNS나 라우팅에 의존한다면 의존 관계를 기록해 시작 단계에서 서로 대기하지 않도록 하세요.

체인 연결을 테스트할 때는 먼저 단순한 대상을 사용하고 복잡한 도메인 규칙을 동시에 활성화하지 마세요. 로그에는 요청이 어느 인바운드로 들어왔는지, 어느 규칙에 일치했는지, 어느 아웃바운드를 선택했는지와 어느 단계에서 실패했는지가 나타나야 합니다. 연결 시간 초과는 포트가 수신 중이 아니거나 라우팅에 접근할 수 없거나 이후 대상이 응답하지 않는 등 범위가 넓습니다. 인증 실패라면 해당 아웃바운드의 인증 정보와 프로토콜 매개변수를 우선 확인하세요. 명확한 설정 오류를 모든 시간 초과를 늘려서 가리지 마세요.

로그를 계층별로 읽기

전체 진단은 여섯 계층으로 나눌 수 있습니다. 클라이언트 프로세스가 시작되었는지, 코어 설정이 파싱되었는지, 인바운드 포트나 TUN이 요청을 인계하는지, DNS가 사용 가능한 결과를 얻는지, 라우팅이 예상한 아웃바운드를 선택하는지, 아웃바운드가 연결을 완료하는지입니다. 로그에서 가장 먼저 나타난 오류가 보통 근본 원인에 가장 가깝습니다. 코어 설정 파싱에 실패했다면 이후의 “프록시를 사용할 수 없음”은 독립적인 진단 가치가 없습니다. DNS가 이미 실패했다면 서버 속도 측정 매개변수부터 조정해서도 안 됩니다.

문제 해결 중에는 로그 수준을 일시적으로 높이고 확인이 끝나면 일반 수준으로 되돌리세요. 상세 로그에는 대상 도메인, 서버 주소와 로컬 경로가 포함될 수 있으므로 공유하기 전에 민감한 내용을 정리해야 합니다. 로그를 발췌할 때는 오류 전후의 시간대와 작업 단계를 남기고 마지막 한 줄만 복사하지 마세요. 관련 없는 대량의 로그보다 명확하게 재현한 한 번의 과정이 원인을 찾기 쉽습니다.

재현 가능한 진단 절차 만들기

“V2Ray에 연결할 수 없음”이 발생하면 먼저 발생 시간, 현재 서버, 프록시 모드, TUN 활성화 여부, FakeDNS 활성화 여부와 영향을 받는 프로그램을 기록하세요. 그런 다음 최소 테스트 대상 하나를 선택하고 문제와 관련 없는 사용자 지정 규칙을 끈 뒤 연결을 다시 시작합니다. 기본 연결이 복구되면 원래 순서대로 설정을 하나씩 활성화하다가 오류가 다시 나타나는 지점을 확인하세요. 이 방법으로 복잡한 문제를 단일 변경으로 좁힐 수 있습니다.

모든 서버가 동시에 실패한다면 서버 매개변수를 하나씩 수정하기보다 로컬 네트워크, 구독이 방금 업데이트되었는지, 시스템 시간, DNS와 클라이언트 실행 상태를 먼저 확인하세요. 특정 서버만 실패할 때는 같은 그룹의 다른 기록과 해당 서버의 프로토콜 매개변수를 비교합니다. 특정 애플리케이션만 실패한다면 해당 애플리케이션이 현재 프록시 진입점으로 들어오는지 먼저 확인하세요. 더 많은 간단한 질문은 자주 묻는 질문 페이지에서 항목별로 확인할 수 있습니다.

장기 유지보수와 업그레이드 점검

클라이언트와 코어를 업데이트한 뒤에는 먼저 기존 기본 설정으로 시작하고 사용자 지정 필드가 계속 지원되는지 확인하세요. 클라이언트 업데이트와 동시에 모든 라우팅과 DNS를 재구성하지 마세요. 설정을 로드할 수 없다면 필드 폐기나 형식 변경과 관련된 로그를 확인하고 문제를 특정 조각으로 좁히세요. 다운로드와 클라이언트 선택은 이 사이트의 다운로드 페이지에서 통합 제공하며, 데스크톱 플랫폼에는 v2rayN을 우선 사용하고 Android에서는 코어 요구 사항에 따라 v2rayNG 또는 v2flyNG를 선택할 수 있습니다.

주기적으로 구독 그룹, 필터 조건, 라우팅 항목, DNS 전용 규칙과 사용자 지정 아웃바운드를 검토하세요. 더 이상 용도를 설명할 수 없는 임시 규칙은 삭제하고 로컬 네트워크 제외 설정이 현재 네트워크와 일치하는지 확인하며 자동 업데이트가 계속 성공하는지도 점검합니다. 고급 설정의 목표는 옵션 수를 늘리는 것이 아니라 각 계층의 동작을 설명하고 검증하며 되돌릴 수 있게 만드는 것입니다.