V2Ray 설정 파일 완벽 가이드

listen, port와 노출 범위

인바운드 객체에서 먼저 확인할 것은 listen과 port입니다. 데스크톱 클라이언트가 로컬 애플리케이션에 프록시를 제공할 때는 보통 127.0.0.1에서 수신하며, 이는 현재 기기에서만 연결할 수 있음을 뜻합니다. 수신 주소를 외부 네트워크 인터페이스에 노출되는 주소로 바꾸면 접근 범위가 달라지고 로컬 네트워크 경계, 시스템 방화벽과 인증을 함께 고려해야 합니다. 브라우저, 터미널 또는 로컬 소프트웨어에만 프록시를 제공한다면 수신 범위를 넓힐 필요가 없습니다.

포트는 다른 프로세스가 사용하고 있지 않아야 합니다. 동일한 설정의 두 인바운드도 같은 주소에서 같은 포트를 수신할 수 없습니다. 일반적인 클라이언트는 SOCKS와 HTTP 인바운드를 각각 만들거나 혼합 인바운드를 지원합니다. 시스템 프록시는 보통 HTTP 인바운드를 사용하며, SOCKS를 명시적으로 지원하는 애플리케이션은 SOCKS 포트를 직접 입력할 수 있습니다. 애플리케이션이 HTTP 요청을 SOCKS 포트로 보내면 로그에 핸드셰이크를 인식하지 못했다는 메시지, 연결 종료 또는 잘못된 요청 형식이 나타날 수 있습니다. 이는 원격 노드 문제가 아니라 로컬 인바운드 프로토콜을 잘못 입력한 경우입니다.

SOCKS 인바운드와 UDP

{
  "tag": "socks-in",
  "listen": "127.0.0.1",
  "port": 10808,
  "protocol": "socks",
  "settings": {
    "auth": "noauth",
    "udp": true,
    "ip": "127.0.0.1"
  },
  "sniffing": {
    "enabled": true,
    "destOverride": ["http", "tls"],
    "routeOnly": true
  }
}

auth는 SOCKS 인바운드의 인증 방식을 제어하며, 루프백 주소에서만 수신할 때는 noauth를 자주 사용합니다. udp는 SOCKS UDP 요청을 받을지 결정합니다. 이 옵션을 켠다고 해서 모든 애플리케이션이 자동으로 UDP를 프록시로 전달하는 것은 아닙니다. 애플리케이션 자체가 SOCKS UDP를 지원해야 하며 원격 프로토콜과 전송 경로도 해당 트래픽을 처리할 수 있어야 합니다. ip는 UDP 연관 응답 주소에 사용되므로 실제 접근 방식과 일치해야 합니다. 로컬 인바운드에는 루프백 주소를 입력하는 것이 직관적이지만, 다른 기기를 대상으로 한다면 해당 주소에 요청 측이 접근할 수 있는지 다시 확인해야 합니다.

HTTP 인바운드와 시스템 프록시

{
  "tag": "http-in",
  "listen": "127.0.0.1",
  "port": 10809,
  "protocol": "http",
  "settings": {
    "allowTransparent": false
  },
  "sniffing": {
    "enabled": true,
    "destOverride": ["http", "tls"],
    "routeOnly": true
  }
}

HTTP 인바운드는 일반 프록시 요청과 CONNECT 터널 요청을 처리하므로 브라우저 및 시스템 프록시 설정을 따르는 소프트웨어에 적합합니다. 이는 웹사이트 서버가 사용하는 HTTP 서비스와 다릅니다. 애플리케이션이 해당 포트가 프록시 포트임을 명확히 인식해야 합니다. 터미널 명령, 개발 도구와 백그라운드 서비스는 데스크톱 시스템 프록시를 읽지 않을 수 있으므로 브라우저가 연결된다고 해서 모든 프로그램이 이 인바운드를 거친다고 볼 수 없습니다. '웹페이지는 정상인데 명령줄은 직접 연결되는' 경우 먼저 대상 프로그램의 프록시 옵션이나 환경 변수를 확인한 다음 V2Ray 설정을 점검하세요.

sniffing의 역할과 한계

트래픽 스니핑은 일부 연결에서 대상 도메인을 복원하여 도메인 라우팅 규칙이 적용될 가능성을 높입니다. TLS 연결을 예로 들면 애플리케이션이 로컬에서 도메인을 먼저 해석한 뒤 IP 주소로 연결할 수 있습니다. 이때 인바운드가 IP만 확인하면 단순한 도메인 규칙은 일치하지 않을 수 있습니다. sniffing을 활성화하면 커널이 핸드셰이크 정보에서 대상 도메인을 식별할 수 있습니다. destOverride는 식별을 허용할 프로토콜 유형을 지정하고, routeOnly는 식별 결과를 주로 라우팅 판단에 사용하며 최종 연결 대상을 강제로 바꾸지는 않습니다.

스니핑은 범용 복호화 기능이 아니며 모든 연결에서 식별 가능한 도메인을 보장하지도 않습니다. 비표준 프로토콜, 암호화 핸드셰이크 변경, 애플리케이션의 자체 캡슐화 또는 IP 직접 접속에서는 IP 조건만 남을 수 있습니다. 라우팅을 구성할 때는 도메인 규칙과 IP 규칙을 함께 고려해야 하며, 모든 판단을 스니핑 결과에 의존해서는 안 됩니다. 특정 애플리케이션에서 스니핑 활성화 후 이상이 발생하면 해당 인바운드에서 스니핑을 끄거나 별도의 인바운드 태그로 분리해 입구별 라우팅 규칙을 적용하세요.

여러 인바운드의 협업 방식

여러 인바운드의 가장 유용한 용도는 트래픽 출처를 구분하는 것입니다. 예를 들어 브라우저에는 http-in을, 개발 도구에는 socks-in을 할당한 뒤 inboundTag로 두 인바운드에 서로 다른 라우팅을 적용할 수 있습니다. 이는 도메인만 보고 애플리케이션 출처를 추측하는 것보다 안정적입니다. 각 인바운드에는 명확한 태그를 지정하고 클라이언트 인터페이스, 시스템 프록시와 애플리케이션 설정에서 포트를 일치시켜야 합니다. v2rayN에서 로컬 포트를 변경해도 기존 시스템 프록시 값이나 터미널 환경 변수가 반드시 함께 바뀌지는 않습니다. 문제를 해결할 때는 수신 로그와 애플리케이션 측 설정을 모두 확인하세요.

규칙은 위에서 아래로 대조됩니다

routing.rules는 순서가 있는 배열입니다. 요청이 라우터에 도착하면 규칙을 보통 위에서 아래로 확인하며, 먼저 일치한 규칙이 대상 아웃바운드를 결정합니다. 따라서 범위가 좁고 의도가 명확한 규칙을 앞에, 범위가 넓은 규칙을 뒤에 배치해야 합니다. 예를 들어 로컬 네트워크 직결은 광범위한 프록시 규칙보다 앞에, 특정 도메인 차단은 일반 도메인 프록시 규칙보다 앞에 둡니다. 모든 포트 프록시 규칙을 맨 앞에 두면 뒤의 로컬 네트워크 직결 규칙은 적용될 기회를 잃습니다.

규칙의 type은 보통 field를 사용하고, 이어서 domain, ip, port, network, protocol, inboundTag 등의 조건으로 대상을 설명합니다. 하나의 규칙에 여러 조건이 포함되면 조건을 조합해 모두 충족해야 일치하며, 동일 필드의 여러 값은 보통 그중 하나만 일치해도 됩니다. 서로 관계없는 조건을 하나의 규칙에 넣으면 예상보다 범위가 좁아질 수 있습니다. 더 명확한 방법은 여러 규칙으로 나누고 각 규칙에 하나의 목적만 부여하는 것입니다.

자주 사용하는 기본 트래픽 분할 구조

{
  "routing": {
    "domainStrategy": "IPIfNonMatch",
    "domainMatcher": "hybrid",
    "rules": [
      {
        "type": "field",
        "ip": ["geoip:private"],
        "outboundTag": "direct"
      },
      {
        "type": "field",
        "domain": ["geosite:private"],
        "outboundTag": "direct"
      },
      {
        "type": "field",
        "protocol": ["bittorrent"],
        "outboundTag": "direct"
      },
      {
        "type": "field",
        "domain": [
          "domain:example.net",
          "full:status.example.org"
        ],
        "outboundTag": "proxy"
      }
    ]
  }
}

geoip:private는 일반적인 사설 주소 범위와 일치하므로 라우터, 프린터와 로컬 네트워크 서비스에 접속할 때 원격으로 우회하지 않게 하는 데 적합합니다. geosite:private는 해당 사설 도메인 모음을 처리합니다. GeoIP와 GeoSite는 서로 다른 데이터 출처입니다. 전자는 IP 범위로 분류하고 후자는 도메인 집합으로 분류합니다. 데이터 파일이 오래되면 분류 결과가 최신 상태와 어긋날 수 있으므로 업데이트 방법은 GeoIP 및 GeoSite 데이터 파일 업데이트 방법을 참고하세요.

domain:은 지정한 도메인과 하위 도메인을 일치시키고, full:은 완전한 호스트 이름만 일치시키며, keyword:는 키워드로 일치시킵니다. 정확한 서비스에는 full:을 우선 사용하고, 사이트와 하위 도메인을 함께 지정할 때는 domain:을 사용할 수 있습니다. 키워드는 범위가 넓어 이름이 비슷하지만 관계없는 도메인까지 잘못 일치할 수 있으므로 로그로 확인한 명확한 범위에 적합합니다. 규칙의 일반 문자열은 커널 설정 문맥에 따라 기본 해석이 달라질 수 있으므로 수동 설정에서는 접두사를 사용해 모호함을 줄이세요.

domainStrategy가 도메인 및 IP 규칙에 미치는 영향

AsIs는 라우팅 단계에서 원래 대상을 기준으로 처리하려고 합니다. 요청이 도메인으로 들어오면 도메인 규칙이 대조에 참여할 수 있지만, IP만 포함된 요청에서는 도메인 이름을 임의로 복원할 수 없어 도메인 규칙이 보통 적용되지 않습니다. IPIfNonMatch는 도메인 규칙이 일치하지 않을 때 도메인을 해석한 뒤 IP 규칙을 시도합니다. IPOnDemand는 IP가 필요한 규칙을 만났을 때 더 일찍 해석을 시작할 수 있습니다. 전략에 따라 DNS 조회 시점, 라우팅 일치 여부와 연결 시간이 달라지므로 이름만 보고 선택해서는 안 됩니다.

도메인 집합을 우선하고 IP 지리 규칙을 보완으로 사용하려면 IPIfNonMatch가 보통 이해하기 쉽습니다. 먼저 도메인을 확인하고 일치하지 않을 때 해석한 뒤 IP를 확인합니다. IP 규칙이 많고 주소를 일찍 확보해야 한다면 IPOnDemand를 검토할 수 있습니다. 라우터가 규칙 대조를 위해 능동적으로 해석하는 것을 원하지 않는다면 AsIs를 사용하되, 인바운드 스니핑이나 애플리케이션 요청에 충분한 대상 정보가 제공되는지 확인하세요.

포트, 네트워크와 인바운드 태그별 트래픽 분할

{
  "type": "field",
  "inboundTag": ["socks-in"],
  "network": "tcp",
  "port": "443",
  "outboundTag": "proxy"
}

포트는 단일 값이나 범위로 작성할 수 있으며 예시는 80,443, 10000-20000과 같습니다. 포트는 대상 서비스의 포트만 설명할 뿐 특정 웹사이트나 애플리케이션을 의미하지 않습니다. 많은 서비스가 443 포트를 공유하므로 포트만으로 분할하면 범위가 지나치게 넓어질 수 있습니다. network는 TCP와 UDP를 구분하고, inboundTag는 요청이 들어온 로컬 인바운드에 따라 분할합니다. 소프트웨어별로 독립 인바운드를 만든 뒤 인바운드 태그를 사용하는 방식이 프로세스 이름을 추측하는 것보다 범용적입니다.

규칙 불일치와 잘못된 일치

어떤 규칙도 일치하지 않으면 요청은 기본 아웃바운드로 이동합니다. 기본 동작은 설정 구조와 커널 구현을 통해 확인해야 하며, 반드시 직결이거나 반드시 프록시라고 가정하지 마세요. 문제를 해결할 때는 먼저 적절한 수준의 실행 로그를 켜고 요청 대상, 인바운드 태그와 최종 아웃바운드 태그를 기록합니다. 규칙이 일치하지 않으면 요청에 도메인과 IP 중 무엇이 포함되었는지, 도메인 스니핑이 작동하는지, Geo 데이터가 존재하는지와 규칙 접두사가 올바른지 확인하세요. 잘못 일치하면 배열의 처음부터 내려오며 해당 대상을 포괄할 수 있는 첫 번째 규칙을 찾습니다.

라우팅을 조정한 뒤에는 명확한 대상 몇 가지로 각각 확인하세요. 로컬 네트워크 주소 하나, 직결할 도메인 하나, 프록시로 보낼 도메인 하나와 차단 대상 하나를 사용합니다. 대부분의 웹페이지가 열린다는 사실만으로 트래픽 분할이 올바르다고 판단하지 마세요. 기본 출구가 규칙 오류를 가릴 수 있습니다. 노드 속도 측정도 특정 테스트 요청의 연결 결과만 보여줄 뿐 하나씩 검증하는 과정을 대신할 수 없습니다. 시스템 프록시와 터미널의 경로가 다른 문제는 브라우저와 명령줄 터미널을 나누어 문제 해결하기를 참고하세요.

levels와 사용자 등급 참조

policy.levels는 사용자 등급을 키로 사용해 해당 등급의 연결에 정책을 설정합니다. 일부 인바운드나 아웃바운드 프로토콜의 사용자 객체에는 level을 지정할 수 있으며, 실행 시 같은 이름의 정책을 조회합니다. 등급은 속도 점수나 권한 순위를 자동으로 정하는 값이 아니라 정책 집합을 참조하기 위한 숫자 키일 뿐입니다. 사용자에게 등급을 명시하지 않으면 보통 기본 등급을 사용하지만, 정확한 기본 동작은 현재 설정과 커널 구현을 함께 확인해야 합니다.

동일한 등급으로 핸드셰이크 시간, 연결 유휴 시간과 업로드·다운로드 통계 등을 일괄 제어할 수 있습니다. '완전해 보이게' 하려고 참조되지 않는 등급을 대량으로 만들지 마세요. 클라이언트가 생성한 단일 사용자 아웃바운드에서는 통계가 활성화되어 있는지 또는 타임아웃이 변경되었는지 정도만 기본 등급에서 확인하면 충분한 경우가 많습니다. 서버의 다중 사용자 환경에서는 등급을 더 자주 구분하지만, 이 페이지는 클라이언트 설정 읽기에 초점을 두므로 정상 연결을 의도치 않게 짧게 끊는 정책이 없는지에 더 주의해야 합니다.

정책 객체 예제

{
  "policy": {
    "levels": {
      "0": {
        "handshake": 4,
        "connIdle": 300,
        "uplinkOnly": 2,
        "downlinkOnly": 5,
        "statsUserUplink": false,
        "statsUserDownlink": false,
        "bufferSize": 4
      }
    },
    "system": {
      "statsInboundUplink": true,
      "statsInboundDownlink": true,
      "statsOutboundUplink": true,
      "statsOutboundDownlink": true
    }
  },
  "stats": {}
}

handshake는 연결 수립 단계에서 기다릴 수 있는 시간을 제한합니다. 너무 짧게 설정하면 네트워크 변동, 이름 해석 또는 원격 핸드셰이크가 조금만 느려도 연결이 조기에 종료될 수 있으며, 너무 길면 접근할 수 없는 연결의 실패를 확인하기까지 오래 걸립니다. connIdle은 데이터 전송이 없을 때 연결을 유지할 수 있는 시간을 나타냅니다. 장시간 연결을 사용하는 애플리케이션, 푸시 메시지, 원격 터미널과 지속 전송 도구는 유휴 시간에 민감하므로 웹 브라우징 경험만으로 조정해서는 안 됩니다.

uplinkOnly와 downlinkOnly는 한 방향의 데이터만 남은 뒤 연결을 유지할 시간을 처리합니다. 이는 연결 수명 관리용이며 대역폭 제한을 의미하지 않습니다. bufferSize는 연결별 데이터 버퍼링 방식을 결정합니다. 무작정 크게 하면 메모리 사용량이 늘고, 지나치게 줄이면 처리량에 영향을 줄 수 있습니다. 대부분의 클라이언트 사용자는 커널이나 클라이언트가 제공하는 기본값을 유지하고, 로그와 재현 가능한 테스트에서 문제가 연결 수명과 관련된 것으로 확인될 때만 조정해야 합니다.

통계 스위치는 쌍으로 이해해야 합니다

statsUserUplink와 statsUserDownlink은 사용자 단위 통계를 제어하고, policy.system의 항목은 인바운드 및 아웃바운드 단위 통계를 제어합니다. "stats": {}만 작성한다고 모든 지표가 자동 수집되는 것은 아니며 해당 policy 스위치도 활성화해야 합니다. 반대로 통계를 켜도 이를 읽는 인터페이스나 API가 없다면 불필요한 기록 작업만 늘어납니다. 데스크톱 클라이언트가 트래픽 통계를 표시하는지는 커널을 어떻게 시작하고 통계 인터페이스를 읽는지에 따라 달라집니다.

통계 값은 현재 실행 인스턴스의 트래픽 방향을 관찰하는 데 적합하지만 구독 잔여량, 결제 기록이나 원격 서버 트래픽의 공식 출처로 사용해서는 안 됩니다. 클라이언트 재시작, 설정 재로드와 커널 전환으로 로컬 통계가 다시 시작될 수 있습니다. '인터페이스에 트래픽 숫자가 표시되지 않는' 문제를 해결할 때는 먼저 클라이언트가 하위 통계를 읽도록 설계되었는지 확인하고, 그다음 stats 객체와 system 스위치를 확인하세요. 프로토콜 매개변수부터 바로 수정하지 마세요.

policy와 타임아웃 오류의 관계

로그의 timeout은 이름 해석, TCP 연결, TLS 또는 REALITY 핸드셰이크, 프록시 프로토콜 핸드셰이크, 업무 데이터 읽기·쓰기 등 서로 다른 단계에서 발생할 수 있습니다. policy는 이 중 일부 세션 타임아웃만 설명합니다. 연결이 일정하고 매우 짧은 시간 뒤 끊긴다면 handshake와 connIdle을 확인하세요. 로그에 원격 주소 연결 타임아웃이 명확히 표시되면 먼저 네트워크와 아웃바운드를 점검하세요. 특정 애플리케이션의 장시간 연결만 주기적으로 끊긴다면 유휴 주기와 정책 값을 비교하세요.

타임아웃을 변경하기 전에 오류가 발생한 단계와 시간 패턴을 기록하세요. 모든 값을 무작정 크게 하면 오류 피드백이 늦어지고 실패한 연결이 리소스를 오래 점유합니다. 반대로 값을 일괄적으로 줄이면 느린 네트워크와 장시간 연결에 문제가 생깁니다. 기본 정책을 기준선으로 유지하고 재현 가능한 상황에서 한 항목만 조정한 뒤, 클라이언트를 재시작해 같은 대상을 다시 테스트하는 것이 바람직합니다.

시스템 정책과 설정 이식성

클라이언트와 커널 계열에 따라 지원하는 정책 필드나 기본값이 다를 수 있습니다. v2rayN이 사용하는 실행 커널, v2rayNG에서 흔히 사용하는 Xray 커널과 v2flyNG에 해당하는 v2fly 커널은 공통 필드 외에도 동작 차이가 있을 수 있습니다. 전체 설정을 다른 클라이언트로 복사하기 전에 대상 클라이언트가 완전한 사용자 지정 설정을 허용하는지, 시작할 때 policy를 다시 작성하는지 확인해야 합니다.

설정 이식성의 핵심은 필드를 적게 만드는 것이 아니라 표준 구조, 커널 확장과 클라이언트 생성 내용을 명확히 구분하는 데 있습니다. 인바운드 포트, 로그 경로와 TUN 매개변수는 플랫폼 환경에 종속되는 경우가 많고, 서버 프로토콜 매개변수는 대체로 이전할 수 있습니다. 클라이언트 인터페이스 상태와 실행 설정은 반드시 일대일로 대응하지 않습니다. 플랫폼을 옮길 때는 먼저 구독을 가져와 실행 가능한 기준선을 만든 다음 라우팅, DNS와 정책을 하나씩 이전하는 편이 전체 파일을 덮어쓰는 것보다 비호환 필드를 찾기 쉽습니다.

시작 실패: 먼저 문법, 포트와 참조를 확인

커널이 시작된 직후 종료된다면 보통 세 가지 문제를 먼저 확인해야 합니다. 첫째는 쉼표 누락, 괄호 불일치와 잘못된 데이터 형식을 포함한 JSON 문법 오류입니다. 둘째는 다른 프로세스가 수신 포트를 사용 중이거나 로그 디렉터리에 쓸 수 없거나 TUN 장치를 만들 수 없는 로컬 리소스 충돌입니다. 셋째는 라우팅 대상 태그가 존재하지 않거나 프로토콜 설정에 필수 필드가 빠졌거나 현재 커널이 특정 확장 항목을 인식하지 못하는 설정 객체 참조 오류입니다.

처리 순서는 로그와 일치해야 합니다. 해석 오류가 읽기 단계에서 발생했다면 먼저 파일을 수정하세요. 주소 사용 중 오류가 수신 단계에서 발생했다면 중복 클라이언트와 로컬 포트를 확인하세요. 아웃바운드를 찾지 못했다면 라우팅 구성 단계의 문제이므로 태그를 대조하세요. 커널이 명확히 실행 상태에 들어간 뒤에만 원격 연결 문제를 확인해야 합니다. 클라이언트 인터페이스에 '연결되지 않음'이 표시된다는 사실만으로는 어느 계층의 문제인지 판단할 수 없으므로 마지막 오류 로그를 확인해야 합니다.

로컬 포트는 있지만 애플리케이션에 트래픽이 없습니다

먼저 애플리케이션에 올바른 프록시 유형과 포트가 입력되었는지 확인하세요. HTTP 프록시와 SOCKS 프록시는 서로 다른 인바운드이며 시스템 프록시가 터미널과 백그라운드 서비스에서 자동으로 사용된다는 보장도 없습니다. 그다음 애플리케이션이 로컬 주소를 우회하는지, 자체 해석이나 프록시 설정을 사용하는지, 요청이 실제로 access 로그에 도착했는지 확인합니다. 로그에 이번 요청이 전혀 없다면 문제는 애플리케이션과 인바운드 사이에 있습니다. 로그에 인바운드 기록이 나타난 뒤에야 트래픽이 V2Ray에 들어온 것입니다.

일부 애플리케이션만 작동하지 않는다면 해당 애플리케이션에 명확한 SOCKS 또는 HTTP 인바운드를 설정해 비교하세요. 수동 인바운드는 작동하지만 시스템 프록시가 작동하지 않는다면 운영 체제의 프록시 상태와 제외 목록을 확인하세요. 시스템 프록시에서 브라우저는 작동하지만 터미널이 작동하지 않는다면 터미널 도구가 지원하는 프록시 옵션을 설정하세요. 한 애플리케이션이 시스템 프록시를 우회한다고 해서 원격 노드 프로토콜을 바꾸지는 마세요.

도메인은 실패하지만 IP는 작동함

이 현상에서는 먼저 해석 경로를 확인하세요. 애플리케이션이 도메인을 제출했는지 이미 해석된 IP를 제출했는지, 내장 DNS가 조회를 받았는지, 서버가 사용 가능한 주소를 반환했는지와 queryStrategy가 현재 네트워크에서 접근 가능한 주소 체계를 선택했는지 확인합니다. 도메인 규칙이 스니핑에 의존한다면 인바운드가 대상 이름을 식별할 수 있는지도 확인해야 합니다. Fake DNS를 사용한다면 예약 주소가 동일한 실행 인스턴스에서 복원되는지 확인하세요.

DNS가 이미 주소를 반환했지만 아웃바운드 단계에서 연결 타임아웃이 발생한다면 문제는 더 이상 '해석 결과가 없음'이 아니라 해당 주소의 연결 경로, 라우팅 또는 원격 서비스에 있습니다. 반환 주소가 expectIPs에서 예상과 맞지 않는 것으로 판정되면 Geo 데이터와 서버 그룹을 확인하세요. 방금 수정한 도메인만 계속 이전 주소를 사용한다면 애플리케이션, 시스템과 내장 캐시를 고려하고 관련 프로세스를 재시작하거나 새 도메인으로 테스트해 캐시 영향을 배제하세요.

규칙은 올바른 것처럼 보이지만 일치하지 않음

먼저 요청의 실제 형태를 확인하세요. 라우터가 완전한 도메인, 하위 도메인 또는 IP 중 무엇을 받았는지, 규칙이 full:, domain: 또는 키워드를 사용하는지, 앞에 더 넓은 규칙이 먼저 일치하지 않았는지와 Geo 데이터 파일을 사용할 수 있는지 확인합니다. 규칙 문구와 대상이 비슷해 보여도 일치 의미가 같다는 뜻은 아닙니다. full:example.com은 다른 하위 도메인과 일치하지 않으며 지나치게 넓은 키워드는 관계없는 여러 대상과 일치할 수 있습니다.

문제 규칙을 잠시 배열 앞쪽으로 옮기면 다른 규칙에 가려졌는지 판단하는 데 도움이 되지만, 테스트가 끝난 뒤에는 전체 순서를 다시 검토해야 합니다. 더 신뢰할 수 있는 방법은 라우팅 관련 로그를 활성화해 요청이 최종적으로 선택한 아웃바운드 태그를 기록하는 것입니다. 요청에 IP만 포함되어 있다면 도메인 규칙이 일치하지 않는 것이 자연스럽습니다. 이때는 같은 도메인 문자열을 계속 고치기보다 sniffing, 애플리케이션의 해석 방식 또는 적절한 IP 규칙 추가를 확인하세요.

노드 매개변수는 올바르지만 핸드셰이크 실패

먼저 서버 주소와 포트에 접근할 수 있는지 확인한 뒤 프로토콜 인증 매개변수, 전송 방식과 보안 계층을 대조하세요. TLS 환경에서는 서버 이름, 시스템 시간과 인증서 오류를 확인하고, REALITY 환경에서는 서버 이름, 공개 키, 짧은 식별자, 지문과 흐름 제어 매개변수를 확인하세요. 다른 프로토콜도 클라이언트 매개변수와 서버 설정을 항목별로 일치시켜야 합니다. 서로 다른 노드의 전송 필드를 섞어 하나의 설정을 만들지 마세요. 각 계층에 의존 관계가 있을 수 있습니다.

구독 업데이트 후 갑자기 실패한다면 이전 노드를 비교 대상으로 남겨 두고 업데이트로 주소, 포트, 전송 방식 또는 인증 매개변수가 바뀌었는지 확인하세요. 누락된 필드를 추측해 수동으로 입력하지 마세요. 모든 노드가 동시에 실패한다면 먼저 로컬 네트워크, 시스템 시간, 커널 시작과 라우팅을 확인해야 합니다. 하나의 노드만 실패할 때 해당 노드의 매개변수나 원격 상태에 문제가 있을 가능성이 더 큽니다.

설정이 점점 커진 뒤 정리하는 원칙

장기간 사용하면 설정에 작동하지 않는 태그, 중복 도메인 규칙, 서로 덮어쓰는 Geo 규칙과 더 이상 사용하지 않는 인바운드가 쌓이기 쉽습니다. 정리할 때는 먼저 현재 처리 체인을 그려 모든 인바운드 태그, 아웃바운드 태그, 각 규칙의 대상과 DNS 서버 용도를 나열하세요. 참조가 없는 것을 확인한 뒤 객체를 삭제합니다. 같은 대상과 같은 출구를 사용하는 규칙은 합칠 수 있지만, 행 수를 줄이려고 목적이 다른 조건을 설명하기 어려운 하나의 규칙에 넣지는 마세요.

태그에 안정적인 명명 규칙을 만들고 '특수 차단, 로컬 네트워크 직결, 특정 프록시, 기본 처리' 순서로 라우팅을 배열하는 것이 좋습니다. DNS 서버 객체는 적용 도메인 범위별로 그룹화하고 policy에는 실제 사용하는 등급만 남기세요. 설정 파일 자체가 주석을 지원하지 않는다면 별도의 유지 관리 기록에 각 태그의 용도, 마지막 검증 상황과 클라이언트 생성 방식을 적어 두세요. 나중에 필드를 보고도 조정하지 못하는 상황을 막을 수 있습니다.

클라이언트 업데이트와 설정 이전

클라이언트를 업데이트하기 전에 현재 실행 가능한 설정, 라우팅 프리셋과 구독 설정을 저장하세요. 업데이트 후에는 기존 노드로 최소 연결 테스트를 먼저 진행한 다음 고급 기능을 확인합니다. 클라이언트가 실행 커널을 바꿨다면 시작 로그의 알 수 없는 필드와 사용 중단 알림에 주의하세요. 인터페이스 옵션 이름이 바뀌었다고 하위 설정을 즉시 삭제하지 마세요. 먼저 새로 생성된 실행 파일을 내보내고 기존 설정과 최상위 구간별로 비교하세요.

데스크톱에서 다른 데스크톱 플랫폼으로 옮길 때 서버 프로토콜 매개변수는 보통 구독으로 복원할 수 있지만, 로컬 수신 포트, 시스템 프록시, TUN 권한과 로그 경로는 새 플랫폼에 맞게 다시 설정해야 합니다. Android에서 v2rayNG 또는 v2flyNG로 옮길 때도 먼저 구독을 가져온 뒤 대상 커널에 맞춰 라우팅과 DNS를 복원하세요. 플랫폼 차이는 주로 시스템 인계와 파일 위치에 있으므로 서버 아웃바운드에 플랫폼과 무관한 추측성 필드를 추가해서는 안 됩니다.

고정된 문제 해결 체크리스트 만들기

모든 장애를 이 네 계층 순서대로 기록하면 같은 작업을 반복하지 않을 수 있습니다. 로그에 rejected가 나타나면 거부가 로컬 인바운드, 라우팅 차단 또는 원격에서 발생했는지 확인하세요. timeout이 나타나면 타임아웃 단계를 확인합니다. 인증이나 핸드셰이크 오류가 나타나면 해당 아웃바운드 매개변수로 돌아가세요. 그래도 판단하기 어렵다면 문제 해결에서 기본 이해, 설치 및 설정, 고급 활용과 문제 해결 분류를 따라 계속 찾아보세요.

설정 유지 관리의 목표는 선택 필드를 가득 채우는 것이 아니라 각 구간의 역할을 명확히 하고 로그로 처리 결과를 입증할 수 있게 하는 것입니다. 먼저 단순하고 반복 검증이 가능한 기준선을 유지한 뒤 라우팅, DNS, TUN과 정책을 추가하세요. 문제가 생기면 복잡한 설정에서 무작위로 필드를 삭제하기보다 기준선으로 돌아가 계층별로 복원하는 편이 안정적입니다.