고급 설정 가이드

구독 그룹과 서버 필터

구독 그룹은 네트워크 출구가 아니라 관리 단위입니다. 그룹에는 구독 주소, 업데이트 옵션, 관련 필터 조건이 저장되고, 서버 항목에는 프로토콜·주소·포트가 포함됩니다. 서버 항목을 다른 그룹으로 옮겨도 연결 경로가 자동으로 바뀌지는 않습니다. 그룹 탭을 클릭해도 보통 목록 표시 범위만 달라질 뿐, 현재 사용 중인 서버가 전환되는 것은 아닙니다. 설정을 바꾸기 전에 ‘어떤 그룹을 보고 있는지’와 ‘어떤 서버를 사용 중인지’를 구분하세요. 그래야 업데이트 후 연결 상태를 잘못 판단하지 않습니다.

추적하기 쉬운 그룹 만들기

v2rayN의 구독 그룹 관리 메뉴에서 그룹을 추가하고, 출처와 용도를 알 수 있는 메모를 입력한 다음 전체 구독 주소를 붙여 넣으세요. 인터페이스에 따라 메뉴나 도구 모음에서 해당 기능을 찾을 수 있습니다. 구독 주소에는 개인 인증 정보가 포함되는 경우가 많으므로 공개 스크린샷이나 문의 글, 공유 문서에 올리지 마세요. 처음에는 그룹 하나만 추가하고 업데이트가 완료되면 프로토콜 종류와 주소가 제대로 표시되는지 확인한 뒤 다른 출처를 추가하세요. 이렇게 하면 문제가 발생했을 때 원인을 특정 구독으로 좁히기 쉽습니다.

업데이트 방식은 현재 연결 상태에 맞춰 선택해야 합니다. ‘프록시를 사용하지 않고 업데이트’는 현재 네트워크에서 구독 주소에 직접 접근할 수 있을 때 적합합니다. ‘프록시를 사용해 업데이트’하려면 사용할 수 있는 프록시 연결이 이미 있어야 합니다. 사용 가능한 서버를 하나도 가져오지 않은 상태에서 업데이트 요청을 프록시로 보내면 시작 단계에서 의존성이 꼬일 수 있습니다. 이 경우 구독 주소에 직접 접속할 수 있는지 확인하거나, 출처에서 제공한 단일 공유 링크로 먼저 연결한 다음 프록시 업데이트를 시도하세요. 업데이트 실패만으로 모든 서버가 작동하지 않는다고 판단하지 마세요.

목록 필터와 데이터 변경의 차이

서버 필터는 크게 두 가지입니다. 목록 검색은 조건에 맞지 않는 행을 숨기기만 하지만, 구독 가져오기 필터는 로컬 데이터베이스에 어떤 항목을 저장할지 결정할 수 있습니다. 적용 시점이 서로 다르므로 먼저 목록 검색으로 키워드가 대상 항목과 일치하는지 확인한 뒤 그룹 설정에서 가져오기 필터를 사용하세요. 인터페이스에서 정규식을 지원한다고 명시한 경우에만 별칭 필터에 정규식을 사용하세요. 일반 텍스트만 지원한다면 정규식 문법을 그대로 입력해도 작동하지 않습니다. 필드 이름과 일치 범위는 현재 인터페이스의 안내를 따르세요.

연구|업무
^(연구|업무)-

위 두 줄은 각각 ‘키워드 중 하나를 포함’하는 정규식과 ‘지정한 접두사로 시작’하는 정규식을 보여 주는 예시입니다. 둘 다 동시에 입력하는 설정이 아닙니다. 첫 번째는 범위가 넓고, 두 번째는 별칭이 일정한 이름 구조를 따라야 합니다. 먼저 소수의 항목으로 대소문자 구분 여부와 전체 문자열 일치 여부를 확인한 뒤 구독 전체에 적용하세요. 결과가 비어 있으면 필터를 해제하고 다시 업데이트해 보세요. 필터 조건 때문에 목록이 비었을 때 구독 주소를 반복해서 바꿔도 해결되지 않습니다.

업데이트 후 확인 순서

구독을 업데이트하면 서버 항목이 새로 만들어질 수 있어 수동으로 수정한 별칭, 전송 매개변수, 메모가 유지되지 않을 수 있습니다. 장기간 사용할 사용자 지정 항목은 별도의 수동 관리 그룹에 넣고 수정 이유를 기록하세요. 자동 업데이트 그룹에서 서버 측 매개변수를 직접 고쳐 계속 사용하면 다음 업데이트 때 수정 내용이 덮어써질 수 있습니다. 출처 설정에 실제 오류가 있다면 알 수 없는 매개변수를 하나씩 시험하기보다 먼저 제공처에 확인하세요.

v2rayNG에서는 ‘구독 그룹 설정’에서 구독 출처를 관리한 다음 구독을 업데이트할 수 있습니다. 메뉴 이름은 설치된 버전에 따라 다를 수 있습니다. Android는 데스크톱과 클립보드 권한 및 네트워크 환경이 다르므로 데스크톱에서 업데이트된 주소가 휴대폰에서도 접속된다고 보장할 수 없습니다. V2Fly 코어를 사용하는 대안인 v2flyNG에서는 구독에 포함된 프로토콜과 확장 필드의 지원 여부도 별도로 확인하세요. 목록에 항목이 표시된다는 사실만으로 연결 매개변수가 모두 호환된다고 단정할 수 없습니다.

업데이트 후 먼저 그룹에 예상한 항목이 있는지 확인하고, 현재 서버를 다시 선택해야 하는지 살펴본 뒤 실제 연결을 테스트하세요. 실제 연결 테스트는 연결을 직접 수립하는 작업으로, 호스트 응답만 확인하는 것과 다릅니다. 일괄 테스트는 트래픽을 사용할 수도 있으니 항목이 많다면 먼저 일부만 골라 검증하고, 이상이 있으면 로그를 확인하세요. 지연 시간과 배율을 함께 고려하는 방법은 서버 선택 안내를 참고하세요. 목록 정렬만으로 모든 서비스의 출구를 결정하지 마세요.

라우팅 규칙 활용

라우팅 규칙은 ‘코어에 들어온 연결을 어떤 아웃바운드로 보낼지’를 정합니다. 모든 앱의 트래픽이 코어로 들어오게 하는 기능은 아닙니다. 시스템 프록시를 따르지 않는 앱은 라우팅 규칙을 추가해도 자동으로 처리되지 않는 경우가 많습니다. 먼저 시스템 프록시를 사용하는 브라우저에서 규칙을 검증한 다음 TUN을 고려하세요. v2rayN의 ‘라우팅’ 메뉴에서 미리 설정된 구성을 선택하거나 규칙을 편집할 수 있습니다. ‘중국 본토 우회’와 같은 이름은 구체적인 정책 묶음을 뜻하므로 이름만 보고 모든 도메인이 어떻게 처리될지 추측하지 말고 규칙 내용을 확인하세요.

일치 순서와 아웃바운드 태그 확인

Xray와 V2Fly의 일반적인 라우팅 규칙은 순서대로 검사하며, 먼저 일치한 규칙이 연결의 경로를 결정합니다. 범위가 넓은 규칙을 앞에 두면 뒤에 있는 정밀한 규칙이 적용되지 않을 수 있습니다. 하나의 규칙 객체에 도메인, 포트, 네트워크 유형을 함께 지정하면 보통 모든 조건이 충족되어야 합니다. 같은 도메인 배열의 여러 항목은 일치 후보를 나타냅니다. 먼저 명확한 도메인 규칙 하나로 검증한 다음 포트나 주소 조건을 단계적으로 추가해 ‘그리고’와 ‘또는’의 관계가 뒤섞이지 않도록 하세요.

다음은 Xray / V2Fly 라우팅 필드의 구조 예시입니다. 사설 주소는 직접 연결하고, 예시용 예약 도메인도 직접 연결한 뒤 나머지 트래픽은 프록시로 보내는 순서만 보여 줍니다. 기존 설정에 direct와 proxy라는 이름의 아웃바운드가 정의되어 있어야 합니다. 클라이언트가 생성하는 태그는 다를 수 있으므로 실제 설정에 맞게 바꾸세요. 예시에 사용된 예약 도메인은 설명용이며 실제 업무 분할에 필요한 도메인을 대신할 수 없습니다.

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

도메인 일치와 주소 일치를 따로 검증

full:은 도메인 전체를 정확히 일치시킬 때, domain:은 해당 도메인과 하위 도메인을 일치시킬 때, regexp:는 정규식을 사용할 때 씁니다. 접두사가 없는 텍스트는 부분 문자열 기준으로 처리될 수 있어 예상보다 넓게 일치할 수 있습니다. 특정 사이트 하나만 처리하려면 읽기 쉬운 정확 일치나 접미사 일치를 우선 사용하세요. 서비스 페이지는 로그인, 정적 리소스, API 도메인에 각각 요청할 수 있습니다. 첫 페이지가 열렸다고 해서 서비스 전체 요청이 같은 경로로 완료된 것은 아니므로 로그에서 관련 요청을 확인하세요.

AsIs는 이미 제공된 대상 정보를 그대로 활용해 일치시키는 방식입니다. IPIfNonMatch는 도메인 규칙에 일치하지 않을 때 주소 규칙을 이어서 확인하도록 이름을 해석합니다. IPOnDemand는 규칙에 주소 정보가 필요할 때 이름을 해석할 수 있습니다. 이 설정들은 라우팅 단계의 이름 해석 시점을 바꾸는 것이지 브라우저의 DNS를 일괄 지정하는 기능은 아닙니다. 지리적 주소 분류에 의존하는 규칙이라면 도메인 해석 방식, 지리 데이터 사용 가능 여부, 현재 연결에 도메인 정보가 포함되는지 함께 확인하세요.

미리 설정된 규칙과 사용자 지정 규칙의 차이

지리 도메인 분류는 해당 데이터 파일을 사용하며, 분류 결과는 실시간 네트워크 검사 결과가 아닙니다. 데이터가 없으면 시작 오류가 발생할 수 있고, 오래된 데이터는 예상과 다른 분류로 이어질 수 있습니다. 먼저 클라이언트가 어떤 규칙 리소스를 사용하는지 확인한 뒤 클라이언트의 업데이트 기능을 이용하세요. 다른 규칙 엔진의 문법을 그대로 붙여 넣지 마세요. 도메인과 지역 이름이 같아 보여도 필드, 일치 방식, 데이터 형식은 완전히 다를 수 있습니다.

라우팅을 수정한 뒤에는 테스트 앱의 기존 연결을 종료하고 다시 시도하세요. 브라우저의 연결 재사용, 앱 연결 풀, 캐시 때문에 새 규칙이 적용되지 않은 것처럼 보일 수 있습니다. 검증할 때는 규칙 하나만 바꾸고 관련 로그를 열어 새 요청의 대상과 아웃바운드 태그를 확인한 다음 다른 서비스를 점검하세요. 처리 대상인 모든 트래픽을 프록시로 보내려면 라우팅의 기본 동작을 조정해야 합니다. 원래 프록시를 거치지 않는 앱까지 처리하려면 아래 TUN 항목을 확인하세요. 두 문제는 서로 다른 차원이므로 둘 다 ‘전체 설정’이라고 뭉뚱그려 해결하려 하지 마세요.

라우팅 규칙은 LAN 접근 요구도 고려해야 합니다. 프린터, 가정용 스토리지, 사내 사이트는 사설 주소나 내부 도메인을 사용할 수 있습니다. 사설 주소만 허용해도 내부 도메인 해석 문제는 해결되지 않을 수 있고, 도메인만 허용해도 앱이 직접 접속하는 주소가 포함되지 않을 수 있습니다. 먼저 실제 서비스가 어떤 방식으로 접속하는지 확인한 뒤 DNS와 라우팅을 함께 설정하세요. 연결 방식의 차이는 입문 가이드의 연결 확인을 참고해 기본 상태를 다시 점검할 수 있습니다.

DNS 설정 최적화

DNS 문제는 ‘프록시 연결은 됐는데 웹 페이지가 열리지 않음’으로 나타나는 경우가 많지만, 모든 도메인 요청이 같은 곳에서 해석되는 것은 아닙니다. 운영체제, 브라우저, 앱 내장 해석기, 프록시 코어는 각각 캐시와 해석 경로를 관리할 수 있습니다. 설정을 바꾸기 전에 요청 경로를 정리하세요. 앱이 도메인을 로컬 프록시에 전달하는지, 먼저 주소로 해석한 뒤 연결하는지, 코어가 도메인 기준으로 라우팅하는지, 주소 기준 일치를 위해 해석이 필요한지 확인해야 합니다. 도메인이 어느 계층에서 주소로 바뀌는지 알아야 수정할 설정도 찾을 수 있습니다.

세 가지 이름 해석 작업 구분

첫 번째는 프록시 서버 자체의 도메인 해석으로, 프록시 연결이 시작되기 전에 이루어지므로 그 시점에 접근할 수 있는 해석 경로가 필요합니다. 두 번째는 서비스 대상 도메인 해석으로, 로컬에서 처리될 수도 원격에서 처리될 수도 있습니다. 세 번째는 주소 규칙 일치를 돕는 라우팅용 해석입니다. 세 작업을 모두 반드시 프록시를 거쳐야 하는 DNS 서버에 맡기면 시작 단계에서 순환 의존성이 생길 수 있습니다. 프록시가 아직 연결되지 않았는데 프록시를 통해 서버 주소를 해석해야 하는 상황입니다.

v2rayN에서 ‘DNS 설정’을 변경하기 전에 현재 코어와 설정 모드를 확인하세요. 일부 옵션은 Xray 설정을 생성하고, 일부는 TUN에 사용하는 네트워크 구성 요소에 적용됩니다. 이름이 비슷한 옵션이라도 같은 필드에 기록된다는 뜻은 아닙니다. v2rayNG의 ‘로컬 DNS 활성화’는 로컬 이름 해석 처리와 관련되며, 원격 DNS나 직접 연결 DNS 등 실제 옵션을 함께 살펴봐야 합니다. 적용 범위를 모르는 상태에서 DNS 트래픽을 가로채는 기능을 여러 개 동시에 켜지 마세요.

{
  "dns": {
    "servers": [
      {
        "address": "localhost",
        "domains": ["domain:example.com"],
        "skipFallback": true
      },
      "1.1.1.1"
    ],
    "queryStrategy": "UseIP"
  }
}

이 Xray / V2Fly 스타일 DNS 예시는 도메인에 따라 해석기를 선택하고 나머지 쿼리에는 일반 해석 주소를 사용하는 방법을 보여 줍니다. 해당 주소에 접속할 수 있는지는 실제 네트워크 환경에 달려 있습니다. localhost는 시스템 해석기를 사용한다는 뜻이지, 로컬에 별도의 DNS 서버를 반드시 실행해야 한다는 뜻은 아닙니다. skipFallback은 지정되지 않은 도메인의 대체 쿼리에 해당 서버를 사용하지 않도록 하는 설정이며, 모든 해석 실패에 대한 재시도를 막는다는 의미는 아닙니다. 이 예시는 코어 DNS에만 적용되며 모든 앱을 직접 제어할 수 없습니다.

암호화 DNS도 올바른 라우팅이 필요합니다

암호화 DNS를 사용할 때는 해석 서비스 도메인의 최초 해석, 연결 포트, 요청을 보낼 아웃바운드를 함께 고려해야 합니다. 암호화 전송을 선택해도 네트워크 접속 불가가 자동으로 해결되거나 서비스 트래픽의 라우팅 규칙이 대체되지는 않습니다. 해석 서비스에 프록시를 통해서만 접근할 수 있다면, 프록시 서버 자체가 아직 연결되지 않은 해당 경로에 의존하지 않는지 확인하세요. 이미 작동하는 설정에서는 먼저 서비스용 해석기만 따로 바꿔 검증하고, 이후 시스템 DNS 가로채기를 고려하세요. 한 번에 여러 의존성을 추가하지 않는 것이 좋습니다.

IPv4와 IPv6도 함께 점검해야 합니다. IPv6 주소가 반환되어도 현재 네트워크와 선택한 아웃바운드에서 IPv6 경로를 사용할 수 있다는 뜻은 아닙니다. IPv4만 요청하면 문제가 잠시 우회될 수 있지만 IPv6가 해결된 것은 아닙니다. 일부 사이트에서 시간 초과가 발생하면 반환된 주소 유형, 실제 연결 주소, 라우팅 출구를 각각 살펴보세요. UseIP, UseIPv4, UseIPv6의 지원 범위와 적용 필드는 현재 사용하는 코어의 문서를 따르세요. 다른 구성 요소의 설정을 그대로 가져오면 안 됩니다.

캐시 계층별로 변경 사항 검증

DNS를 변경한 뒤에는 먼저 클라이언트 관련 네트워크 구성 요소를 다시 시작하고 테스트 앱의 기존 연결을 종료하세요. 필요하다면 운영체제와 브라우저 캐시도 비우세요. 브라우저에서 별도의 보안 DNS를 사용하면 테스트 요청이 시스템 해석기를 거치지 않을 수 있으므로 테스트 기록에 해당 설정 상태를 남겨야 합니다. 명령줄 조회 결과는 해당 명령이 사용한 해석 경로만 보여 줍니다. 브라우저, 메신저 앱, 프록시 코어에서도 같은 결과를 얻는다는 뜻은 아닙니다.

사내 도메인은 특히 기존 해석 경로를 유지해야 합니다. 공용 해석기는 보통 내부 이름을 알지 못하므로 DNS를 일괄 교체하면 외부 사이트는 다시 열리지만 업무 시스템이 작동하지 않을 수 있습니다. 내부 도메인에는 시스템 또는 사내 DNS를 사용하고, 해당 주소에는 직접 연결 규칙을 설정하세요. 내부 도메인이 네트워크에서 동적으로 할당된다면 어느 시점에 확인한 서버 주소를 영구적으로 고정하지 마세요. 사내 네트워크를 바꾼 뒤 다시 검증해 특정 환경의 설정을 다른 곳에 그대로 가져가지 않도록 하세요.

문제 해결 순서는 먼저 프록시 서버 도메인이 해석되는지 확인하고, 다음으로 서비스 도메인에서 예상한 주소 유형이 반환되는지 살핀 뒤, 요청이 어느 아웃바운드로 가는지 확인하고 마지막으로 연결 오류를 점검하는 방식으로 고정하는 것이 좋습니다. 해석 결과가 실제로 예상과 다를 때만 DNS를 조정하세요. 인증서 이름 불일치, 핸드셰이크 실패, 계정 인증 오류가 발생했다면 해당 연결 매개변수부터 확인해야 합니다. 해석기를 반복해서 바꿔도 보통 이런 문제는 해결되지 않습니다. 가상 주소 매핑이 관련된 경우 FakeDNS 항목을 확인하세요.

TUN 모드

TUN 모드는 가상 네트워크 어댑터로 IP 패킷을 받아 시스템 프록시 설정을 따르지 않는 앱의 트래픽까지 처리할 때 주로 사용합니다. ‘시스템 프록시 자동 설정’과 같은 기능이 아니며 모든 트래픽을 프록시 서버로 보내는 것도 아닙니다. 연결을 가로챌지는 가상 어댑터와 라우팅이 결정하고, 가로챈 뒤 직접 연결할지 프록시를 사용할지는 규칙이 정합니다. 따라서 TUN 문제는 패킷이 트래픽 처리 경로에 들어왔는지, 들어온 뒤 어떤 아웃바운드가 선택됐는지 두 단계로 나눠 확인하세요.

활성화 전 시스템 프록시 기준 상태 확인

먼저 TUN을 끄고 시스템 프록시로 웹 페이지를 열어 실제 연결을 테스트해 서버 매개변수가 정상인지 확인하세요. 현재 서버, 라우팅 구성, DNS 설정을 기록한 다음 TUN을 켜면 됩니다. 시스템 프록시 상태에서도 연결되지 않는다면 TUN까지 켜 변수만 늘리지 않는 것이 좋습니다. v2rayN의 TUN 구현은 플랫폼과 배포 패키지에 따라 다르며, 관련 구성 요소가 기본 프록시 코어와 다를 수도 있습니다. Xray 라우팅 예시를 변환 없이 다른 구성 요소의 설정으로 사용하지 마세요.

가상 네트워크 어댑터와 시스템 라우팅에는 적절한 권한이 필요한 경우가 많습니다. Windows에서는 권한 상승이 필요할 수 있고, macOS에서는 네트워크 권한이 필요할 수 있으며, Linux에서는 장치 접근 권한과 라우팅 관리 권한이 관련됩니다. 활성화에 실패하면 먼저 로그에서 어댑터가 생성됐는지, 경로가 추가됐는지 확인한 다음 권한 문제인지 네트워크 매개변수 문제인지 판단하세요. 모든 클라이언트를 항상 최고 권한으로 실행하는 것을 기본 해결책으로 삼지 마세요. 현재 패키지의 권한 요청 방식과 구체적인 오류를 먼저 확인하세요.

출구 루프와 중복 트래픽 가로채기 방지

시스템 트래픽을 가로챈 뒤에는 프록시 프로그램이 서버에 연결하는 트래픽이 정상적으로 빠져나가야 합니다. 그렇지 않으면 트래픽이 다시 자신에게 전달될 수 있습니다. 일반적으로 잘 만들어진 클라이언트는 인터페이스 바인딩, 경로 제외, 프로세스 보호 등을 처리하지만 여러 네트워크 어댑터, 다른 VPN, 수동 라우팅, 방화벽 규칙이 이런 조건을 깨뜨릴 수 있습니다. 활성화하자마자 인터넷이 끊긴다면 다른 네트워크 트래픽 처리 도구를 잠시 끄고 클라이언트 하나만 남긴 뒤 활성화 전후의 라우팅과 로그를 비교하세요.

시스템 프록시와 TUN을 함께 켜도 반드시 문제가 생기는 것은 아니지만 트래픽 경로가 복잡해집니다. 일부 앱은 로컬 프록시 포트에 연결하고 다른 앱은 가상 어댑터로 직접 들어갈 수 있습니다. 문제를 해결할 때는 먼저 한 가지 트래픽 처리 방식만 사용해 안정성을 확인한 다음 함께 쓸 필요가 있는지 결정하세요. Android의 v2rayNG와 v2flyNG는 보통 시스템 VPN 인터페이스로 트래픽을 처리합니다. 같은 사용자 공간의 다른 VPN 앱과 권한을 두고 충돌할 수 있으므로 연결 버튼에 시작 상태가 표시되는 것만으로는 부족하며 실제 네트워크를 확인해야 합니다.

앱 범위, LAN, UDP

v2rayNG의 ‘앱별 프록시’는 VPN 처리에 포함하거나 제외할 앱을 정하는 기능입니다. 포함 모드와 제외 모드는 선택 방향이 반대이므로 현재 모드의 설명을 확인하세요. 앱을 선택했다고 해서 항상 ‘선택한 앱만 프록시 처리’된다는 뜻은 아닙니다. 테스트 앱 하나를 고르고 완전히 종료한 뒤 다시 열어 클라이언트 로그에 나타나는지 확인한 다음 범위를 넓히세요. 시스템 구성 요소, 다운로드 관리자, 내장 웹 페이지는 각각 다른 프로세스에서 요청할 수 있으므로 실제 사용 방식에 맞춰 검증해야 합니다.

LAN 기기 검색, 인쇄, 화면 전송은 브로드캐스트나 멀티캐스트에 의존할 수 있으므로 사설 주소 직접 연결 규칙 하나만으로 복구된다고 보장할 수 없습니다. 해당 트래픽이 TUN을 거쳐야 하는지 확인한 뒤 클라이언트에 LAN 우회 설정이 있는지 살펴보세요. 실시간 통신이나 게임은 UDP를 자주 사용합니다. 웹 페이지가 열린다고 UDP 경로도 정상이라는 뜻은 아니므로 로컬 트래픽 처리 기능, 아웃바운드 프로토콜, 서버 지원 여부를 함께 확인하세요. 프로토콜이 UDP를 지원한다고 해서 모든 네트워크 환경에서 UDP를 전송할 수 있는 것은 아닙니다.

MTU는 단일 패킷에서 사용할 수 있는 페이로드 크기에 영향을 줍니다. 특정 대용량 요청이 멈추거나 연결은 되지만 전송이 불안정한 등 구체적인 단서가 있을 때만 조정을 고려하고, 기존 값을 기록한 뒤 단계적으로 검증하세요. 무작정 MTU를 낮추면 효율이 떨어지거나 다른 문제가 가려질 수 있습니다. 먼저 DNS, 아웃바운드 접속 불가, 중복 트래픽 처리를 확인한 뒤 이런 하위 계층 설정을 조정하세요. 하나의 값을 모든 플랫폼과 네트워크에 적용할 수는 없습니다.

종료할 때는 클라이언트에서 먼저 TUN을 끄고 프로그램을 종료한 다음 일반 네트워크 연결이 복구됐는지 확인하세요. 비정상 종료로 네트워크를 사용할 수 없게 됐다면 클라이언트를 다시 열어 정상적으로 종료하고 시스템 프록시와 가상 어댑터 상태를 점검하세요. 필요한 경우 현재 네트워크에 다시 연결하세요. 정체를 모르는 시스템 어댑터를 바로 삭제하거나 방화벽 규칙을 모두 지우지 마세요. macOS 권한 문제는 설치 허용 및 네트워크 권한 안내를 참고하고, 시작 단계에서 발생한 문제는 먼저 클라이언트 자체를 점검하세요.

FakeDNS

FakeDNS는 로컬 매핑에 사용할 가상 주소를 반환하며, 서비스 서버의 실제 공인 주소를 반환하지 않습니다. 앱이 가상 주소로 연결을 시도하면 트래픽 처리 구성 요소가 매핑을 통해 원래 도메인을 찾은 뒤 도메인 기준으로 라우팅하거나 프록시에 전달합니다. 이 방식은 도메인 정보를 유지하는 데 도움이 되지만 조건이 분명합니다. DNS 조회와 이후 연결이 매핑 정보를 공유할 수 있는 경로를 거쳐야 합니다. FakeDNS라는 옵션 하나만 켠다고 전체 경로가 자동으로 구성되지는 않습니다.

가상 매핑이 꼭 필요한지 먼저 판단

앱이 이미 로컬 프록시에 전체 도메인을 전달하고 있다면 코어에서 도메인 기준으로 일치시킬 수 있으므로 ‘최적화’를 위해 FakeDNS를 추가할 필요가 없는 경우가 많습니다. FakeDNS는 IP 계층에서 연결을 가로채면서 도메인 정보를 복원해야 하는 환경에 적합합니다. 활성화 여부는 옵션을 무조건 켤지 말지가 아니라 트래픽 처리 방식과 클라이언트 지원 여부에 따라 결정해야 합니다. 여러 구성 요소에서 사용하는 FakeDNS와 fake-ip는 이름이 비슷해도 설정 필드, 주소 풀, 캐시 구현이 다를 수 있습니다.

다음은 Xray / V2Fly 스타일 설정에서 주소 풀, DNS, 인바운드 스니핑이 어떻게 연결되는지 보여 줍니다. v2rayN의 모든 TUN 구현에서 사용할 수 있는 범용 설정이 아니며 전체 인바운드와 아웃바운드도 포함하지 않습니다. 현재 코어가 해당 필드를 지원하고 DNS 쿼리를 실제로 처리하는지 확인한 경우에만 필요한 부분을 사용자 지정 설정에 병합하세요. 클라이언트 그래픽 옵션을 사용하는 경우 클라이언트가 설정을 생성하도록 하는 것이 좋습니다. 충돌하는 설정을 별도로 직접 작성하지 마세요.

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

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

두 번째 블록은 매핑 복원이 필요한 인바운드 객체 내부에 들어가야 하며 완성된 설정의 아무 위치에나 붙여 넣을 수 없습니다. 주소 풀은 트래픽 처리 경로와 일치해야 하며 실제 네트워크 주소와 충돌해서는 안 됩니다. 예시에는 테스트 전용 주소 범위를 사용했으며 앱이 직접 접속할 수 있는 공용 서비스 주소가 아닙니다. poolSize는 매핑 용량을 뜻하며 서버 수나 성능을 보장하지 않습니다. 클라이언트가 매핑 풀을 관리한다면 명확한 문제가 없는 한 기본값을 유지하세요.

매핑, 캐시, 트래픽 스니핑의 관계

일반 트래픽 스니핑은 연결 초기 데이터에서 도메인을 식별하려고 시도하고, FakeDNS 복원은 앞서 생성된 주소 매핑에 의존합니다. 두 기능은 서로 간단히 대체할 수 없습니다. 일부 프로토콜이나 암호화 핸드셰이크에서는 식별 가능한 도메인이 드러나지 않아 스니핑이 실패할 수 있습니다. 매핑이 사라진 뒤에는 가상 주소만으로 원래 도메인을 알아낼 수도 없습니다. v2rayNG의 ‘트래픽 스니핑 활성화’는 실제 코어 설정과 함께 이해해야 하며, 임의의 연결 대상을 복원하는 만능 스위치가 아닙니다.

자주 발생하는 경계 사례는 클라이언트를 재시작한 뒤 매핑이 사라졌지만 앱은 이전 가상 주소를 캐시한 상태입니다. 이때 앱은 기존 주소로 계속 연결을 시도하지만 현재 코어에는 매핑 정보가 없어 일부 앱이 실패하다가 다시 열면 정상으로 돌아올 수 있습니다. 이 경우 기존 연결을 닫고 관련 DNS 캐시를 비우거나 테스트 앱을 다시 시작한 뒤 도메인을 다시 조회하세요. 프록시만 재시작하고 앱 연결은 그대로 두면 불일치가 지속되어 문제 해결 결과가 서로 모순될 수 있습니다.

특정 서비스는 실제 주소 해석 사용

일부 프로그램은 해석된 주소를 비교하거나 후속 프로토콜 필드에 주소를 넣고, 시스템 DNS를 우회하는 별도의 해석기를 사용하기도 합니다. 내부 기기 검색이나 주소 의미에 의존하는 앱도 가상 주소 응답과 호환되지 않을 수 있습니다. 호환성 문제가 있다면 스니핑 매개변수를 계속 추가하기보다 해당 도메인이나 앱에서 실제 주소 해석 경로를 사용하도록 되돌린 뒤 서비스가 작동하는지 확인하세요. LAN 도메인은 보통 가상 주소를 일괄 반환하는 대신 사내 DNS와 함께 처리해야 합니다.

테스트 도구에 표시된 대상이 가상 주소 풀에 속한다고 해서 서비스가 어느 지역에 배치됐는지 알 수 있는 것은 아닙니다. 지연 시간 비교나 서버 주소 수동 고정에도 이 주소를 사용하지 마세요. 실제 연결을 확인하려면 아웃바운드와 원격 대상 로그를 살펴보세요. 반대로 브라우저에 정상적인 공인 주소가 표시되어도 FakeDNS가 전혀 적용되지 않았다고 단정할 수 없습니다. 브라우저가 별도 DNS를 사용하거나 아직 만료되지 않은 캐시를 사용했을 수 있습니다. 검증은 새로 조회하는 단계부터 시작해야 합니다.

FakeDNS를 끌 때도 캐시와 라우팅 처리 순서를 지켜야 합니다. 먼저 실제 주소를 반환하는 DNS 설정으로 바꾸고 클라이언트를 다시 불러온 다음, 앱에 남아 있는 가상 주소를 지우세요. 새 조회 결과가 주소 풀 범위에 들지 않는지 확인한 뒤 트래픽 처리 규칙이 예상대로 복구됐는지 점검합니다. 변경 후 일부 앱만 실패한다면 먼저 캐시를 확인하세요. 모든 서비스가 즉시 실패한다면 서버 항목을 바꾸기보다 설정 생성, DNS 접속 가능 여부, 트래픽 처리 경로를 우선 확인하세요.

다중 구독 관리

다중 구독 관리는 출처별 구분을 유지하고 중복 수정을 줄이며 업데이트 실패 시 명확히 되돌릴 수 있도록 하는 것이 목적입니다. 구독 수가 늘어난다고 자동 장애 조치가 제공되거나 앱이 서비스에 가장 적합한 서버를 알아서 고르는 것은 아닙니다. ‘출처 관리’, ‘활성 서버 선택’, ‘서비스 라우팅’을 각각 설계하세요. 출처는 서버 항목을 제공하고, 활성 서버는 기본 프록시 출구를 결정하며, 라우팅은 어떤 연결을 해당 출구로 보낼지 정합니다. 이 세 가지를 뒤섞으면 업데이트 후 변경 내역을 추적하기 어렵습니다.

임시 용도가 아니라 관리 방식에 따라 그룹화

자동 업데이트 구독과 수동으로 관리하는 항목을 분리하는 것이 좋습니다. 자동 그룹에는 출처에서 받은 매개변수만 보관하고, 수동 그룹에는 명확히 검증한 로컬 수정 사항을 넣어 용도와 수정 이유를 메모하세요. 출처 이름은 안정적으로 유지하고 현재 활성 서버에 따라 바꾸지 않아도 됩니다. ‘업무’, ‘동영상’ 같은 용도는 메모나 필터로 구분하세요. 같은 구독을 여러 번 가져오면 결국 서로 같은 항목인지 판단하기 어려워집니다.

별칭만으로 중복 여부를 판단할 수는 없습니다. 이름이 비슷한 두 서버도 전송 계층, 포트, 인증 매개변수, 서비스 이름이 다를 수 있고, 이름이 달라도 연결 매개변수는 같을 수 있습니다. 중복을 정리하기 전에 클라이언트가 어떤 필드를 기준으로 중복을 판별하는지 확인하고 먼저 백업하세요. 기준을 알 수 없다면 출처별 그룹을 유지하고 표시 필터로 목록을 정리하는 편이 안전합니다. 추적할 수 없는 일괄 삭제는 피하세요.

업데이트 일정과 실패 시 복구

자동 업데이트는 매개변수가 안정적이고 출처 응답이 신뢰할 수 있는 구독에 적합하지만, 실제 필요 이상으로 자주 실행할 필요는 없습니다. 지나치게 잦은 업데이트는 출처의 요청 제한을 유발하거나 일시적인 오류를 재현하기 어렵게 만들 수 있습니다. 정기 업데이트를 설정한 뒤 정상 흐름을 한 번 지켜보며 실패했을 때 기존 항목이 유지되는지, 성공했을 때 활성 서버가 어떻게 처리되는지 확인하세요. 클라이언트와 업데이트 방식에 따라 동작이 다를 수 있으므로 ‘업데이트가 실패하면 로컬 데이터는 반드시 그대로다’라고 가정하지 마세요.

일괄 업데이트 전에 최소 한 개의 검증된 연결 경로를 복구에 사용할 수 있는지 확인하세요. 업데이트에 프록시가 필요하다면 현재 사용할 수 있는 항목을 특히 잘 보존해야 합니다. 업데이트 후 출처가 빈 응답을 반환하면 그룹을 모두 비우기 전에 응답 오류와 필터 조건부터 확인하세요. 복구할 때는 로컬 백업을 복원하거나 확인된 구독 설정을 다시 가져오세요. 다른 사람에게 테스트를 부탁한다며 기존 인증 링크를 공개하지 마세요. 인증 정보가 만료됐다면 제공처에 새로 발급받아야 합니다.

기기 간 동기화와 형식 선택

데스크톱과 Android 사이에서 데이터를 옮길 때는 클라이언트 데이터 디렉터리 전체를 복사하기보다 구독 주소나 클라이언트가 지원하는 단일 공유 링크를 전달하세요. 데이터베이스, 인터페이스 상태, 경로, 실행 구성 요소는 플랫폼마다 다르므로 디렉터리를 복사하면 사용할 수 없는 경로나 이전 권한이 함께 옮겨질 수 있습니다. 이전한 뒤 프로토콜, 전송 매개변수, 보안 설정을 확인하고 실제 연결을 테스트하세요. v2rayN에서 사용할 수 있는 확장 필드가 v2flyNG의 코어에서도 지원된다는 보장은 없습니다.

Base64 구독에는 보통 여러 공유 항목이 포함되고, 전체 JSON에는 인바운드, 아웃바운드, 라우팅, DNS가 들어 있을 수 있습니다. 전체 JSON을 일반 구독으로 가져와도 클라이언트가 서버 목록을 추출하지 못할 수 있습니다. 반대로 공유 링크를 가져와도 원래 라우팅 구성이 자동으로 적용되지는 않습니다. 가져오기에 실패하면 먼저 데이터 형식과 클라이언트의 가져오기 메뉴를 확인하세요. 구체적인 구조는 구독 형식과 공유 링크 안내를 참고하고, 파일 확장자만 바꿔 변환하려 하지 마세요.

내보내기 범위도 확인해야 합니다. 선택한 서버만 내보내는 기능, 현재 그룹을 내보내는 기능, 모든 그룹과 설정이 포함될 수 있는 전체 백업은 서로 다릅니다. 다른 기기로 옮기기 전에 파일에 이전할 필요가 없는 구독 출처가 포함됐는지 확인하세요. 이전 기기를 정리할 때는 내보낸 파일, 클립보드 기록, 클라우드 저장소의 복사본도 확인해야 합니다. 클라이언트 화면에서 항목만 삭제하고 계속 접근할 수 있는 구독 주소를 남겨 두지 마세요.

반복해서 설정을 시험하는 대신 변경 내역 기록

큰 설정 변경을 할 때마다 기존 라우팅 구성, 현재 코어, 트래픽 처리 방식, 수정 이유를 기록하세요. 인증 정보는 저장할 필요가 없습니다. ‘어느 단계부터 문제가 시작됐는지’를 확인할 수 있으면 됩니다. 여러 구독 출처에서 동시에 문제가 생기면 현재 네트워크, DNS, 시스템 시간, 클라이언트 권한, 업데이트 프록시 경로처럼 공통으로 사용하는 요소부터 확인하세요. 한 출처에서만 실패한다면 주소 유효성, 응답 형식, 출처 인증을 점검합니다. 클라이언트 세 개를 번갈아 재설치하는 것보다 이 순서가 유용한 단서를 보존하기 쉽습니다.

마지막으로 백업 복원도 실제로 테스트하세요. 백업을 다시 가져올 수 있는지, 수동 항목을 인식하는지, 라우팅과 DNS 설정이 빠지지 않았는지 확인한 뒤 자동 업데이트에 의존해 장기간 사용하세요. 복원 테스트는 업무 연결을 전환할 필요가 없는 시간에 진행하는 것이 좋습니다. 데스크톱 클라이언트가 시작되지 않으면 먼저 시작 시 강제 종료 문제 해결을 따라 실행 환경을 확인하세요. 설정 손상과 구독 출처 문제는 서로 다른 원인이므로 따로 처리해야 합니다.

사용자 지정 아웃바운드

아웃바운드는 코어가 대상에 실제 연결을 수립하는 실행 객체이며, 라우팅은 태그를 통해 연결을 해당 아웃바운드로 보냅니다. v2rayN을 일반적으로 사용할 때는 클라이언트가 선택한 서버에 따라 프록시 아웃바운드를 생성하고 직접 연결 및 차단 아웃바운드와 함께 사용합니다. 여러 출구, 특수 연결 경로, 완전한 사용자 지정 설정이 필요한 경우에만 아웃바운드 구조를 직접 관리하세요. 직접 설정을 작성하기 전에 그래픽 인터페이스의 서버 선택과 라우팅 규칙으로 요구 사항을 해결할 수 있는지 확인하면 클라이언트 생성 설정과 로컬 수정 내용이 서로 덮어쓰는 위험을 줄일 수 있습니다.

검증 가능한 최소 구조부터 시작

다음은 로컬 SOCKS 인바운드, 직접 연결 아웃바운드, 차단 아웃바운드만 포함한 Xray / V2Fly 스타일의 학습용 설정입니다. 원격 프록시 서버에는 연결되지 않습니다. 로컬 프록시 서비스가 실수로 LAN에 공개되지 않도록 수신 주소를 루프백으로 제한했습니다. 이 설정은 인바운드, 라우팅, 아웃바운드 태그의 참조 관계를 이해하기 위한 예시입니다. 구독에서 제공하는 원격 서버에 연결하려면 검증된 서버 매개변수를 사용하고 인증 필드를 임의로 추측하지 마세요.

{
  "log": {
    "loglevel": "warning"
  },
  "inbounds": [
    {
      "tag": "local-socks",
      "listen": "127.0.0.1",
      "port": 10808,
      "protocol": "socks",
      "settings": {
        "auth": "noauth",
        "udp": true
      }
    }
  ],
  "outbounds": [
    {
      "tag": "direct",
      "protocol": "freedom",
      "settings": {}
    },
    {
      "tag": "block",
      "protocol": "blackhole",
      "settings": {}
    }
  ],
  "routing": {
    "rules": [
      {
        "type": "field",
        "domain": ["full:blocked.example.com"],
        "outboundTag": "block"
      }
    ]
  }
}

예시에서 일치하지 않는 연결은 첫 번째 아웃바운드인 직접 연결로 전달됩니다. 예약된 예시 도메인은 차단 규칙을 보여 주기 위한 것입니다. 테스트 전에 해당 수신 포트를 기존 클라이언트가 사용 중인지 확인하고 같은 포트에서 두 번째 인스턴스를 실행하지 마세요. 클라이언트에서 전체 사용자 지정 설정을 사용하면 인터페이스의 활성 서버, DNS, 라우팅 옵션이 계속 적용될지는 가져오기 방식에 따라 다릅니다. 실제 생성된 설정이나 로그를 확인해야 하며 모든 그래픽 옵션이 자동으로 함께 적용된다고 가정하면 안 됩니다.

태그 이름과 기본 동작

tag는 로컬에서 참조하는 이름이지 프로토콜 이름이나 서버가 자동으로 인식하는 매개변수가 아닙니다. 라우팅의 outboundTag는 정의된 아웃바운드 이름과 정확히 일치해야 합니다. 이름이 다르면 시작 또는 실행 중 문제가 발생할 수 있습니다. 의미가 분명하고 중복되지 않는 짧은 이름을 사용하고 기본 아웃바운드의 배치 순서를 기록해 두세요. 서버 별칭이 자동으로 아웃바운드 태그가 된다고 가정하지 마세요. 클라이언트 목록에 표시되는 이름과 코어 설정 필드는 서로 다른 계층입니다.

수정하기 전에 정상 작동하는 전체 설정을 하나 저장한 뒤 문법과 시작 여부를 확인하세요. JSON에는 일반 주석이나 끝의 불필요한 쉼표를 넣을 수 없습니다. 인터페이스 편집기에서 내용이 허용되어도 코어가 해당 필드를 지원한다는 뜻은 아닙니다. 로그에 알 수 없는 프로토콜이나 필드가 표시되면 실제로 Xray와 V2Fly 중 어느 코어가 실행되는지, 해당 필드가 어느 계층에 속하는지 확인하세요. JSON을 사용하더라도 다른 네트워크 구성 요소의 설정을 그대로 가져올 수는 없습니다. 연쇄적으로 발생한 후속 오류에 휘둘리지 말고 처음 발생한 유효한 오류부터 살펴보세요.

체인 연결과 다중 출구의 범위

체인 연결에서는 각 구간의 역할을 명확히 해야 합니다. 앞 구간은 다음 구간에 도달하고, 다음 구간은 최종 대상에 접속합니다. 다른 아웃바운드를 참조하는 방식, 사용할 수 있는 전송 기능, 필드 지원 여부는 코어 구현에 따라 다릅니다. 서버 객체 두 개를 나란히 놓는 것만으로 연결 체인이 만들어진다고 생각하지 마세요. 각 구간을 먼저 따로 검증한 다음 조합된 DNS, UDP, 연결 재사용을 테스트하세요. 연결 경로가 복잡해지면 의존성이 늘어나 어느 한 구간의 실패도 최종 연결에 영향을 줄 수 있습니다.

아웃바운드가 여러 개 있어도 자동 속도 측정, 부하 분산, 장애 조치가 활성화되는 것은 아닙니다. 선택기나 분산 정책을 사용하려면 후보 목록, 선택 로직, 상태 확인을 별도로 설정하고 현재 코어가 이를 지원하는지 확인해야 합니다. 기본 서버만 바꾸려는 데스크톱 사용자는 v2rayN의 기존 서버 선택 기능을 우선 사용하세요. 복잡한 설정을 일상 환경에 적용하기 전에 간단한 설정으로 해결되지 않는 구체적인 문제가 무엇인지 설명할 수 있어야 합니다.

서비스 요청으로 돌아가 검증

설정을 마친 뒤 인바운드 수신, 라우팅 일치, 아웃바운드 연결, 서비스 응답의 네 단계로 확인하세요. 포트가 수신 중이라는 사실은 프로그램이 어느 정도까지 시작됐다는 뜻일 뿐입니다. 실제 연결이 성공해도 대상 서비스의 모든 도메인과 UDP가 작동한다는 보장은 없습니다. 반복할 수 있는 서비스 작업 하나를 선택해 기존 연결을 닫고 실행한 다음 오류가 어느 단계에서 발생하는지 기록하세요. 로그 상세 수준을 임시로 높일 때 대상 도메인과 주소가 기록될 수 있다는 점에 유의하고, 문제 해결이 끝나면 평소 로그 수준으로 되돌리세요.

사용자 지정 설정은 실패하지만 그래픽 인터페이스에서 생성한 설정이 정상이라면 먼저 정상 구성으로 되돌린 다음 두 설정의 인바운드, 기본 아웃바운드, DNS, 라우팅 차이를 비교하세요. 구독의 인증 매개변수를 계속 수정하지 마세요. 사용자 지정 구성을 장기간 유지한다면 적용되는 코어, 필요한 리소스, 복구 절차를 로컬 문서에 기록하세요. 기본 용어는 용어집을, 세 클라이언트의 사용 범위는 클라이언트 선택 가이드를 참고하세요. 최초 연결이 아직 되지 않았다면 입문 가이드로 돌아가 최소한의 설정부터 완료해야 합니다.