고급 설정 가이드

구독 그룹 및 서버 필터링

그룹 구성: 출처, 용도, 추적 가능성

구독 그룹은 서버의 출처를 구분하기 위한 기능이지, 라우팅 정책을 대신하지 않습니다. 먼저 설정 출처별로 그룹을 나누고 메모에 일상 연결, 임시 테스트, 코어 호환성 확인 등의 용도를 적어 두세요. 그룹 이름은 정리와 선택에만 영향을 주며 특정 앱의 트래픽 경로를 자동으로 결정하지 않습니다. 도메인이나 주소에 따라 출구를 선택하려면 라우팅 설정을 사용해야 합니다.

설정 위치: v2rayN의 구독 그룹 설정에서 새 그룹을 만들고 알아보기 쉬운 이름을 입력한 다음, 구독 주소를 해당 그룹의 주소란에 넣으세요. 저장한 뒤에는 해당 그룹만 업데이트하고 파싱이 완료되었는지 확인한 다음 서버 목록이 예상한 위치에 표시되는지 살펴보세요. 메뉴 이름은 버전에 따라 다를 수 있습니다. 화면 좌표를 그대로 따라 하기보다 그룹 이름, 구독 주소, 업데이트 항목을 확인해 메뉴를 찾으세요.

정보 보호: 구독 주소에는 계정을 식별할 수 있는 경로나 매개변수가 들어 있는 경우가 많으므로 접근 자격 증명처럼 취급해야 합니다. 그룹 메모에 전체 주소를 복사하지 말고, 문제 해결 화면을 공유할 때도 민감한 부분을 가리세요. 설정을 다른 사람에게 전달하기 전에는 서버 주소, 사용자 식별 정보, 인증 항목도 확인해야 합니다. 구독 링크만 삭제해도 내보낸 서버 설정에서 민감 정보가 제거되는 것은 아닙니다.

필터 규칙: 먼저 매칭 대상을 확인

서버 필터링: 현재 메뉴가 구독에서 받은 내용, 이미 가져온 서버, 화면에 표시 중인 목록 중 무엇을 필터링하는지 먼저 확인하세요. 검색창은 보통 보이는 항목만 바꾸며 설정을 삭제하지 않습니다. 구독 필터는 다음 가져오기 결과에 영향을 줄 수 있습니다. 두 기능을 혼동하면 서버가 사라졌다고 생각하기 쉽지만, 실제로는 표시 조건이 남아 있거나 업데이트 중 필터링된 것일 수 있습니다.

매칭 문법: 모든 필터 항목이 정규식을 지원하는 것은 아니며 대소문자 처리 방식도 제각각입니다. 실제로 존재하는 짧은 단어 하나로 먼저 테스트한 뒤 조건을 조합하세요. 정규식을 지원한다고 명시된 메뉴에서는 办公|测试를 사용해 메모에 두 단어 중 하나가 포함된 항목을 찾을 수 있습니다. 일반 텍스트만 지원한다면 이 문자열 전체가 하나의 검색어로 처리되어 결과가 나오지 않을 수 있습니다.

조건 좁히기: 먼저 넓은 범위로 검색해 필요한 설정이 나오는지 확인한 뒤 제외 조건을 하나씩 추가하세요. 복잡한 부정 매칭부터 작성하지 마세요. 제공자가 노드 메모를 바꿀 수 있고 괄호, 공백, 지역 약어도 고정되어 있지 않습니다. 프로토콜 지원 여부는 설정 내용과 코어 로그를 확인해야 하며, 메모의 특정 키워드만으로 판단할 수 없습니다.

업데이트 확인: 다운로드 실패와 파싱 실패 구분

업데이트 경로: 구독 업데이트는 클라이언트가 보내는 네트워크 요청으로, 브라우저에서 웹페이지에 접속되는지 확인하는 것과는 별개의 테스트입니다. 직접 연결로 콘텐츠를 가져오지 못한다면 '구독 업데이트 시 프록시 사용' 같은 설정을 고려할 수 있지만, 먼저 사용 가능한 출구가 있어야 합니다. 아직 연결을 설정하지 않은 상태에서 프록시 업데이트를 켜면 순환 의존이 생길 수 있으므로 먼저 기본 접속 경로부터 해결하세요.

파싱 결과: 업데이트 성공 메시지만 확인하지 말고 전체 항목 수와 함께 프로토콜 유형, 주소, 포트, 그룹 소속을 점검하세요. 응답 내용이 만료 안내 페이지나 인증 페이지일 수도 있습니다. 네트워크 요청이 성공했다고 유효한 구독이라는 뜻은 아닙니다. 로그에 형식 오류가 표시되면 주소를 빠짐없이 복사했는지, 만료되지는 않았는지 확인한 다음 현재 클라이언트가 해당 구독 형식을 지원하는지 살펴보세요.

로컬 수정 사항: 구독 서버를 수동으로 수정해도 다음 업데이트 때 덮어써질 수 있습니다. 계속 유지해야 할 변경 사항은 클라이언트에서 지원하는 별도 설정으로 관리하거나 수동 관리 그룹에 복사하고, 원본 설정과 달라진 부분을 기록하세요. 같은 설정을 여러 그룹에서 반복 편집하지 마세요. 문제 발생 시 실제 활성화된 항목을 확인하기 어려워집니다.

복구 순서: 서버 수가 갑자기 줄었다면 먼저 목록 검색을 지우고 새 필터 조건을 끈 다음 문제가 생긴 그룹만 업데이트하세요. 오류 로그와 원래 설정 유형을 비교하고 구독을 모두 삭제한 뒤 다시 만들지는 마세요. 업데이트 실패의 세부 원인은 v2rayN 구독 업데이트 실패 및 자동 업데이트 설정을 참고하세요. 여러 출처의 관리 주기를 조정하려면 다중 구독 관리도 확인하세요.

라우팅 규칙 실전

요청 경로: 인바운드, 매칭, 아웃바운드

라우팅 구조: 앱 요청은 먼저 인바운드로 들어옵니다. 코어는 대상 도메인, 대상 주소, 포트 등의 조건으로 규칙을 찾고 연결을 해당 아웃바운드로 전달합니다. 시스템 프록시나 TUN은 요청이 이 경로에 들어올 수 있는지를 결정하고, 라우팅은 코어에 전달된 트래픽만 처리합니다. 따라서 앱이 로컬 프록시를 사용하지 않는다면 도메인 규칙을 반복해서 수정해도 접속 결과가 달라지지 않을 수 있습니다.

매칭 순서: 규칙은 일반적으로 등록된 순서대로 확인하며 먼저 일치한 규칙이 아웃바운드를 결정합니다. 범위가 명확한 예외를 앞에 두고 더 넓은 규칙을 뒤에 배치하세요. 하나의 규칙 객체에 있는 여러 조건은 보통 모두 충족해야 하고, 같은 조건 배열의 항목은 대개 하나만 일치해도 됩니다. 도메인 조건과 주소 조건을 같은 객체에 넣으면 예상보다 범위가 좁아질 수 있습니다.

프로토콜 범위: VMess, VLESS, Trojan은 연결 프로토콜을 설명하고 REALITY는 전송 보안 관련 설정입니다. 어느 것도 라우팅을 대신하지 않습니다. 노드를 가져올 수 있다는 것은 클라이언트가 설정 형식을 인식했다는 뜻일 뿐, 실행 중인 모든 코어가 모든 필드를 지원한다는 의미는 아닙니다. 프로토콜은 서버 설정을 기준으로 선택하고 실제로 실행되는 코어의 지원 여부를 확인하세요. 라우팅 규칙에 맞추려고 노드 프로토콜을 바꾸지는 마세요.

규칙 예시: 일부 설정 병합 및 태그 확인

예시 용도: 아래는 Xray 라우팅의 일부 설정으로, 사설 주소와 중국 본토 도메인 목록을 direct라는 아웃바운드로 전달합니다. 사용 전에 해당 아웃바운드가 실제로 있는지, 규칙 데이터 파일을 읽을 수 있는지 확인하세요. 이 예시에는 프록시 출구가 정의되어 있지 않고, 일치하지 않는 요청의 처리 방식도 지정되어 있지 않습니다. 따라서 나머지 트래픽이 반드시 프록시를 거친다고 볼 수 없습니다.

{
  "routing": {
    "domainStrategy": "IPIfNonMatch",
    "rules": [
      {
        "type": "field",
        "ip": ["geoip:private"],
        "outboundTag": "direct"
      },
      {
        "type": "field",
        "domain": ["geosite:cn"],
        "outboundTag": "direct"
      }
    ]
  }
}

태그 연결: outboundTag는 아웃바운드 식별자를 참조하며 임의로 표시할 이름이 아닙니다. 클라이언트가 다른 태그를 생성할 수 있으므로 실제 적용 중인 설정을 확인한 뒤 참조하세요. 저장할 때는 통과했지만 실행 중 아웃바운드를 찾을 수 없다는 오류가 나면 태그의 대소문자와 철자를 확인하세요. 클라이언트가 설정을 다시 생성하면서 태그가 바뀌었다면 지원되는 라우팅 편집 메뉴에서 수정해야 합니다.

도메인 전략: AsIs는 이미 전달된 도메인 정보로 매칭하며 주소 규칙을 위해 별도로 조회하지 않습니다. IPIfNonMatch는 도메인 매칭에 실패하면 주소를 조회한 뒤 IP 규칙을 계속 확인합니다. IPOnDemand는 규칙에 주소 정보가 필요할 때 조회합니다. 뒤의 두 설정은 DNS 조회에 대한 의존성을 높일 수 있으므로 더 적극적으로 조회할수록 정확하다고 단정할 수 없습니다.

매칭 확인: 로그로 규칙 문제와 연결 문제 구분

정보 출처: 앱이 도메인과 함께 SOCKS 요청을 보내면 코어가 도메인으로 바로 매칭할 수 있습니다. 앱이 먼저 DNS를 조회한 뒤 주소만 전달하면 사용할 수 있는 정보가 달라집니다. 트래픽 스니핑으로 일부 프로토콜에서 도메인을 보완할 수는 있지만 모든 연결을 식별하는 것은 아닙니다. 로그에 주소만 표시된다면 요청에 어떤 정보가 담겼는지 확인한 뒤 스니핑, DNS 설정, TUN이 필요한지 판단하세요.

검증 방법: 대상이 분명한 동작 하나를 선택하고 백그라운드 앱의 영향을 줄인 다음, 연결에 사용된 인바운드와 대상, 아웃바운드 태그를 확인하세요. 올바른 아웃바운드에 연결됐는데도 실패한다면 해당 출구의 연결 상태와 서버 설정을 점검하세요. 잘못된 아웃바운드에 연결됐다면 규칙 순서, 도메인 정보가 전달되는지, 주소 목록에 대상이 포함되는지 확인하세요. 웹페이지가 빠르게 열린다는 사실만으로 라우팅 규칙이 적용됐다고 판단할 수는 없습니다.

기본 처리: 사용자 지정 설정에서 어떤 규칙에도 일치하지 않은 트래픽은 대개 기본 아웃바운드로 전달됩니다. 기본 아웃바운드는 아웃바운드 목록 순서와 관련이 있으며 GUI 클라이언트가 자체 기본 규칙을 생성할 수도 있습니다. 아웃바운드를 추가하거나 순서를 바꾸기 전에 이 동작을 확인하고 기록하세요. 직접 연결 아웃바운드를 앞에 두면 원래 프록시를 통해야 할 미매칭 요청까지 직접 연결될 수 있어 영향 범위가 커집니다.

복구 방법: 한 번에 한 종류의 조건만 추가하고 변경 전 규칙 순서와 현재 출구를 기록해 두세요. 문제가 생기면 새 규칙을 먼저 비활성화한 뒤 코어를 재시작하거나 테스트 연결을 다시 만드세요. 기존 연결은 규칙을 다시 적용하지 않을 수 있습니다. 규칙 목록 이름은 용어 설명을 참고하세요. 올바른 규칙에 매칭됐는데도 연결되지 않는다면 노드 시간 초과 문제 해결 순서에 따라 원인을 확인하세요.

DNS 설정 최적화

DNS 계층: 먼저 조회 주체 확인

조회 경로: 시스템 리졸버, 브라우저 내장 보안 DNS, 클라이언트 내장 DNS, 서버 측 조회가 동시에 사용될 수 있습니다. 클라이언트 DNS를 바꿔도 브라우저가 직접 보내는 조회 요청은 달라지지 않을 수 있습니다. 시스템 프록시를 켰다고 시스템의 모든 조회가 코어를 통과하는 것도 아닙니다. 최적화하기 전에 실제 경로를 정리하고 앱이 도메인과 주소 중 무엇을 전달하는지, 마지막으로 어떤 계층이 DNS 서버를 선택하는지 확인하세요.

문제 구분: 도메인 조회 실패, 조회 결과로 접속 불가, 느린 응답, 잘못된 라우팅 대상은 서로 다른 문제입니다. 주소를 이미 받았는데 연결이 시간 초과된다면 DNS 서버를 계속 바꿔도 해결되지 않을 수 있습니다. 같은 도메인이 네트워크에 따라 서로 다른 주소를 반환하더라도 바로 오류라고 단정하지 마세요. 분산 서비스는 접속 위치에 따라 다른 결과를 반환할 수 있습니다. 연결 로그와 대상 네트워크를 함께 확인하세요.

목표 설정: DNS 최적화는 공용 서버를 더 많이 추가하는 것이 아니라 불필요한 의존성을 줄이는 작업입니다. 코어 시작에 필요한 노드 도메인을 조회할 때 DNS 요청도 아직 연결되지 않은 노드를 반드시 거치도록 설정하면 시작 단계에서 순환 의존이 생깁니다. 현재 네트워크에서 기본 조회를 완료할 경로를 유지한 뒤 서비스 도메인의 조회 방식을 단계적으로 조정하세요.

필드 비교: 주소 계열 및 도메인별 조회

기본 예시: 아래는 Xray 내장 DNS의 일부 설정으로, 조회 서버와 주소 계열을 선택하는 방식을 보여줍니다. 주소는 설정 구조를 설명하기 위한 예시일 뿐이므로 사용 전에 현재 네트워크에서 연결 가능한지, 원하는 조회 방식에 맞는지 확인하세요. 이 설정만으로 시스템 DNS 요청이 자동으로 코어에 전달되지는 않으며 조회 트래픽에 사용할 아웃바운드도 지정하지 않습니다. 따라서 기기 전체의 DNS 트래픽을 이 설정만으로 처리할 수는 없습니다.

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

조회 범위: 서버 객체의 domains는 해당 서버에 우선 전달할 도메인 목록을 지정하지만, 다른 서버로는 관련 조회가 절대 전달되지 않는다고 단정할 수 없습니다. 재시도 방식, 예상 주소 조건, 코어 구현이 이후 동작에 영향을 줍니다. 조회 경로를 엄격히 제한하려면 사용 중인 코어의 폴백 필드를 확인하고 로그나 로컬 네트워크에서 동작을 검증하세요.

주소 계열 선택: 네트워크에서 IPv4와 IPv6를 모두 사용할 수 있다면 로그를 줄이기 위해 한쪽 주소 계열을 계속 제한할 필요는 없습니다. 일시적으로 UseIPv4를 사용하면 다른 주소 계열과 관련된 문제인지 확인하는 데 도움이 됩니다. 테스트가 성공한 뒤에도 시스템 라우팅, 출구 지원, 서버의 수신 설정을 확인하세요. 내장 DNS의 선택은 해당 조회 동작에만 적용되며 앱이 주소를 직접 전달하면 주소가 변환되지 않습니다.

캐시 및 폴백: 테스트 결과를 명확히 확인

캐시 영향: DNS 서버를 바꾼 뒤에도 시스템, 브라우저, 클라이언트가 캐시된 결과를 계속 사용할 수 있습니다. 먼저 기존 연결을 닫고 실제로 관련된 구성 요소의 캐시를 지우거나 앱을 재시작하세요. 매번 기기 전체를 재부팅할 필요는 없습니다. 변경 전후의 반환 주소와 출구 태그를 기록해야 설정이 실제 적용된 것인지, 연결 가능한 이전 주소를 우연히 사용한 것인지 구분할 수 있습니다.

폴백 설정: 보조 서버를 지정하면 한 경로에 문제가 생겼을 때 가용성이 높아질 수 있지만 DNS 동작은 복잡해집니다. 모든 서버에서 시간 초과가 발생한다면 도메인보다 조회 트래픽의 아웃바운드나 현재 네트워크가 원인일 수 있습니다. 특정 도메인만 문제가 있다면 도메인 목록 매칭과 반환 주소부터 확인하세요. 문제가 없는 앱까지 영향을 받도록 전역 DNS 설정을 변경하지 마세요.

로컬 네트워크: 프린터, LAN 호스트, 내부 서비스는 라우터 DNS나 로컬 검색 도메인에 의존할 수 있습니다. 모든 조회를 공용 DNS 서버로 보내면 이런 이름이 더 이상 확인되지 않을 수 있습니다. 명확한 내부 도메인은 로컬 DNS 경로를 유지하고 해당 주소의 라우팅이 직접 연결인지 확인하세요. DNS 레코드만 추가하고 사설 주소를 원격 출구로 보내도 정상적으로 접속되지 않습니다.

단계별 검증: 먼저 시스템 프록시 모드에서 일반 도메인 하나의 조회와 연결을 확인하고, 다음으로 TUN을 활성화한 뒤 마지막으로 FakeDNS를 검토하세요. 각 단계에서 복구 가능한 설정을 남기고 주소 계열, 조회 서버, 라우팅 정책을 동시에 바꾸지 마세요. 인증서 이름이 일치하지 않는다면 TLS 핸드셰이크 및 SNI 확인 방법을 참고하세요. 인증서 검증을 끄는 방식으로 DNS나 설정 오류를 가리지 마세요.

TUN 모드

처리 범위: 가상 네트워크 어댑터는 출구가 아님

TUN의 역할: 가상 네트워크 어댑터는 시스템 라우팅 조건에 맞는 네트워크 트래픽을 사용자 공간으로 전달하므로 시스템 프록시를 따르지 않는 앱에 유용합니다. TUN은 트래픽이 클라이언트에 들어오는 방식을 해결할 뿐, 노드 인증 오류나 서버 연결 실패, 잘못된 라우팅 규칙을 자동으로 수정하지 않습니다. 활성화 후에도 사용 가능한 출구와 올바른 DNS 경로가 필요하며 자체 연결이 반복해서 가로채이지 않도록 시스템 라우팅도 확인해야 합니다.

모드 차이: 시스템 프록시는 앱이 시스템 프록시 설정을 읽어야 작동하고, TUN은 네트워크 계층에 가까운 곳에서 패킷을 받습니다. 환경에 따라 두 방식을 함께 사용할 수 있지만 처음 문제를 진단할 때는 한 가지 처리 방식만 검증하는 것이 좋습니다. 브라우저는 정상인데 다른 앱에 문제가 있다면 해당 앱이 시스템 프록시를 사용하지 않는 것일 수 있습니다. 그렇다고 모든 노드나 코어를 바꿔야 한다고 볼 수는 없습니다.

코어 구성: 데스크톱 클라이언트의 TUN 기능은 별도 구성 요소와 프록시 코어가 함께 동작할 수 있으며, 설정 필드와 권한 요건은 실제 조합에 따라 달라집니다. 인터넷에서 찾은 tun 필드가 포함된 설정을 아무 Xray 설정에나 붙여 넣지 마세요. 우선 v2rayN에서 제공하는 TUN 설정 메뉴를 사용하고 시작 로그에서 관련 구성 요소가 실제로 실행되는지 확인하세요.

활성화 절차: 기본 상태 확인부터 시스템 라우팅까지

연결 기본값 확인: TUN을 켜기 전에 시스템 프록시 모드에서 사용 가능한 서버를 하나 선택해 연결하고 선택한 서버, 라우팅 모드, DNS 설정을 기록하세요. 그런 다음 라우팅을 바꾸거나 가상 네트워크 어댑터를 만드는 다른 도구를 종료해 기본 경로를 두고 충돌하지 않도록 하세요. FakeDNS도 동시에 켜지 말고 일반 DNS와 TUN 처리를 각각 확인할 수 있는 상태를 먼저 만드세요.

권한 준비: Windows에서 네트워크 어댑터를 만들거나 라우팅을 추가하려면 관리자 권한이 필요할 수 있습니다. macOS와 Linux에서도 시스템 승인이나 관련 서비스 권한이 필요할 수 있으므로 클라이언트 안내를 따르세요. 스위치를 켜자마자 꺼진다면 반복해서 클릭하지 말고 권한 거부, 구성 요소 시작 실패, 네트워크 어댑터 생성 오류를 확인하세요. 권한을 승인한 뒤에도 라우팅이 실제로 설정됐는지 점검해야 합니다.

모바일 기기 동작: Android의 v2rayNG와 v2flyNG는 보통 시스템 VPN 인터페이스로 트래픽을 처리하며 처음 실행할 때 시스템 권한을 승인해야 합니다. 데스크톱 TUN과 구현 방식이 다르므로 데스크톱 설정을 그대로 적용하지 마세요. 같은 인터페이스를 사용하는 다른 앱과 충돌할 수 있으니 전환 전에 현재 트래픽을 처리하는 클라이언트를 확인하세요.

트래픽 처리 확인: 먼저 시스템 프록시를 따르지 않던 앱에서 테스트하고 클라이언트 연결 기록에 해당 대상이 나타나는지 확인하세요. 다음으로 일반 웹사이트, LAN 서비스, 구독 업데이트가 계속 작동하는지 점검합니다. 네트워크 어댑터가 보이거나 연결 아이콘이 표시되는 것만으로는 충분하지 않습니다. 어댑터 생성에 성공해도 DNS 라우팅, 출구 라우팅, 앱 접속은 각각 실패할 수 있습니다.

일반적인 충돌: 우회, 루프, 패킷 크기

자체 트래픽 우회: 프록시 구성 요소가 서버에 연결하는 트래픽은 가상 네트워크 어댑터로 다시 들어가지 않도록 적절히 우회되어야 합니다. 그렇지 않으면 연결 루프가 생길 수 있습니다. 클라이언트가 관련 라우팅을 자동으로 설정하는 경우가 많지만 기본 라우팅, 인터페이스 바인딩, 사용자 지정 아웃바운드를 직접 변경하면 이 설정이 깨질 수 있습니다. 로그에 같은 연결이 반복해서 생성되고 접속이 전반적으로 실패한다면 새 설정을 비활성화하고 클라이언트의 기본 처리 방식으로 되돌리세요.

LAN 접속: 원격 데스크톱, 프린터, 내부 주소에 접속할 수 없다면 먼저 사설 네트워크 대역이 처리 대상인지 확인한 다음, 해당 트래픽이 직접 연결 아웃바운드로 가는지 점검하세요. 일부 네트워크의 내부 리소스는 일반적인 사설 주소를 사용하지 않을 수 있으므로 사설 대역 규칙만 추가해서 해결되지 않을 수 있습니다. 실제 네트워크 대역에 맞춰 예외 범위를 최소화하고, 특정 리소스 하나 때문에 무관한 트래픽 전체를 우회하지 마세요.

패킷 크기: 일부 사이트는 열리지만 대용량 파일이나 장시간 연결이 멈춘다면 MTU를 후속 점검 항목으로 고려하세요. 처음부터 무작정 바꾸지는 마세요. 먼저 DNS, 프로토콜, 서버 문제를 제외하고 클라이언트에서 제공하는 메뉴를 이용해 한 번에 하나씩 테스트한 뒤 기존 값을 기록해 두세요. 네트워크마다 캡슐화 오버헤드가 달라 모든 기기와 연결에 맞는 고정 최적값은 없습니다.

안정성 확인: 절전 모드에서 깨어난 뒤, 무선 네트워크를 바꾼 뒤, 기본 네트워크 어댑터를 변경한 뒤에는 이전 인터페이스나 라우팅이 더 이상 유효하지 않을 수 있으므로 다시 확인하세요. 트래픽 처리가 안정된 다음 도메인 분할 라우팅이나 FakeDNS를 추가하세요. 용어 차이는 FAQ를 참고하세요. 첫 연결이 완료되지 않았다면 설정 가이드로 돌아가세요. 검증되지 않은 여러 단계를 오가며 동시에 변경하지 마세요.

FakeDNS

주소 매핑 원리: 가상 주소로 도메인 보존

동작 방식: FakeDNS는 대상 서버의 실제 주소를 반환하는 대신 도메인에 매핑 주소를 할당합니다. 앱이 해당 주소에 연결하면 연동 구성 요소가 매핑 정보를 이용해 원래 도메인을 찾아 라우팅이나 아웃바운드로 전달합니다. 이 기능은 주소만 전달하는 트래픽에도 도메인 정보를 유지하는 데 유용하며, 원격 네트워크에 해당 주소를 사용하는 실제 서버를 만드는 기능은 아닙니다.

필요 조건: 앱의 DNS 요청이 지정된 FakeDNS 경로를 통과하고, 이후 연결도 해당 매핑 정보를 인식하는 구성 요소가 받아야 합니다. 둘 중 하나만 처리하면 실패합니다. 시스템이 가상 주소를 받은 뒤 일반 네트워크로 직접 보내면 실제 대상에 도달하지 못할 수 있습니다. 반대로 연결을 가로채더라도 DNS 요청이 매핑 서비스를 우회하면 도메인 정보를 복원할 수 없습니다.

라우팅 효과: 도메인 규칙이 충분히 구성되어 있고 앱이 먼저 조회한 뒤 연결하는 경우 매핑을 활용하면 도메인 기반 분할 라우팅을 일관되게 유지하는 데 도움이 됩니다. 잘못된 규칙 순서를 수정하거나 실제 DNS의 모든 용도를 대신할 수는 없습니다. 앱이 고정 주소에 직접 접속하거나 자체 암호화 DNS 경로를 사용하면 이 매핑 절차를 거치지 않을 수도 있습니다.

설정 구성: 주소 풀, DNS 진입점, 스니핑

구조 예시: 아래 설정은 Xray의 주소 풀과 DNS 서비스를 연결하는 방법을 보여줍니다. 198.18.0.0/15는 벤치마크용 주소 대역이며 원격 서비스의 실제 주소가 아닙니다. 설정 전에 기존 네트워크, 다른 가상 네트워크 어댑터, 테스트 환경과 주소가 겹치는지 확인하세요. 겹친다면 바로 활성화하지 말고 먼저 주소 계획을 조정해야 합니다.

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

인바운드 연동: 연결을 받는 인바운드도 매핑 정보를 복원할 수 있어야 합니다. 아래 예시는 해당 인바운드 객체에 병합할 스니핑 필드만 보여주며 인바운드 프로토콜, 수신 주소, 포트는 정의하지 않습니다. GUI 클라이언트가 이미 같은 설정을 만들었을 수 있으니 실제 설정을 먼저 확인해 중복 추가를 피하세요. 서로 다른 트래픽 처리 구성 요소가 관리하는 매핑은 필드를 복사하는 것만으로 공유되지 않습니다.

{
  "sniffing": {
    "enabled": true,
    "destOverride": ["fakedns", "http", "tls"]
  }
}

코어별 차이: 위 설정은 Xray의 관련 설정 관계를 설명하기 위한 것입니다. 확인 없이 v2flyNG나 다른 TUN 구성 요소로 옮겨 사용하지 마세요. 클라이언트에서 FakeDNS 옵션을 제공한다면 해당 메뉴를 우선 사용하고 어떤 코어가 실행 중인지 확인하세요. 지원 여부가 분명하지 않다면 구현 방식이 다른 설정 필드를 억지로 조합하기보다 일반 DNS 경로를 유지하는 편이 관리하기 쉽습니다.

호환성 및 일반 DNS로 되돌리기

앱 호환성: 실제 조회 주소를 표시하거나 주소 소유권을 확인하고, LAN 기기를 검색하거나 조회 결과를 다른 프로세스에 넘기는 앱은 매핑을 전역 적용하기에 적합하지 않을 수 있습니다. 일부 앱은 가상 주소를 캐시해 클라이언트가 종료된 뒤에도 해당 주소로 연결을 시도합니다. 특정 앱에서만 문제가 생기면 해당 앱의 DNS 조회와 연결이 같은 처리 경로를 거치는지 확인한 뒤 제외 범위를 정하세요.

캐시 유지 시간: 매핑 정보와 앱 캐시의 수명이 달라 재시작 후 간헐적으로 실패할 수 있습니다. 코어를 재시작하면 이전 매핑 정보가 사라져도 앱에는 예전 주소가 남아 있을 수 있습니다. 이런 경우 노드만 바꾸어도 해결되지 않을 수 있으므로 기존 연결을 닫고 관련 앱의 DNS 캐시를 지운 뒤 새로 조회해 매핑을 다시 생성하세요.

검증 방법: 활성화한 뒤 시스템이나 앱이 대상 도메인을 조회하면 매핑 풀의 주소가 반환되어야 합니다. 동시에 클라이언트가 연결을 원래 도메인과 연결해 예상한 아웃바운드를 선택하는지 확인하세요. 예약 주소가 보이는 것만으로는 설정이 완전하다고 볼 수 없습니다. 서비스 연결, LAN 접속, 매핑을 사용하지 않는 실제 주소 트래픽이 기존 규칙대로 처리되는지도 확인하세요.

비활성화 순서: 관련 FakeDNS 설정을 끄고 일반 DNS 서버로 되돌린 다음 시스템과 앱의 캐시를 지우고 이전 매핑을 사용하는 연결을 닫으세요. 가상 네트워크 어댑터만 끄고 앱 캐시에 매핑 주소를 남겨 두면 접속 문제가 계속될 수 있습니다. 복구한 뒤 DNS 반환값을 다시 확인해 주소 풀의 결과가 실제 원격 주소처럼 사용되지 않는지 점검하세요.

도입 판단: 일반 DNS와 TUN이 안정적으로 작동하는데도 도메인 정보가 실제로 손실되는 경우에만 이 계층을 추가하세요. 구독 만료, 서버 시간 초과, 인증 실패가 주요 문제라면 FakeDNS로 해결할 수 없습니다. 매핑 방식과 사용 사례는 FakeDNS 원리와 v2rayN에서 사용할 시점에서 더 자세히 확인하고, 비활성화 상태의 설정도 비교용으로 보관하세요.

다중 구독 관리

관리 방식: 출처 분리 및 일관된 이름 지정

출처 분리: 여러 구독은 각각의 업데이트 범위를 명확히 유지해야 합니다. 출처별로 그룹을 나누고 수동 관리 설정은 별도 그룹에 보관하세요. 목록을 보기 좋게 만들겠다고 모든 서버를 출처를 추적할 수 없는 하나의 큰 그룹에 복사하지 마세요. 서버가 만료되거나 형식이 바뀌거나 업데이트로 설정이 덮어써질 때 출처를 알면 문제 범위를 좁히고 영향을 받은 항목만 비활성화하기 쉽습니다.

이름 지정 규칙: 그룹 이름이나 메모에 출처 약칭, 용도, 관리 방식을 기록하세요. 계정 정보나 전체 구독 주소는 포함하지 마세요. 노드 메모는 제공자가 설정한 내용을 유지하고 필요한 경우 로컬 식별 표식을 따로 추가할 수 있습니다. 수동으로 바꾼 이름이 업데이트 후에도 유지되는지는 클라이언트 구현에 따라 다릅니다. 메모를 기준으로 필터링한다면 정기적으로 확인하고 영구 식별자로 간주하지 마세요.

선택 범위: 구독을 추가해도 로드 밸런싱, 장애 조치, 앱별 분할 라우팅이 자동으로 구성되지는 않습니다. 일반 서버 목록에서는 보통 활성화된 서버 하나만 선택되며 여러 출처는 설정 후보를 늘릴 뿐입니다. 트래픽마다 다른 아웃바운드를 사용하려면 라우팅과 출구를 명시적으로 설정하세요. 그룹 순서나 목록 정렬을 코어의 출구 우선순위로 오해하지 마세요.

업데이트 주기: 연쇄 장애 줄이기

수동 검증: 새 출처를 추가할 때는 먼저 별도로 가져와 업데이트하고 프로토콜 유형과 코어 지원 여부를 확인한 다음 실제 연결을 테스트하세요. 정상 작동이 확인된 뒤 정기 업데이트에 포함하세요. 기존 출처를 모두 동시에 업데이트하면 현재 연결이 끊겼을 때 새 내용이 원인인지 기존 출처가 바뀐 것인지 구분하기 어려워져 문제 해결에 더 많은 시간이 듭니다.

자동 업데이트 간격: 업데이트 빈도는 출처의 설정 변경 주기와 서비스 요구에 맞춰야 합니다. 자주 업데이트한다고 더 안정적인 것은 아닙니다. 요청이 지나치게 많으면 불필요한 업데이트가 늘거나 제공자의 제한을 받을 수 있습니다. 그룹별 업데이트를 지원한다면 필요에 따라 주기를 나누세요. 통합 간격만 설정할 수 있다면 안정적으로 관리할 수 있는 주기를 선택하고 일시적인 변경에 대비해 수동 업데이트 메뉴를 남겨 두세요.

프록시 의존성: 프록시를 통한 업데이트는 일부 출처에 직접 연결할 수 없는 문제를 해결할 수 있지만, 모든 출처가 검증되지 않은 단일 출구에 의존하게 만들지는 마세요. 현재 노드에 문제가 생기면 프록시 업데이트도 함께 실패해 모든 구독이 만료된 것처럼 보일 수 있습니다. 업데이트 요청의 네트워크 경로를 먼저 확인하고 링크 상태를 점검하세요. 필요하다면 이미 작동이 확인된 설정으로 전환한 다음 해당 구독만 다시 업데이트하세요.

중복 제거, 이전, 백업 범위

중복 제거 원칙: 이름이 같아도 설정이 동일하다는 뜻은 아니며, 주소가 같아도 인증 및 전송 매개변수가 같다고 볼 수 없습니다. 중복 항목을 삭제하기 전에 프로토콜, 포트, 사용자 식별 정보, 전송 방식, 보안 필드를 비교하세요. 일부 필드만으로 자동 중복 제거를 하면 서로 다른 접속 방식에 필요한 설정을 잘못 삭제할 수 있습니다. 판정 기준을 모른다면 사본에서 먼저 테스트한 뒤 주요 그룹을 정리하세요.

기기 간 이전: v2rayN, v2rayNG, v2flyNG는 구독 파싱, GUI 저장 방식, 사용자 지정 설정 지원 범위가 서로 다를 수 있습니다. 이전할 때는 구독 파싱, 노드 실행, 라우팅 및 DNS 설정 복원을 각각 확인하세요. 서버 목록을 가져오는 데 성공했어도 데스크톱의 TUN, 시스템 프록시, 모든 사용자 지정 규칙까지 모바일 기기에 동기화된 것은 아닙니다.

백업 내용: 그룹 구조, 필요한 구독 정보, 로컬 별도 설정, 규칙을 저장해 접근을 관리할 수 있는 위치에 보관하세요. 임시로 생성된 코어 파일만 백업하면 GUI에 저장된 출처 정보와 업데이트 설정이 빠질 수 있습니다. 복원 전에 백업 파일이 어느 클라이언트와 설정 메뉴에 해당하는지 확인해 구조가 다른 새 환경의 필드를 덮어쓰지 않도록 하세요.

변경 기록: 큰 변경을 할 때마다 구독 그룹을 프록시로 업데이트하도록 변경, 필터 조건 완화, 규칙 순서 조정처럼 동작에 영향을 주는 항목만 기록하세요. 민감한 주소를 저장하거나 인증 정보가 포함된 설정을 공개 메모에 붙여 넣지 마세요. 문제가 발생했을 때 마지막으로 어느 계층을 바꿨는지 알 수 있으면 설명 없이 저장한 설정 사본을 많이 보관하는 것보다 문제 해결에 도움이 됩니다.

사용 중단: 출처를 더 이상 사용하지 않을 때는 현재 서버, 자동 업데이트 작업, 사용자 지정 출구가 해당 출처를 참조하지 않는지 먼저 확인한 다음 그룹을 비활성화하세요. 다른 출처가 정상 작동하는지 확인한 뒤 삭제해야 참조할 수 없는 태그가 남지 않습니다. 일시적인 네트워크 문제라면 업데이트를 잠시 중지하고 기존 설정을 보관하세요. 구독 만료와 파싱 문제는 자주 묻는 질문과 구독 그룹 섹션을 함께 확인하세요.

사용자 지정 아웃바운드

코어와 생태계: 먼저 설정의 소속 확인

코어 관계: Project V는 이러한 프록시 도구 생태계를 이해하는 배경이며 V2Fly와 Xray는 구분해야 할 코어 계열입니다. GUI 클라이언트는 구독, 화면, 설정 생성을 담당하고 코어는 실제 연결을 처리합니다. 인터페이스가 비슷한 두 클라이언트라도 같은 설정을 사용할 수 있다고 보장할 수 없습니다. 한 클라이언트에서 실행 코어를 바꾸는 경우에도 프로토콜과 필드 지원 여부를 다시 확인하세요.

Xray 설정: v2rayNG는 Xray 코어를 사용하고 v2flyNG는 V2Fly 코어를 사용하는 대안입니다. v2rayN의 실제 동작은 현재 실행 중인 구성 요소를 기준으로 확인하세요. 사용자 지정 아웃바운드를 추가하기 전에 로그의 시작 정보와 클라이언트 설정에서 어떤 설정 체계가 실행 중인지 확인하세요. 오픈 소스라는 점은 코드를 연구하고 유지 관리할 수 있다는 의미이지, 구현 차이를 무시하고 설정을 임의로 서로 바꿔 쓸 수 있다는 뜻은 아닙니다.

REALITY의 적용 범위: 연결 보안 관련 매개변수이므로 서버에서 제공한 설정과 일치해야 하며 로컬 분할 라우팅 스위치가 아닙니다. 아웃바운드 태그 변경, 직접 연결 규칙 조정, 로컬 SOCKS 아웃바운드 추가로 잘못된 서버 이름이나 공개 키 같은 연결 매개변수를 보완할 수는 없습니다. 이러한 노드를 사용할 때는 원본 설정을 보관하고 기본 연결을 확인한 뒤 사용자 지정 연결 경로를 추가하세요.

아웃바운드 정의: 직접 연결 및 차단의 최소 구성

정의 방식: 아웃바운드 객체의 tag는 라우팅에서 참조할 식별자를 지정하고 protocol은 동작을 지정합니다. 아래는 Xray의 직접 연결 및 차단 아웃바운드 목록 일부입니다. 태그는 예시이므로 앞의 라우팅 설정과 맞춰야 합니다. 기존 설정에 병합할 때 원래 프록시 아웃바운드를 덮어쓰지 마세요. 기본 동작을 확인하지 않은 상태에서 목록 순서를 바꾸는 것도 피해야 합니다.

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

기본 동작: 이 예시에는 원격 프록시 출구와 전체 라우팅 설정이 없습니다. 이를 완전한 아웃바운드 목록으로 사용하면 일치하지 않는 요청이 첫 번째 직접 연결 아웃바운드로 전달될 수 있습니다. 차단 아웃바운드도 규칙에서 선택된 경우에만 작동합니다. 객체를 추가한 뒤 생성된 설정과 기본 출구를 확인하고 범위가 작은 규칙 하나로 태그 참조를 먼저 테스트하세요.

로컬 업스트림: 연결이 자기 자신에게 되돌아가지 않도록 설정

연결 체인: 특정 요청을 로컬에서 실행 중인 다른 관리 대상 SOCKS 서비스로 전달해야 할 수 있습니다. 아래 예시는 local-upstream이라는 아웃바운드를 정의하고 루프백 주소의 지정 포트에 연결합니다. 해당 포트에서 호환되는 서비스가 수신 중이며 현재 클라이언트가 같은 트래픽을 받는 인바운드가 아니어야 합니다. 업스트림 서비스가 없다면 이 설정만으로는 사용할 수 있는 출구가 만들어지지 않습니다.

{
  "tag": "local-upstream",
  "protocol": "socks",
  "settings": {
    "servers": [
      {
        "address": "127.0.0.1",
        "port": 10810
      }
    ]
  }
}

순환 여부 확인: 로컬 인바운드가 같은 주소와 포트를 수신하고 있으면 전달된 연결이 다시 자신에게 들어와 재귀하거나 즉시 실패할 수 있습니다. TUN 모드에서는 업스트림 프로세스의 외부 연결이 다시 가로채져 또 다른 루프를 만들지 않는지도 확인해야 합니다. 먼저 업스트림을 독립적으로 검증하고 테스트 규칙 하나를 연결한 뒤 사용 범위를 넓히세요. 처음부터 모든 트래픽을 처리하지 마세요.

기능 확인: SOCKS 업스트림의 인증, 도메인 전달, UDP 지원 여부를 각각 확인해야 합니다. 웹페이지 접속에 성공했다고 모든 유형의 데이터를 전달할 수 있는 것은 아닙니다. 일부 앱만 실패한다면 요청 유형과 업스트림 기능을 확인하세요. 관찰하기 어려운 중첩 단계를 늘리기 위해 프록시 필드를 더 복사하지 마세요.

적용 여부 확인: 편집 메뉴, 문법, 설정 유지

편집 메뉴: 전체 사용자 지정 설정 모드와 GUI 생성 설정 모드는 관리 책임이 서로 다릅니다. 전자는 인바운드, 라우팅, DNS, 아웃바운드를 직접 정의해야 할 수 있고, 후자는 클라이언트가 일부 제어권을 유지합니다. 저장하기 전에 어떤 필드가 덮어써지는지, 노드를 바꾼 뒤 사용자 지정 내용이 유지되는지 확인하세요. 임시 파일에 필드가 한 번 표시됐다는 이유만으로 설정이 지속 적용된다고 볼 수는 없습니다.

오류 구분: 시작하자마자 실패한다면 JSON 쉼표와 괄호, 필드 유형, 프로토콜 이름을 먼저 확인하세요. 시작은 됐지만 규칙에 매칭되지 않으면 라우팅 태그를 점검하고, 매칭된 뒤 연결이 실패한다면 수신 설정, 인증, 네트워크 연결 상태를 확인하세요. 문제를 진단하는 동안에만 로그 수준을 높이고 진단이 끝나면 평소 수준으로 되돌리세요. 대상 주소와 인증 정보가 포함된 전체 로그를 공개하지 마세요.

변경 마무리: 아웃바운드 계층을 추가할 때마다 입력이 어디서 오는지, 출력이 어디로 전달되는지, 실패하면 어떻게 되돌릴지 기록하세요. 이 세 가지를 설명할 수 없다면 클라이언트 기본 설정을 유지하는 편이 낫습니다. 설치 파일과 구성 요소 선택은 설치 파일 페이지에서 확인하고 기본 연결 검증은 설정 가이드를 참고하세요. 연결이 안정된 뒤 이 가이드를 따라 라우팅, DNS, 트래픽 처리 설정을 단계별로 추가해 서로 다른 문제를 재현하기 어렵게 만들지 마세요.