구독 그룹, 라우팅, DNS 및 TUN 설정

1. 구독 그룹 및 서버 필터링

구독 그룹은 “설정 출처”를, 서버 필터링은 “목록에 표시할 항목”을 결정합니다. 두 기능은 분리해 설정해야 합니다. 그룹은 출처를 관리하고 필터는 표시 범위만 바꾸며, 설정 삭제까지 담당해서는 안 됩니다.

안정적인 그룹 경계 만들기

v2rayN에서 여러 구독을 가져올 때는 먼저 출처별로 독립된 그룹을 만드세요. 모든 서버를 기본 그룹에 장기간 쌓아 두지 않는 것이 좋습니다. 그룹 이름은 “일상용”, “업무 테스트”, “수동 설정”처럼 용도나 출처를 설명해야 하며, 쉽게 바뀌는 지역명은 피하세요. 지역, 프로토콜 및 회선 태그는 필터 규칙으로 처리하는 편이 적합합니다. 이렇게 하면 구독 주소를 바꿔도 기존 라우팅과 필터링 로직이 이름 변경과 함께 무효화되지 않습니다.

새 구독을 추가한 뒤 먼저 해당 그룹만 한 번 업데이트하고, 그룹 안에 설정이 나타나는지 확인하세요. 문제가 없을 때 자동 업데이트를 활성화합니다. 업데이트 결과가 비어 있어도 기존 그룹을 바로 삭제하지 마세요. 먼저 구독 주소가 완전한지, 현재 그룹에 제외 규칙이 적용되어 있는지, 업데이트 요청이 현재 시스템 프록시를 사용해야 하는지 확인해야 합니다. 더 자세한 점검 순서는 구독 업데이트 실패 자가 점검 목록을 참고하세요. 새 데이터 검증이 끝날 때까지 기존 데이터를 보존하면 잘못된 업데이트로 사용 가능한 설정이 덮어써지는 일을 막을 수 있습니다.

수동으로 추가한 VMess, VLESS, Trojan 또는 Shadowsocks 설정은 별도 그룹에 넣는 것이 좋습니다. 구독 업데이트는 대개 원격 콘텐츠를 기준으로 목록을 다시 만들기 때문에, 수동 설정을 구독 그룹에 섞어 두면 이후 업데이트에서 각 항목이 로컬 설정인지 구독에서 가져온 것인지 판단하기 어렵습니다. 별도 그룹으로 관리하면 내보내기, 이전 및 전송 매개변수의 항목별 확인도 쉬워집니다.

포함, 제외 및 정규식 필터

필터에는 보통 “포함 키워드”와 “제외 키워드”라는 두 가지 조건이 있습니다. 포함 조건은 후보 범위를 좁히고, 제외 조건은 불필요하다고 알려진 태그를 제거합니다. 먼저 제외 조건을 설정한 다음 포함 조건을 조금씩 추가하는 방법을 권장합니다. 두 조건을 함께 설정하면 일반적으로 포함 조건을 만족하면서 제외 조건에는 해당하지 않는 항목만 표시됩니다. 필터는 비고나 구독에서 제공한 태그에만 적용되며, 서버의 실제 위치, 프로토콜 기능 또는 사용 가능 여부를 검증하지 않습니다.

단순한 경우에는 일반 키워드를 우선 사용하세요. 여러 단어 중 “하나라도” 일치해야 한다면 정규식의 세로줄을 사용할 수 있습니다. 예: 가정용|업무용. 시작 부분은 ^, 끝 부분은 $로 일치시킵니다. 정규식에서 괄호, 마침표와 더하기 기호는 특수한 의미를 가지므로 해당 문자를 그대로 찾으려면 먼저 이스케이프해야 합니다. 설정 후에는 필터 결과 수와 처음·마지막 항목을 바로 확인해 표현식 범위가 지나치게 넓지 않은지 점검하세요.

포함: ^(가정용|업무용).*(VLESS|Trojan)$
제외: 테스트|만료|점검
설명: “가정용” 또는 “업무용”으로 시작하고 지정된 프로토콜 태그로 끝나는 항목만 표시

필터 적용 후 목록이 비어 있으면 세 단계로 점검하세요. 첫째, 모든 필터 조건을 임시로 지워 원본 목록이 존재하는지 확인합니다. 둘째, 일반 키워드 하나만 남겨 비고 필드에 해당 단어가 실제로 포함되어 있는지 확인합니다. 셋째, 정규식을 다시 적용하고 표현식을 구간별로 늘려 갑니다. 처음부터 구독 주소, 그룹과 정규식을 동시에 바꾸면 어떤 단계에서 결과가 달라졌는지 알 수 없습니다.

정렬, 선택 및 업데이트 후 안정성

서버 정렬은 화면에 표시되는 순서일 뿐 라우팅 우선순위와는 다릅니다. 비고, 주소 또는 프로토콜 기준으로 정렬해도 현재 선택된 서버는 클라이언트 상태에 따라 결정됩니다. 구독 업데이트로 목록 순서가 바뀌거나 항목 식별자가 다시 생성될 수 있으므로, 장기 선택 조건으로 “몇 번째 줄”을 사용하지 마세요. 명확한 비고, 고정된 그룹과 재현 가능한 필터 규칙을 사용하는 편이 안정적입니다.

그룹 구성이 끝나면 각 그룹의 업데이트 방식, 자동 업데이트 설정과 필터 조건을 따로 확인하세요. 자주 사용하는 그룹은 예약 업데이트를 활성화할 수 있고, 임시 테스트 그룹은 원격 변경으로 비교 테스트가 자주 중단되지 않도록 수동 업데이트가 적합합니다. 업데이트 전후 서버 수에 큰 차이가 있으면 먼저 클라이언트 로그와 필터 결과를 확인한 뒤 현재 설정을 전환하세요.

2. 라우팅 규칙 실전과 일치 순서

라우팅 규칙은 연결을 서로 다른 아웃바운드로 보냅니다. 결과는 대상 정보, 규칙 순서와 아웃바운드 태그에 따라 결정됩니다. 설정할 때는 먼저 정책을 정의한 다음 문법을 작성하세요.

위에서 아래로 진행되는 일치 과정 이해하기

라우팅 엔진은 일반적으로 규칙을 위에서 아래로 확인하며, 조건을 만족하는 첫 번째 규칙이 아웃바운드를 결정하고 이후 규칙은 적용하지 않습니다. 정밀한 규칙은 앞에, 범위가 넓은 규칙은 뒤에 배치하고 마지막에는 명확한 기본 정책을 남겨 두세요. 예를 들어 로컬 네트워크 주소의 직접 연결은 광범위한 프록시 규칙보다 앞에 있어야 하며, 특정 도메인의 직접 연결 또는 차단 규칙도 분류 집합보다 앞에 배치해야 합니다. 적용 범위가 매우 넓은 규칙을 맨 위에 두면 이후 세부 규칙은 문법이 올바르더라도 적용되지 않습니다.

자주 사용하는 일치 대상에는 도메인, IP, 포트, 네트워크 유형 및 프로세스가 있습니다. 도메인 규칙에는 전체 도메인, 접미사, 키워드 또는 geosite 분류를 사용할 수 있습니다. IP 규칙에는 단일 주소, CIDR 네트워크 또는 geoip 분류를 사용할 수 있습니다. 포트는 대상 포트만 나타내며 애플리케이션 유형을 판단하지는 못합니다. 프로세스 일치는 시스템과 클라이언트가 프로세스 정보를 가져올 수 있어야 하므로, 플랫폼을 옮길 때 유일한 조건으로 사용해서는 안 됩니다.

설명 가능한 기본 순서

기본 트래픽 분할은 세 단계로 시작할 수 있습니다. 첫째, 사설 주소를 처리해 프린터, 라우터와 로컬 네트워크 서비스가 원격 아웃바운드로 나가지 않게 합니다. 둘째, 명확한 도메인 분류를 처리합니다. 셋째, 기본 프록시 아웃바운드를 설정합니다. 출처가 불분명한 규칙 집합을 한 번에 많이 추가하지 마세요. 규칙이 많을수록 우선순위 충돌을 찾기 어렵고 리소스 업데이트도 관리하기 힘들어집니다.

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

domainStrategy는 도메인 규칙이 일치하지 않을 때 IP를 계속 조회할지 결정합니다. IPIfNonMatch를 사용하면 라우팅이 먼저 도메인 규칙을 시도하고, 일치하지 않을 경우 DNS로 주소를 얻어 IP 규칙을 확인합니다. geosite와 geoip를 함께 사용하는 구성에 적합합니다. 도메인만 기준으로 판단하면 대상 IP에 의존하는 규칙이 적용되지 않을 수 있고, 모든 도메인을 미리 조회하면 DNS 요청이 늘어나며 연결 순서도 달라집니다.

규칙이 적용되지 않을 때 원인 찾기

먼저 실제 대상이 도메인인지 이미 조회된 IP인지 확인하세요. 브라우저는 보통 도메인을 전달하지만 일부 애플리케이션은 직접 조회한 뒤 IP로 연결하므로 도메인 규칙에서 원래 이름을 볼 수 없습니다. 다음으로 규칙이 가리키는 아웃바운드 태그가 실제로 존재하는지 확인하세요. 대소문자를 구분하는 태그라면 proxy와 Proxy는 서로 다른 대상입니다. 마지막으로 규칙 순서를 확인하되, 특히 맨 위에 모든 포트·모든 네트워크·광범위한 도메인을 덮는 규칙이 있는지 살펴보세요.

단일 규칙을 테스트할 때는 조건 범위를 임시로 줄이세요. 예를 들어 분류 규칙을 전체 도메인 하나로 바꾸고, 라우팅 판단을 확인할 수 있도록 로그 수준을 조정한 다음 새 연결을 한 번 생성해 선택된 아웃바운드를 확인합니다. 기존 연결은 이전 경로를 재사용할 수 있으므로 규칙을 변경한 뒤 해당 애플리케이션의 연결을 닫거나 클라이언트 코어를 다시 시작해야 합니다. 페이지 새로 고침만으로는 새 연결이 생성되지 않을 수 있습니다.

UDP와 TCP에 서로 다른 규칙을 사용할 수 있지만 애플리케이션 동작을 명확히 이해해야 합니다. 도메인 조회는 일반적으로 UDP를 사용하지만 TCP로 폴백할 수도 있고, 실시간 통신은 여러 대상 포트를 동시에 사용할 수 있습니다. TCP만 특정 아웃바운드로 허용하면 관련 UDP 요청이 기본 규칙으로 빠져 “페이지는 열리지만 일부 기능이 비정상인” 현상이 생길 수 있습니다. 점검할 때는 도메인만 보지 말고 네트워크 유형, 대상 포트와 최종 아웃바운드를 함께 확인하세요.

3. DNS 설정 최적화와 조회 경로

DNS 설정은 서버 주소를 입력하는 것만으로 끝나지 않습니다. 다음 세 가지 질문에 동시에 답해야 합니다. 누가 조회를 시작하는가, 조회가 어느 아웃바운드를 거치는가, 반환 결과가 라우팅에 어떻게 참여하는가입니다.

시스템 조회와 코어 조회 구분하기

시스템 프록시 모드에서는 일부 애플리케이션이 시스템 DNS를 직접 호출한 뒤 조회된 IP를 프록시에 전달하고, 다른 애플리케이션은 도메인을 그대로 프록시 클라이언트에 전달합니다. 두 요청은 코어에 들어올 때 포함한 정보가 다릅니다. 전자는 IP만 남을 수 있어 라우팅이 geoip 또는 네트워크 대역 규칙에 의존해야 하고, 후자는 도메인이 남아 geosite, 접미사 및 전체 도메인 규칙을 먼저 사용할 수 있습니다. 같은 웹사이트가 애플리케이션에 따라 다른 아웃바운드로 연결된다면 먼저 조회가 애플리케이션 측에서 일어나는지 코어 측에서 일어나는지 확인하세요.

TUN 모드는 더 많은 시스템 트래픽을 가로채고 DNS 경로를 통일하기 쉽지만, 시스템 DNS, TUN DNS와 브라우저 자체 조회 정책이 동시에 경쟁하지 않도록 해야 합니다. 목표는 모든 조회가 같은 서버를 사용하게 만드는 것이 아니라 조회 결과와 라우팅 정책을 일치시키는 것입니다. 도메인 분류로 트래픽을 나눌 계획이라면 도메인 정보를 최대한 보존하고, 대상 IP 기준으로 나눌 계획이라면 판단에 사용할 조회 결과가 안정적으로 제공되도록 해야 합니다.

서버 유형과 일치 조건

DNS 서버는 도메인 조건에 따라 그룹화할 수 있습니다. 직접 연결할 도메인은 로컬 네트워크에서 접근 가능한 조회 서비스를 사용하고, 나머지는 프록시 아웃바운드를 통해 조회할 수 있습니다. 설정할 때는 서버 주소 자체를 어떻게 조회하고 연결할지도 명확히 해야 합니다. 암호화 DNS의 호스트 이름에 추가 DNS 조회가 필요하다면 접근 가능한 부트스트랩 조회 주소를 준비해야 순환 의존성을 피할 수 있습니다.

queryStrategy는 IPv4, IPv6 또는 두 주소 유형을 반환할지 제어합니다. 선택 기준은 현재 네트워크와 대상 서비스의 실제 접근 가능성으로 정해야 합니다. IPv4만 반환하면 듀얼 스택 환경의 불확실한 분기를 줄일 수 있지만 IPv6만 제공하는 대상은 제외됩니다. 둘 다 반환하려면 시스템 라우팅과 아웃바운드 경로가 듀얼 스택을 올바르게 처리해야 합니다. 로그에 특정 주소 유형이 나타난다는 이유만으로 다른 유형을 강제로 끄지 말고, 먼저 로컬 네트워크에서 안정적으로 연결되는지 테스트하세요.

{
  "dns": {
    "queryStrategy": "UseIP",
    "servers": [
      {
        "address": "223.5.5.5",
        "domains": [
          "geosite:cn"
        ],
        "expectIPs": [
          "geoip:cn"
        ]
      },
      {
        "address": "1.1.1.1",
        "domains": [
          "geosite:geolocation-!cn"
        ],
        "skipFallback": true
      },
      "localhost"
    ]
  }
}

expectIPs는 응답 주소가 예상한 분류에 맞는지 검증합니다. 결과를 특정 지역으로 강제하는 기능이 아니라, 응답이 조건에 맞지 않을 때 조회 과정에서 다른 후보 서버를 시도하게 하는 기능입니다. skipFallback은 해당 서버를 일반 폴백 과정에서 제외한다는 뜻이며, 명확한 도메인 집합만 처리하는 조회기에 적합합니다. 지원되는 필드는 현재 사용하는 코어 설정 형식에 따라 다르므로, 사용자 지정 조각을 가져오기 전에 v2rayN이 생성한 전체 설정과 시작 로그를 확인하세요.

캐시, 폴백 및 오염된 응답 오류 구분하기

DNS를 변경한 뒤 결과가 즉시 바뀌지 않는다면 브라우저, 시스템, 클라이언트 코어 또는 상위 조회기가 여전히 캐시를 보관하고 있을 수 있습니다. 점검할 때는 먼저 테스트 애플리케이션의 기존 연결을 닫고 코어를 다시 시작하세요. 필요하면 시스템 DNS 캐시도 삭제합니다. 같은 페이지를 연속으로 새로 고친 뒤 한 번의 결과만으로 판단하지 마세요. 연결 풀과 캐시가 새 설정을 우회할 수 있습니다.

조회 이상은 일반적으로 시간 초과, 빈 레코드 반환, 접근할 수 없는 주소 반환, 주소 유형 불일치로 나뉩니다. 시간 초과는 DNS 요청에 사용된 아웃바운드와 방화벽을 확인하고, 빈 레코드는 도메인 자체와 조회 유형을 확인해야 합니다. 접근할 수 없는 주소는 라우팅 테이블과 대상 네트워크를, 유형 불일치는 queryStrategy를 점검하세요. 로그상 조회는 성공했지만 연결에 실패한다면 문제는 이미 DNS 계층에서 라우팅, 아웃바운드 또는 전송 계층으로 넘어간 경우가 많습니다.

DNS 설정을 평가할 때는 최소한 세 종류의 대상을 선택하세요. 명확한 직접 연결 도메인, 명확한 프록시 연결 도메인, 특정 주소 유형만 제공하는 테스트 대상입니다. 각각의 조회 결과, 일치한 규칙과 최종 아웃바운드를 기록하세요. 자주 사용하는 웹사이트 하나만 테스트해서는 폴백 순서와 경계 조건이 올바르다고 증명할 수 없습니다.

4. TUN 모드의 적용 범위와 시스템 라우팅

시스템 프록시는 프록시 설정을 읽는 애플리케이션에만 영향을 주지만, TUN 모드는 가상 네트워크 인터페이스를 통해 더 넓은 트래픽을 가로챕니다. 둘은 단순한 강약 관계가 아니라 서로 다른 연결 방식입니다.

TUN은 언제 활성화해야 하는가

브라우저, 다운로드 도구와 대부분의 데스크톱 애플리케이션이 시스템 프록시를 읽을 수 있다면 먼저 시스템 프록시를 사용하세요. 경로가 짧고 개별적으로 종료하기도 쉽습니다. 게임 런처, 명령줄 프로그램, 일부 스토어 구성 요소 또는 고정 직접 연결 애플리케이션이 시스템 프록시를 읽지 않을 때 TUN을 고려해야 합니다. 활성화하기 전에 일반 시스템 프록시 설정이 이미 작동하는지 확인하세요. 기본 경로를 검증하지 않은 상태에서 가상 네트워크 카드와 라우팅 테이블까지 추가하면 점검 범위만 넓어집니다.

TUN을 시작하면 클라이언트가 가상 인터페이스를 만들고 설정에 따라 시스템 라우팅을 기록합니다. 트래픽은 먼저 가상 인터페이스로 들어간 뒤 코어가 라우팅과 아웃바운드를 판단합니다. DNS도 코어 처리로 리디렉션될 수 있습니다. 클라이언트를 종료할 때는 원래 라우팅이 복원되어야 합니다. 프로세스가 비정상 종료되면 임시 인터페이스나 라우팅 상태가 남아 클라이언트를 닫았는데도 네트워크가 이상해질 수 있습니다. 이때는 먼저 클라이언트를 다시 시작해 TUN을 정상적으로 종료한 뒤 시스템 네트워크 설정을 확인하세요.

주요 매개변수의 의미

stack은 TUN에서 사용할 네트워크 스택 구현을 의미합니다. 구현마다 TCP, UDP, 듀얼 스택과 시스템 호환성에 대한 초점이 다릅니다. 정상적인 경우에는 클라이언트 권장값을 유지하고, 특정 애플리케이션의 연결 실패, UDP 이상 또는 높은 부하가 발생할 때만 항목별로 전환해 테스트하세요. 네트워크 스택을 바꾼 뒤에는 코어를 완전히 다시 시작해야 하며 기존 연결은 자동으로 이전되지 않습니다.

autoRoute는 대상 트래픽이 가상 인터페이스로 들어가도록 라우팅을 자동으로 추가합니다. 끄면 시스템 라우팅을 직접 관리해야 하므로 명확한 네트워크 토폴로지가 있는 환경에 적합하며, 처음 설정할 때는 권장하지 않습니다. strictRoute는 우회 경로를 더 엄격하게 제한해 일부 트래픽이 TUN을 빠져나가는 것을 줄이지만, 로컬 네트워크 탐색, 가상 머신 또는 다른 네트워크 도구에 영향을 줄 수 있습니다. mtu는 단일 패킷의 최대 전송 단위를 제어합니다. 너무 크면 일부 경로에서 조각화나 패킷 손실이 발생하고, 너무 작으면 추가 오버헤드가 늘어납니다.

로컬 네트워크, 가상 머신 및 기타 네트워크 도구

TUN을 활성화한 뒤 라우터 관리 페이지, 네트워크 저장 장치 또는 프린터에 접근할 수 없다면 먼저 geoip:private가 직접 연결되는지 확인하고, 엄격한 라우팅이 로컬 네트워크 대역을 차단하는지 점검하세요. 로컬 네트워크는 흔하지 않은 사설 대역을 사용할 수 있으므로 분류 데이터에만 의존해서는 안 됩니다. 필요하면 실제 대역에 CIDR 직접 연결 규칙을 추가하세요. 예: 192.168.50.0/24. 규칙은 기본 프록시 규칙보다 앞에 있어야 합니다.

가상 머신, 컨테이너와 기업 네트워크 클라이언트도 라우팅 테이블을 변경할 수 있습니다. 여러 도구를 동시에 활성화하면 시스템은 접두사 길이와 메트릭에 따라 서로 다른 인터페이스를 선택할 수 있습니다. 모든 도구를 반복해서 켰다 끄며 운에 맡기지 마세요. 먼저 TUN 시작 전후 라우팅 테이블의 차이를 기록한 다음 네트워크 스택을 변경하는 다른 소프트웨어를 종료하고 단독 실행이 정상인지 확인합니다. 단독 실행이 정상이라면 다른 구성 요소를 하나씩 다시 활성화하세요.

절전 후 복귀하거나 유선에서 무선으로, 가정 네트워크에서 업무 네트워크로 전환하면 기존 인터페이스 인덱스가 바뀔 수 있습니다. 연결이 멈추면 먼저 TUN을 끄고 가상 인터페이스가 종료될 때까지 기다린 후 다시 활성화하세요. 클라이언트에서 계속 인터페이스 생성 실패가 표시되면 실행 권한, 시스템 네트워크 구성 요소 상태와 같은 이름의 잔여 인터페이스가 있는지 확인해야 합니다.

5. FakeDNS의 작동 방식과 적용 범위

FakeDNS는 도메인에 임시 예약 주소를 할당해 대상 IP만 포함한 연결에서도 원래 도메인을 복원할 수 있게 합니다. 주된 목적은 애플리케이션의 조회 단계에서 도메인 정보가 사라지는 문제를 해결하는 것입니다.

조회부터 연결까지의 매핑 과정

FakeDNS를 활성화하면 가로챈 DNS 조회가 실제 대상 주소를 애플리케이션에 즉시 전달하지 않고 전용 주소 풀의 임시 주소를 반환합니다. 애플리케이션이 해당 주소에 연결하면 코어가 매핑 테이블에서 원래 도메인을 찾아 도메인 라우팅과 실제 조회를 수행합니다. 이 과정 덕분에 TUN 환경에서 도메인 규칙이 더 안정적으로 작동합니다. 애플리케이션이 먼저 조회한 뒤 연결하더라도 코어가 연결이 처음 대응한 이름을 알 수 있기 때문입니다.

임시 주소는 현재 매핑의 유효 기간 동안에만 의미가 있으므로 실제 대상 서버 주소로 저장하거나 공유하거나 장기 규칙에 기록해서는 안 됩니다. 애플리케이션이 조회 결과를 오래 캐시하는 동안 코어 매핑이 만료되면 연결이 실패할 수 있습니다. 애플리케이션을 다시 시작하거나 DNS 캐시를 삭제하면 새 매핑을 만들 수 있습니다. 클라이언트 코어를 다시 시작한 뒤에는 이전 임시 주소가 더 이상 원래 도메인에 대응하지 않을 수도 있습니다.

주소 풀과 예외 도메인

FakeDNS 주소 풀은 현재 로컬 네트워크, 가상 머신 네트워크, 컨테이너 네트워크 또는 다른 터널의 주소 대역과 겹치면 안 됩니다. 겹치면 시스템이 임시 주소를 잘못된 인터페이스로 보낼 수 있고, 로그에 연결이 코어로 들어온 흔적조차 나타나지 않을 수 있습니다. 주소 풀을 선택하기 전에 현재 무선 네트워크만 확인하지 말고 로컬 라우팅 테이블과 자주 사용하는 네트워크 환경을 함께 확인하세요.

모든 도메인이 FakeDNS에 적합한 것은 아닙니다. 로컬 네트워크 장치 이름, 기업 내부 도메인, 특정 시스템 조회기가 처리해야 하는 이름, 실제 IP로 로컬 판단을 수행하는 애플리케이션은 예외로 지정할 수 있습니다. 예외 목록은 정확하게 유지하고 전체 도메인이나 명확한 접미사를 우선 사용하세요. 범위가 지나치게 넓은 분류를 모두 제외하면 FakeDNS가 도메인을 복원하는 기능이 약해집니다.

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

198.18.0.0/15는 벤치마크 네트워크에 자주 사용되며 실제 대상의 위치를 의미하는 주소로 이해해서는 안 됩니다. 설정 전에 현재 가상 네트워크가 이 대역을 사용하지 않는지 확인해야 합니다. poolSize는 관리할 수 있는 매핑 수를 결정하며, 일반적인 데스크톱 사용에서는 무작정 늘릴 필요가 없습니다. 주소 풀이 너무 커도 단일 조회 속도가 빨라지지 않고 오히려 충돌 범위를 확인하기 어려워집니다.

실제 DNS, 스니핑 및 라우팅과의 관계

FakeDNS는 실제 DNS를 대체하지 않습니다. 애플리케이션에는 먼저 임시 주소를 반환하고, 코어가 연결을 준비할 때 대상의 실제 주소를 다시 조회해야 합니다. 실제 조회에 사용할 서버, 조회 전략과 아웃바운드 경로는 여전히 DNS 설정이 결정합니다. 실제 조회가 시간 초과되면 애플리케이션에서는 임시 주소 연결 실패처럼 보일 수 있으므로, 점검할 때 FakeDNS 매핑과 이후 조회 로그를 함께 확인해야 합니다.

프로토콜 스니핑도 TLS 핸드셰이크나 HTTP 요청에서 호스트 정보를 읽어 일부 트래픽의 도메인을 복원할 수 있지만, 트래픽에 식별 가능한 필드가 있어야 합니다. FakeDNS는 연결이 설정되기 전에 매핑을 통해 도메인을 복원하므로 두 기능은 작동 단계가 다릅니다. 하나를 활성화했다고 다른 하나까지 반드시 켜야 하는 것은 아닙니다. 모든 관련 옵션을 동시에 켜기보다 로그에서 실제로 어떤 정보가 누락되는지에 따라 설정하세요.

FakeDNS가 필요한지 판단하려면 먼저 명확한 도메인 규칙 하나를 선택하세요. 비활성화 상태에서 TUN 연결이 IP 규칙에만 일치하는지 관찰한 다음 FakeDNS를 활성화하고 애플리케이션 캐시를 삭제한 뒤 새 연결을 만드세요. 로그에서 도메인이 복원되고 예상한 아웃바운드에 일치하는지 확인합니다. 도메인이 이미 안정적으로 코어에 전달된다면 FakeDNS를 추가로 활성화해도 효과는 제한적입니다.

6. 다중 구독 관리 및 업데이트 운영

다중 구독 관리의 핵심은 더 많은 주소를 가져오는 것이 아니라 업데이트, 필터링, 전환과 복구 과정을 추적 가능하게 만드는 데 있습니다. 각 구독에는 독립적인 경계와 명확한 용도가 있어야 합니다.

이름 지정, 업데이트 및 책임 분리

구독 이름에는 “일상 주력”, “임시 테스트”, “수동 보관”처럼 용도와 출처 유형을 포함하는 것이 좋습니다. 업데이트 시간을 이름에 넣지 마세요. 시간은 빠르게 오래되고 자동화된 필터링도 어렵게 만듭니다. 같은 출처에서 서로 다른 프로토콜이나 용도의 구독을 제공하더라도 별도로 가져와 각 그룹을 독립적으로 업데이트하고 중지할 수 있게 하세요.

모든 그룹에 똑같이 짧은 주기의 자동 업데이트를 적용하는 것은 적합하지 않습니다. 주력 그룹은 안정적인 주기로 업데이트하고 테스트 그룹은 수동으로 실행하세요. 당분간 사용하지 않는 그룹은 주소를 보존한 채 자동 업데이트만 끌 수 있습니다. 업데이트할 때 클라이언트가 구독 주소에 접근해야 하므로 “구독 업데이트 시 프록시 사용” 또는 해당 옵션이 현재 네트워크와 일치하는지 확인하세요. 현재 서버가 작동하지 않을 때 그 서버에 의존해 구독을 업데이트하면 순환 문제가 생길 수 있으므로, 업데이트 주소에 직접 접근할 수 있는 경로 또는 수동으로 복구 가능한 기존 설정을 남겨 두세요.

일괄 업데이트를 실행하기 전에 그룹 하나만 따로 업데이트하고 결과를 관찰하세요. 성공 표시 여부뿐 아니라 항목 수의 이상 여부, 비고 변경 여부, 프로토콜 필드의 완전성, 필터의 정상 일치 여부도 확인해야 합니다. 원격 구독 형식이 바뀌면 클라이언트가 다운로드는 완료했지만 파싱 결과가 비어 있을 수 있습니다. 성공적으로 가져온 것과 서버 목록을 성공적으로 생성한 것은 같은 의미가 아닙니다.

중복 제거 및 충돌 처리

서로 다른 구독에는 주소, 포트와 프로토콜은 같지만 비고가 다른 항목이 포함될 수 있고, 비고는 같지만 전송 매개변수가 다를 수도 있습니다. 비고만 기준으로 중복을 제거하면 유효한 설정을 삭제하기 쉽고, 주소만 기준으로 하면 포트, 사용자 식별자, 전송 계층과 보안 매개변수를 놓치게 됩니다. 장기적으로 관리할 때는 프로토콜, 주소, 포트, 인증 필드, 전송 방식과 보안 설정을 하나의 설정 지문으로 보고 클라이언트에 실제로 표시되는 필드를 항목별로 비교하세요.

중복 항목을 발견해도 출처를 바로 삭제할 필요는 없습니다. 먼저 어느 그룹이 장기 업데이트를 담당할지, 다른 그룹이 임시 백업인지 확인하세요. 단일 항목을 삭제해도 다음 구독 업데이트에서 다시 나타날 수 있으므로, 실제 관리 지점은 보통 그룹 필터나 구독 출처입니다. 비고가 충돌하면 클라이언트가 허용하는 범위에서 그룹 접두사를 사용해 구분하고, 원격으로 생성된 핵심 매개변수는 수정하지 않는 것이 좋습니다.

안전한 복구와 이전

구독 출처를 바꾸거나 광범위한 필터를 조정하기 전에 현재 클라이언트 설정과 라우팅 설정을 먼저 내보내세요. 내보낸 파일에는 구독 주소와 서버 인증 정보가 포함될 수 있으므로 관리되는 장소에 보관하고 공개 공유는 피해야 합니다. 복구할 때는 새 그룹으로 먼저 가져오고 현재 사용 중인 그룹을 직접 덮어쓰지 마세요. 연결, 라우팅과 DNS를 확인한 뒤 이전 출처를 중지합니다.

장치 간 이전 시에는 “서버 설정”과 “클라이언트 기본 설정”을 구분해야 합니다. 서버 링크에는 일반적으로 시스템 프록시 모드, TUN 매개변수, 라우팅 규칙, DNS, 자동 시작과 화면 필터 등의 설정이 포함되지 않습니다. 구독만 가져온다고 작업 환경 전체가 복제되지는 않습니다. 구독 그룹, 현재 서버, 라우팅 규칙, DNS, TUN, 자동 업데이트 주기와 사용자 지정 아웃바운드를 각각 기록한 이전 목록을 사용하는 것이 좋습니다.

v2rayN은 Windows, macOS 및 Linux 데스크톱 환경에 적합하며, Android에서는 v2rayNG 또는 필요에 따라 v2flyNG를 사용할 수 있습니다. 클라이언트마다 메뉴 구조와 가져올 수 있는 필드가 완전히 같지는 않습니다. 라우팅을 이전할 때는 전체 데스크톱 설정을 그대로 사용할 수 있다고 가정하지 말고 대상 클라이언트가 지원하는 규칙 표현으로 변환해야 합니다. 클라이언트 진입점과 플랫폼 안내는 다운로드 페이지에서 확인할 수 있습니다.

7. 사용자 지정 아웃바운드와 체인 선택

아웃바운드는 연결이 코어를 빠져나가는 최종 방식을 정의합니다. 일반적인 태그에는 프록시, 직접 연결과 차단이 있습니다. 사용자 지정 아웃바운드의 핵심은 태그가 고유하고 참조가 일관되며 순환이 발생하지 않도록 하는 것입니다.

아웃바운드 태그와 라우팅 참조

각 아웃바운드는 tag를 통해 라우팅 규칙에서 참조됩니다. 태그는 proxy, direct, block 또는 dns-out처럼 짧고 안정적인 영문 이름을 사용하세요. 태그를 변경하면 모든 라우팅 규칙, DNS 아웃바운드 참조, 체인 프록시 설정과 통계 정책도 함께 수정해야 합니다. 시작 로그의 “아웃바운드를 찾을 수 없음” 오류는 대개 철자 불일치 또는 설정 병합 과정에서 태그가 덮어써진 경우에 발생합니다.

직접 연결 아웃바운드는 로컬 네트워크에서 직접 연결을 수립할 때 사용하고, 차단 아웃바운드는 일치한 트래픽을 명시적으로 거부할 때 사용합니다. 차단 규칙은 정확하게 유지하고 전체 도메인이나 특정 포트부터 테스트하세요. 범위가 지나치게 넓으면 일반 연결이 명확한 오류 대신 응답 없음으로 보일 수 있습니다. 프록시 아웃바운드는 보통 현재 서버 설정에서 생성되므로 수동 편집할 때 전송, 보안과 인증 필드를 빠뜨리지 마세요.

{
  "outbounds": [
    {
      "protocol": "freedom",
      "tag": "direct",
      "settings": {
        "domainStrategy": "UseIP"
      }
    },
    {
      "protocol": "blackhole",
      "tag": "block",
      "settings": {
        "response": {
          "type": "none"
        }
      }
    }
  ]
}

freedom 아웃바운드의 domainStrategy는 직접 연결 단계에서 도메인을 처리하는 방식을 결정합니다. 라우팅 단계에서 이미 조회를 마쳤다면 아웃바운드가 얻은 주소를 직접 사용할 수 있고, 도메인이 남아 있다면 아웃바운드가 정책에 따라 조회합니다. 이 설정은 전역 DNS 및 라우팅 정책과 조정해 같은 도메인이 단계마다 서로 다른 결과를 얻지 않도록 해야 합니다.

사용자 지정 아웃바운드의 실제 용도

독립적인 직접 연결 아웃바운드는 특정 인터페이스나 주소에 연결해 여러 네트워크 카드 환경에서 사용할 수 있습니다. 독립적인 차단 아웃바운드는 명확히 필요하지 않은 대상을 처리할 수 있고, DNS 전용 아웃바운드는 조회 요청을 지정된 경로로 보낼 수 있습니다. 아웃바운드를 하나 추가할 때마다 진입 규칙, 의존 조건과 폴백 방식을 기록하세요. 아웃바운드만 있고 이를 참조하는 라우팅 규칙이 없다면 연결에 자동으로 참여하지 않습니다.

여러 네트워크 카드를 바인딩할 때 선택한 소스 주소가 실제 활성 인터페이스에 속하는지 확인하세요. 네트워크가 바뀌면 이전 주소가 무효화되어 바인딩된 아웃바운드만 연결되지 않을 수 있습니다. 여러 네트워크를 오가는 장치에서는 쉽게 바뀌는 소스 주소를 고정하지 않는 것이 좋습니다. 더 안정적인 방법은 시스템 라우팅으로 출구를 결정하고, 인터페이스 분리가 꼭 필요할 때만 바인딩하는 것입니다.

체인 아웃바운드와 순환 위험

체인 프록시는 한 아웃바운드의 연결을 다시 다른 아웃바운드를 통해 수립하는 방식입니다. 명확한 상위 경로가 있는 환경에 적합하지만 핸드셰이크, 조회와 장애 지점이 늘어납니다. 설정하기 전에 각 구간이 독립적으로 작동하는지 먼저 확인한 뒤 경로를 조합하세요. 기본 아웃바운드 자체가 불안정하면 체인 설정은 오류를 더 판단하기 어렵게 만들 뿐입니다.

체인 관계는 폐쇄 루프를 만들 수 없습니다. 예를 들어 A가 B를 통해 연결되는데 B의 연결이 다시 A로 라우팅되면 실패할 때까지 재귀가 반복됩니다. 순환을 피하려면 상위 서버 주소에 더 정밀한 직접 연결 또는 지정 아웃바운드 규칙을 설정하고 일반 프록시 규칙보다 앞에 배치해야 합니다. 상위 주소가 도메인이라면 해당 도메인의 조회 요청이 어느 아웃바운드를 거치는지도 고려하세요.

체인 아웃바운드를 테스트할 때는 먼저 로그에서 연결 순서를 확인한 다음 대상 요청과 상위 연결이 각각 어느 규칙에 일치하는지 확인하세요. 최종 페이지가 열리는지만으로 설정이 올바르다고 판단하지 마세요. 시스템이 예상한 경로를 우회해 기본 아웃바운드를 사용할 수도 있습니다. 기본 폴백을 끄고 짧게 테스트하면 누락된 설정을 찾는 데 도움이 되지만, 테스트가 끝나면 관리 가능한 기본 경로를 복원해야 합니다.

전체 사용자 지정 설정을 작성하기 전에 v2rayN이 자동 생성한 설정을 비교용으로 보관하는 것이 좋습니다. 먼저 생성 결과를 내보내고 outbounds, routing 및 dns 세 영역을 찾은 다음 최소한의 변경으로 새 태그를 추가하세요. 저장 후 코어 시작 로그를 확인해 설정 파싱이 성공했는지 확인합니다. 시작에 실패하면 최근에 추가한 영역 하나부터 되돌리고 전체 구조를 동시에 다시 작성하지 마세요.

8. 설정 검증, 로그 확인 및 복구 절차

고급 설정을 완료한 뒤에는 단계별 테스트로 각 구성 요소가 작동하는지 확인해야 합니다. 테스트 순서는 설정 로드부터 시작해 조회, 라우팅, 아웃바운드와 시스템 적용 순서로 진행하세요.

먼저 코어가 설정을 수락했는지 확인하기

설정을 저장했다고 해서 코어가 새 설정을 사용한다는 뜻은 아닙니다. 첫 단계로 시작 로그를 확인해 설정 파일 파싱, 포트 충돌 여부, 참조된 아웃바운드 태그의 존재와 리소스 파일 읽기 상태를 점검하세요. 문법 오류는 보통 필드 위치나 주변 구조를 표시합니다. 오류가 발생하면 가장 최근 변경부터 되돌리되 JSON 쉼표, 배열과 객체 계층, 태그 철자 및 지원되지 않는 필드를 특히 확인하세요.

코어가 정상적으로 시작된 뒤 로컬 수신 포트와 시스템 프록시 대상이 일치하는지 확인하세요. 클라이언트 상태는 실행 중인데 애플리케이션이 연결되지 않는다면 시스템 프록시가 이전 포트를 가리키거나 다른 프로그램이 수신 주소를 사용 중일 수 있습니다. TUN 모드에서는 가상 인터페이스가 생성되고 라우팅 테이블이 기록되었는지, DNS 가로채기가 실패하지 않았는지도 확인해야 합니다.

단계별로 테스트하고 하나의 결과로 모든 결론을 대신하지 않기

첫 번째 단계에서는 구독과 서버 설정을 테스트합니다. 연결 가능한 것으로 확인된 항목 하나를 선택하고 라우팅을 최소화해 사용하세요. 두 번째 단계에서는 DNS를 테스트합니다. 직접 연결 도메인과 프록시 도메인을 각각 조회하고 반환된 유형과 사용된 조회기를 기록합니다. 세 번째 단계에서는 라우팅을 테스트합니다. 전체 도메인 하나에 임시 규칙을 추가하고 로그에서 일치 여부를 확인하세요. 네 번째 단계에서는 시스템 적용을 테스트합니다. 먼저 시스템 프록시를 사용한 뒤 TUN을 활성화합니다. 각 단계가 통과된 후 다음 설정을 추가하세요.

지연 시간 테스트는 특정 시점에 특정 탐색 방식이 응답을 받았는지만 보여 주며 실제 연결을 대신할 수 없습니다. 일부 서버는 실제 프로토콜 연결은 허용하지만 단순 탐색에는 응답하지 않을 수 있고, 탐색은 정상이어도 대상 연결은 실패할 수 있습니다. 설정을 판단할 때는 목록의 단일 상태만 보지 말고 코어 로그, 연결 수립 결과와 애플리케이션 동작을 함께 확인하세요.

규칙을 변경한 뒤에는 새 연결을 만들어야 합니다. 브라우저 연결 풀, DNS 캐시와 애플리케이션 백그라운드 프로세스가 이전 경로를 계속 재사용할 수 있습니다. 신뢰할 수 있는 테스트 방법은 테스트 애플리케이션을 닫고 연결이 해제될 때까지 기다린 뒤 다시 여는 것입니다. 필요하면 코어도 다시 시작하세요. 절전 후 복귀나 네트워크 전환 뒤에만 문제가 발생한다면 네트워크 상태 변화를 재현 단계에 포함해야 합니다.

최소 사용 가능 설정 만들기

최소 설정에는 사용 가능한 서버 하나, 프록시 아웃바운드 하나, 직접 연결 아웃바운드 하나, 사설 주소 직접 연결 규칙과 명확한 기본 정책이 포함됩니다. DNS는 단순하고 접근 가능한 서버를 사용하며 FakeDNS, 체인 아웃바운드와 복잡한 프로세스 규칙은 일단 활성화하지 않습니다. 최소 설정이 정상 작동하면 “구독 필터, 도메인 라우팅, 조건부 DNS, TUN, FakeDNS, 사용자 지정 아웃바운드” 순서로 항목을 하나씩 복원하세요.

항목을 하나 복원할 때마다 변경 내용, 테스트 대상과 결과를 기록하세요. 설정 노트에는 인증 필드를 저장할 필요가 없으며 옵션, 태그와 규칙 순서만 기록하면 됩니다. 그러면 이후 코어 업데이트나 장치 이전 시 문제가 버전 동작 변화, 시스템 네트워크 변화 또는 로컬 규칙 조정에서 비롯되었는지 판단할 수 있습니다.

검증 목록
1. 코어 시작 로그에 설정 파싱 오류가 없음
2. 현재 서버와 로컬 수신 포트가 올바름
3. DNS 조회가 예상한 주소 유형을 반환함
4. 테스트 도메인이 예상한 라우팅 규칙에 일치함
5. 대상 연결이 올바른 아웃바운드로 전달됨
6. 시스템 프록시를 끈 뒤 네트워크가 복구됨
7. TUN을 끈 뒤 가상 인터페이스와 임시 라우팅이 제거됨

일반적인 현상별 점검 방향

모든 애플리케이션이 연결되지 않는다면 먼저 코어, 수신 포트와 서버 설정을 확인하세요. 특정 애플리케이션 하나만 이상하다면 시스템 프록시를 읽는지, DNS를 자체 조회하는지, UDP를 사용하는지 점검합니다. 로컬 네트워크만 이상하다면 사설 네트워크 대역 직접 연결과 엄격한 라우팅을 확인하세요. 도메인 규칙이 일치하지 않으면 애플리케이션이 IP만 전달하는지, FakeDNS 또는 스니핑으로 도메인을 복원할 수 있는지 확인합니다. 구독 업데이트는 성공했지만 목록이 비어 있다면 조회 결과와 그룹 필터를 점검하세요.

로그 정보가 부족하다면 짧은 시간 동안 로그 수준을 높여 재현하고, 연결 전체 과정을 한 번 기록한 뒤 일반 수준으로 되돌리세요. 로그를 장기간 지나치게 자세하게 유지하면 파일 용량이 커지고 중요한 오류가 정상 기록에 묻힐 수 있습니다. 로그를 공유하기 전에는 구독 주소, 사용자 식별자, 서버 인증 매개변수와 로컬 파일 경로를 제거하세요.

원인을 계속 찾지 못했다면 먼저 FAQ 문제 해결을 확인하고, 이어서 v2rayN 메인 화면 기능 한눈에 보기와 비교해 설정 위치를 확인하세요. 프로토콜 필드 간 차이는 VMess, VLESS, Trojan 및 Shadowsocks 비교를 참고할 수 있습니다. 문제를 제보할 때는 운영체제, 클라이언트 이름, 적용 모드, 재현 단계와 정리된 오류 로그를 포함하고 “사용할 수 없음”이라고만 작성하지 마세요.