V2Ray 고급 설정
라우팅·DNS·TUN

01 / 설정 소스

구독 그룹 및 서버 필터

그룹의 역할과 한계

구독 그룹은 우선 소스를 관리하는 기능이지, 트래픽을 분기하는 규칙이 아닙니다. 일반적으로 그룹에는 구독 주소, 업데이트 옵션, 해당 소스에서 가져온 서버 항목이 저장됩니다. 서버를 그룹으로 옮겨도 특정 웹사이트가 자동으로 그 서버를 사용하지는 않습니다. 웹사이트별 연결 경로는 현재 연결 설정과 라우팅 규칙으로 결정됩니다. 이 차이를 먼저 이해해야 목록 정리를 네트워크 정책 설정으로 착각하지 않습니다.

v2rayN에서 먼저 구독 그룹 관리 화면을 열고 용도를 알기 쉬운 이름으로 새 그룹을 만든 다음, 구독 제공처의 주소를 입력하세요. ‘일상 사용’, ‘예비 연결’처럼 용도나 소스를 드러내는 이름을 권장합니다. 구분하기 어려운 알파벳만 쓰는 것은 피하세요. 저장한 뒤 해당 그룹을 업데이트하고 서버 목록에서 가져온 항목을 확인합니다. 메뉴 위치는 버전에 따라 다를 수 있으므로 화면의 기능명과 설명을 기준으로 찾으세요.

구독 주소에는 접속 인증 정보가 포함될 수 있으므로 계정 정보처럼 다뤄야 합니다. 화면을 공유하기 전에는 주소와 QR 코드를 가리고, 전체 링크를 공개 로그에 붙여 넣지 마세요. 브라우저에서 주소가 열린다고 해서 응답 내용이 현재 클라이언트에 맞는 것은 아닙니다. 로그인 페이지, 안내 페이지, 형식 변환 결과가 일반 텍스트로 내려올 수도 있습니다. 이 경우 업데이트 완료로 표시되더라도 사용할 수 있는 서버가 없을 수 있습니다.

서버 필터

필터는 목록을 좁히거나 업데이트 후 남길 항목을 제어하는 데 사용하지만, 클라이언트마다 적용 범위가 다릅니다. 화면에 표시되는 항목만 제한하는 경우도 있고, 구독을 해석하는 단계에서 항목을 제외하는 경우도 있습니다. 처음에는 간단한 이름 키워드로 동작을 확인하세요. 업데이트 전 목록을 기록하고 조건을 저장한 뒤 해당 그룹을 다시 업데이트하고, 필터를 지워 결과를 비교합니다. 실제 적용 범위를 파악한 다음에 복잡한 조건을 조합하세요.

입력란에서 정규식을 지원한다고 명시한 경우에는 아래 패턴으로 이름에 포함된 두 가지 용도 표현을 찾을 수 있습니다. 세로줄은 ‘또는’, 괄호는 그룹을 나타냅니다. 일반 텍스트만 지원하는 입력란에 정규식을 붙여 넣어도 같은 결과가 나오지 않습니다. 이름은 구독 제공처가 정하므로 업데이트 때 바뀔 수 있습니다. 지역 약칭, 배율 표기, 프로토콜명도 표기 방식이 일정하지 않을 수 있으므로 필터 조건은 넉넉하게 설정하세요.

(일상|예비)

입력란이 ‘일치 항목 유지’ 방식인지 ‘일치 항목 제외’ 방식인지 먼저 확인하세요. 같은 표현식도 모드에 따라 결과가 정반대로 달라집니다. 목록이 비어 있으면 클라이언트를 바로 다시 설치하지 마세요. 필터를 지우고 모든 그룹을 선택한 뒤 검색어를 비우고, 소스 하나만 업데이트하세요. 항목이 다시 나타난다면 문제는 서버 연결 설정이 아니라 표시 또는 필터 계층에 있습니다.

업데이트와 수동 수정

구독 항목은 보통 원격 데이터로 다시 생성됩니다. 주소, 포트, 전송 설정을 직접 수정하면 다음 업데이트 때 원래 값으로 돌아갈 수 있습니다. 오래 유지해야 하는 변경 사항은 항목을 별도로 복사해 다른 이름으로 저장하고, 복사 날짜와 용도를 함께 기록하세요. 이렇게 하면 구독 업데이트를 계속 받으면서도 어떤 항목이 구독 관리에서 분리되었는지 알 수 있어 새 설정이 이전 값으로 덮이는 일을 막을 수 있습니다.

Android의 v2rayNG와 v2flyNG에서도 소스별로 구독을 관리하세요. QR 코드 가져오기는 단일 설정에 적합하고, 구독 가져오기는 이후 일괄 업데이트에 적합합니다. 두 방식은 데이터 관리 관계가 다릅니다. 다른 기기에서 옮겨 올 때는 내보낸 항목이 단일 연결인지, 구독 주소인지, 앱 전체 설정인지 먼저 확인한 뒤 알맞은 가져오기 메뉴를 선택하세요. 서로 다른 형식을 반복해서 시도하지 마세요.

업데이트에 실패하면 현재 사용 가능한 항목을 먼저 보존한 뒤 시스템 시간, 구독 만료 여부, 업데이트 요청에 기존 프록시가 필요한지 확인하세요. 일부 클라이언트는 현재 프록시를 통해 업데이트할 수 있지만, 다른 클라이언트는 직접 연결을 사용합니다. 현재 네트워크에서 접속 가능한 방법으로 그룹 하나를 업데이트해 성공을 확인한 뒤 자동 업데이트를 고려하세요. 아직 검증되지 않은 연결 하나에 모든 소스를 의존하게 하지 마세요.

정리를 마친 뒤 항목 하나를 테스트 기준으로 선택하고 자동 전환이나 복잡한 필터는 잠시 꺼 두세요. 먼저 일반 시스템 프록시에서 연결이 작동하는지 확인한 다음 라우팅과 DNS 설정을 살펴보세요. 소스 관리는 ‘설정이 어디서 오는가’를, 연결 테스트는 ‘설정이 작동하는가’를 확인합니다. 두 항목을 따로 기록해야 이후 문제 범위를 좁힐 수 있습니다.

03 / 도메인 이름 해석

DNS 설정 최적화

DNS 요청 경로

DNS 최적화는 응답 속도보다 경로의 일관성을 먼저 확인해야 합니다. 한 번의 접속에도 시스템 리졸버, 브라우저 내장 암호화 DNS, 클라이언트 DNS, 원격 서버의 DNS 해석이 차례로 관여할 수 있습니다. 누가 조회를 보내고, 어떤 아웃바운드로 전달되며, 결과를 누가 사용하는지 알아야 변경 효과를 판단할 수 있습니다. 서버 주소 하나만 바꿔서는 전체 DNS 경로를 제어하기 어렵습니다.

시스템 프록시는 주로 프록시 설정을 따르는 앱 요청을 전달하며, 시스템 DNS까지 반드시 가로채지는 않습니다. 브라우저는 도메인을 프록시에 바로 전달할 수도 있고 먼저 직접 해석할 수도 있습니다. 다른 프로그램은 지정된 DNS 주소로 직접 요청을 보낼 수도 있습니다. 따라서 클라이언트에 DNS를 입력했다고 해서 기기의 모든 조회가 그 서버를 사용하는 것은 아닙니다. 브라우저 설정, 시스템 네트워크 설정, 클라이언트의 가로채기 범위를 각각 확인하세요.

원격 DNS와 직접 연결 DNS의 구분은 라우팅 목표에 맞춰야 합니다. 직접 연결할 리소스는 현재 네트워크에서 접근 가능한 리졸버를 사용하는 것이 일반적이고, 프록시 대상은 DNS 요청이 의도한 경로로 전달되는지 확인해야 합니다. 암호화 DNS 서버를 도메인 주소로 지정했다면 서버 주소 자체를 먼저 해석해야 합니다. 이를 부트스트랩 DNS라고 하며, 경로가 잘못되면 리졸버가 자기 자신의 주소를 해석하기를 기다리는 의존 문제가 생길 수 있습니다.

코어 DNS 설정 예시

아래는 기본 설정에 들어가는 부분 dns 객체입니다. 중국 본토 도메인은 지정한 서버에 우선 전달하고, 나머지 조회에는 DoH 주소를 사용합니다. 도메인별로 리졸버를 할당하는 구조를 설명하는 예시이며 모든 네트워크에 적합하다고 보장하지는 않습니다. DoH 요청의 아웃바운드는 실제 코어와 설정에 따라 달라지므로 라우팅과 로그를 확인해야 합니다. 주소 접두사만 보고 반드시 프록시를 거친다고 판단하지 마세요.

{
  "dns": {
    "queryStrategy": "UseIPv4",
    "servers": [
      {
        "address": "223.5.5.5",
        "domains": ["geosite:cn"]
      },
      "https://1.1.1.1/dns-query"
    ]
  }
}

domains는 해당 서버에서 우선 처리할 도메인 범위를 지정하지만, 조회 실패 후 동작은 폴백 옵션과 코어 구현에도 영향을 받습니다. 이를 엄격한 네트워크 격리 정책으로 이해해서는 안 됩니다. 특정 조회가 다른 리졸버로 절대 전달되지 않도록 해야 한다면 현재 코어가 지원하는 폴백 필드와 실패 동작, 실제 네트워크 경로를 확인한 뒤 규칙을 설계하세요. 이 예시만 남겨서는 충분하지 않습니다.

여기서 queryStrategy는 코어 DNS의 조회 방식을 제한합니다. 운영체제의 IPv6를 끄거나 모든 앱이 다른 레코드를 직접 조회하는 것을 막지는 않습니다. IPv4를 선택하면 듀얼 스택 문제를 분리해 테스트할 수 있지만, 일반적인 속도 향상 옵션은 아닙니다. 현재 네트워크와 서버에서 IPv6가 정상 작동한다면 별도로 검증한 뒤 유지 여부를 결정하세요. 관련 문제를 장기간 숨겨 두지 마세요.

캐시 및 단계별 확인

DNS 설정을 바꾼 뒤에도 기존 결과가 시스템, 브라우저, 앱, 코어 캐시에 남아 있을 수 있습니다. 대상 앱을 종료하고 클라이언트를 재시작한 다음 시스템에서 제공하는 방법으로 캐시를 갱신하세요. 비교할 때는 같은 도메인을 사용하고 해석 결과와 실제 연결 주소를 기록합니다. 웹페이지를 한 번 새로고침한 것만으로 새 설정이 적용됐다고 판단하지 마세요. 페이지 리소스가 로컬 캐시에서 제공되거나 기존 연결이 재사용될 수 있습니다.

‘IP 주소로는 접속되지만 도메인으로는 열리지 않는’ 경우 먼저 DNS를 확인하세요. ‘도메인은 해석되지만 연결에 실패하는’ 경우에는 라우팅과 원격 연결을 이어서 점검해야 합니다. DNS 해석 성공은 주소를 얻었다는 뜻일 뿐, 현재 네트워크 경로에 적합한 주소라는 뜻은 아닙니다. 일부 서비스는 리졸버의 위치에 따라 다른 접속 주소를 반환합니다. 직접 연결 DNS의 결과를 원격 아웃바운드에서 사용하면 불필요한 우회나 연결 실패가 생길 수 있습니다.

브라우저에서만 문제가 생긴다면 브라우저의 사용자 지정 보안 DNS를 잠시 끄고 시스템 설정을 따르도록 바꿔 비교하세요. 특정 앱에서만 문제가 생긴다면 별도의 DNS를 사용하거나 고정 주소에 접속하는지 확인합니다. 테스트를 마친 뒤 최종 정책을 결정하세요. 임시로 끄는 것은 문제 범위를 좁히기 위한 절차이지, 모든 네트워크에서 같은 DNS 방식을 사용하라는 뜻은 아닙니다.

클라이언트의 ‘원격 DNS’, ‘직접 연결 DNS’ 같은 입력란은 설정 생성기를 통해 여러 코어 객체로 변환될 수 있습니다. 우선 같은 입력 화면에서 설정을 마치고, 사용자 지정 JSON에 반대되는 설정을 중복해서 작성하지 마세요. 수동으로 확장해야 한다면 최종 생성 파일을 확인해 객체가 중복되거나 덮어쓰이지 않는지 점검한 뒤, 적용된 변경 사항을 별도의 기록에 남기세요.

05 / 도메인 매핑

FakeDNS

가상 주소와 원래 도메인

FakeDNS는 도메인에 주소 풀의 가상 주소를 반환하고 내부에 주소와 도메인의 매핑을 저장합니다. 이후 앱이 해당 가상 주소에 연결하면 연동된 진입점이 원래 도메인을 복원해 라우팅과 아웃바운드로 전달합니다. FakeDNS는 공용 리졸버가 아니며 대상 웹사이트의 주소를 새로 만드는 기능도 아닙니다. 도메인 정보를 유지해 로컬에서 실제 주소를 해석하는 과정이 이후 라우팅 판단에 미치는 영향을 줄이는 데 목적이 있습니다.

이 방식은 DNS 조회와 연결이 같은 제어 경로를 따라야 합니다. DNS 조회만 FakeDNS로 보내고 이후 연결은 클라이언트를 우회하면 앱이 실제 서버 주소가 아닌 가상 주소에 직접 접속하려고 합니다. 반대로 연결은 진입점으로 들어오더라도 조회를 브라우저의 별도 암호화 DNS가 처리하면 클라이언트에 매핑이 생성되지 않아 도메인을 예상대로 복원할 수 없습니다.

따라서 FakeDNS를 일반 DNS 주소처럼 시스템에 입력하지 마세요. 클라이언트와 진입점 구성 요소가 해당 모드를 명시적으로 지원하는지 확인한 뒤, 같은 구현에 맞춰 DNS 가로채기, 주소 풀 라우팅, 매핑 복원을 설정하세요. v2rayN이 실행하는 TUN 구성 요소는 자체 가상 주소 기능을 사용할 수 있습니다. 기능 이름이 비슷하다는 이유로 코어의 다른 FakeDNS까지 함께 켜지 마세요.

Xray 부분 설정

아래는 Xray의 관련 설정 계층 세 가지를 보여 줍니다. 최상위 주소 풀, DNS 서버 목록, 대상 인바운드에 병합할 스니핑 객체입니다. 주소 풀에는 테스트용으로 예약된 주소 대역을 사용하며 공용 인터넷의 목적지 주소가 아닙니다. 이 예시는 투명 인바운드를 만들거나 시스템 경로를 추가하지 않습니다. 관련 조건이 빠진 상태에서 복사해도 기기 전체에 FakeDNS 기능이 자동으로 적용되지 않습니다.

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

{
  "sniffing": {
    "enabled": true,
    "destOverride": ["fakedns"],
    "routeOnly": false
  }
}

ipPool은 가상 주소 범위를 정의하고, poolSize는 매핑 풀의 용량을 지정합니다. 풀 안의 주소는 식별을 위한 값일 뿐, 실제 원격 주소처럼 직접 연결 아웃바운드에 전달해서는 안 됩니다. 설정 전에 기존 LAN, 다른 터널, 테스트 네트워크가 같은 범위를 사용하는지도 확인하세요. 주소 범위가 충돌하면 일부 연결이 물리 인터페이스나 다른 가상 인터페이스로 잘못 전달될 수 있습니다.

destOverride의 fakedns는 매핑을 이용해 목적지를 복원합니다. 여기서는 routeOnly: false를 명시했습니다. 라우팅 판단에만 사용하고 가상 주소를 실제 연결 대상으로 유지하면 이 예시의 목적을 달성할 수 없습니다. 일반 HTTP 또는 TLS 스니핑과 FakeDNS 매핑은 서로 다른 방식입니다. 필드 이름이 비슷하다는 이유만으로 서로 대체하지 마세요.

호환성 및 문제 해결

활성화한 뒤 일반 도메인 하나의 해석 결과가 설정한 풀에 포함되는지 확인하고, 연결 시 도메인이 올바르게 복원되는지 살펴보세요. 결과가 여전히 실제 공인 주소라면 DNS 조회가 대상 경로로 들어오는지 확인합니다. 가상 주소를 받았지만 연결에 실패한다면 주소 풀 트래픽이 연동된 진입점으로 되돌아오는지, 진입점이 같은 매핑 상태를 사용하는지 먼저 점검하세요.

일부 프로그램은 주소 유형을 로컬에서 확인해 예약 주소를 거부하거나 해석 결과를 다른 기기에 전달합니다. 이런 환경에서는 FakeDNS가 적합하지 않을 수 있습니다. LAN 기기 검색, 실제 주소가 필요한 서비스, 특정 네트워크 진단 도구에는 클라이언트가 지원하는 방식으로 실제 DNS 예외를 설정하세요. 예외는 DNS와 라우팅을 모두 처리해야 합니다. 가상 주소 범위만 직접 연결로 지정해서는 해결되지 않습니다.

재시작 후에도 시스템이나 앱이 이전 가상 주소를 캐시하고 있을 수 있지만, 새 프로세스의 매핑 테이블은 이미 바뀌었을 수 있습니다. 이로 인해 ‘처음에는 작동했는데 재시작 후 일부 기능이 실패’하는 현상이 생깁니다. 관련 캐시를 지우고 대상 앱을 재시작한 뒤 설정 오류인지 판단하세요. 이전 가상 주소를 장기적인 hosts 항목으로 저장하거나 서비스의 고정 접속 주소로 사용하지 마세요.

일반 DNS와 도메인 스니핑만으로 라우팅 요구 사항을 충족한다면 설정을 늘리기 위해 FakeDNS를 켤 필요는 없습니다. FakeDNS는 도메인 정보를 유지해야 하는 명확한 문제를 해결하는 기능이지 모든 네트워크의 기본 최적화가 아닙니다. 앱 하나로 효과와 호환성을 먼저 확인하고, 쉽게 복구할 수 있는 설정 사본을 보관한 뒤 적용 범위를 단계적으로 넓히세요.

07 / 출구 구성

사용자 지정 아웃바운드

태그와 프로토콜 객체

아웃바운드는 트래픽을 받은 뒤 다음 연결을 어떻게 만들지 정의합니다. 라우팅의 outboundTag는 참조일 뿐이며 실제 아웃바운드 객체의 tag와 일치해야 합니다. 태그는 대소문자를 구분하므로 짧고 용도가 분명한 이름을 사용하세요. 존재하지 않는 태그를 가리키는 규칙을 추가해도 클라이언트가 연결을 자동 생성하지 않습니다. 시작 시 검사 또는 실제 전달 과정에서 오류가 날 수 있습니다.

클라이언트가 생성한 아웃바운드와 수동으로 추가한 아웃바운드를 구분하세요. v2rayN은 보통 현재 서버를 바탕으로 원격 연결 객체를 생성하며, 서버를 전환하면 객체가 다시 만들어질 수 있습니다. 임시 파일을 직접 편집하면 재시작 때 변경 사항이 사라질 수 있습니다. 클라이언트가 명시적으로 제공하는 사용자 지정 설정 메뉴를 사용하고, 기본 설정에 병합하는지, 대체하는지, 완전히 제어권을 넘기는지 확인하세요.

아래는 직접 연결, 차단, 로컬의 다른 SOCKS 서비스로 전달하는 아웃바운드의 독립적인 예시입니다. 원격 서버의 인증 정보는 포함하지 않습니다. 지정한 주소에서 해당 로컬 서비스가 실제로 수신 대기 중이고 현재 진입점 자체는 아니라고 가정합니다. 복사하기 전에 수신 포트를 확인하세요. 트래픽이 같은 처리 경로로 다시 전달되어 루프가 생길 수 있습니다.

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

freedom은 코어가 실행되는 네트워크를 통해 직접 연결한다는 뜻이지, 이 기기의 다른 모든 네트워크 도구를 우회한다는 뜻은 아닙니다. 시스템 기본 경로가 이미 다른 터널을 가리키면 직접 연결 아웃바운드도 그 터널을 거칠 수 있습니다. 실제 출구를 판단할 때는 운영체제 라우팅과 클라이언트 로그를 함께 확인하세요. 태그 이름이 direct라고 해서 물리 네트워크를 사용한다고 단정하지 마세요.

blackhole은 일치한 트래픽을 버리는 데 사용합니다. 차단 아웃바운드는 연결할 필요가 없는 대상을 명확히 지정할 때 적합하지만 설정 오류를 해결하기 위한 기본 수단으로 사용해서는 안 됩니다. 서비스가 작동하지 않으면 차단 규칙에 잘못 일치했는지 먼저 확인한 뒤 매칭 범위를 조정하세요. 요청이 조용히 실패하면 오래 기다리는 것처럼 보일 수 있으므로 문제 해결 시 차단 규칙을 따로 점검해야 합니다.

규칙 연결 및 기본 출구

아래 규칙은 문서 예시 도메인을 로컬 SOCKS 아웃바운드로 전달합니다. 포괄적인 기본 규칙보다 앞에 넣으세요. 예시 도메인은 문법을 설명하기 위한 것이므로 실제 환경에서는 필요한 대상으로 바꾸세요. 서비스 범위가 넓다면 실제 요청을 바탕으로 도메인을 추가하세요. 모든 포트를 로컬 서비스로 넘기면 관련 없는 앱의 출구까지 바뀔 수 있습니다.

{
  "type": "field",
  "domain": ["full:example.com"],
  "outboundTag": "local-socks"
}

규칙에 일치하지 않으면 코어는 보통 기본 아웃바운드를 사용하며, 일반적인 설정에서는 아웃바운드 배열의 첫 항목과 관련이 있습니다. 위 예시의 첫 항목은 직접 연결이므로, 전체를 기존 설정에 그대로 붙여 넣고도 일치하지 않은 트래픽이 프록시를 이용한다고 가정해서는 안 됩니다. 기존 원격 객체를 보존하고 기본 동작을 명확히 지정하거나 배열 순서를 다시 확인해 최종 동작이 예상과 일치하게 하세요.

체인 연결의 범위

로컬 서비스로 전달하는 방식과 코어 내부의 체인 연결은 서로 다른 설정 방식입니다. 전자는 다른 수신 포트에 연결한 뒤 해당 서비스가 처리를 이어갑니다. 후자는 사용하는 코어가 지원하는 아웃바운드 조합 필드에 의존합니다. 코어마다 필드와 적용 계층이 다를 수 있으므로 한 구현의 전송 설정을 다른 구현에 복사하지 마세요. 클라이언트가 명시적으로 지원하고 동작을 확인하기 쉬운 방식을 우선 사용하세요.

전달 단계를 추가했다면 각 연결 구간을 따로 검증해야 합니다. 먼저 로컬 SOCKS 서비스가 독립적으로 작동하는지 확인하고, 코어가 해당 포트에 연결되는지 테스트한 뒤 규칙이 일치하는지 확인하세요. 앞 단계는 정상인데 전체 경로가 실패한다면 DNS 해석 위치, UDP 지원, 추가 캡슐화 필요 여부를 점검합니다. 원인을 알 수 없게 되므로 양쪽 설정을 동시에 바꾸지 마세요.

사용자 지정 아웃바운드가 안정적으로 작동하면 용도 설명, 태그 매핑, 복구 방법을 저장하세요. 민감한 연결 정보는 보호된 클라이언트 설정에 보관하고 일반 유지보수 문서에 복사하지 마세요. 필요한 규칙만 조정하고 구독을 바꿀 때마다 아웃바운드 전체를 다시 작성하지 마세요. 설정 소스와 출구 구성을 분리하면 업데이트와 복구를 제어하기 쉬워집니다.