V2Ray 고급 설정 가이드

구독 그룹 및 서버 필터링

구독 주소, 구독 그룹, 서버 항목은 서로 다른 개념입니다. 구독 주소는 설정을 가져오는 경로이고, 구독 그룹은 클라이언트가 주소와 업데이트 정책을 저장하는 단위이며, 서버 항목은 업데이트 후 가져온 연결 정보입니다. 서버 하나를 삭제해도 구독 자체가 삭제되는 것은 아니므로 다음 업데이트 때 다시 추가될 수 있습니다. 설정 묶음을 더 이상 사용하지 않으려면 먼저 해당 그룹의 자동 업데이트를 중지한 뒤 그룹과 항목을 삭제할지 결정하세요.

관리하기 쉬운 그룹 만들기

v2rayN에서 구독 그룹 관련 설정을 열고 새 그룹을 만든 다음, 알아보기 쉬운 메모와 전체 구독 주소를 입력해 저장하세요. 메모에는 ‘업무용 기기’, ‘임시 테스트’처럼 출처와 용도를 적고 접근 토큰은 넣지 않는 것이 좋습니다. 구독 주소에 접근 토큰이 포함될 수 있으므로 복사할 때는 쿼리 부분까지 모두 포함하되, 전체 주소가 보이는 화면을 캡처하거나 공개 로그에 붙여 넣지 마세요. 입력란 앞뒤에 공백이 있으면 먼저 제거해 입력 오류를 네트워크 문제로 오인하지 않도록 합니다.

저장한 뒤에는 해당 그룹만 업데이트하세요. 완료 여부는 알림이 사라졌는지가 아니라 로그의 요청 완료 여부, 항목 수의 합리적인 변화, 목록에 해당 그룹의 서버가 표시되는지로 판단해야 합니다. 사용 가능한 서버 하나를 선택해 활성 서버로 지정하고 빠른 시작 안내에 따라 연결을 확인하세요. 처음 그룹을 만들 때 여러 출처를 한꺼번에 업데이트하면 다른 그룹의 성공 결과가 실패를 가릴 수 있으므로 전체 업데이트는 피하는 편이 좋습니다.

자동 업데이트 간격은 구독 출처가 변경되는 주기에 맞추세요. 간격이 너무 짧으면 불필요한 요청이 반복되고 출처 측의 접근 제한을 받을 수 있습니다. 컴퓨터 절전, 네트워크 전환, 앱 미실행은 예약 작업에 영향을 주므로 업데이트 간격을 서버 푸시로 이해해서는 안 됩니다. 업데이트 전에 구독 주소에 직접 연결할 수 있는지도 확인하세요. 현재 프록시를 통해서만 가져올 수 있다면 클라이언트의 프록시 업데이트 기능을 사용하고, 작동 중인 활성 서버 설정 하나를 남겨 두어 업데이트 경로와 연결이 동시에 끊기지 않도록 합니다.

필터링과 설정 삭제의 차이

서버 필터는 일반적으로 목록에 표시되는 항목만 바꾸며 서버 설정 자체는 수정하지 않습니다. 먼저 그룹을 선택한 뒤 이름 키워드를 입력하면 잘못 조작할 가능성을 줄일 수 있습니다. 이름 필터, 프로토콜 필터, 특정 그룹만 표시하는 옵션이 켜져 있는지 확인한 다음 항목이 실제로 삭제됐는지 판단하세요. 일부 화면은 정규식을 지원하지만 일반 문자열만 검색하는 화면도 있으므로 입력란의 안내를 확인해야 합니다. 일반 키워드와 정규식은 서로 바꿔 쓸 수 없습니다.

필터가 정규식을 지원한다고 명시되어 있다면 업무|예비로 두 키워드 중 하나를 찾거나 ^테스트로 이름이 ‘테스트’로 시작하는 항목을 찾을 수 있습니다. 입력 후에는 결과를 먼저 확인하고 바로 일괄 삭제하지 마세요. 괄호, 더하기 기호, 대괄호는 정규식에서 특별한 의미가 있습니다. 출처 이름에 이런 문자가 포함되면 해당 화면의 정규식 규칙에 따라 이스케이프해야 합니다. 검색 방식이 확실하지 않다면 복잡한 표현식을 조합하기보다 일반 키워드 하나로 확인하는 편이 안전합니다.

업데이트 실패 시 상태 확인

목록이 비어 있다면 먼저 필터를 지우고 해당 그룹으로 전환한 뒤 업데이트 로그를 확인하세요. 연결 시간 초과는 네트워크 경로를, 파싱 오류는 응답 내용을 중점적으로 살펴봐야 합니다. 구독 API가 로그인 페이지, 만료 안내 또는 일반 웹 페이지를 반환하면 네트워크 요청 자체는 성공했더라도 클라이언트가 서버 설정으로 인식하지 못할 수 있습니다. 이때 프로토콜을 계속 바꾸는 것은 도움이 되지 않습니다. 주소가 만료됐는지, 구독 주소를 다시 발급받아야 하는지 확인하세요.

구독으로 가져온 항목을 직접 수정하기 전에 별도의 로컬 그룹에 복사하세요. 출처를 업데이트하면 항목이 다시 생성되어 로컬 변경 사항이 덮어써질 수 있습니다. 원본 그룹은 동기화용, 복사한 그룹은 실험용으로 역할을 나누면 문제 해결 시 원본 설정으로 돌아가기 쉽습니다. Android용 v2rayNG와 v2flyNG는 메뉴 위치가 다를 수 있지만 구독 업데이트와 현재 서버 선택은 구분해야 합니다. 흔한 연결 문제는 도움말 센터에서 확인할 수 있습니다. 구독을 가져오기도 전에 DNS와 라우팅을 동시에 변경하지 마세요.

라우팅 규칙 적용과 매칭 순서

라우팅은 코어에 들어온 요청을 아웃바운드로 전달하는 역할을 하며, 앱의 연결을 대신 만들어 주지는 않습니다. 먼저 요청이 로컬 프록시에 실제로 도달하는지 확인한 뒤 트래픽 분기 결과를 살펴보세요. 프로그램이 시스템 프록시를 사용하지 않는다면 라우팅 규칙을 아무리 완벽하게 작성해도 연결 경로는 바뀌지 않습니다. 앱 진입 경로, 요청에 포함된 정보, 규칙 매칭, 아웃바운드 연결 순서로 확인하세요. 이 네 단계를 한꺼번에 살펴보면 진입 경로 문제를 규칙 오류로 착각하기 쉽습니다.

규칙이 적용되는 설정 계층부터 확인

v2rayN의 라우팅 편집 화면에서는 domain:example.com, geosite:private처럼 축약된 형식을 쓰거나 도메인과 IP를 별도 입력란에 나눠 넣을 수 있습니다. 이는 클라이언트에서 입력하는 방식일 뿐 코어 JSON의 모든 필드와 같지는 않습니다. 코어 설정에서는 도메인을 domain 배열에, 네트워크 대역을 ip 배열에 넣어야 합니다. 화면의 한 줄 전체를 임의의 필드에 붙여 넣지 마세요. 특히 ip:192.168.0.0/16 같은 화면용 축약 표기는 코어의 IP 배열 요소로 그대로 사용할 수 없습니다.

다음은 V2Fly 또는 호환되는 Xray 설정에 병합할 수 있는 라우팅 예제입니다. direct와 proxy라는 아웃바운드가 이미 있다고 가정합니다. 첫 번째 규칙은 로컬 주소를 직접 연결하고, 두 번째 규칙은 예시 도메인을 프록시로 보내며, 마지막 규칙은 나머지 TCP 및 UDP 요청을 처리합니다. 이 예제는 매칭 관계만 보여 주며 원격 서버 설정은 포함하지 않습니다. 단독으로 완전한 연결 설정이 되지도 않습니다.

{
  "routing": {
    "domainStrategy": "AsIs",
    "rules": [
      {
        "type": "field",
        "ip": ["127.0.0.0/8", "10.0.0.0/8", "172.16.0.0/12", "192.168.0.0/16", "::1/128", "fc00::/7"],
        "outboundTag": "direct"
      },
      {
        "type": "field",
        "domain": ["domain:example.com"],
        "outboundTag": "proxy"
      },
      {
        "type": "field",
        "network": "tcp,udp",
        "outboundTag": "proxy"
      }
    ]
  }
}

예외 규칙은 기본 규칙보다 앞에 배치

규칙은 일반적으로 순서대로 검사하며 조건에 처음 일치하는 규칙이 아웃바운드를 결정합니다. 모든 연결을 처리하는 기본 규칙은 반드시 뒤에 두어야 합니다. 그렇지 않으면 뒤에 있는 예외 규칙이 적용되지 않습니다. 단일 규칙에 도메인, 포트, 네트워크 유형을 함께 입력하면 보통 모든 조건을 충족해야 합니다. 같은 배열에 있는 도메인 여러 개는 선택 가능한 대상을 나타냅니다. 서로 관련 없는 요구를 한 규칙에 묶지 말고 나누어 작성하면 확인하기 쉽습니다.

domain:example.com은 해당 도메인과 하위 도메인을 매칭하고, full:example.com은 도메인 전체가 정확히 일치하는 경우에 매칭합니다. 정규식은 이름에 명확한 패턴이 있을 때 유용하지만 기본 선택으로 쓰기에는 적합하지 않습니다. 도메인 규칙은 사용자가 직접 입력한 IP 주소와 자동으로 일치하지 않습니다. 대상 네트워크 대역에도 같은 경로를 적용하려면 IP 조건을 별도로 추가하고, 라우팅 단계에서 주소를 조회할 수 있도록 도메인 해석 정책도 확인하세요.

AsIs는 IP 규칙에 맞추기 위해 도메인을 능동적으로 조회하지 않습니다. IPIfNonMatch는 도메인 단계에서 일치하지 않을 때 조회를 시도해 IP 규칙을 추가로 확인합니다. IPOnDemand는 IP 조건이 필요하면 더 이른 시점에 조회할 수 있습니다. 이 옵션은 조회 횟수와 규칙 매칭에 영향을 주며 단순한 속도 설정이 아닙니다. 선택하기 전에 대상 IP 기반 분기가 실제로 필요한지, DNS 조회가 올바른 아웃바운드를 통해 가능한지 확인하세요.

요청 하나로 규칙 매칭 확인

검증할 때는 도메인이 확실한 대상을 하나 선택하고 기존 페이지를 닫거나 대상 앱을 다시 시작한 뒤 새 연결을 만드세요. 이미 연결된 세션은 규칙을 저장해도 자동으로 경로가 바뀌지 않습니다. 잠시 로그 상세 수준을 높여 요청 대상, 인바운드 태그, 아웃바운드 태그가 예상과 일치하는지 확인하고, 완료되면 평소 쓰던 로그 수준으로 되돌리세요. 로그에 IP만 보이고 도메인이 보이지 않는다면 앱이 호스트명을 전달하는지, 트래픽 스니핑이 해당 프로토콜에 적용되는지 확인하세요.

규칙에서 참조하는 지리 정보는 현재 클라이언트와 코어가 제공해야 합니다. 데이터 파일이나 분류 이름을 찾을 수 없다는 오류가 발생하면 순서를 바꿔 로딩 실패를 감추려 하지 말고 데이터 출처부터 복구하세요. GUI 라우팅 설정은 코어 재시작 때 설정을 다시 생성할 수 있으므로 임시 생성 파일을 계속 수정하지 말고 클라이언트에 규칙을 저장해야 합니다. 필드 간 관계는 JSON 설정 파일 구조 자세히 알아보기를 참고해 형식 오류와 매칭 로직 오류를 나눠 확인하세요.

DNS 설정 최적화와 조회 경로

DNS 문제를 확인할 때는 세 경로를 구분하세요. 앱 또는 운영체제의 리졸버, 프록시 코어의 리졸버, 프록시를 통해 접속하는 원격 서비스입니다. 브라우저에서 보안 DNS를 사용하면 시스템 리졸버를 우회할 수 있고, 앱이 도메인을 SOCKS 인바운드에 전달하면 프록시 측에서 후속 처리를 할 수 있습니다. 클라이언트에서 DNS 주소 하나를 바꿔도 기기의 모든 프로그램이 해당 주소를 사용하게 되는 것은 아닙니다. 요청이 어느 계층에서 IP 주소로 바뀌는지 먼저 파악한 뒤 설정을 변경하세요.

서버 도메인과 대상 도메인을 따로 다루기

프록시 서버 주소가 도메인이라면 프록시 연결을 맺기 전에 해당 주소를 조회해야 합니다. 아직 연결되지 않은 프록시 경로를 통해 조회하도록 설정하면 순환 의존이 생길 수 있습니다. 대상 웹사이트 도메인은 트래픽 분기 방식에 따라 직접 조회하거나 프록시를 통해 조회할 수 있습니다. 두 도메인은 역할이 다르므로 모호한 ‘모든 원격 DNS’ 설정 하나로 처리하지 않는 것이 좋습니다. 시작 후 연결이 전혀 되지 않는다면 서버 도메인을 별도 경로로 조회할 수 있는지 먼저 확인하세요.

v2rayN의 DNS 설정에서 어떤 코어 설정을 편집 중인지 먼저 확인하세요. 코어 백엔드마다 필드와 기본 동작, 지원하는 전송 방식이 다를 수 있으므로 한 백엔드의 JSON을 다른 백엔드에 붙여 넣으면 안 됩니다. 다음은 V2Fly 형식의 내장 DNS 설정을 보여 주는 예제입니다. 예시 도메인에 고정 주소를 지정하고 지정된 리졸버에 IPv4 주소를 요청합니다. 이 설정은 내장 리졸버를 사용하는 요청에만 영향을 주며 시스템 DNS를 자동으로 가로채지는 않습니다.

{
  "dns": {
    "hosts": {
      "example.com": "192.0.2.10"
    },
    "servers": ["1.1.1.1"],
    "queryStrategy": "UseIPv4"
  }
}

예제의 고정 주소는 문서 설명용이며 실제 웹사이트 연결을 시험하는 대상으로 사용할 수 없습니다. 실제 설정에서는 예제 매핑을 삭제하거나 직접 관리하는 도메인과 올바른 주소로 바꾸세요. 고정 매핑은 명확하고 안정적인 내부 서비스에 적합하지만, 콘텐츠 전송 서비스의 주소를 장기간 고정하는 용도로는 적절하지 않습니다. 이런 서비스는 지역, 네트워크, 시간에 따라 다른 주소를 반환할 수 있어 주소를 고정하면 오히려 연결 오류가 생길 수 있습니다.

최적화 전에 기준값 마련

한 번에 한 가지 변경 사항만 비교하세요. 같은 활성 서버, 라우팅 설정, 테스트 도메인을 유지하고 DNS 조회 경로만 바꾼 뒤 새 연결을 만듭니다. 서버와 DNS를 동시에 바꾸면 결과가 나아져도 원인을 알 수 없습니다. 시스템 조회 도구로 확인할 수 있는 것은 해당 도구가 사용한 조회 경로뿐이며 코어 DNS가 정상이라는 뜻은 아닙니다. 코어 로그와 실제 앱 요청을 함께 확인해 조회 대상, 응답 유형, 이후 연결에 사용된 주소를 살펴보세요.

IPv4와 IPv6 설정은 실제 출구 경로의 지원 여부에 맞춰야 합니다. IPv6 주소를 조회했지만 출구에서 사용할 수 있는 IPv6 경로가 없으면 앱이 실패를 기다렸다가 IPv4로 전환해 DNS가 느린 것처럼 보일 수 있습니다. 문제를 진단할 때 IPv4만 임시로 사용해 볼 수는 있지만 모든 네트워크에 적용할 고정 해법은 아닙니다. IPv6가 필요하다면 로컬 네트워크, 프록시 서버, 코어 아웃바운드, 라우팅 대역을 함께 확인하세요. AAAA 응답만 유지하고 이후 연결 가능성을 무시해서는 안 됩니다.

암호화된 조회와 캐시 범위 이해

암호화 DNS를 사용할 때는 리졸버에 연결하는 경로, 인증서 이름, 초기 도메인 조회도 고려해야 합니다. 리졸버를 도메인 이름으로 지정하면 해당 이름도 처음에는 조회해야 합니다. 일부 특수 형식은 일반 아웃바운드 라우팅을 따르지 않고 로컬에서 바로 조회를 시작할 수 있습니다. 실제 동작은 현재 코어가 지원하는 DNS 유형을 기준으로 확인하세요. 주소가 암호화 프로토콜로 시작한다는 이유만으로 조회가 활성 프록시를 통과한다고 단정하지 마세요.

설정을 저장한 뒤에도 클라이언트, 운영체제, 브라우저 캐시와 앱의 장기 연결에 이전 상태가 남을 수 있습니다. 먼저 테스트 연결을 새로 만들고 필요한 계층의 캐시만 정리하세요. 매번 네트워크 전체를 초기화할 필요는 없습니다. 코어 로그에 올바른 주소가 나오는데 앱이 여전히 이전 대상에 접속한다면 앱 캐시를 확인하세요. TUN에서는 DNS 가로채기가 대상 요청까지 실제로 적용되는지도 점검해야 합니다. 가로채지 않은 조회는 내장 DNS 필드를 바꿔도 경로가 자동으로 바뀌지 않습니다.

TUN 모드와 가상 네트워크 어댑터 트래픽 가로채기

시스템 프록시는 앱에 로컬 프록시 주소를 알려 주는 방식이며, 이를 사용할지는 앱 구현에 달려 있습니다. TUN은 가상 네트워크 어댑터와 시스템 라우팅을 이용해 조건에 맞는 IP 트래픽을 처리 경로로 보냅니다. 두 방식은 진입 경로가 다르므로 같은 기능의 단순한 강도 차이로 볼 수 없습니다. 시스템 프록시가 정상 작동하는데도 일부 프로그램이 프록시 설정을 읽지 않는 경우에만 TUN 사용을 검토하세요. 기본 설정 문제를 더 복잡한 트래픽 가로채기 환경으로 가져가지 않는 것이 좋습니다.

사용 전 권한과 기존 라우팅 확인

먼저 현재 라우팅 설정, 활성 서버, DNS 설정을 기록하고 TUN을 꺼도 일반 연결을 복구할 수 있는지 확인하세요. 다른 VPN, 가상 네트워크 어댑터 도구, 트래픽 가로채기 프로그램이 실행 중인지도 살펴봐야 합니다. 여러 도구가 기본 경로를 동시에 차지하려 하면 모두 활성화된 것처럼 보여도 실제 트래픽은 다른 경로로 들어갈 수 있습니다. 테스트할 때는 가로채기 방식을 하나만 사용하고 각 기능의 범위를 확인한 뒤 함께 쓸지 결정하세요.

Windows에서 가상 네트워크 어댑터를 만들고 라우팅을 변경하려면 보통 관리자 권한이 필요합니다. macOS와 Linux에서는 시스템 승인이나 관련 서비스 구성 요소가 필요할 수 있습니다. 현재 v2rayN 화면의 권한 안내를 따르고, 일반 권한으로 반복 실행한 뒤 스위치 색상만 확인하지 마세요. 권한 부족, 구성 요소 누락, 설정 문법 오류는 서로 다른 문제이므로 시작 로그에서 각각 확인해야 합니다. 설치 파일은 클라이언트 다운로드 페이지에서 운영체제와 프로세서 아키텍처에 맞춰 선택하세요.

v2rayN의 TUN 기능은 V2Fly나 Xray JSON에 공통 필드를 추가하는 방식이 아니라 별도 트래픽 가로채기 백엔드에서 처리할 수 있습니다. 따라서 인터넷에서 찾은 임의의 TUN 설정을 모든 코어에 공통으로 적용되는 문법으로 간주해서는 안 됩니다. 먼저 클라이언트가 제공하는 스위치와 설정 항목을 사용해 백엔드 설정을 생성하세요. 고급 매개변수를 수정하려면 백엔드 종류와 설정 위치부터 확인해야 합니다.

단계별로 활성화하고 연결 상태 확인

활성화한 뒤 가상 네트워크 어댑터가 생성됐는지, 라우팅 항목이 추가됐는지, DNS가 예상대로 가로채지는지, 대상 앱에 새 연결 로그가 생기는지 순서대로 확인하세요. 스위치가 켜졌다는 것은 활성화 요청을 보냈다는 뜻일 뿐 각 단계가 완료됐다는 뜻은 아닙니다. 일반 웹페이지 하나를 먼저 시험한 뒤 시스템 프록시를 사용하지 않던 앱을 확인하세요. 웹페이지도 열리지 않으면 TUN을 끄고 기본 연결부터 복구하세요. MTU, 라우팅 테이블, 서버 설정을 동시에 바꾸지 마세요.

프록시 서버로 향하는 연결은 올바른 출구를 사용해야 하며 같은 프록시 경로로 다시 가로채지 않도록 해야 합니다. 클라이언트가 보통 제외 또는 보호 규칙을 생성하지만 여러 네트워크 어댑터, 모바일 핫스팟, 네트워크 전환은 출구 선택에 영향을 줄 수 있습니다. 로그에 연결 반복, 비정상적인 연결 수 증가, 서버 주소의 반복적인 가로채기가 나타나면 TUN을 먼저 끄고 서버 주소의 제외 방식과 기본 출구 어댑터를 확인하세요. 재시도 횟수부터 늘리지 마세요.

LAN 제외 규칙은 흔히 쓰이는 사설 네트워크 대역을 그대로 복사하지 말고 실제 네트워크에 맞춰야 합니다. 회사 네트워크, 가상 머신, 컨테이너 네트워크는 다른 주소 대역을 사용하거나 특정 인터페이스에 의존할 수 있습니다. 사무실 네트워크에 연결한 뒤에만 실패한다면 연결 전후의 라우팅 변화를 비교하세요. LAN 기기가 이 컴퓨터의 프록시에 연결하도록 허용하는 기능은 수신 주소와 방화벽 설정이 필요한 별도 기능입니다. TUN 스위치로 대체할 수 없습니다. 자세한 내용은 LAN 프록시 공유 설정을 참고하세요.

전송 지원과 네트워크 어댑터 가로채기 구분

TUN이 특정 종류의 패킷을 받을 수 있어도 원격 아웃바운드가 이를 올바르게 전달한다는 뜻은 아닙니다. UDP 앱은 서버 설정, 전송 방식, 네트워크 환경에도 영향을 받습니다. 일부 진단 도구가 사용하는 제어 패킷은 프록시 서비스의 사용 가능성을 판단하는 기준으로 적절하지 않을 수 있습니다. 단일 진단 결과를 전체 네트워크 상태로 간주하지 말고 실제 앱에 필요한 프로토콜로 확인한 뒤 로그에서 전달 경로를 점검하세요.

일부 페이지 로딩이 멈춘다면 DNS, 라우팅, UDP 경로를 확인한 뒤 MTU를 점검하세요. 일부 경로에서는 큰 패킷이 조각화되거나 경로 MTU 탐색에 문제가 생길 수 있지만, MTU를 무작정 낮추면 근본 원인을 놓칠 수 있습니다. 기존 값을 기록하고 한 번에 하나만 변경한 뒤 같은 작업을 다시 시험하세요. 개선이 없으면 원래 값으로 되돌리세요. TUN 활성화와 되돌리기 순서는 v2rayN TUN 모드 설정을 참고하세요. 고급 옵션을 한꺼번에 모두 켜기보다 되돌릴 수 있도록 설정하는 것이 중요합니다.

FakeDNS 매핑과 도메인 복원

FakeDNS가 반환하는 값은 대상 서비스의 실제 주소가 아니라 프록시가 매핑 정보를 관리하는 합성 주소입니다. 앱이 이 주소에 연결하면 처리 경로에서 매핑을 통해 원래 도메인을 찾아 라우팅하거나 원격으로 연결합니다. 일부 진입 경로에서 IP만 확인되어 도메인 기준으로 처리하기 어려운 문제를 해결하는 기능이지, 일반 DNS 조회에 캐시를 더하는 기능이 아닙니다. 이 점을 이해해야 현재 진입 경로에 필요한 기능인지 판단할 수 있습니다.

전체 매핑 경로가 갖춰져야 활성화 가능

사용 가능한 연결 경로에는 최소 네 단계가 필요합니다. 조회가 FakeDNS에 도달하고, 앱이 합성 주소를 받고, 연결이 매핑을 관리하는 처리기로 돌아오며, 처리기가 도메인을 복원해 아웃바운드를 선택해야 합니다. 하나라도 빠지면 합성 주소가 일반 주소처럼 네트워크로 전송될 수 있습니다. 설정에 주소 풀만 적고 조회와 후속 연결을 가로채지 않으면 기능이 자동으로 완성되지 않습니다. 현재 클라이언트 백엔드가 이 기능을 실제로 제공하는지 먼저 확인하세요.

V2Fly 방식의 FakeDNS 설정과 일부 TUN 백엔드의 합성 주소 기능은 같은 문법이 아닙니다. 이름이 비슷해도 주소 풀, 캐시, 영구 저장, 도메인 제외 방식이 다를 수 있습니다. 한 백엔드의 스위치와 다른 백엔드의 주소 풀을 조합해서는 안 됩니다. 다음 예제는 해당 문법을 지원하는 V2Fly 설정에서 주소 풀, DNS, 인바운드 스니핑이 어떻게 연결되는지 보여 줍니다. 기존 설정에 병합할 때도 전체 아웃바운드와 라우팅 규칙을 유지해야 합니다.

{
  "fakedns": [
    {
      "ipPool": "198.18.0.0/15",
      "poolSize": 65535
    }
  ],
  "dns": {
    "servers": ["fakedns"]
  },
  "inbounds": [
    {
      "tag": "local-socks",
      "listen": "127.0.0.1",
      "port": 10808,
      "protocol": "socks",
      "settings": {
        "udp": true
      },
      "sniffing": {
        "enabled": true,
        "destOverride": ["fakedns"]
      }
    }
  ]
}

이 설정은 운영체제의 DNS 요청을 자동으로 코어에 전달하지 않습니다. 앱이 다른 리졸버에서 실제 주소를 받으면 해당 요청에는 FakeDNS 풀이 사용되지 않습니다. 앱이 합성 주소를 받았더라도 프록시를 우회해 직접 연결하면 역시 실패합니다. 테스트할 때 조회와 연결이 같은 처리 경로를 통과하는지 확인하세요. 현재 Xray나 다른 백엔드가 같은 필드를 지원하는지는 클라이언트의 실제 설정 옵션에서 확인해야 합니다. 이 예제를 호환성 확인 대신 사용하지 마세요.

주소 풀은 접속 가능한 대상 네트워크가 아님

합성 주소 풀은 실제 사용 중인 네트워크 구성과 충돌하지 않는지 별도로 확인해야 합니다. 예시 주소 대역은 이런 매핑에 자주 사용되지만 테스트 환경이나 내부 네트워크에서 실제로 쓰일 수도 있습니다. 대역이 겹치면 시스템이 대상 IP만으로 실제 서비스와 합성 매핑을 구분할 수 없습니다. 라우팅 테이블과 내부 네트워크 용도를 확인한 뒤 백엔드가 허용하는 주소 풀을 사용하세요. 충돌을 피하려고 임의의 공인 IP 대역으로 바꾸지 마세요.

풀 용량은 관리할 수 있는 매핑 규모를 제한하는 것이지 동시 연결 수를 제한하는 것은 아닙니다. 도메인이 많거나 네트워크 전환이 잦거나 앱이 주소를 장기간 캐시하면 이전 주소와 현재 매핑이 어긋날 수 있습니다. 코어를 다시 시작해도 앱에 이전 합성 주소가 남아 있을 수 있으므로 오래된 연결을 계속 재시도하지 말고 앱이 새로 조회하도록 하세요. 브라우저 페이지를 닫는 것만으로 시스템 캐시까지 지워지지는 않으므로 실제 캐시가 있는 계층을 정리해야 합니다.

일부 앱은 대상 주소가 특정 네트워크 대역에 속하는지 확인하거나 조회 결과를 장기간 저장합니다. 이런 앱은 합성 주소 사용에 적합하지 않을 수 있습니다. 제외가 필요하면 해당 기능을 지원하는 DNS 규칙에서 지정 도메인이 실제 주소를 반환하도록 하되, 실제 연결은 필요한 경로를 계속 사용하도록 설정하세요. DNS 합성에서 제외하는 것과 직접 연결을 선택하는 것은 다른 작업입니다. 실제 주소를 반환하더라도 프록시 아웃바운드로 연결할 수 있습니다.

도메인 라우팅과 함께 검증

활성화한 뒤 도메인 하나로 먼저 확인하세요. 로그에서 합성 주소가 도메인으로 복원되고 예상한 규칙이 적용되는지 살펴봅니다. 합성 주소가 일반 IP 규칙에 바로 매칭되면 주소 풀 전체를 특정 아웃바운드로 강제로 보내지 말고 복원 단계부터 확인하세요. 주소 풀을 통째로 전달하면 현상이 일시적으로 바뀔 수는 있어도 사라진 도메인을 복원하지 못하며, 원격으로 의미 없는 대상 주소를 보낼 수도 있습니다.

기존 SOCKS 도메인 진입 경로가 안정적으로 도메인 기준 분기를 지원한다면 FakeDNS를 추가해도 이점이 없을 수 있습니다. IP 진입 경로에서 도메인을 복원해야 하고 조회와 연결을 함께 제어할 수 있는 경우에 적합합니다. 테스트가 끝나면 활성화 이유, 적용할 진입 경로, 제외 도메인, 되돌리는 방법을 기록하세요. 코어나 트래픽 가로채기 백엔드를 바꾸면 다시 검증해야 합니다. 기존 주소 풀만 복사했다고 이전이 완료된 것은 아닙니다.

다중 구독 관리와 업데이트 범위

다중 구독 관리는 모든 서버를 한 목록에 쌓는 것이 아니라 출처와 용도를 추적하기 위한 기능입니다. 출처마다 기본 그룹을 하나씩 만들고 수동 실험은 별도의 로컬 그룹에 보관하는 것이 좋습니다. 한 출처에 여러 업무용 진입 경로가 있다면 메모에 용도를 적어 이름이 비슷한 그룹이 반복 업데이트되는 일을 막으세요. 그룹 구조가 명확해야 항목의 출처와 변경 이유, 일상 연결에 사용할 설정을 파악할 수 있습니다.

동기화 데이터와 로컬 변경 사항 분리

구독에서 가져온 서버 설정은 출처에서 관리하는 데이터이고, 로컬 메모와 정렬, 수동 변경은 클라이언트 상태입니다. 업데이트 후 상태가 유지되는지는 클라이언트가 항목을 식별하는 방식에 따라 다르므로 이름이 같다고 같은 항목으로 처리된다고 단정할 수 없습니다. 출처에서 이름, 포트, 식별자가 바뀌면 클라이언트가 새 항목을 만들 수 있습니다. 중요한 로컬 변경은 수동 그룹에 복사해 변경 목적을 기록하고 원본 그룹은 동기화용으로 유지하세요.

표시 이름만 보고 중복 설정을 삭제하지 마세요. 이름이 같은 두 항목도 포트, 프로토콜, 전송 방식, 보안 설정이 다를 수 있고 이름이 다른 두 항목이 같은 엔드포인트를 가리킬 수도 있습니다. 정리할 때는 먼저 출처를 확인한 뒤 연결 설정과 실제 용도를 비교하세요. 클라이언트에 중복 제거 기능이 있다면 어떤 필드로 중복을 판단하는지 알아보고 설정을 내보낸 뒤 실행하세요. 확신이 없는 항목은 일괄 삭제보다 테스트 범위로 옮겨 확인하는 편이 복구하기 쉽습니다.

로컬 그룹과 구독 그룹에는 서로 다른 업데이트 정책을 적용해야 합니다. 수동 그룹에는 구독 주소를 입력할 필요가 없습니다. 출처 링크를 저장하면 그 안의 모든 수동 변경이 자동 관리된다고 오해할 수 있습니다. 구독 업데이트 후 프로토콜 설정이 바뀌었다면 원본 그룹에서 새 서버를 먼저 확인한 뒤 로컬 실험 항목을 옮길지 결정하세요. 이전 설정을 원본 항목에 다시 덮어쓰면 다음 업데이트 때 같은 충돌이 반복됩니다.

업데이트 순서와 장애 대체 경로 설계

현재 네트워크에서 직접 업데이트할 수 있는 출처가 하나 이상 있는지, 모든 출처가 프록시를 필요로 하는지 먼저 확인하세요. 프록시 업데이트가 필요하면 활성 서버 선택이 업데이트 성공률에 영향을 줍니다. 일상적인 업데이트는 그룹별로 진행하세요. 비활성 출처를 먼저 업데이트해 연결 가능 여부를 확인한 다음 현재 출처를 업데이트하면 됩니다. 이렇게 하면 활성 연결과 설정 동기화가 동시에 바뀌는 상황을 줄이고, 특정 그룹의 응답에 문제가 생겨도 작동하는 비교 기준을 남길 수 있습니다.

구독이 여러 개 있다고 자동으로 장애 조치가 되는 것은 아닙니다. 일반 그룹은 설정을 정리하는 단위일 뿐이며 활성 서버를 바꾸려면 사용자가 직접 조작해야 하는 경우가 많습니다. 클라이언트가 지원하는 선택 또는 스케줄링 기능을 명확히 설정한 경우에만 다른 아웃바운드로 자동 전환된다고 기대해야 합니다. 이 기능에 필요한 상태 점검 조건도 별도로 검증하세요. 목록에 서버가 여러 개 있다는 이유만으로 연결 실패 시 코어가 다음 서버를 자동으로 찾는다고 가정하지 마세요.

속도 측정 결과만으로 장기 우선순위를 정할 수도 없습니다. 연결 수립, 웹페이지 접속, 지속 전송은 각각 다른 지표를 확인하며 테스트 대상에 따라서도 결과가 달라집니다. 업무 요구에 맞는 테스트 유형을 선택한 뒤 같은 조건에서 결과를 비교하세요. 테스트 중에는 네트워크, 라우팅, DNS를 동일하게 유지해 네트워크 전환에 따른 차이를 구독 출처의 차이로 오인하지 않도록 합니다. 특정 설정의 테스트가 실패하면 현재 활성화되지 않은 프로토콜이나 전송 기능이 필요한지도 확인하세요.

설정 이전과 구독 주소 보호

컴퓨터를 옮기기 전에 클라이언트 설정, 구독 주소, 로컬 수동 서버가 모두 내보내기 대상에 포함되는지 각각 확인하세요. 일부 내보내기 기능은 서버만 포함하고 라우팅, DNS, 트래픽 가로채기 설정은 포함하지 않습니다. 가져온 뒤에는 항목이 모두 보인다는 이유만으로 TUN을 바로 켜지 말고 하나씩 확인하세요. 일반 프록시를 먼저 검증하고 트래픽 분기를 복원한 뒤 고급 트래픽 가로채기 설정을 복원하면 이전 과정의 오류를 특정 계층으로 좁힐 수 있습니다.

구독 주소는 접근 권한을 포함할 수 있으므로 민감한 설정으로 취급해야 합니다. 문제 해결 정보를 공유할 때는 오류 유형과 상태만 남기고 전체 주소, 사용자 식별 정보, 서버 인증 정보는 가리세요. 주소가 유출된 것으로 의심되면 출처에서 새 주소를 발급받아 클라이언트에 반영해야 합니다. 그룹 메모만 바꾸는 것으로는 해결되지 않습니다. 사용 중지한 출처를 삭제한 뒤에도 로컬 그룹에 복사한 이전 항목이 남아 있는지 확인해 잘못 선택하지 않도록 하세요.

여러 출처가 동시에 업데이트에 실패하면 시스템 시간, DNS, 현재 네트워크, 프록시 업데이트 경로, 로컬 방화벽처럼 공통으로 사용하는 부분부터 확인하세요. 한 출처에서만 실패한 경우에는 해당 출처의 주소와 응답을 중점적으로 살펴보면 됩니다. 이 순서대로 확인하면 전역 장애를 각 구독의 개별 문제로 잘못 판단하는 일을 줄일 수 있습니다. 브라우저에서는 접속되지만 클라이언트 업데이트가 실패한다면 두 프로그램의 프록시와 DNS 경로를 비교하세요. 브라우저가 정상이라는 이유만으로 로컬 설정 문제를 배제해서는 안 됩니다.

사용자 지정 아웃바운드와 설정 전체 검증

아웃바운드는 코어가 요청을 다음 홉으로 전달하는 방식이고, 라우팅은 사용할 아웃바운드를 선택합니다. 사용자 지정 아웃바운드는 특수한 상위 서버, 고정된 로컬 전달 경로, 명확한 체인 연결이 필요한 경우에 적합하며 일반 구독을 가져올 때 반드시 필요한 기능은 아닙니다. 시작하기 전에 v2rayN에서 검증된 일반 설정 하나를 보존하고, 현재 사용 중인 방식이 클라이언트 관리 서버인지, 전체 사용자 지정 설정인지, 병합 가능한 설정 조각인지 확인하세요. 세 방식은 필드 덮어쓰기와 저장 동작이 서로 다릅니다.

태그로 인바운드, 규칙, 아웃바운드 연결

tag는 설정 내부에서 사용하는 이름입니다. 라우팅의 outboundTag는 기존 아웃바운드의 태그와 정확히 일치해야 하며 대소문자와 철자를 임의로 바꾸면 안 됩니다. 역할을 알아보기 쉬운 짧은 이름을 사용하고 서버 비밀번호나 전체 주소를 태그에 넣지 마세요. 태그가 없거나 중복되거나 존재하지 않는 대상을 가리키면 시작에 실패하거나 예상과 다른 경로를 사용할 수 있습니다.

다음은 독립적으로 시작할 수 있는 로컬 전달 예제로, V2Fly 및 호환 Xray에서 흔히 쓰는 구조를 사용합니다. 루프백 주소에 SOCKS 인바운드를 열고 모든 트래픽을 이 컴퓨터의 다른 SOCKS 서비스로 전달합니다. 로컬 포트 20808에서 별도 상위 서버가 실행 중이어야 합니다. 상위 서버가 없다면 설정 구조 확인에는 사용할 수 있지만 실제 연결은 실패합니다. 원격 서버 인증 정보는 포함하지 않으므로 구독에서 받은 실제 설정을 대신할 수 없습니다.

{
  "log": {
    "loglevel": "warning"
  },
  "inbounds": [
    {
      "tag": "local-in",
      "listen": "127.0.0.1",
      "port": 10818,
      "protocol": "socks",
      "settings": {
        "auth": "noauth",
        "udp": false
      }
    }
  ],
  "outbounds": [
    {
      "tag": "upstream-socks",
      "protocol": "socks",
      "settings": {
        "servers": [
          {
            "address": "127.0.0.1",
            "port": 20808
          }
        ]
      }
    },
    {
      "tag": "direct",
      "protocol": "freedom",
      "settings": {}
    }
  ],
  "routing": {
    "domainStrategy": "AsIs",
    "rules": [
      {
        "type": "field",
        "network": "tcp",
        "outboundTag": "upstream-socks"
      }
    ]
  }
}

예제에서 UDP를 끈 것은 검증 범위를 TCP로 한정하고 상위 서버의 UDP 지원을 가정하지 않기 위해서입니다. 수신 주소가 루프백 인터페이스로 제한되어 있어 이 컴퓨터에서만 사용할 수 있습니다. 테스트가 편하다는 이유로 모든 네트워크 어댑터에서 수신하도록 바꾸지 마세요. 공유가 꼭 필요하다면 허용할 출처, 인증, 방화벽을 별도로 설정해야 합니다. 포트가 기존 클라이언트의 수신 포트와 겹치면 시작에 실패하며, 이는 원격 연결 문제와 무관합니다.

체인 연결의 루프 방지

전달 체인에서 흔히 발생하는 오류는 진입 경로가 자기 자신을 가리키거나 상위 서버가 시스템 프록시를 통해 현재 진입 경로로 되돌아오는 것입니다. 설정 전에 앱, 로컬 인바운드, 선택된 아웃바운드, 독립 상위 서버, 최종 대상 순서로 체인을 분명하게 그려 보세요. 각 단계의 수신 주소와 포트를 기록하고 ‘프록시 사용’처럼 모호하게 적지 마세요. 상위 서버에서도 TUN을 사용한다면 상위 서버로 향하는 연결이 하위 트래픽 가로채기에 다시 잡히지 않는지 확인하세요.

도메인을 어느 단계에서 조회하는지도 명확해야 합니다. 앱이 도메인을 전달하면 상위 SOCKS 서비스에서 해당 도메인을 처리할 수 있지만, 앱이 미리 IP를 전달하면 신뢰할 수 있는 복원 기능이 없는 한 이후 경로에서는 그 주소만 사용하게 됩니다. 아웃바운드 체인이 잘못된 조회 결과를 자동으로 수정하거나 특정 전송 방식을 지원하지 않는 상위 서버에 해당 기능을 추가해 주지는 않습니다. 체인 연결을 테스트할 때는 먼저 상위 서버가 독립적으로 작동하는지 확인하고 그다음 하위 전달을 추가하세요.

전체 사용자 지정 설정은 클라이언트가 자동 생성하는 라우팅과 DNS 일부를 우회할 수 있습니다. 저장하기 전에 화면 안내를 확인하고 시스템 프록시 진입 주소가 실제 수신 포트를 가리키는지 확인하세요. GUI에서 라우팅을 바꿨다고 사용자 지정 설정에도 자동 반영된다고 가정하지 마세요. 반대로 임시 생성 파일은 다음 시작 때 덮어써질 수 있습니다. 장기적으로 관리하려면 클라이언트가 공식 지원하는 설정 위치를 사용하고 원본 파일을 복구용으로 보관하세요.

구조, 진입 경로, 라우팅, 출구 순서로 검증

먼저 JSON 문법을 확인한 뒤 코어가 각 필드를 지원하는지 점검하세요. JSON 형식이 올바르다는 것은 괄호, 쉼표, 문자열 구조가 맞다는 뜻일 뿐 설정 의미까지 올바르다는 뜻은 아닙니다. 시작 로그에 알 수 없는 프로토콜, 태그 없음, 포트 사용 중 오류가 나타나면 먼저 해당 로컬 문제를 해결하세요. 코어가 안정적으로 시작되면 앱 하나에서 요청을 보내 인바운드가 연결을 받는지, 라우팅이 예상한 아웃바운드를 선택하는지, 상위 서버가 연결을 수락하는지 확인합니다.

브라우저에서는 되지만 터미널에서 실패한다면 아웃바운드를 계속 수정하기보다 터미널이 로컬 프록시를 실제로 사용하는지 먼저 확인하세요. 일부 터미널 프로그램은 프록시 환경 변수나 별도 매개변수를 직접 설정해야 하며 시스템 프록시가 일괄 적용되지 않습니다. 자세한 문제 해결은 시스템 프록시가 작동하지 않을 때: 브라우저와 터미널 점검을 참고하세요. 검증할 때마다 새 연결을 사용해야 합니다. 기존 세션은 이전 출구를 계속 사용할 수 있습니다.

마지막으로 설정을 불러올 수 있는지, 대상 요청에 어떤 규칙이 적용되는지, 어떤 아웃바운드를 사용하는지, 고급 기능을 껐을 때 복구되는지 기록하세요. 구독 업데이트, LAN 연결, 필요한 UDP 작업도 각각 확인해 웹페이지 하나만 테스트하는 데 그치지 마세요. 완료 후에는 평소 로그 수준으로 되돌리고 임시 규칙과 불필요한 진입 경로를 제거하세요. 이후 클라이언트나 코어를 바꾸면 같은 순서로 다시 검증해야 합니다. 설정 파일을 가져올 수 있다고 모든 동작이 그대로 유지되는 것은 아닙니다.