V2Ray 고급 설정 체계적으로 살펴보기

먼저 구독, 설정, 그룹을 구분하세요

구독 링크는 단일 서버가 아니라 서비스 제공자가 관리하는 설정 목록에 가깝습니다. 클라이언트가 구독을 업데이트하면 목록을 읽어 여러 서버 항목을 만들고, 그룹은 클라이언트에서 이 항목을 분류하는 관리 계층입니다. 세 요소의 수명 주기는 서로 다릅니다. 구독은 정기적으로 갱신될 수 있고 서버 이름과 매개변수도 바뀔 수 있지만, 로컬 그룹은 일반적으로 안정적으로 유지해야 합니다. 이 점을 이해하면 설정 전략이 분명해집니다. 구독은 소스 변경을 받아들이고, 필터 규칙은 필요한 항목을 골라내며, 그룹은 고정된 용도의 항목을 담습니다. 수십 개 항목을 수동으로 끌어 순서를 유지하려 하지 마세요. 다음 업데이트에서 목록이 다시 생성되면 수동 정렬이 무의미해질 수 있습니다.

v2rayN에서는 먼저 소스별로 구독 그룹을 만드는 방식이 안정적입니다. 예를 들어 ‘일상용 메인 구독’, ‘백업 구독’, ‘테스트 구독’으로 나눈 뒤 각 소스에 업데이트 주기, 필터, 별칭을 설정하세요. Android의 v2rayNG는 그룹 수를 적게 유지하는 편이 좋습니다. 모바일 화면은 제한적이므로 그룹을 지나치게 세분화하면 전환 비용이 커집니다. v2flyNG의 관리 방식도 v2rayNG와 비슷하지만 코어 체계가 다르므로 가져온 뒤 프로토콜과 전송 매개변수가 모두 올바르게 인식됐는지 확인해야 합니다. 클라이언트 간에 이전할 때는 구독 주소나 표준 설정을 옮기고, 특정 클라이언트의 표시 순서를 공통 설정으로 간주하지 마세요.

예측 가능한 목록을 만드는 포함 필터부터 사용하세요

서버 필터에는 일반적으로 별칭 일치, 프로토콜 필터, 주소 필터, 포트 조건이 포함됩니다. 먼저 어떤 항목을 남길지 명확히 정하는 포함 조건을 작성한 뒤, 소수의 제외 조건을 추가하는 방식을 권장합니다. 구독 별칭에 지역, 용도, 배율 정보가 포함되어 있다면 이름에 ‘자주 사용’이나 명확한 지역 태그가 있는 항목만 우선 남기고, ‘만료’, ‘점검’, ‘테스트’처럼 일상적인 선택에서 제외할 항목을 걸러낼 수 있습니다. 포함 조건이 분명할수록 구독 제공자가 명명 규칙을 바꿨을 때 문제를 쉽게 발견할 수 있습니다. 제외 단어만 길게 관리하면 새로운 이상 태그가 눈치채지 못한 사이 선택 목록에 들어갈 수 있습니다.

필터 표현식은 구독에 실제로 존재하는 명명 규칙을 기준으로 작성해야 합니다. 예를 들어 ^(?!.*(?:점검|만료)).*(?:자주 사용|백업)은 ‘점검’ 또는 ‘만료’가 포함된 항목을 제외하고, 이름에 ‘자주 사용’ 또는 ‘백업’이 들어간 항목만 남긴다는 뜻입니다. 표현식의 전각 문장 부호, 공백, 대소문자는 결과에 영향을 줄 수 있습니다. 처음 작성할 때는 실제 별칭 몇 개를 로컬 텍스트에 복사해 하나씩 대조한 뒤 클라이언트에 입력하세요. 복잡한 표현식부터 시작하지 마세요. 유지하기 어려운 하나의 조합 규칙보다 단순한 두 개의 규칙이 더 안정적인 경우가 많습니다.

{
  "group": "일상용 메인 구독",
  "include": "(자주 사용|백업)",
  "exclude": "(점검|만료|테스트)",
  "updateIntervalHours": 24
}

업데이트 전후에 각각 보존할 항목

구독을 업데이트하기 전에 현재 연결 가능한 설정이 하나 있는지 확인하고, 소속 구독과 별칭을 기록하세요. 업데이트 후에는 항목 수가 비정상적으로 변했는지 먼저 확인한 다음 현재 선택 항목이 여전히 존재하는지 살펴보세요. 항목 수가 갑자기 0이 되었다면 프로토콜 매개변수를 바로 수정하기보다 구독 접근, 필터 조건, 그룹 선택을 먼저 의심해야 합니다. 수가 크게 줄었다면 필터를 잠시 끄고 원본 결과를 확인하세요. 원본 항목이 온전하면 로컬 필터가 문제이고, 원본 결과도 불완전하면 구독 자체가 반환한 내용을 확인해야 합니다.

업데이트에는 덮어쓰기 정책도 관련됩니다. 구독으로 생성된 항목은 원칙적으로 구독이 관리하므로 주소, 포트, 사용자 식별자, 전송 계층 매개변수를 장기간 직접 수정하지 않는 편이 좋습니다. 이후 업데이트에서 변경 내용이 덮어써질 수 있기 때문입니다. 실험이 필요하다면 항목을 로컬 테스트 그룹으로 복사하고 이름 앞에 ‘로컬 테스트’를 붙여 구분하세요. 테스트가 성공한 뒤 변경이 구독 측 설정에 해당하면 구독 소스로 돌아가 수정해야 합니다. 로컬 라우팅이나 DNS 요구라면 서버를 하나씩 수정하지 말고 클라이언트의 전역 설정이나 라우팅 규칙에 반영하세요.

빈 목록과 중복 항목 처리

구독을 가져온 뒤 서버가 보이지 않으면 정해진 순서대로 확인하세요. 먼저 올바른 그룹을 보고 있는지 확인하고, 수동으로 한 번 업데이트한 다음 모든 포함 및 제외 조건을 끄고, 마지막으로 클라이언트 로그에 파싱 오류가 있는지 살펴봅니다. 필터를 끈 뒤 복구된다면 규칙을 하나씩 다시 켜 충돌 항목을 찾으세요. 로그에 콘텐츠 형식을 인식할 수 없다고 표시되면 구독이 클라이언트가 지원하는 설정 형식을 반환하는지 확인해야 합니다. 로그인 페이지, 안내 문구, 만료된 응답이 아니어야 합니다. 관련 기초 문제는 도움말 센터에서 계속 확인할 수 있습니다.

중복 항목은 같은 구독을 두 번 가져왔거나, 두 구독에 동일한 서버가 포함되어 있거나, 업데이트 시 덮어쓰기가 아닌 추가를 선택했을 때 주로 발생합니다. 처리할 때 별칭만 보고 판단하지 마세요. 이름이 같아도 주소나 전송 매개변수가 다를 수 있습니다. 주소, 포트, 프로토콜, 전송 방식, 보안 계층 설정을 대조해야 합니다. 완전히 같은 항목은 안정적인 구독에서 관리하는 하나만 남기고, 매개변수가 다른 동명 항목은 소스를 표시하도록 이름을 다시 지정하세요. 목표는 목록 수를 늘리는 것이 아니라 모든 항목의 출처와 용도를 추적할 수 있고 업데이트 후에도 이해하기 쉬운 상태를 유지하는 것입니다.

라우팅 판단은 연결이 수립되기 전에 이루어집니다

라우팅 규칙의 역할은 서버 매개변수를 바꾸는 것이 아니라 각 대상 연결에 사용할 아웃바운드를 선택하는 것입니다. 애플리케이션이 접속을 시작하면 코어는 대상 도메인, 대상 주소, 포트, 네트워크 유형, 프로세스 출처 등 사용 가능한 정보를 읽고 규칙 순서대로 일치 항목을 찾습니다. 일치하면 연결은 프록시, 직접 연결, 차단과 같은 지정된 아웃바운드로 전달됩니다. 어떤 규칙도 일치하지 않으면 최종 기본 아웃바운드로 들어갑니다. 따라서 라우팅 문제를 점검할 때는 현재 어떤 서버를 선택했는지만 보지 말고 ‘이 연결을 어느 규칙이 처리했는가’를 먼저 확인해야 합니다.

도메인과 주소를 항상 동시에 얻을 수 있는 것은 아닙니다. 일부 연결은 코어에 들어올 때 도메인을 포함하므로 규칙이 도메인으로 직접 매칭할 수 있습니다. 다른 연결은 이미 해석된 주소만 제공하므로 도메인 규칙이 적용되지 않을 수 있습니다. 도메인 스니핑을 켜면 코어가 일부 프로토콜 트래픽에서 대상 도메인을 복원할 수 있지만 모든 상황에서 안정적인 것은 아니며 올바른 DNS 설계를 대신할 수도 없습니다. 안정적인 라우팅 설정은 도메인 규칙과 주소 규칙을 함께 고려하고 어떤 규칙이 스니핑에 의존하는지 명확히 해야 합니다.

규칙 순서가 최종 결과를 결정합니다

대부분의 클라이언트는 위에서 아래로 매칭하며 첫 번째로 일치한 규칙이 즉시 아웃바운드를 결정합니다. 범위가 가장 좁고 우선순위가 높은 규칙을 앞에, 범위가 넓은 기본 규칙을 뒤에 배치하세요. 예를 들어 특정 내부 도메인을 직접 연결해야 한다면 넓은 프록시 도메인 규칙보다 앞에 둬야 합니다. 로컬 네트워크 주소의 직접 연결 규칙도 기본 프록시보다 앞에 두고, 마지막에 나머지 연결을 처리하는 기본 규칙을 배치하세요. 순서가 반대면 넓은 규칙이 먼저 일치해 뒤의 정확한 규칙이 올바르게 작성되어도 실행되지 않습니다.

유지 관리하기 쉬운 규칙 세트는 보통 ‘특정 차단, 지정 직접 연결, 지정 프록시, 주소 범위, 기본 동작’ 순서로 구성합니다. 차단 규칙은 꼭 필요한 대상만 명시해 최소화하세요. 직접 연결 규칙에는 로컬 네트워크, 클라이언트 업데이트에 필요한 대상, 로컬 네트워크로 접속해야 하는 서비스가 포함됩니다. 지정 프록시 규칙은 반드시 필요한 도메인이나 애플리케이션에 사용하고, 주소 범위 규칙은 주소만 제공되는 연결을 처리합니다. 기본 동작은 분류되지 않은 트래픽을 담당합니다. 규칙 계층이 명확하면 로그의 아웃바운드 태그도 쉽게 해석할 수 있습니다.

Xray 라우팅 구조 예시

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

domainStrategy를 이해하고 값을 기계적으로 적용하지 마세요

domainStrategy는 라우팅 단계에서 도메인을 언제 주소로 해석할지 결정합니다. AsIs는 원본 도메인을 우선 판단하며 주소 규칙을 위해 적극적으로 해석하지 않습니다. IPIfNonMatch는 먼저 도메인 규칙을 시도하고 일치하지 않을 때 주소를 해석해 주소 규칙을 계속 적용합니다. IPOnDemand는 주소 정보가 필요한 규칙을 만나면 더 일찍 해석을 시작할 수 있습니다. 모든 네트워크에 맞는 단일 값은 없습니다. 도메인 규칙이 중심이고 추가 해석을 줄이고 싶다면 AsIs부터 시작할 수 있습니다. 주소 데이터베이스에 의존해 트래픽을 나눠야 한다면 IPIfNonMatch가 대체로 이해하기 쉽습니다.

라우팅 단계의 해석은 DNS 모듈의 영향도 받습니다. DNS 조회 자체가 잘못된 아웃바운드로 나가면 라우팅이 예상과 다른 주소를 받아 다른 규칙에 매칭될 수 있습니다. domainStrategy를 바꾼 뒤 ‘같은 도메인이 가끔 다른 출구로 나가는’ 현상이 생기면 DNS 서버 선택, 캐시, 도메인 규칙 적중 여부를 함께 확인하세요. 라우팅과 DNS는 서로 이어진 두 시스템이므로 따로 맹목적으로 조정하기 어렵습니다.

포트, 네트워크, 애플리케이션으로 범위를 좁히세요

포트 조건은 특정 아웃바운드가 특정 TCP 포트를 맡게 하는 등 명확한 서비스에 적합하지만, 일반적인 포트를 도메인 분류의 대체 수단으로 사용해서는 안 됩니다. 많은 서비스가 443 포트를 공유하므로 포트만으로 대상을 구분할 수 없습니다. 네트워크 조건은 TCP와 UDP를 구분하는 데 사용할 수 있으며, 특정 아웃바운드가 UDP를 지원하지 않거나 실시간 통신을 별도로 처리해야 할 때 유용합니다. 애플리케이션 조건은 클라이언트 기능에 따라 달라집니다. v2rayNG의 애플리케이션별 프록시는 Android 앱 기준으로 어떤 프로그램을 VPN에 넣을지 결정하며, 코어에 들어온 연결은 도메인, 주소, 포트 라우팅을 계속 적용할 수 있습니다.

애플리케이션별 프록시의 포함 모드와 제외 모드는 하나의 명확한 목표에 따라 선택해야 합니다. 일부 앱만 클라이언트에 넣어야 한다면 포함 모드가 관리하기 쉽고, 대부분의 앱을 넣되 소수의 로컬 앱만 예외로 둘 때는 제외 모드가 관리 부담을 줄입니다. 앱 업데이트나 패키지명 변경 후에는 기존 규칙이 더 이상 일치하지 않을 수 있습니다. 시스템 업데이트 후 특정 앱의 경로가 갑자기 바뀌었다면 도메인 규칙을 다시 작성하기보다 먼저 앱 선택 목록을 확인하세요.

웹 결과만 보지 말고 로그로 매칭을 확인하세요

라우팅을 검증할 때는 먼저 혼동을 일으킬 수 있는 기존 백그라운드 연결을 정리하고 클라이언트 로그를 연 다음 테스트 대상 하나만 접속하세요. 대상 도메인 또는 주소, 일치한 규칙, 최종 아웃바운드 태그를 중점적으로 확인합니다. 로그에 주소만 표시되면 DNS와 스니핑 설정을 확인하세요. 아웃바운드 태그는 올바르지만 접속에 실패한다면 대상 서버, 선택한 노드, 전송 매개변수, 로컬 네트워크 문제일 가능성이 큽니다. 태그가 틀리면 해당 규칙을 임시로 맨 앞에 옮겨 규칙 자체가 매칭되는지 확인한 뒤 합리적인 순서로 되돌리세요.

라우팅 규칙을 수정한 뒤에는 새 설정이 완전히 적용되도록 연결을 다시 시작해야 합니다. 브라우저가 기존 연결을 재사용하거나 DNS 캐시를 유지할 수 있으므로 페이지 새로고침만으로는 변경 사항을 검증하기 어렵습니다. 클라이언트를 연결 해제하고 테스트 앱의 백그라운드 프로세스를 종료한 다음 다시 연결해 새 접속을 시작하는 편이 안전합니다. ‘연결됨으로 표시되지만 인터넷이 되지 않는’ 문제를 체계적으로 점검하려면 프록시 포트, 라우팅 모드 및 DNS 단계별 점검 목록을 참고하세요.

먼저 해석 경로를 그려 보세요

DNS 장애가 어려운 이유는 시스템 DNS, 클라이언트 DNS, 브라우저의 암호화 DNS, 원격 해석이 동시에 존재하기 때문인 경우가 많습니다. 애플리케이션이 도메인을 제출하면 운영체제가 먼저 처리할 수도 있고 TUN이 가로챌 수도 있습니다. 브라우저에서 독립적인 암호화 DNS를 사용하면 클라이언트 설정을 우회할 수도 있습니다. 코어가 조회를 받은 뒤에는 도메인 규칙에 따라 DNS 서버를 선택하고 조회 요청을 직접 연결로 보낼지 프록시로 보낼지 결정합니다. 반환된 주소는 캐시에 들어간 뒤 라우팅 모듈에서 다시 매칭될 수 있습니다. 어느 한 계층이 바뀌어도 ‘도메인은 열리지 않지만 주소는 연결됨’ 또는 ‘같은 도메인의 결과가 불안정함’으로 나타날 수 있습니다.

최적화의 첫 단계는 DNS 주소를 더 많이 추가하는 것이 아니라 주 경로를 하나로 정하는 것입니다. 일반 시스템 프록시 모드에서는 클라이언트가 프록시가 필요한 도메인의 해석을 담당하고 로컬 리소스는 시스템 해석을 유지할 수 있습니다. TUN 모드에서는 가상 네트워크 인터페이스로 들어오는 조회를 코어가 통합해 처리하도록 하는 편이 좋습니다. 테스트 중에는 브라우저의 독립 DNS를 잠시 꺼 병렬 경로가 생기지 않게 하세요. 클라이언트 경로가 정상임을 확인한 뒤 브라우저 설정을 복원할지 결정하고 트래픽이 예상대로 라우팅되는지 검증하세요.

로컬 DNS와 원격 DNS의 역할

로컬 DNS는 로컬 네트워크 이름, 사내 도메인, 현재 네트워크가 답해야 하는 대상의 해석에 적합합니다. 원격 DNS는 프록시 아웃바운드가 담당하는 도메인 조회에 적합해 해석 위치와 접속 출구를 일치시킬 수 있습니다. 둘은 단순히 ‘빠른 DNS와 느린 DNS’를 고르는 관계가 아니라 담당 범위가 다릅니다. 내부 도메인을 원격 서버에 맡기면 올바른 주소를 얻지 못하는 경우가 많고, 프록시 출구와 일치해야 하는 도메인을 항상 로컬 서버에 맡겨도 현재 출구에 적합하지 않은 결과를 받을 수 있습니다.

설정할 때 도메인 집합별로 서버를 지정하고 명확한 기본 해석기를 하나 유지하세요. 클라이언트가 DoH를 지원한다면 https://1.1.1.1/dns-query와 같은 HTTPS 엔드포인트를 사용할 수 있습니다. 일반 UDP DNS를 사용한다면 요청이 프록시 아웃바운드를 거치는지 명확히 해야 합니다. DoH는 전송 방식일 뿐 라우팅이 올바르다는 보장은 하지 않습니다. 엔드포인트 도메인 자체도 최초 해석이 필요하므로 엄격한 환경에서는 명확한 서버 주소나 부트스트랩 해석 전략을 함께 사용해 ‘DNS 서버 도메인을 해석하려면 먼저 같은 DNS 서버에 접속해야 하는’ 순환 의존을 피하세요.

도메인 범위에 따라 DNS 서버 선택

{
  "dns": {
    "hosts": {
      "router.internal.example": "192.168.1.1"
    },
    "servers": [
      {
        "address": "192.168.1.1",
        "domains": [
          "domain:internal.example"
        ],
        "skipFallback": true
      },
      {
        "address": "https://1.1.1.1/dns-query",
        "domains": [
          "geosite:geolocation-!cn"
        ]
      },
      "localhost"
    ],
    "queryStrategy": "UseIP"
  }
}

queryStrategy와 주소 계열 선택

queryStrategy는 IPv4, IPv6 또는 두 주소를 모두 조회할지 제어합니다. UseIP를 선택하면 일반적으로 두 유형의 주소가 허용되지만 실제 반환 결과는 서버와 네트워크에 따라 달라집니다. IPv4만 사용하면 IPv6 경로를 사용할 수 없을 때 대기 시간을 줄일 수 있고, IPv6만 사용하려면 로컬 네트워크, 프록시 아웃바운드, 대상 서비스가 모두 완전한 지원을 제공해야 합니다. 로그에 IPv6 주소가 보인다는 이유만으로 즉시 비활성화하지 말고 실제로 IPv6 연결 단계에서 실패했는지 먼저 판단하세요. 안정적인 네트워크에서는 듀얼 스택을 유지하고, 불완전한 네트워크에서는 실제 연결 능력에 맞는 주소 계열을 선택하세요.

주소 계열 문제는 처음 열 때 느리다가 잠시 후 회복되거나, 같은 대상이 앱마다 다르게 동작하는 현상으로 나타날 수 있습니다. 앱마다 주소 선택 알고리즘이 다르거나 한 주소 계열이 먼저 실패한 뒤 다른 계열로 대체되기 때문일 수 있습니다. 점검할 때는 A와 AAAA 결과를 따로 확인하고 클라이언트 로그에서 최종 시도한 대상 주소를 확인하세요. DNS 반환 유형만 바꾸고 아웃바운드 능력을 확인하지 않으면 원래 사용할 수 있던 다른 주소 계열까지 제외할 수 있습니다.

캐시, Fallback, 오염된 응답 오판

DNS 캐시는 반복 조회를 줄여 주지만 잘못된 결과의 영향도 오래 유지합니다. 서버나 분기 규칙을 수정한 뒤에는 클라이언트를 연결 해제했다가 다시 연결하고, 필요하면 테스트 앱을 재시작해 기존 캐시를 제거하세요. 시스템에 해석 결과가 남아 있다면 레코드가 만료될 때까지 기다리거나 시스템에서 제공하는 캐시 갱신 방법을 사용하세요. 여러 DNS를 연속으로 바꾼 직후 비교하지 마세요. 브라우저, 시스템, 클라이언트가 서로 다른 단계의 결과를 보유할 수 있어 단일 설정의 효과를 관찰할 수 없습니다.

Fallback은 우선 서버가 적합하지 않거나 결과가 특정 조건을 만족할 때 보조 해석기로 전환하는 기능입니다. 명확한 판단 조건이 없으면 여러 서버가 서로 다른 결과를 동시에 반환해 이해하기 어려워집니다. 내부 도메인에는 skipFallback을 사용해 내부 이름을 모르는 서버로 조회가 유출되지 않게 할 수 있습니다. 일반 도메인은 도메인 집합이나 주소 범위를 기준으로 폴백을 설계하고, 여러 서버를 단순히 나열한 뒤 클라이언트가 ‘가장 좋은’ 답을 자동으로 고르길 기대하지 마세요. 설정이 복잡할수록 실제로 어떤 해석기가 사용됐는지 로그에서 확인해야 합니다.

원격 DNS 실패 점검 순서

원격 DNS가 응답하지 않으면 먼저 엔드포인트에 연결을 수립할 수 있는지 직접 확인한 뒤 요청이 프록시 또는 직접 연결 중 어느 아웃바운드로 나가는지 살펴보세요. 엔드포인트가 도메인을 사용한다면 부트스트랩 해석으로 주소를 얻을 수 있는지 확인하세요. HTTPS를 사용한다면 기기의 시스템 시간이 정확한지 확인해야 합니다. 시간 오차가 TLS 연결 수립에 영향을 줄 수 있습니다. 그다음 라우팅 규칙이 DNS 엔드포인트를 차단되거나 지원하지 않는 사용자 지정 아웃바운드로 잘못 보내는지 확인하세요. 마지막으로 클라이언트 로그의 응답 형식과 타임아웃 정보를 살펴봅니다. 이 순서를 따르면 ‘엔드포인트에 연결할 수 없음’, ‘라우팅 오류’, ‘해석 결과 부적합’을 구분할 수 있습니다.

Android에서 VPN 모드를 켠 뒤에는 시스템 비공개 DNS 설정도 확인해야 합니다. 시스템 비공개 DNS, 브라우저 독립 DNS, v2rayNG 원격 DNS가 동시에 실행되면 조회 경로가 예상과 달라질 수 있습니다. 문제를 해결할 때는 먼저 v2rayNG 단일 경로만 유지해 도메인 해석과 접속이 안정적인지 확인한 뒤 시스템 기능을 하나씩 복원하세요. 데스크톱의 v2rayN에서는 시스템 프록시와 TUN을 구분해야 합니다. 시스템 프록시는 모든 프로그램의 DNS를 반드시 가로채지 않지만 TUN은 전역 네트워크 계층을 더 가깝게 통합합니다. 두 모드를 같은 방식으로 판단해서는 안 됩니다.

TUN과 시스템 프록시는 작동 계층이 다릅니다

시스템 프록시는 앱이 운영체제의 프록시 설정을 직접 읽어야 하므로 브라우저와 시스템 네트워크 설정을 따르는 소프트웨어에 적합합니다. TUN 모드는 더 낮은 네트워크 계층에서 트래픽을 받는 가상 네트워크 인터페이스를 만들어 HTTP 또는 SOCKS 프록시 설정을 지원하지 않는 프로그램까지 처리할 수 있습니다. 범위가 넓은 만큼 라우팅 테이블, DNS 가로채기, UDP, 주소 계열, 로컬 네트워크 접근, 다른 가상 네트워크 소프트웨어 등 더 많은 세부 사항을 다뤄야 합니다. TUN을 ‘더 강한 스위치’로 이해하는 것은 정확하지 않습니다. TUN은 다른 트래픽 진입점입니다.

모드를 선택할 때는 앱 요구 사항을 기준으로 하세요. 일반적인 웹 사용과 시스템 프록시를 명확히 지원하는 소프트웨어는 설정과 장애 범위가 비교적 단순한 시스템 프록시부터 사용할 수 있습니다. 특정 프로그램이 시스템 프록시를 무시하거나 UDP를 처리해야 하거나 더 많은 앱을 통합 관리하려면 TUN을 활성화하세요. 기본 연결을 확인하기 전에 TUN을 바로 추가하지 마세요. 일반 프록시 모드에서 서버, 프로토콜, 구독이 정상인지 먼저 확인한 뒤 진입점을 바꿔야 새 문제를 TUN, DNS, 라우팅 테이블 범위로 제한할 수 있습니다.

활성화 전 시스템 준비

데스크톱의 v2rayN에서 TUN을 활성화하려면 일반적으로 시스템이 가상 네트워크 카드를 만들고 라우팅을 수정하도록 허용해야 합니다. 권한이 부족하면 스위치가 켜진 것처럼 보여도 인터페이스가 제대로 생성되지 않을 수 있습니다. 버튼 상태만 보지 말고 클라이언트 로그에서 인터페이스 생성, 주소 할당, 라우팅 기록이 완료됐는지 확인하세요. 보안 소프트웨어, 방화벽, 다른 가상 네트워크 카드 도구가 드라이버를 차단하거나 라우팅 우선순위를 바꿀 수 있습니다. 처음 테스트할 때는 불필요한 유사 네트워크 도구를 끄고 변수를 하나만 남겨 v2rayN이 독립적으로 실행되는지 확인하세요.

Android의 v2rayNG는 시스템 VPN 인터페이스를 사용해 트래픽을 가로채며 시스템에 VPN 상태가 표시됩니다. 이때 애플리케이션별 프록시, 항상 켜진 VPN, 시스템 비공개 DNS, 배터리 절전 정책이 결과에 영향을 줄 수 있습니다. 시스템에서 다른 VPN 서비스를 동시에 지정하면 일반적으로 하나의 인터페이스를 함께 사용할 수 없습니다. 클라이언트를 전환하기 전 현재 연결을 먼저 끊고 상태가 완전히 해제될 때까지 기다린 뒤 새 연결을 시작하세요. 백그라운드 제한으로 클라이언트가 시스템에 의해 일시 중지될 수 있으므로 기기의 배터리 관리 규칙에서 안정적으로 실행되도록 허용해야 합니다.

스택 유형, MTU 및 UDP

TUN 구현은 여러 네트워크 스택 옵션을 제공할 수 있습니다. 시스템 스택은 운영체제 동작에 가까워 호환성이 대체로 좋고, 사용자 공간 스택은 더 많은 네트워크 처리를 클라이언트 내부에서 수행해 플랫폼 간 동작을 일관되게 유지하기 쉽습니다. 구체적인 명칭은 클라이언트 인터페이스에 따라 다르지만 선택 원칙은 같습니다. 먼저 클라이언트가 권장하는 기본 스택을 사용하고, 로그가 호환성 문제나 UDP 이상 또는 특정 앱 실패를 명확히 가리킬 때만 전환하세요. 전환 후 연결을 다시 만들고 같은 대상을 반복 테스트하세요.

MTU는 네트워크 인터페이스가 한 번에 운반하는 데이터 크기입니다. 값이 너무 크면 일부 경로에서 패킷이 조각화되거나 폐기되어 작은 페이지는 열리지만 큰 콘텐츠가 멈추거나 업로드가 실패하고 연결 후 데이터가 흐르지 않을 수 있습니다. 값이 너무 작으면 추가 오버헤드가 늘어납니다. 점검할 때는 시스템 또는 클라이언트 기본값에서 시작하고 조각화가 의심될 때만 조금씩 낮추며 매번 변경 내용을 기록하세요. 네트워크, 전송 방식, 캡슐화 계층마다 유효한 상한이 다르므로 극단적인 값을 그대로 적용하지 마세요.

UDP는 아웃바운드와 서버 설정이 함께 지원해야 합니다. TUN이 UDP를 받는다고 해서 원격에서 반드시 전달할 수 있는 것은 아닙니다. 웹은 정상인데 실시간 통신, 음성 또는 일부 도메인 해석이 실패한다면 로그에서 UDP가 올바른 아웃바운드로 들어갔는지와 현재 서버 설정이 이를 허용하는지 확인하세요. 원인을 좁히기 위해 DNS를 잠시 HTTPS 기반 조회로 바꿔 일반 UDP DNS 장애인지 전체 UDP 트래픽 장애인지 구분할 수 있습니다. 이후에는 실제 사용 환경으로 돌아가 검증해야 하며 임시 대체 방안으로 문제가 해결됐다고 판단해서는 안 됩니다.

로컬 네트워크 우회와 라우팅 루프 방지

TUN이 트래픽을 가로챈 뒤 로컬 프린터, 라우터 관리 페이지, 파일 공유가 실수로 프록시로 전송될 수 있습니다. 라우팅 규칙 앞부분에 사설 주소 직접 연결을 유지하고 필요하면 로컬 도메인을 추가하세요. 일반적인 사설 주소 집합은 코어의 geoip:private로 처리할 수 있지만 기업 네트워크가 별도의 주소 대역을 사용한다면 실제 네트워크에 맞춰 추가해야 합니다. 게이트웨이 주소, 로컬 장치 주소, 내부 도메인을 각각 방문해 주소 직접 연결과 내부 DNS가 모두 정상인지 확인하세요.

라우팅 루프는 클라이언트가 프록시 서버나 DNS 엔드포인트에 접속하는 트래픽까지 TUN이 다시 가로채 자기 자신으로 반복 전송할 때 발생합니다. 클라이언트는 보통 자체 프로세스나 서버 주소를 자동으로 제외하지만 사용자 지정 아웃바운드, 체인 프록시, 특수 네트워크 환경에서는 이 보호가 깨질 수 있습니다. 연결 직후 인터넷이 끊기거나 로그에 같은 대상이 반복해서 나타나거나 서버 연결이 계속 재수립되는 것이 대표적인 증상입니다. 프록시 서버 주소, 필요한 부트스트랩 DNS, 클라이언트 자체 통신에 명확한 도달 경로를 마련하고 모든 트래픽을 구분 없이 같은 진입점으로 보내는 기본 규칙을 피하세요.

TUN 환경의 기본 라우팅 구조

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

충돌 진단과 복구 경로

TUN을 켠 뒤 전혀 접속할 수 없다면 먼저 연결을 끊고 시스템 네트워크가 복구되는지 확인하세요. 복구되지 않으면 클라이언트를 종료하고 가상 네트워크 카드나 시스템 라우팅이 남아 있는지 점검합니다. 그런 다음 클라이언트를 다시 열되 TUN은 켜지 않고 일반 프록시로 서버를 검증하세요. 일반 프록시가 정상이라면 다른 VPN, 가상 머신 네트워크 강화 도구, 라우팅을 변경할 수 있는 소프트웨어를 끈 뒤 TUN을 다시 활성화하세요. 이때 복구되면 소프트웨어 충돌이고, 여전히 실패하면 인터페이스 생성, DNS 가로채기, 기본 라우팅 기록을 확인하세요.

일부 앱만 실패한다고 전체 설정을 초기화하지 마세요. 먼저 실패한 앱이 애플리케이션별 규칙에 포함됐는지 확인하고, TCP·UDP 중 무엇을 사용하는지 또는 자체 DNS를 사용하는지 살펴본 뒤 해당 연결의 라우팅 태그를 확인하세요. 웹은 되지만 앱 로그인이 실패한다면 앱이 다른 도메인이나 인증서 검증 경로를 사용하는 것일 수도 있습니다. 한 번에 하나의 앱만 실행하고 로그 대상만 필터링하면 문제를 특정 연결까지 좁힐 수 있습니다. 노드 타임아웃과 연결 직후 끊김의 점검 순서는 v2rayNG 노드 타임아웃 6단계 점검에서 계속 확인할 수 있습니다.

FakeDNS가 해결하는 문제

일부 앱은 먼저 자체적으로 DNS 조회를 완료한 뒤 대상 주소를 시스템에 전달합니다. 연결이 TUN에 들어올 때 코어에는 주소만 남고 원래 도메인은 사라질 수 있어 도메인 기반 라우팅 규칙이 일치하지 않습니다. FakeDNS는 제어된 조회에 가상 주소를 반환하는 동시에 ‘도메인과 가상 주소’의 매핑을 기록합니다. 이후 앱이 해당 가상 주소에 연결하면 코어가 매핑에서 원래 도메인을 복원한 뒤 도메인 규칙에 따라 실제 DNS와 아웃바운드를 선택합니다. FakeDNS는 도메인 정보를 보존하는 기능이지 공용 DNS를 대체하는 기능은 아닙니다.

이 메커니즘은 조회와 후속 연결이 같은 클라이언트를 거쳐야 합니다. 앱이 클라이언트를 우회해 독립적으로 해석하거나 연결이 TUN에 들어오지 않으면 매핑을 만들거나 사용할 수 없습니다. 브라우저 암호화 DNS, 앱 내장 해석기, 일부 직접 연결 네트워크 라이브러리가 우회 경로를 만들 수 있습니다. 따라서 FakeDNS를 활성화하기 전에 DNS 가로채기 경로가 명확하고 TUN의 기본 기능이 정상인지 확인하세요. 그렇지 않으면 문제가 매핑, DNS 우회, 가상 네트워크 카드 중 어디에서 발생했는지 구분하기 어렵습니다.

가상 주소 풀은 접속 가능한 서버가 아닙니다

FakeDNS가 반환하는 주소는 전용 가상 풀에서 가져오며 클라이언트 내부에서 특정 도메인을 나타낼 뿐 인터넷에서 실제로 접속할 수 있는 서버가 아닙니다. 테스트 도구에 가상 주소가 표시된다고 해서 해석 오류는 아닙니다. 중요한 것은 후속 연결이 클라이언트에 의해 수신되고 도메인이 복원되는지입니다. 앱이 가상 주소를 파일이나 장기 캐시에 저장하거나 다른 장치와 공유하면 클라이언트 매핑 밖에서는 의미가 없습니다. 따라서 FakeDNS 조회 결과를 영구 설정, 서버 허용 목록, 로컬 네트워크 장치 공유에 사용하지 마세요.

주소 풀은 실제 네트워크, 로컬 네트워크, 다른 가상 인터페이스와 충돌하지 않아야 합니다. 클라이언트 기본값은 일반적인 환경을 고려한 경우가 많으므로 로그에 라우팅 충돌이 나타나지 않는 한 임의로 바꾸지 않는 편이 좋습니다. 기업 네트워크가 특수 주소 대역을 사용하거나 장치에 컨테이너, 가상 머신, 다른 터널이 있다면 라우팅 테이블에 겹치는 항목이 있는지 확인하세요. 충돌이 발생하면 실제 주소가 가상 매핑으로 잘못 인식되거나 가상 연결이 다른 네트워크 카드에 의해 처리될 수 있습니다.

FakeDNS와 DNS 서버 조합 예시

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

스니핑 및 라우팅과 함께 사용하기

FakeDNS와 도메인 스니핑은 모두 코어가 도메인을 얻도록 돕지만 경로가 다릅니다. FakeDNS는 DNS 조회 단계에서 명확한 매핑을 만들며 조회가 완전히 가로채진 TUN 트래픽에 적합합니다. 스니핑은 후속 프로토콜 내용에서 도메인을 식별하려 하므로 FakeDNS를 거치지 않은 연결에 사용할 수 있습니다. 둘을 함께 사용할 수는 있지만 모든 문제를 스니핑에 맡겨서는 안 됩니다. 암호화 수준이 높거나 프로토콜 내용에 식별 가능한 도메인이 없는 연결에서는 스니핑이 실패할 수 있고, FakeDNS 매핑이 더 직접적입니다.

라우팅 규칙은 여전히 정해진 순서대로 실행됩니다. 도메인이 복원되면 정확한 도메인 규칙, 도메인 집합 규칙, 기본 규칙이 차례로 매칭됩니다. FakeDNS가 도메인을 성공적으로 복원했는데도 트래픽이 잘못된 아웃바운드로 나간다면 주소 풀을 계속 조정하지 말고 규칙 순서와 아웃바운드 태그를 확인하세요. 로그에는 일반적으로 원본 대상, 복원된 도메인, 최종 아웃바운드가 표시됩니다. 세 정보를 연결해 보아야 문제가 어느 단계에서 발생했는지 판단할 수 있습니다.

활성화를 신중히 고려해야 하는 상황

로컬 네트워크 내부 도메인, 장치 검색, 인쇄 서비스, 실제 주소 반환에 의존하는 앱은 신중하게 처리해야 합니다. 내부 도메인은 일반적으로 로컬 DNS로 보내 직접 연결해야 하며 FakeDNS에 넣지 않아야 합니다. DNS가 반환한 주소로 로컬 네트워크를 검색하거나 접근을 제어하는 소프트웨어는 가상 주소를 이해하지 못할 수도 있습니다. 내부 이름이 FakeDNS를 건너뛰고 로컬 해석기를 직접 사용하도록 도메인 규칙을 설정할 수 있습니다. 앱이 실제 주소를 반드시 받아야 한다면 애플리케이션별 우회나 실제 DNS 결과를 사용하도록 설정하세요.

서버 프로그램, 개발 디버깅 도구, 실제 대상 주소를 표시해야 하는 네트워크 분석 작업에도 FakeDNS를 기본 활성화하는 것이 적합하지 않을 수 있습니다. 로그에 가상 주소가 기록되어 분석자가 대상 서버가 해당 주소에 있다고 오해할 수 있습니다. 패킷 캡처나 문제 재현을 진행할 때는 FakeDNS 활성화 여부를 기록하고 도메인 매핑 로그도 함께 보존하세요. 그래야 가상 주소를 실제 대상으로 정확히 되돌릴 수 있습니다.

캐시 불일치와 앱 이상

FakeDNS를 끈 뒤에도 앱이 오래된 가상 주소를 보유하는 것은 흔한 전환 장애입니다. 클라이언트는 더 이상 기존 매핑을 유지하지 않는데 앱이 계속 이전 주소로 연결하므로 실패하는 것입니다. FakeDNS 상태를 바꾼 뒤에는 연결을 다시 만들고 관련 앱의 백그라운드 프로세스를 종료하세요. 필요하면 앱 DNS 캐시가 만료될 때까지 기다리세요. 반대로 FakeDNS를 방금 켠 경우에도 앱이 이전의 실제 주소를 계속 사용하면 잠시 동안 효과가 보이지 않을 수 있습니다.

특정 앱만 FakeDNS를 켠 직후 이상을 보이고 다른 앱은 정상이라면 해당 앱을 임시로 제외해 비교 기준을 만드세요. 제외 후 복구되면 자체 DNS 사용 여부, 주소 장기 캐시 여부, 로컬 네트워크 검색 의존 여부, 앱 계층에서 실제 주소를 검증하는지 확인하세요. 앱 하나가 호환되지 않는다고 모든 도메인 라우팅을 삭제하지 마세요. 해당 앱에는 실제 해석 경로를 제공하면서 다른 앱은 도메인 매핑의 이점을 계속 사용하도록 설정하는 편이 합리적입니다.

각 소스의 역할 정의

다중 구독은 링크를 모두 하나의 목록에 가져오는 것이 아닙니다. 각 소스에 명확한 역할을 부여해야 합니다. 메인 구독은 일상 사용을 담당하고, 백업 구독은 메인 소스에 문제가 있을 때만 사용하며, 테스트 구독은 새 프로토콜이나 전송 매개변수를 검증하는 용도입니다. 역할에 따라 업데이트 주기, 필터 규칙, 자동 선택 참여 여부가 달라집니다. 세 소스의 항목을 전부 섞으면 장애 발생 시 어느 구독이 원인인지 판단하기 어렵고 이름이 같은 서버를 잘못 선택하기 쉽습니다.

이름에는 개인정보보다 용도를 포함하세요. 예를 들어 ‘메인｜일상’, ‘백업｜수동 업데이트’, ‘테스트｜임시’와 같이 지정할 수 있습니다. v2rayN에서는 구독 그룹으로 소스 경계를 유지하고, v2rayNG에서는 그룹 수를 줄인 뒤 명확한 별칭으로 모바일 전환 부담을 낮추세요. v2flyNG를 Android용 대체 클라이언트로 사용할 때도 같은 소스 명명 원칙을 적용하되 두 클라이언트가 로컬 그룹 구조를 완전히 동일하게 유지한다고 가정하지 마세요.

자동 업데이트에는 실패 보호가 필요합니다

자동 업데이트는 소스 변경을 빠르게 반영하지만 구독이 일시적으로 빈 내용이나 잘못된 형식을 반환하면 기존 목록에 영향을 줄 수 있습니다. 안정적인 흐름은 최근에 사용 가능한 결과를 보존하고 새 결과가 비정상적으로 보이면 덮어쓰기를 중단하는 것입니다. 이 동작을 클라이언트가 지원하는지는 실제 인터페이스와 로그로 확인해야 합니다. 확신할 수 없다면 메인 구독은 고정 주기로 업데이트하고 백업과 테스트 구독은 수동으로 업데이트하세요. 이렇게 하면 불필요한 요청을 줄이고 모든 소스가 동시에 바뀌는 상황을 피할 수 있습니다.

업데이트 일정을 분산할 수 있습니다. 예를 들어 메인 구독은 매일 확인하고, 백업 구독은 전환이 필요할 때 수동으로 확인하며, 테스트 구독은 실험 기간에만 업데이트합니다. 업데이트 후에는 항목 수와 현재 선택 항목을 먼저 확인한 다음 일괄 속도 측정이나 연결 테스트를 진행하세요. 속도 측정은 테스트 시점의 연결 가능성만 보여 줄 뿐 프로토콜 매개변수 검증을 대신하지 않습니다. 많은 항목이 동시에 실패하면 하나씩 삭제하기보다 구독 형식, 시스템 시간, 로컬 네트워크를 먼저 확인해야 합니다.

중복 제거는 표시 이름만으로 판단할 수 없습니다

두 구독이 같은 별칭을 사용해도 서버 주소, 포트, 사용자 식별자, 전송 방식, 보안 설정이 다를 수 있습니다. 실제 중복 여부는 핵심 연결 매개변수를 종합해 비교해야 합니다. 반대로 같은 설정이 서로 다른 소스에서 다른 이름으로 표시될 수도 있습니다. 중복을 제거할 때는 먼저 소스별 경계를 유지한 뒤 완전히 같은 항목으로 확인된 것만 안정적인 하나의 소스에서 관리하세요. 서로 다른 구독이 생성한 항목을 추적할 수 없는 로컬 복사본으로 합치면 이후 매개변수 변경을 자동으로 동기화할 수 없습니다.

여러 기기에서 일관성을 유지해야 한다면 공유하기 가장 적합한 것은 구독 링크와 소량의 표준화된 설정이지 전체 클라이언트 상태가 아닙니다. 데스크톱 창 배치, 속도 측정 결과, 현재 선택 항목, Android 애플리케이션별 목록은 기기 로컬 정보이므로 무리하게 동기화할 필요가 없습니다. 동기화 가능한 계층에는 구독 소스, 표준 프로토콜 매개변수, 공통 라우팅 구상이 포함됩니다. 기기 계층에서는 시스템 프록시, TUN, 앱 선택, 로컬 DNS를 각각 관리하세요. 더 자세한 방식 비교는 구독 링크, QR 코드, 내보내기 설정 비교에서 확인할 수 있습니다.

QR 코드와 내보내기 파일의 범위

QR 코드는 자신의 기기 사이에서 단일 설정을 빠르게 이전할 때 적합합니다. 스캔한 뒤에도 프로토콜, 주소, 포트, 전송, 보안 필드가 완전한지 확인하고 별칭만 믿지 마세요. QR 코드는 생성 후 자동으로 업데이트되지 않으므로 장기간 변경되는 다중 구독 체계를 담기에 적합하지 않습니다. 장기 관리에는 구독 링크가 더 적합하고, 일회성 이전이나 소량의 테스트 설정을 오프라인으로 보관할 때는 QR 코드가 더 간편합니다.

설정 파일을 내보내면 더 많은 필드를 보존할 수 있지만 현재 기기에만 필요한 경로, 포트, 로컬 규칙이 포함될 수도 있습니다. 다른 플랫폼으로 가져오기 전에 내용을 읽고 맞지 않는 로컬 설정을 제거하며 접속 자격 증명이 포함된 파일을 공개된 위치에 두지 마세요. 이전이 끝나면 새 기기에서 단일 연결 기준선을 먼저 만든 뒤 라우팅과 DNS를 복원하세요. 데스크톱의 모든 고급 설정을 한 번에 Android로 옮기면 권한, 네트워크 진입점, 앱 선택의 차이가 동시에 문제 범위에 들어갑니다.

변경 기록과 복구 지점 만들기

다중 구독 환경에서 가장 필요한 것은 간결한 변경 기록입니다. 복잡할 필요 없이 날짜, 변경 대상, 이전 상태, 새 상태, 검증 결과만 포함하면 됩니다. 예를 들어 ‘메인 구독에 제외 단어 추가’, ‘백업 구독을 수동 업데이트로 변경’, ‘Android에 메인 소스만 가져옴’처럼 기록하세요. 목록에 이상이 생겼을 때 최근 변경이 어디에서 발생했는지 빠르게 판단할 수 있습니다. 연결 자격 증명이 포함된 설정이라면 전체 민감 필드를 복사하지 말고 변경 유형만 기록하세요.

복구 지점은 ‘연결 가능함이 검증된’ 상태를 기준으로 만들어야 합니다. 필터 규칙을 수정하기 전에 기존 표현식을 보존하고, 일괄 업데이트 전 현재 사용 가능한 항목을 기록하며, 새 설정을 가져오기 전 기존 그룹을 남겨 두세요. 업데이트 후 연결에 실패하면 먼저 선택 항목과 필터 조건을 복원한 뒤 새 구독 내용을 판단하세요. 구독을 되돌리는 동시에 DNS와 TUN 설정까지 바꾸지 마세요. 여러 계층을 한꺼번에 되돌리면 우연히 복구될 수 있지만 실제 원인을 확인할 수 없습니다.

메인·백업 전환 검증 절차

백업 구독은 정기적으로 검증해야 진정한 백업 역할을 합니다. 계속 연결해 둘 필요는 없으며 네트워크가 안정적일 때 수동으로 업데이트하고 설정 하나를 선택해 연결을 테스트한 뒤 기본 DNS와 라우팅이 작동하는지 확인하면 됩니다. 테스트가 끝나면 메인 구독으로 돌아가 현재 선택 항목이 실수로 테스트 소스에 남지 않게 하세요. 메인과 백업이 서로 다른 프로토콜이나 전송 방식을 사용한다면 각각 필요한 시스템 조건을 기록해 두어 장애 발생 시 아직 켜지지 않은 기능에 의존하는 일이 없게 하세요.

메인 소스에 문제가 생기면 구독 업데이트 실패인지 기존 서버 연결 실패인지 먼저 구분하세요. 구독을 일시적으로 업데이트할 수 없다고 이미 가져온 설정이 즉시 무효가 되는 것은 아닙니다. 기존 목록을 유지하며 계속 테스트할 수 있습니다. 서버 연결까지 실패한 경우에만 백업 소스로 전환하세요. 반대로 구독 업데이트는 성공했지만 목록이 비어 있다면 먼저 필터를 끄고 원본 내용을 확인해 로컬 필터 오류를 소스 장애로 오판하지 않도록 하세요.

아웃바운드는 라우팅 규칙의 실행 대상입니다

라우팅 규칙은 판단만 하고 실제 연결을 수립하는 것은 아웃바운드입니다. 가장 기본적인 설정에는 프록시 아웃바운드, 직접 연결 아웃바운드, 차단 아웃바운드가 포함됩니다. 프록시 아웃바운드는 현재 서버 연결을 담당하고, 직접 연결 아웃바운드는 로컬 네트워크로 대상에 접속하며, 차단 아웃바운드는 불필요한 연결을 거부합니다. 사용자 지정 아웃바운드는 여기에 지정된 SOCKS 상위 서버, 별도의 직접 연결 정책, 특정 프로토콜 연결과 같은 추가 출구를 더하는 방식입니다. 각 아웃바운드에는 고유하고 안정적인 tag가 있어야 하며 라우팅은 이 태그로 참조합니다.

태그 이름은 기능을 표현해야 합니다. 예를 들어 proxy, direct, block, upstream-socks와 같이 지정하세요. ‘회선 1’, ‘테스트 2’처럼 현재 화면을 벗어나면 의미를 잃는 이름은 사용하지 마세요. 태그를 변경할 때는 모든 라우팅 규칙, DNS 아웃바운드 참조, 체인 프록시 관계도 함께 수정해야 합니다. 한 곳만 바꾸면 설정 로딩에 실패하거나 매칭되지 않은 트래픽이 기본 출구로 들어갈 수 있습니다.

검토 가능한 기본 구조 만들기

사용자 지정 설정은 먼저 세 가지 기본 아웃바운드로 시작하고 각각의 태그가 로그에 표시되는지 확인한 뒤 추가 상위 서버를 넣으세요. 직접 연결에는 freedom 프로토콜, 차단에는 blackhole을 사용하며 프록시 아웃바운드는 현재 클라이언트가 생성하거나 구독 설정에서 제공합니다. 코어 전체 설정을 직접 편집할 때는 클라이언트가 연결 시 설정을 다시 생성할 수 있다는 점에 유의하세요. 인터페이스에 사용자 지정 설정 진입점이 있다면 지원되는 덮어쓰기 또는 병합 방식을 사용해 임시 파일 수정 내용이 다음 연결에서 사라지지 않게 하세요.

기본 아웃바운드와 SOCKS 상위 서버 예시

{
  "outbounds": [
    {
      "tag": "direct",
      "protocol": "freedom",
      "settings": {}
    },
    {
      "tag": "block",
      "protocol": "blackhole",
      "settings": {
        "response": {
          "type": "none"
        }
      }
    },
    {
      "tag": "upstream-socks",
      "protocol": "socks",
      "settings": {
        "servers": [
          {
            "address": "127.0.0.1",
            "port": 1081,
            "users": [
              {
                "user": "example-user",
                "pass": "your-password"
              }
            ]
          }
        ]
      }
    }
  ]
}

예시에 나온 로컬 SOCKS 서비스는 해당 주소와 포트에서 실제로 실행 중이어야 합니다. 그렇지 않으면 이 아웃바운드로 라우팅된 연결이 즉시 실패합니다. 상위 서버에 인증이 필요하지 않다면 빈 문자열을 남기지 말고 코어가 지원하는 형식에 맞춰 사용자 필드를 제거하세요. 원격 상위 서버에 연결할 때는 해당 주소가 다시 같은 아웃바운드에 의해 처리되어 루프가 생기지 않는지 확인해야 합니다. 접속 자격 증명은 통제된 자신의 설정에만 저장하고, 문제 해결용 화면 캡처와 로그를 공유하기 전에 관련 필드를 삭제하세요.

체인 프록시의 방향을 명확히 하세요

체인 프록시는 한 아웃바운드의 하위 연결이 다른 아웃바운드를 통해 수립되는 구조입니다. 명확한 네트워크 토폴로지가 필요한 상황에 적합하지만 지연, 장애 지점, 로그 복잡도가 늘어납니다. 설계 전에 순서를 그려 보세요. 앱 트래픽이 클라이언트에 들어오고, 라우팅이 업무 아웃바운드를 선택하며, 업무 아웃바운드가 다시 상위 출구를 통해 대상에 연결합니다. 체인의 각 계층은 독립적으로 도달 가능해야 하고 상위 연결 자체가 다시 업무 아웃바운드로 돌아가서는 안 됩니다.

체인 구조를 검증할 때는 가장 바깥쪽 상위 서버를 단독으로 테스트한 뒤 내부 연결을 추가하세요. 상위 서버가 로컬 SOCKS 서비스라면 SOCKS를 명확히 지원하는 도구로 포트가 열려 있는지 먼저 확인하세요. 상위 서버도 클라이언트 내부 아웃바운드라면 테스트 도메인 하나만 대상으로 하는 정확한 라우팅을 먼저 작성하세요. 로그가 두 태그를 예상대로 통과하는지 확인한 뒤 매칭 범위를 넓히세요. 검증되지 않은 체인으로 기본 트래픽을 모두 전환하면 실패 시 조회, 업데이트, 문제 해결에 필요한 연결까지 동시에 잃을 수 있습니다.

DNS 트래픽도 출구를 선택해야 합니다

사용자 지정 아웃바운드를 추가한 뒤에도 DNS 요청은 기존 경로를 계속 사용할 수 있습니다. 대상 접속은 upstream-socks를 거치는데 원격 DNS는 직접 연결로 나가면 해석 위치와 접속 출구가 일치하지 않습니다. 일치가 필요한지는 상황에 따라 다르지만 우연히 결정되어서는 안 됩니다. DNS 엔드포인트에 정확한 라우팅을 추가해 지정 아웃바운드로 보내거나 내부 DNS는 항상 직접 연결하도록 설정할 수 있습니다. 변경 후 DNS 엔드포인트 연결과 대상 연결이 각각 예상 태그에 적중하는지 확인하세요.

DNS 루프도 방지해야 합니다. 상위 아웃바운드의 서버 주소가 도메인이고 그 도메인을 해석하는 DNS가 다시 같은 상위 서버로 라우팅되면 상위 연결이 아직 수립되지 않은 상태에서 의존성이 순환할 수 있습니다. 해결 방법으로는 상위 주소에 신뢰할 수 있는 부트스트랩 해석을 제공하거나, 명확히 도달 가능한 주소를 사용하거나, 해당 DNS 조회에 독립적인 직접 연결 경로를 설정하는 방법이 있습니다. 네트워크 조건에 따라 방법은 달라지지만 핵심은 상위 연결을 수립하는 데 필요한 기반 연결이 상위 서버 자체에 의존하지 않게 하는 것입니다.

차단 아웃바운드와 실패 현상

차단 아웃바운드는 필요하지 않은 연결을 명확히 거부할 때 사용합니다. 겉으로는 ‘연결 실패’와 비슷해 보일 수 있지만 로그에는 트래픽이 block 태그에 적중한 사실이 표시되어야 합니다. 대상에 접속할 수 없을 때는 특히 넓은 도메인 접미사나 포트 조건을 사용할 경우 차단 규칙에 잡혔는지 먼저 확인하세요. 차단 규칙은 적절한 우선순위에 두고 설명 가능한 범위로 제한해야 합니다. 범위가 너무 넓으면 정상 리소스, 로그인 과정, 클라이언트 업데이트 요청까지 함께 거부됩니다.

차단 방식은 조용히 폐기할 수도 있고 적극적으로 거부를 반환할 수도 있습니다. 앱마다 두 방식의 표시가 다릅니다. 조용한 폐기는 대기 후 타임아웃으로 나타나는 경우가 많고, 적극적인 거부는 더 빠르게 실패합니다. 선택할 때는 불필요한 대기를 줄이고 앱 호환성을 유지하는 것을 기준으로 삼으세요. 불명확한 대상을 대량 차단해 애플리케이션별 설정과 라우팅 설계를 대신하지 마세요. 규칙을 해석하기 어려울수록 유지 관리 비용이 커집니다.

클라이언트 생성 설정과 수동 설정의 경계

v2rayN, v2rayNG, v2flyNG는 모두 인터페이스 설정을 바탕으로 코어 실행 설정을 생성합니다. 수동 예시는 필드 관계를 이해하기 위한 것이며 모든 클라이언트에서 전체 JSON을 그대로 붙여 넣을 수 있다는 뜻은 아닙니다. 클라이언트가 사용자 지정 설정 가져오기를 제공한다면 전체 설정, 일부 덮어쓰기, 단일 아웃바운드 조각 중 무엇을 요구하는지 먼저 확인하세요. JSON 문법이 올바르더라도 형식이 맞지 않거나 클라이언트가 요구하는 구조가 없으면 시작되지 않을 수 있습니다.

클라이언트를 업그레이드하거나 전환하기 전에 어떤 내용이 구독에서 왔고, 어떤 내용이 클라이언트 인터페이스에서 왔으며, 어떤 내용이 수동 덮어쓰기인지 기록하세요. 구독 서버 매개변수는 다시 가져올 수 있지만 복잡한 사용자 지정 아웃바운드와 라우팅은 별도로 백업해야 합니다. 백업한 뒤 텍스트에서 태그 참조를 확인하세요. 모든 outboundTag는 실제 아웃바운드에 대응해야 하고, 모든 체인 참조에는 대상이 있어야 하며, 모든 DNS 라우팅은 상위 연결이 수립되기 전에 필요한 해석을 완료할 수 있어야 합니다.

최소 규칙부터 단계적으로 적용

사용자 지정 아웃바운드를 적용할 때는 먼저 전용 테스트 도메인 하나를 새 태그에 연결하고 나머지 트래픽은 그대로 유지하세요. 로그에서 새 아웃바운드 적중, 올바른 DNS 경로, 루프 없음이 확인되면 도메인 집합이나 앱 범위를 단계적으로 넓히세요. 범위를 확장할 때마다 변경 내용을 기록하고 새 규칙을 빠르게 삭제할 수 있도록 보존하세요. 실패하면 가장 최근 계층만 되돌리고 이미 검증한 구독, 서버, 기본 라우팅은 초기화하지 마세요.

최종 설정은 네 가지 질문에 답할 수 있어야 합니다. 각 트래픽 유형은 어느 규칙에 매칭되는가, 규칙은 어떤 아웃바운드를 선택하는가, 아웃바운드는 하위 연결을 어떻게 수립하는가, 연결 수립에 필요한 DNS는 어디로 나가는가. 어느 한 단계라도 추측에 의존해야 한다면 장기 실행에 적합한 설정이 아닙니다. 복잡한 장애가 발생하면 먼저 proxy, direct, block의 기본 구조를 복원한 뒤 사용자 지정 출구를 하나씩 추가하세요. 플랫폼에 맞는 클라이언트를 다시 선택해야 한다면 선택 가이드와 설치 패키지 페이지를 확인하세요.