v2rayN 고급 설정
구독, 라우팅, 네트워크 모드

구독 그룹과 서버 필터

구독 주소는 서버 정보를 갱신하는 경로이고, 구독 그룹은 클라이언트가 정보를 저장하고 관리하는 단위이며, 서버 항목은 실제 연결에 사용하는 구체적인 설정입니다. 목록을 정리하기 전에 이 세 가지를 구분하세요. 그룹 이름을 바꿔도 원격 구독 내용은 대개 바뀌지 않으며, 목록 필터를 전환해도 현재 사용 중인 서버가 자동으로 바뀌지 않습니다. 문제를 진단할 때는 그룹 출처, 목록에 표시되는 범위, 현재 활성 서버를 각각 기록해 관리 화면의 변화와 네트워크 상태의 변화를 혼동하지 않도록 하세요.

그룹을 만든 뒤 서버 업데이트

v2rayN의 구독 그룹 설정에서 구독 출처마다 별도의 그룹을 만들고 전체 구독 주소를 입력해 저장한 다음, 해당 그룹을 업데이트하세요. 이름은 ‘업무용 구독’, ‘백업 구독’처럼 출처와 용도를 알 수 있게 정하고, 출처에서 자동 생성된 서버 이름만으로 소속을 구분하지 마세요. 처음에는 그룹 하나만 업데이트해 항목을 가져오고 서버를 선택해 연결되는지 확인한 뒤 다른 출처를 추가하세요. 오류가 발생해도 어느 작업에서 문제가 생겼는지 쉽게 찾을 수 있습니다.

구독 링크에는 접근 인증 정보가 포함될 수 있으므로 계정 정보처럼 관리하세요. 전체 주소가 보이는 스크린샷이나 공개 로그, 공유 메모를 만들지 마세요. 문제를 설명할 때는 요청 방식과 오류 유형만 남기고 호스트 일부는 가리세요. 주소를 복사한 뒤 앞뒤 공백이나 줄바꿈, 메신저가 덧붙인 문장부호가 없는지 확인하세요. 서비스 제공자가 클라이언트별 접속 경로를 여러 개 제공한다면, 여러 링크를 무작정 붙여 넣기보다 현재 클라이언트와 호환되는 형식을 선택하세요.

업데이트에 실패하면 먼저 구독 업데이트 로그를 확인하세요. 연결 시간 초과는 제한 시간 안에 요청이 끝나지 않았다는 뜻이고, 인증 실패는 대개 주소에 포함된 인증 정보를 확인해야 합니다. 요청은 성공했지만 파싱에 실패했다면 로그인 페이지를 받았거나 데이터 형식이 호환되지 않을 수 있습니다. 이미 사용할 수 있는 연결이 있다면 클라이언트의 프록시 경유 업데이트 기능을 시도할 수 있지만, 처음 가져올 때는 쓸 수 있는 프록시가 없을 수 있으므로 항상 해결책이 되는 것은 아닙니다. 원본 응답에 민감한 정보가 포함되어 있다면 그대로 공개 업로드하지 마세요.

연결 설정은 바꾸지 않고 목록만 필터링

서버 필터는 특정 지역 이름이 포함된 항목만 보거나 더는 사용하지 않는 용도 태그를 제외하는 등 후보를 좁힐 때 유용합니다. 먼저 필터가 어느 그룹의 어떤 필드에 적용되는지 확인한 다음 조건을 입력하세요. 일반 키워드와 정규식은 문법이 다릅니다. UI에서 정규식을 지원한다고 명시한 경우에만 정규식 문법을 사용하세요. 그렇지 않으면 괄호나 파이프 기호도 문자 그대로 검색될 수 있습니다. 필터를 적용한 뒤에도 현재 활성 서버는 직접 확인해야 합니다.

필터가 정규식을 지원한다고 명시된 경우, 아래 표현식으로 이름에 키워드 두 개 중 하나가 포함된 항목을 찾을 수 있습니다. 이는 이름 필터 예시일 뿐, 해당 이름이 붙은 회선의 품질이나 네트워크 트래픽의 출구를 뜻하지 않습니다. 서버 이름은 구독 제공자가 정하므로 대소문자, 공백, 이름 변경에 따라 일치 결과가 달라질 수 있습니다. 실제 항목을 먼저 살펴본 뒤 조건을 조금씩 좁히세요. 처음부터 조건을 너무 엄격하게 잡으면 그룹에 서버가 하나도 없는 것처럼 보일 수 있습니다.

(홍콩|싱가포르)

목록이 비어 있으면 ‘검색어 지우기 → 추가 필터 해제 → 전체 그룹으로 전환 → 업데이트 로그 확인’ 순서로 살펴보세요. 빈 목록이 로컬 표시 조건 때문일 수 있으므로 구독부터 삭제하지 마세요. 서버 필터와 앱별 트래픽 분기는 서로 다릅니다. 필터는 목록에 표시할 서버를 정하고, 라우팅 규칙은 연결을 어떤 아웃바운드로 보낼지 결정합니다. 목록에 항목이 하나만 남아도 이미 연결된 기존 세션은 이전 출구를 계속 사용할 수 있습니다.

업데이트에 따른 덮어쓰기와 로컬 수정 관리

구독을 업데이트하면 출처가 관리하는 서버 항목이 바뀔 수 있습니다. 서버 항목의 포트, 전송 설정, 메모를 직접 수정했다면 다음 업데이트에서 변경 사항이 덮어써질 수 있다고 생각해야 합니다. 로컬 수정을 계속 유지해야 한다면 별도의 수동 관리 그룹에 복사하고 메모에 출처와 수정 이유를 적어두세요. 원본 구독은 계속 업데이트하면서 수동 복사본을 언제 동기화해야 하는지도 파악할 수 있습니다. 수동 복사본이 자동 업데이트된다고 착각하지 마세요.

구독 그룹을 삭제하기 전에 클라이언트가 해당 그룹의 서버까지 함께 삭제하는지, 현재 활성 서버가 그 그룹에 속하는지 확인하세요. UI마다 삭제 방식이 다를 수 있으므로 작업 전에 확인 메시지를 읽어야 합니다. 보존할 항목은 먼저 내보내거나 복사하고, 구독 주소는 별도로 안전하게 백업하세요. 주소가 들어 있는 내보내기 파일도 민감한 설정입니다. 백업을 복원한 뒤에는 이름이 남아 있는지만 볼 것이 아니라 그룹 활성화 상태와 업데이트 정책, 현재 서버도 다시 확인하세요.

V2Ray 라우팅 규칙 실전 가이드

라우팅은 커널에 들어온 연결을 특정 아웃바운드로 보내는 과정입니다. 클라이언트를 우회하는 앱의 연결까지 자동으로 프록시 안으로 끌어들이지는 않습니다. 규칙을 설정하기 전에 대상 앱이 클라이언트의 로컬 연결 지점을 실제로 사용하거나 TUN으로 가로채지고 있는지 확인하세요. 그렇지 않으면 규칙 문법이 정확해도 커널이 연결을 받지 못해 로그에 예상한 규칙 일치 기록이 남지 않습니다. 규칙 순서를 계속 바꾸기보다 먼저 진입 경로를 확인하고, 규칙을 살펴본 뒤 아웃바운드를 점검하는 편이 효과적입니다.

위에서 아래로 규칙 순서 정하기

Xray와 V2Fly의 일반적인 필드 기반 라우팅은 순서대로 규칙을 검사하며 먼저 일치한 규칙이 아웃바운드를 결정합니다. 보통 명시적 차단 대상, 사설 네트워크의 직접 연결, 구체적인 업무 예외를 포괄적인 규칙보다 앞에 두고, 그 뒤에 넓은 도메인 목록을 배치합니다. 마지막으로 어떤 규칙에도 일치하지 않을 때의 기본 동작을 확인하세요. 모든 환경에 통하는 고정 순서는 없습니다. 내부 도메인을 전용 프록시로 보내야 한다면, 그 도메인에 대한 구체적인 규칙을 이를 덮어쓸 수 있는 직접 연결 목록보다 앞에 두세요.

아래는 규칙 순서를 설명하는 Xray 라우팅 조각이며 전체 설정에 병합해야 합니다. proxy, direct, block이라는 이름의 아웃바운드가 이미 있고, 참조하는 규칙 데이터도 사용할 수 있다고 가정합니다. 태그는 로컬 식별자일 뿐, 이름을 적는다고 아웃바운드가 자동으로 만들어지지는 않습니다. 클라이언트가 생성한 태그가 다르면 실제 설정에 맞춰 참조를 수정하세요.

{
  "routing": {
    "domainStrategy": "AsIs",
    "rules": [
      {
        "type": "field",
        "domain": ["geosite:category-ads-all"],
        "outboundTag": "block"
      },
      {
        "type": "field",
        "ip": ["geoip:private"],
        "outboundTag": "direct"
      },
      {
        "type": "field",
        "domain": ["geosite:cn"],
        "outboundTag": "direct"
      }
    ]
  }
}

이 조각에는 모든 트래픽을 처리하는 와일드카드 규칙이 없습니다. 여기서 다루는 일반적인 커널 설정에서는 일치하는 규칙이 없는 연결이 보통 아웃바운드 목록의 첫 번째 항목으로 전달됩니다. 클라이언트가 자체 기본 정책을 위해 규칙을 추가로 생성할 수도 있습니다. 따라서 ‘final → proxy’는 정책을 설명하기 위한 예시이지, 위 JSON에 그대로 넣을 수 있는 필드가 아닙니다. 기본 동작을 확인할 때는 UI의 모드 이름만 보고 추측하지 말고 실제 생성 설정과 실행 로그를 살펴보세요.

도메인 일치와 IP 주소 일치 구분하기

도메인 규칙이 일치하려면 연결에 사용할 수 있는 도메인 정보가 있어야 합니다. 앱이 주소를 직접 연결하거나 진입 경로에서 대상 주소만 전달한다면 도메인 규칙만 추가해도 일치하지 않을 수 있습니다. 프로토콜 스니핑이 일부 연결에서 도메인 정보를 보완할 수 있지만, 모든 암호화 트래픽에 적용되지는 않으며 도메인을 항상 복구해 준다고 보장할 수도 없습니다. 먼저 로그에 대상이 도메인과 IP 주소 중 어떤 형태로 표시되는지 확인한 뒤 도메인 목록을 사용할지, 주소 범위를 지정할지, DNS와 진입 경로에서 전달되는 정보를 더 살펴볼지 결정하세요.

domainStrategy는 라우팅 일치 과정에서 도메인 조회를 언제 시도할지 제어하며, 모든 앱의 DNS 요청을 가로채는 설정은 아닙니다. AsIs는 주소 규칙을 위해 별도로 조회하지 않습니다. IPIfNonMatch는 도메인 규칙이 일치하지 않을 때 조회를 시도한 뒤 IP 주소 규칙을 검사할 수 있습니다. IPOnDemand는 규칙에 주소가 필요할 때 조회를 시도합니다. 전략을 바꾸면 조회 횟수와 일치 결과가 달라지므로 DNS 설정과 함께 테스트하세요. 더 적극적으로 조회할수록 정확해지는 것은 아닙니다.

대상 하나를 정해 규칙 검증하기

규칙을 추가할 때마다 결과를 명확히 재현할 수 있는 대상을 하나 선택하세요. 기존 연결을 닫고 다시 접속한 다음 접속 로그에서 대상과 아웃바운드 태그를 확인합니다. 브라우저의 장기 연결, 연결 재사용, 앱 캐시 때문에 기존 연결이 변경 전 경로를 계속 사용할 수 있습니다. 페이지 새로고침만으로 새 연결이 만들어지지 않을 수도 있습니다. 필요하면 해당 앱을 종료한 뒤 다시 테스트하고 다른 설정은 그대로 유지하세요. 로그에서 테스트 시간, 대상, 아웃바운드를 서로 확인할 수 있어야 하며 클라이언트가 실행 중이라는 사실만으로는 부족합니다.

규칙이 적용되지 않으면 앞선 규칙이 먼저 일치했는지, 태그가 있는지, 규칙 데이터가 로드됐는지, 연결에 도메인 정보가 포함됐는지 차례로 확인하세요. 규칙은 일치하지만 접속에 실패한다면 같은 계층에 중복 규칙을 더하지 말고 아웃바운드와 DNS를 살펴보세요. 규칙 데이터 업데이트로 목록 범위가 바뀔 수도 있으므로 업데이트 뒤 자주 사용하는 서비스를 확인하세요. 충돌을 찾기 쉽도록 규칙을 겹겹이 쌓기보다 용도를 짧게 기록해 두는 것이 좋습니다.

DNS 설정과 조회 경로

DNS 문제를 진단할 때는 세 가지를 먼저 확인해야 합니다. 누가 조회를 시작하는지, 조회가 어떤 경로로 DNS 서버에 도달하는지, 결과를 누가 사용하는지입니다. 앱이 직접 조회하거나, 시스템이 결과를 캐시하거나, 커널이 라우팅 또는 연결을 위해 별도로 조회할 수 있습니다. 여러 경로가 동시에 존재하므로 클라이언트의 DNS 서버를 바꿔도 브라우저 자체의 암호화 DNS가 달라지지 않을 수 있고 시스템에 이미 저장된 캐시도 갱신되지 않을 수 있습니다. DNS 서버 주소만 바꾸기보다 실제 경로를 먼저 정리하세요.

시스템 DNS와 커널 DNS 구분하기

시스템 프록시 모드는 프록시 설정을 따르는 앱의 연결 경로를 주로 바꾸며, 시스템의 모든 DNS 요청을 자동으로 가로채지는 않습니다. SOCKS를 사용할 때 대상 도메인을 로컬에서 조회할지 프록시로 전달할지도 앱의 구현과 호출 방식에 따라 다릅니다. TUN과 DNS 가로채기를 함께 사용하면 더 많은 요청을 처리할 수 있지만, 라우팅과 가로챌 포트, 앱 자체 DNS 설정도 확인해야 합니다. TUN이 켜져 있다는 이유만으로 시스템의 모든 조회가 같은 경로를 따른다고 단정하지 마세요.

v2rayN의 커널 DNS, TUN 관련 DNS, 데스크톱 시스템 DNS는 서로 다른 설정 경로일 수 있습니다. 변경 전 현재 실행 모드와 보조 구성 요소를 기록하고, 수정하려는 필드를 어느 구성 요소가 읽는지 확인하세요. Android의 v2rayNG와 v2flyNG는 VPN 서비스와 앱 선택 설정의 영향도 받습니다. 플랫폼 간에는 설정 텍스트를 모바일 UI에 그대로 복사하기보다 정책의 의도를 옮기세요.

아래는 V2Fly 방식의 내장 DNS 설정 조각입니다. Xray에서 지원하는지는 사용 중인 커널에 따라 확인하세요. 일반 UDP DNS 서버와 조회 정책의 구조를 보여주며, 암호화된 DNS를 자동으로 제공하거나 DNS 트래픽의 아웃바운드 경로를 설정하지는 않습니다. 현재 네트워크에서 접속할 수 있는지와 관리 요구 사항을 고려해 주소를 선택하세요. 병합한 뒤에도 생성된 설정과 라우팅, 로그를 확인해야 합니다.

{
  "dns": {
    "servers": [
      {
        "address": "1.1.1.1",
        "port": 53
      }
    ],
    "queryStrategy": "UseIP"
  }
}

용도에 맞는 DNS 조회 정책 선택

직접 연결하는 서비스는 조회 결과가 로컬 출구에서 연결 가능해야 하고, 프록시를 사용하는 서비스는 조회 위치가 출구 네트워크와 일치하는지도 고려해야 합니다. 일부 서비스는 DNS 서버의 위치에 따라 접속 주소를 반환하므로 조회에 성공해도 연결이 불안정할 수 있습니다. 도메인에 따라 DNS 서버를 선택한다면 정확하고 이해하기 쉬운 범위부터 지정한 뒤 규칙 목록을 확장하세요. ‘조회 실패 시 대체 서버 사용’과 ‘라우팅에 따른 트래픽 분기’는 조건과 경로가 다르므로 혼동하지 마세요.

암호화 DNS 주소에 도메인 이름을 사용할 때는 DNS 서버 자체의 도메인을 어떻게 IP 주소로 바꿀지도 고려해야 합니다. 이를 흔히 부트스트랩 DNS 조회라고 합니다. 아직 연결되지 않은 프록시를 거쳐야만 DNS 서버를 조회할 수 있고 프록시 서버 주소도 같은 DNS 서버에 의존한다면 시작 단계에서 의존성 순환이 생깁니다. 부트스트랩 조회 경로를 명확히 지정하거나 클라이언트가 제공하는 별도의 시작용 DNS 설정을 사용하세요. 대체 서버를 계속 추가하는 방식으로 순환 문제를 해결하려 하지 마세요. 추가한 서버도 같은 의존성에 막힐 수 있습니다.

IPv4와 IPv6는 따로 검증해야 합니다. 조회 결과에 두 주소 유형이 모두 있어도 두 주소 체계에서 사용할 수 있는 출구가 있다는 뜻은 아닙니다. 시스템이 우선 연결하는 주소가 클라이언트의 예상과 다를 수도 있습니다. 일부 웹사이트만 오래 기다린 뒤 열리거나 특정 네트워크에서만 실패한다면 IPv6 라우팅과 프록시 서버의 주소 체계 지원을 확인하세요. 비교 테스트를 위해 IPv4만 반환하도록 할 수 있지만, 장기 정책은 네트워크 환경에 맞춰 결정하고 다른 앱에 미치는 영향도 기록하세요.

DNS 조회 결과와 연결 결과를 교차 확인

아래 명령은 운영체제 기본 DNS 조회 경로의 결과를 확인하는 용도이며, 프록시 커널이 어떤 DNS 서버를 사용했는지 단독으로 증명하지는 않습니다. 실행할 때 응답 DNS 서버, 주소 유형, 오류 메시지를 기록한 뒤 클라이언트 로그의 도메인 조회 이벤트와 비교하세요. 커널에서 해당 조회가 보이지 않는다면 캐시가 사용됐거나 앱이 이미 주소를 전달했을 수 있으므로 설정을 바꾸기 전에 원인을 확인하세요.

nslookup example.com

캐시는 계층별로 비우세요. 먼저 대상 앱을 다시 시작하고 운영체제에서 제공하는 방법으로 시스템 DNS 캐시를 지운 뒤 관련 커널을 다시 시작합니다. 한 번의 테스트에서 네트워크 변경, DNS 서버 수정, 기기 재시작을 모두 하면 어떤 변경이 결과에 영향을 줬는지 알기 어렵습니다. 도메인 조회는 되지만 연결에 실패하면 아웃바운드 연결 가능 여부, 인증서 시간, 대상 포트를 확인하세요. DNS 조회 시간 초과라면 조회 경로와 DNS 서버에 접속할 수 있는지를 살펴봐야 합니다. 두 문제를 같은 방식으로 해결하지 마세요.

기업 네트워크나 LAN의 전용 도메인은 보통 내부 DNS 서버 또는 검색 도메인이 필요합니다. 모든 조회를 공용 DNS 서버로 보내면 내부 서비스의 주소를 찾지 못할 수 있습니다. 내부 도메인에 명확한 조회 경로를 설정하고 짧은 이름과 전체 도메인 이름을 각각 테스트하세요. 인터넷은 연결되지만 내부 서비스를 열 수 없다면 프록시 서버나 전체 라우팅을 바꾸기 전에 검색 도메인만 빠졌는지 확인하세요.

TUN 모드와 가로채기 범위

TUN은 가상 네트워크 인터페이스를 통해 선택된 트래픽을 사용자 공간 구성 요소에 전달하므로 시스템 프록시 설정을 따르지 않는 앱에 유용합니다. TUN은 트래픽 진입 경로와 처리 범위를 바꾸지만 모든 프로토콜과 대상에 연결할 수 있게 보장하지는 않습니다. TUN으로 들어온 연결도 DNS 조회와 규칙 일치, 아웃바운드 처리를 거쳐야 합니다. TUN을 켤지는 모든 연결 문제를 해결하는 스위치로 볼 것이 아니라 대상 앱이 프록시를 지원하는지부터 확인해 판단하세요.

복구 가능한 순서로 활성화하기

활성화 전에 일반 시스템 프록시 모드에서 서버 하나가 작동하는지 확인하고 현재 시스템 프록시 상태, DNS 설정, LAN 접속 여부를 기록하세요. 그런 다음 충돌할 수 있는 다른 네트워크 가로채기 프로그램을 끄고 클라이언트 안내에 따라 관리자 권한이나 네트워크 확장 권한을 부여합니다. 처음에는 TUN에 필요한 기본 옵션만 켜고 복잡한 DNS, FakeDNS, 사용자 지정 아웃바운드는 추가하지 마세요. 여러 기능을 한꺼번에 켜면 네트워크가 끊겼을 때 원인을 분리하기 어렵습니다.

v2rayN의 TUN 기능은 가상 인터페이스와 라우팅을 별도 구성 요소로 처리할 수 있으므로 커널 연결 로그가 전체 실행 로그라고 가정하지 마세요. TUN 구성 요소가 시작됐는지, 인터페이스가 만들어졌는지, 기본 라우트가 예상대로 바뀌었는지도 확인해야 합니다. Android의 v2rayNG와 v2flyNG는 시스템 VPN 권한을 사용해 트래픽 진입 경로를 만듭니다. 처음 권한 요청이 표시되면 현재 클라이언트가 요청한 것인지 확인하세요. 다른 VPN 서비스가 실행 중이라면 점유 문제도 먼저 해결해야 합니다.

루프를 방지하고 로컬 접속 유지하기

프록시 서버 연결이 같은 프록시 경로에 다시 가로채이면 루프가 생길 수 있습니다. 클라이언트는 보통 라우트 제외, 인터페이스 바인딩, 프로세스 처리로 이를 방지하지만 수동 라우트를 추가하거나 사용자 지정 상위 프록시를 설정하거나 오래된 설정을 재사용했다면 검증이 필요합니다. TUN을 켠 뒤 기존 서버에도 연결할 수 없거나 비슷한 연결 로그가 반복되거나 요청이 계속 시간 초과되는 것이 대표적인 증상입니다. 이때는 먼저 TUN을 꺼서 기준 상태로 복구하고 프록시 체인을 계속 추가하지 마세요.

LAN 접속에는 네트워크 계층의 우회 경로와 커널 규칙을 모두 고려해야 합니다. 라우팅 테이블은 데이터가 가상 인터페이스에 먼저 들어갈지 결정하고, 커널 규칙은 들어온 연결에 어떤 아웃바운드를 사용할지 결정합니다. 한쪽만 설정해서는 원하는 동작을 얻지 못할 수 있습니다. 라우터 관리 페이지, LAN 프린터, 내부 도메인을 테스트할 때는 IP 주소로 접속한 결과와 도메인으로 접속한 결과를 각각 기록하세요. IP 접속은 되지만 이름으로 접속되지 않으면 내부 DNS를 확인하고, 둘 다 실패하면 사설 네트워크 라우트와 직접 연결 규칙을 살펴보세요.

앱별 분기와 목적지별 분기도 구분해야 합니다. Android의 앱 선택은 보통 어떤 앱의 트래픽이 VPN으로 들어갈지 결정하고, 들어온 연결은 커널 라우팅 규칙에 따라 처리됩니다. 데스크톱에서 프로세스별로 나눌 수 있는지는 실제 구성 요소의 기능에 달려 있습니다. 도메인 규칙을 프로세스 격리 규칙으로 여기거나 한 플랫폼의 앱 제외 방식을 다른 플랫폼에 그대로 적용하지 마세요. 업무별로 경로를 분리해야 한다면 먼저 진입 계층이 지원하는 기능을 확인하고 결과를 검증할 수 있는 방식을 선택하세요.

UDP, 절전 모드, 네트워크 전환 확인

웹페이지가 열린다는 것은 해당 연결이 작동한다는 뜻일 뿐 UDP 앱까지 정상이라는 의미는 아닙니다. 음성 통화, 실시간 통신, 일부 DNS 요청은 UDP를 사용할 수 있으며 지원 여부는 서버와 전송 방식, 아웃바운드 설정에도 좌우됩니다. 테스트할 때 먼저 대상 프로토콜을 확인하고 해당 연결이 로그에 나타나는지 살펴보세요. UDP를 쓰는 기능만 이상하다면 UDP 처리와 상위 서버 지원 범위로 문제를 좁히세요. 브라우저가 웹페이지를 열 수 있다는 이유만으로 네트워크 경로 문제를 제외하지 마세요.

절전 모드에서 깨어나거나 Wi-Fi 네트워크를 바꾸거나 유선 연결을 다시 연결하면 기본 게이트웨이와 DNS, 인터페이스 우선순위가 달라질 수 있습니다. TUN을 켠 뒤에는 이러한 일상 상황도 시험하세요. 먼저 연결한 다음 네트워크를 전환하고 구성 요소가 복구되는지, LAN에 계속 접속할 수 있는지 확인합니다. 전환 후 동작하지 않으면 TUN 구성 요소를 다시 시작한 뒤 확인하세요. 문제가 반복되면 단순히 ‘클라이언트 연결 끊김’이라고 기록하는 대신 인터페이스와 라우트가 어떻게 바뀌었는지 남기세요.

복구할 때는 먼저 TUN을 끄고 클라이언트를 종료한 뒤 시스템 프록시가 예상대로 복원됐는지 확인하고 마지막으로 일반 네트워크와 로컬 서비스를 테스트하세요. 정체를 알 수 없는 가상 인터페이스를 바로 삭제하거나 네트워크 설정을 크게 초기화하지 마세요. 다른 정상 프로그램에 영향을 줄 수 있습니다. 종료 후에도 문제가 남으면 운영체제의 네트워크 설정에서 남아 있는 DNS와 프록시, 라우트를 하나씩 확인하세요. 확신할 수 없는 시스템 항목은 변경 전에 기록해 복구할 근거를 남겨야 합니다.

FakeDNS와 도메인 매핑

FakeDNS는 실제 대상 IP를 앱에 직접 반환하는 대신 지정된 주소 풀에서 합성 IP를 할당하고, 내부에 해당 IP와 도메인의 대응 관계를 저장합니다. 이후 앱이 합성 IP에 연결하면 트래픽 가로채기 구성 요소가 원래 도메인을 복원해 라우팅과 아웃바운드 처리로 넘깁니다. 이 방식은 도메인 정보를 유지하는 데 쓰이며 특히 투명 프록시 환경에 적합합니다. 공용 DNS 서버가 아니며 실제 서비스 IP를 대신하는 주소 제공 방식도 아닙니다.

처리 경로가 연결되는지 확인한 뒤 활성화하기

조회와 후속 연결이 매핑 정보를 공유할 수 있는 처리 경로를 따라야 FakeDNS를 사용할 수 있습니다. 앱이 합성 IP를 받은 뒤 가로채기 구성 요소를 우회해 직접 연결하면 해당 주소는 쓸 수 없습니다. 조회를 한 구성 요소와 연결을 처리하는 구성 요소가 다르고 매핑 정보도 공유하지 않는다면 연결에 실패할 수 있습니다. 따라서 DNS 목록에 이름을 추가하는 것만으로 설정이 끝났다고 보면 안 됩니다. 주소 풀 라우팅, 연결 진입, 도메인 복원 단계가 서로 맞물리는지 확인하세요.

v2rayN의 TUN 구성 요소와 Xray, V2Fly의 FakeDNS는 같은 설정을 자유롭게 섞어 쓸 수 있는 기능이 아닙니다. 커널과 보조 구성 요소마다 필드와 주소 풀, 매핑 유지 방식이 다를 수 있습니다. 먼저 현재 트래픽을 실제로 처리하는 구성 요소를 확인하고 이에 맞는 기능을 선택하세요. 클라이언트에 관련 사전 설정이 있다면 우선 활용하고 생성된 결과를 확인하세요. 다른 커널의 필드를 현재 설정에 그대로 붙여 넣어 빠진 것처럼 보이는 기능을 채우지 마세요.

아래는 Xray 설정에서 FakeDNS에 사용하는 주소 풀과 DNS 선택 항목을 보여주는 예시입니다. 독립적으로 실행할 수 있는 전체 설정이 아니며 실제 연결 진입 지점에서 도메인을 복원하는 설정과 합성 IP를 가로채는 경로가 함께 필요합니다. 예시 주소 대역은 벤치마크용 주소 공간이며 실제 사이트 주소가 아닙니다. 현재 네트워크에서 같은 범위를 사용 중이라면 그대로 적용하지 말고 충돌부터 해결하세요.

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

주소 풀과 매핑 유지 방식 이해하기

ipPool은 할당할 수 있는 주소 범위를 정하고 poolSize는 풀의 용량을 제어합니다. 풀 용량은 처리량 지표가 아니며 동시에 유지할 수 있는 업무 연결 수를 뜻하지도 않습니다. 앱은 주소를 오랫동안 캐시할 수 있고 커널을 재시작하면 매핑이 사라질 수 있습니다. 앱이 오래된 합성 IP로 연결을 시도해도 새 프로세스는 해당 IP에 대응하는 도메인을 모를 수 있습니다. 따라서 관련 구성 요소를 켜거나 끄고 재시작한 뒤에는 대상 앱에서 DNS를 다시 조회하게 하세요.

DNS 캐시와 주소 매핑 캐시의 유지 기간이 다른 것이 간헐적 오류의 흔한 원인입니다. 처음에는 작동하지만 재시작 뒤 일부 앱만 실패하고 앱 캐시를 지운 뒤 다시 작동할 수 있습니다. 진단할 때 모드 전환이나 커널 재시작, 절전 모드 복귀가 있었는지 기록하세요. 주소 풀 용량을 늘려도 이전 주소와 매핑의 연결이 끊기는 문제는 해결되지 않습니다. 오히려 기존 캐시와 새 매핑을 대응하기 어려워질 수 있습니다.

일부 앱은 네트워크 검사, 지역 판별, 직접 프로토콜 통신을 위해 실제 IP가 필요합니다. 앱이 자체 암호화 DNS를 사용해 예상한 조회 경로를 우회할 수도 있습니다. 이런 호환성 문제가 나타나면 해당 도메인이나 앱에는 실제 DNS 경로를 사용하고 연결도 이에 맞는 라우팅을 적용하세요. 예외는 가능한 한 구체적으로 설정하고 대상 하나부터 검증한 뒤 관련 도메인 목록으로 확장합니다. 넓은 범위의 업무를 모두 제외하면 기존 도메인 매핑의 효과가 사라질 수 있습니다.

조회, 도메인 복원, 아웃바운드를 단계별로 검증

첫째, 대상 조회 결과가 합성 IP이며 예상 주소 풀에 속하는지 확인합니다. 둘째, 해당 IP에 연결했을 때 로그에 대응하는 도메인이 복원되는지 확인합니다. 셋째, 그 도메인이 어떤 규칙과 아웃바운드에 일치하는지 살펴봅니다. 합성 IP가 반환됐다고 첫 단계 이후의 경로까지 정상이라는 뜻은 아닙니다. 로그에 합성 IP만 있고 도메인이 없다면 실제 대상 IP 규칙을 바로 추가하지 말고 진입 지점과 도메인 복원 설정을 확인하세요.

라우팅에 주소 규칙이 있다면 합성 IP와 실제 조회 결과를 구분해야 합니다. 합성 IP를 일반 목적지로 간주해 지역이나 사설 IP 여부를 판단하면 업무 의도와 무관한 결과가 나올 수 있습니다. 규칙을 설계할 때 도메인을 복원한 뒤 판단할 항목과 실제 DNS 조회가 필요한 항목을 명확히 나누세요. 주소 기반 규칙이 필요한 연결은 실제 DNS 조회를 별도로 해야 할 수 있으므로 FakeDNS를 쓴다고 모든 상황에서 후속 DNS 처리를 생략할 수 있는 것은 아닙니다.

FakeDNS를 끌 때는 먼저 일반 DNS 설정을 복원하고 관련 주소 풀 가로채기를 끈 뒤 대상 앱을 다시 시작해 남은 캐시를 처리하세요. 비활성화한 뒤에도 앱이 합성 IP에 계속 접속한다면 캐시가 갱신되지 않은 것입니다. 이때 서버를 계속 바꿔도 대개 도움이 되지 않습니다. 복구가 끝나면 일반 DNS와 LAN 서비스도 다시 확인하세요. 안정적으로 활성화하고 결과를 검증한 뒤 완전히 종료할 수 있을 때만 일상 설정에 포함하는 것이 좋습니다.

다중 구독 관리와 업데이트 정책

다중 구독 관리는 출처를 분리하고 업데이트 시기와 복구 가능성을 관리하는 기능이지 자동 부하 분산 기능이 아닙니다. 여러 출처를 클라이언트로 가져와도 기본 설정에서는 활성 서버 하나만 사용하고 나머지는 후보로 남을 수 있습니다. 먼저 일상 업무용, 백업용, 기록 보관용 구독을 구분한 다음 그룹과 업데이트 정책을 정하세요. 목표는 목록에 서버를 최대한 많이 넣는 것이 아니라 변경이 발생했을 때 그 이유를 설명할 수 있도록 관리하는 것입니다.

출처별로 그룹화하고 용도별로 필터링

업데이트 시 소속 출처가 뒤섞이지 않도록 그룹은 먼저 출처에 따라 나누고, 용도는 메모와 키워드, 로컬 필터로 구분하세요. 하나의 구독에 여러 용도의 항목이 포함될 수 있으므로 용도마다 같은 링크를 반복해서 가져오지 않는 편이 좋습니다. 중복으로 가져오면 업데이트 요청이 늘어나고 같은 설정이 여러 곳에 나타나 전환할 때 어느 항목을 관리해야 하는지 혼란스러울 수 있습니다. 별도 관리가 꼭 필요하다면 복사 이유와 이후 동기화 방법을 기록하세요.

서로 다른 출처에서 이름이 같다는 이유만으로 중복 항목이라고 판단하지 마세요. 이름이 같은 서버라도 주소와 포트, 프로토콜, 전송 설정이 다를 수 있고 같은 연결 설정이 이름만 바뀌어 다시 나타날 수도 있습니다. 중복 항목을 정리하려면 실제 설정과 출처를 함께 비교하고 먼저 백업하세요. 구독에서 생성된 항목을 대량 삭제하면 다음 업데이트 때 다시 나타날 수 있으므로, 우선 목록 표시 필터를 사용하거나 출처에서 지원하는 경우 서버 측 구독 설정을 조정하세요.

각 구독 출처에는 용도와 업데이트 방식, 기존 프록시 연결을 이용해야 하는지 정도만 기록하면 됩니다. 일반 메모에 인증 정보가 포함된 전체 링크를 저장할 필요는 없습니다. 계정 만료와 인증 정보 변경, 요금제 조정에 따라 목록이 바뀔 수 있지만 클라이언트는 이름만 보고 이런 상태를 판단하지 못합니다. 항목이 많이 사라졌다면 이전 설정을 복원하기 전에 해당 출처의 응답과 계정 상태부터 확인하세요. 이전 목록을 복원해도 만료된 원격 서비스가 다시 작동하는 것은 아닙니다.

실제 변경 주기에 맞춰 업데이트 빈도 정하기

자동 업데이트 간격은 출처의 변경 빈도와 클라이언트 사용 습관에 맞춰 설정하고 지나치게 촘촘하게 잡지 마세요. 원격 서버에서 일시적인 오류가 발생했을 때 계속 재시도하면 요청 제한에 걸릴 수 있고 로그도 읽기 어려워집니다. 자동 업데이트를 처음 설정한 뒤 한 차례 전체 과정을 관찰해 네트워크가 준비되지 않았을 때 실패를 어떻게 처리하는지, 현재 서버 선택에 영향을 주는지 확인하세요. 클라이언트가 실행되지 않았거나 시스템이 백그라운드 활동을 제한하면 예약 작업이 예상대로 실행되지 않을 수도 있습니다.

프록시 경유 업데이트와 직접 업데이트는 서로 다른 접속 경로이며 각각의 의존성을 확인해야 합니다. 현재 활성 서버가 업데이트하려는 구독에서 가져온 항목이고 이미 작동하지 않는다면 프록시 경유 업데이트도 실패할 수 있습니다. 먼저 검증된 다른 출처의 서버로 전환한 뒤 문제가 있는 그룹을 업데이트하거나, 직접 접속이 가능하면 직접 업데이트를 따로 시도하세요. 모든 그룹의 업데이트 방식을 한꺼번에 바꾸지 마세요. 문제가 특정 출처인지 공통 네트워크 경로인지 판단하기 어렵습니다.

업데이트 전후 서버 수의 변화는 문제 진단에 도움이 될 수 있지만 서버 수가 서비스 품질을 나타내는 지표는 아닙니다. 현재 활성 항목이 남아 있는지, 설정이 바뀌었는지, 수동 메모가 보존됐는지, 주요 업무가 계속 작동하는지가 더 중요합니다. 업데이트에 성공한 뒤 목록을 정리하기 전에 현재 업무부터 확인하세요. 클라이언트에 선택한 항목을 업데이트 후에도 보존하는 기능이 있다면 실제로 확인해야 합니다. 이름이 같다고 같은 서버가 유지된다고 단정하지 마세요.

속도 측정, 서버 전환, 실제 업무 확인 구분하기

지연 시간 테스트와 연결 테스트, 실제 서비스 접속 측정은 각각 확인하는 항목이 다릅니다. 한 번 접속됐다고 장기 연결이나 UDP, 특정 도메인까지 사용할 수 있다는 뜻은 아닙니다. 테스트 실패도 대상이나 DNS 경로가 원인일 수 있습니다. 구독이 여러 개라면 그룹별로 나누어 테스트해 동시 요청에 따른 영향을 줄이고 실제 업무로 최종 확인하세요. 한 번의 순위 결과를 장기 서버 선택 기준으로 삼거나 목록 위치만 보고 클라이언트가 자동 전환했다고 판단하지 마세요.

활성 서버를 수동으로 바꾸어도 기존 연결은 이전 경로를 계속 사용할 수 있습니다. 백업 서버를 확인할 때는 새 테스트 연결을 만들고 로그에서 아웃바운드와 대상을 확인하세요. 사용자 지정 라우팅이나 고정 아웃바운드가 설정되어 있으면 일부 서비스가 기본 서버 전환을 따르지 않을 수 있습니다. 이는 전환 실패가 아니라 정책 설계의 결과일 수 있습니다. 어떤 업무가 기본 서버 선택을 따르고 어떤 업무가 고정 출구를 사용하는지 짧게 기록해 두면 문제 발생 시 오판을 줄일 수 있습니다.

백업에는 그룹 설정과 수동 항목, 로컬 규칙을 포함하고 접근 권한을 적절히 제한하세요. 복원할 때는 기본 설정을 먼저 가져와 출처별로 확인한 뒤 복잡한 규칙을 복원합니다. 오래된 전체 설정으로 현재 작동 중인 환경을 한 번에 덮어쓰지 마세요. 출처를 중지할 때는 먼저 업데이트를 끄고 활성 참조를 제거한 다음 의존성이 없는지 살펴본 뒤 삭제하세요. 그러면 전체 구독을 다시 정리하지 않고도 명확한 범위 안에서 복구할 수 있습니다.

사용자 지정 아웃바운드와 설정 복구

아웃바운드는 커널이 연결을 다음 네트워크 구간으로 보내는 방식을 정하고, 라우팅은 어떤 아웃바운드를 사용할지 선택합니다. 일반적인 서버 전환은 클라이언트가 해당 아웃바운드를 생성해 처리합니다. 사용자 지정 아웃바운드는 고정 출구, 명시적인 직접 연결이나 차단 정책, 로컬 프록시 서비스 연동이 필요할 때 적합합니다. 수동으로 편집하기 전에 일반 설정만으로 필요한 정책을 표현할 수 없는지 확인하세요. UI에서 안정적으로 관리할 수 있는 설정을 사용자 지정 설정에 중복으로 작성할 필요는 없습니다.

설정을 관리하는 주체부터 확인하기

v2rayN은 시작하거나 서버를 전환할 때 실행 설정을 다시 생성할 수 있으므로 임시 생성 파일을 직접 수정해도 변경 사항이 유지되지 않을 수 있습니다. 클라이언트가 지원하는 사용자 지정 설정 경로를 이용하고 전체 설정을 가져오는 방식과 일부 조각을 추가하는 방식을 구분하세요. 전체 설정에는 필요한 모든 인바운드와 아웃바운드가 있어야 하고, 일부 조각은 병합 방식에 의존합니다. 잘못된 경로를 선택하면 기존 구조를 덮어쓸 수 있습니다. 편집 전에 현재 작동하는 설정을 저장하고 복원할 때 어떤 파일을 가져와야 하는지 확인하세요.

Xray와 V2Fly는 인바운드, 라우팅, 아웃바운드 같은 개념을 사용하지만 지원 프로토콜과 필드 세부 사항은 다를 수 있습니다. TUN 보조 구성 요소도 다른 설정 구조를 사용할 수 있습니다. 파일이 모두 JSON이라고 해서 구성 요소 간에 서로 바꿔 쓸 수 있는 것은 아닙니다. 먼저 실제로 실행되는 커널을 확인하고 각 필드가 어디에 속하는지 살펴보세요. 클라이언트와 커널의 역할 구분은 Project V, V2Fly, Xray 생태계 관계를 참고하세요. 클라이언트 이름만 보고 모든 내부 기능을 추측하지 마세요.

아래는 Xray에서 자주 쓰는 아웃바운드 두 가지를 보여주는 예시입니다. freedom은 대상에 직접 연결하고 blackhole은 연결을 폐기합니다. 태그는 라우팅 규칙에서 참조할 수 있습니다. 이 예시에는 프록시 서버 아웃바운드가 포함되어 있지 않으므로 전체 아웃바운드 목록을 대체하면 안 됩니다. 직접 연결을 목록 첫 번째에 두고 기본 처리 정책을 설정하지 않으면 일치하지 않은 연결이 직접 연결될 수 있습니다. 항목을 추가할 때 순서도 함께 확인하세요.

{
  "outbounds": [
    {
      "tag": "direct",
      "protocol": "freedom",
      "settings": {}
    },
    {
      "tag": "block",
      "protocol": "blackhole",
      "settings": {}
    }
  ]
}

태그로 규칙과 아웃바운드 연결하기

태그는 짧고 서로 겹치지 않으며 용도를 알 수 있게 정하세요. 태그를 변경할 때는 라우팅과 체인 전송 등 다른 참조 위치도 모두 확인해야 합니다. 아웃바운드 이름만 바꾸고 참조를 그대로 두면 시작 오류나 실행 중 라우팅 문제가 생길 수 있습니다. 아웃바운드를 추가한 뒤에는 구체적인 도메인 규칙 하나로 먼저 테스트하세요. 넓은 규칙 목록을 바로 연결하지 마세요. 태그 참조와 연결 경로, 로그가 예상대로 동작하는지 확인한 다음 사용 범위를 점차 넓히세요.

로컬 SOCKS 서비스와 연동할 때는 해당 서비스가 지정한 주소와 포트에서 실제로 대기 중인지 확인한 뒤 아웃바운드를 추가하세요. 같은 기기에서 사용할 때는 로컬 루프백 주소로 대기하는 것이 적절하며, 편의를 위해 모든 네트워크 인터페이스에 공개하지 마세요. 컨테이너나 별도의 네트워크 네임스페이스를 사용하면 로컬 루프백 주소가 가리키는 대상도 달라질 수 있습니다. 연결이 거부되면 먼저 대기 중인 프로세스와 주소 범위를 확인하고 라우팅 목록부터 바꾸지 마세요. 시간 초과가 발생하면 방화벽과 경로 연결 가능성도 살펴봐야 합니다.

프록시 체인을 구성하면 추가 의존성이 생깁니다. 앞단 서버에 연결할 수 없으면 뒤쪽 출구도 연결되지 않으며, 한 단계에서 대상 프로토콜을 지원하지 않으면 일부 업무만 실패할 수 있습니다. 구독 항목 여러 개를 배열에 나열한다고 체인이 만들어지는 것은 아닙니다. 배열 순서 자체로는 체인이 되지 않습니다. 구체적인 전달 방식은 커널에서 지원하는 설정을 따르고 자기 자신을 참조하는 구조가 생기지 않는지 확인하세요. 인증이 필요한 예시는 로컬에서 안전하게 입력하고 공개 설정 문서에 실제 인증 정보를 넣지 마세요.

문법, 참조, 연결의 세 단계로 검수하기

첫째, 쉼표와 따옴표, 괄호, 필드 형식 등 JSON 문법을 확인합니다. 둘째, 태그가 존재하는지, 프로토콜 필드가 지원되는지, 규칙 데이터를 불러올 수 있는지 등 의미상 참조를 확인합니다. 셋째, 실제 연결을 점검합니다. 문법 검사를 통과했다는 것은 파일을 읽을 수 있다는 뜻일 뿐 서버 접속이나 의도한 라우팅을 보장하지 않습니다. 클라이언트에 설정 검사 기능이 있다면 시작 전에 실행하세요. 실패하면 핵심 오류의 첫 항목을 보존해 이후 반복 로그에 묻히지 않게 하세요.

문제를 진단할 때만 필요한 수준으로 로그 상세도를 높이세요. 자세한 로그는 연결 경로를 찾는 데 도움이 되지만 접속 대상과 네트워크 정보가 기록될 수도 있으므로 보관 범위를 제한하고 진단 후에는 일상적인 로그 수준으로 복원하세요. 로그를 공유하기 전에 구독 주소와 사용자 식별 정보, 인증 정보를 삭제하세요. 커널이 시작되지 않으면 먼저 설정 검사 결과를 확인합니다. 시작은 되지만 일부 연결만 실패한다면 구체적인 대상으로 재현하세요. 원인을 찾기 전에 클라이언트를 재설치하거나 설정 전체를 다시 작성하지 마세요.

수정하기 전에 복구 방법을 준비하세요. 작동하는 기준 설정을 저장하고 새로 추가할 필드와 예상 결과를 기록하며 클라이언트의 자동 생성 모드로 어떻게 돌아갈지도 정합니다. 변경을 하나씩 마칠 때마다 기본 접속과 구체적인 규칙, LAN, 종료 후 시스템 네트워크를 각각 확인하세요. 새 규칙만 실패하면 그 규칙을 되돌리고 커널 전체가 시작되지 않으면 기준 설정 전체를 복원하세요. 범위를 좁혀 되돌리면 이미 검증한 설정을 보존할 수 있어 전체 초기화보다 다음 진단을 이어가기 쉽습니다.

시스템 업그레이드와 커널 변경, 클라이언트 이전 후에는 같은 검수 절차를 다시 수행하세요. 오래된 필드가 더 이상 지원되지 않거나 기본값이 바뀌었을 수 있으므로 파일을 읽을 수 있다는 이유만으로 동작까지 같다고 보지 마세요. 각 사용자 지정 항목이 어떤 문제를 해결하는지, 어떤 구성 요소에 의존하는지, 무엇으로 검증했는지 간단히 기록하세요. 더 이상 필요하지 않은 설정은 삭제하고 다시 테스트해 장기간 관리하는 설정을 이해하고 복구할 수 있게 유지하세요.