V2Ray 고급 설정 가이드

설정 기준선이 필요한 이유

v2rayN의 실제 연결 결과는 여러 계층의 설정이 함께 결정합니다. 구독은 서버 정보를 제공하고, 클라이언트는 활성 서버를 선택하며, 라우팅은 트래픽을 어느 아웃바운드로 보낼지 결정합니다. DNS는 도메인 해석 방식을 정하고, 시스템 프록시 또는 TUN은 어떤 애플리케이션 트래픽이 코어로 들어갈지 결정합니다. 어느 한 계층만 바뀌어도 “웹페이지가 열리지 않음”, “일부 프로그램만 적용됨”, “서버를 바꾸면 결과가 달라짐”처럼 나타날 수 있습니다. 라우팅, DNS, 트래픽 전달 방식을 한꺼번에 수정하면 문제가 발생했을 때 원인을 특정하기 어렵습니다.

먼저 최소한의 작동 기준선을 만드는 것이 좋습니다. 연결을 확인한 구독 그룹 하나만 남기고, 설정이 완전한 서버 한 대를 선택합니다. 라우팅은 클라이언트 기본 모드를 사용하고 DNS는 기본값으로 유지하며, 트래픽 전달 방식은 우선 시스템 프록시로 둡니다. 그런 다음 평소 사용하는 일반 웹사이트에 접속하고 v2rayN 로그에서 연결 수립, 도메인 해석 및 아웃바운드 선택 기록을 확인합니다. 복잡한 결과를 얻을 필요는 없습니다. 클라이언트, 코어, 서버와 로컬 네트워크가 하나의 경로를 구성하는지만 확인하면 됩니다.

기준선에는 특정 테스트에서 나온 순간적인 수치보다 설정 간의 관계를 기록해야 합니다. 현재 활성 그룹, 서버 별칭, 시스템 프록시 상태, 라우팅 모드 이름, DNS를 클라이언트가 처리하는지 여부, TUN 비활성화 상태와 로그에 기록된 마지막 정상 연결의 대략적인 시간을 적어 둘 수 있습니다. 서버 주소와 인증 정보 같은 민감한 내용은 공개 메모에 기록하지 마세요. 이전이 필요할 때는 클라이언트의 설정 내보내기 기능을 사용하고 파일을 안전한 위치에 보관해야 합니다.

단일 변수 방식으로 변경하기

기준선에서 시작해 매번 하나의 설정 주제만 변경하세요. 예를 들어 먼저 구독 그룹과 필터를 설정하고 업데이트와 선택이 정상인지 확인한 뒤 라우팅 규칙으로 넘어갑니다. 라우팅이 안정된 후 DNS를 조정하고, 마지막에 TUN 또는 FakeDNS를 활성화합니다. 한 단계가 끝날 때마다 최소한 세 가지를 확인하세요. 클라이언트 로그에 지속적인 오류가 없는지, 예상한 애플리케이션이 인터넷에 연결되는지, 전달 대상이 아닌 트래픽이 기존 경로로 계속 동작하는지 확인합니다. 이렇게 하면 설정이 실패해도 전체 설정을 초기화하지 않고 최근 변경만 바로 되돌릴 수 있습니다.

문제 해결 중에는 로그 수준을 info로 일시적으로 높이고, 라우팅 일치 세부 정보를 확인할 때만 더 상세한 수준을 사용하세요. 로그를 장기간 지나치게 자세하게 유지하면 읽기 어려워지고, 실제로 중요한 오류가 많은 연결 기록에 묻힐 수 있습니다. 확인이 끝나면 평소 수준으로 되돌리고 테스트를 위해 만든 임시 규칙을 정리하세요. 로그의 첫 번째 오류는 뒤이어 반복되는 오류보다 대개 더 중요합니다. 이후의 실패는 상위 문제에서 연쇄적으로 발생한 결과일 수 있기 때문입니다.

되돌릴 수 있는 작업 사본 만들기

큰 폭으로 수정하기 전에 v2rayN에서 현재 설정을 내보내거나 기존 라우팅 설정 집합을 복사한 뒤, “업무 기본 라우팅” 또는 “테스트-TUN-DNS”처럼 용도를 설명하는 이름을 붙이세요. 이름에는 사용 상황이 드러나야 하며 “새 설정”, “설정 2”처럼 쓰지 않는 것이 좋습니다. 클라이언트가 여러 라우팅 설정 집합을 지원한다면 실험적으로 수정하지 않은 기본 집합을 하나 보존하세요. 구독 업데이트는 이런 백업을 대신하지 않습니다. 구독에는 주로 서버 항목만 저장되며 로컬 라우팅, DNS, 시스템 프록시 및 사용자 지정 아웃바운드 설정이 포함되지 않을 수 있습니다.

설정을 확인할 때는 “클라이언트가 트래픽을 인계하지 않음”과 “트래픽이 클라이언트에 들어온 뒤 아웃바운드 연결에 실패함”을 구분해야 합니다. 전자는 보통 시스템 프록시, TUN, 애플리케이션 자체 프록시 설정을 확인하고, 후자는 서버, 라우팅, DNS 및 아웃바운드 경로를 확인합니다. 가장 직접적인 방법은 로그에 대상 도메인이나 대상 연결이 나타나는지 먼저 확인하는 것입니다. 관련 기록이 전혀 없다면 트래픽 인계 계층부터 거슬러 올라가며 점검하고, 기록은 있지만 해석 또는 연결 오류가 이어진다면 DNS와 아웃바운드 계층을 확인하세요. 기본적인 오류 현상은 도움말 센터에서도 확인해 애플리케이션 자체 문제를 코어 문제로 오해하지 않도록 하세요.

임시 상태가 아니라 소스별로 그룹 만들기

v2rayN에는 수동으로 추가한 서버와 여러 구독을 함께 저장할 수 있습니다. 안정적인 구성 방식은 “구독 하나당 그룹 하나”를 두고, 수동 설정은 “직접 만든 노드”와 같은 별도 그룹에 넣는 것입니다. 이렇게 하면 한 소스를 업데이트할 때 다른 소스의 항목을 잘못 삭제하지 않고, 서버 필드가 구독에서 왔는지 로컬에서 입력했는지도 빠르게 파악할 수 있습니다. 같은 제공업체가 용도별로 다른 구독 주소를 제공한다면 각각 이름을 달리하고 용도를 이름에 포함하세요. 업데이트 후 서버 별칭만 보고 출처를 추측하지 않는 편이 좋습니다.

그룹 이름은 “업무 구독”, “모바일 예비”, “직접 만든 노드”처럼 짧고 명확하게 유지하는 것이 좋습니다. 만료일, 특정 속도 측정 결과 또는 현재 활성 서버를 그룹 이름에 넣지 마세요. 이런 정보는 자주 바뀌어 이름이 금방 실제 상태와 달라집니다. 구독 메모에는 출처와 사용 범위를 적고 업데이트 시간은 클라이언트 기록에 맡기면 됩니다. 여러 기기에서 같은 서버 소스를 유지해야 한다면 컴퓨터와 휴대폰 등 여러 기기에서 V2Ray 설정을 동기화하는 세 가지 방법을 참고하세요. 구독 동기화와 단일 노드 전달은 적용 범위가 다릅니다.

업데이트, 정리 및 병합의 차이 이해하기

구독을 업데이트하면 클라이언트가 구독 응답에 따라 해당 그룹을 새로 고칩니다. 기존 항목을 유지할지는 클라이언트 설정과 업데이트 방식에 따라 달라지므로, 작업 전에 현재 선택된 그룹을 확인해야 합니다. 구독 소스에서 서버가 삭제됐는데 로컬에 이전 기록이 남아 있다면 업데이트 시 유지 옵션이 켜져 있거나, 같은 이름의 항목이 다른 그룹에서 온 것일 수 있습니다. 이때 같은 이름의 서버를 전체에서 바로 삭제하지 말고 그룹 열을 표시하거나 그룹 보기로 전환해 항목의 실제 출처를 먼저 확인하세요.

“이전 서버 정리”는 구독 내용이 크게 바뀐 경우에 적합하지만 해당 그룹에서 수동으로 수정한 메모에도 영향을 줍니다. 로컬 수정 내용을 보존해야 한다면 필요한 항목을 먼저 수동 그룹에 복사한 뒤 원래 구독을 새로 고치세요. 여러 구독을 병합하면 그룹 수는 줄어들지만 출처 경계가 사라집니다. 업데이트 실패 시 어느 구독에 문제가 있는지 판단하기 어려워지고, 이름이 같은 서버가 덮어써질 가능성도 커집니다. 상위 제공업체가 통합 구독을 제공하는 경우가 아니라면 클라이언트에서는 여러 독립 그룹을 유지하는 편이 좋습니다.

필터 표현식으로 목록 좁히기

서버 필터는 “항목은 많지만 자주 쓰는 범위는 좁은” 상황을 해결합니다. 일반적인 방법으로는 별칭 키워드로 유지하기, 프로토콜 이름으로 필터링하기, 키워드로 제외하기, 여러 조건을 함께 사용하기가 있습니다. 필터는 목록 표시나 후보 범위만 바꾸며 서버 설정을 수정하거나 구독 원본을 변경하지 않습니다. 필터를 설정하기 전에 서버 이름이 일정한지 확인하세요. 구독을 업데이트할 때마다 별칭 형식이 바뀐다면 이름에 의존하는 규칙도 함께 관리해야 합니다.

필터 표현식은 보통 일반 키워드 또는 정규 표현식을 지원합니다. 일반 키워드는 관리하기 쉬워 이름 구조가 단순한 구독에 적합하고, 정규 표현식은 여러 고정 단어를 동시에 검색할 때 유용하지만 이스케이프와 대소문자에 주의해야 합니다. 아래 표현식은 이름에 “업무” 또는 “예비”가 포함된 항목을 유지하고, “테스트”가 포함된 항목은 제외합니다. 구체적인 입력 위치는 클라이언트의 서버 필터 설정을 따르세요.

유지 표현식:
업무|예비

제외 표현식:
테스트

정규 표현식을 사용한다면 먼저 간단한 조합부터 시작하고, 처음부터 지나치게 긴 한 줄 표현식을 작성하지 않는 것이 좋습니다. 이름이 “업무-상하이-VLESS”, “예비-도쿄-Trojan”인 경우 ^(업무|예비)-로 고정 접두사를 일치시킬 수 있습니다. 이름에 괄호, 더하기 기호 또는 마침표처럼 정규 표현식에서 특별한 의미를 갖는 문자가 포함되면 이스케이프해야 합니다. 필터 결과가 비어 있으면 첫 단계로 제외 조건을 잠시 비우세요. 구독을 다시 가져오지 말고 항목이 복원되는지 확인한 다음 조건을 하나씩 추가해 과도하게 일치하는 위치를 찾습니다.

규칙이 위에서 아래로 일치한다는 점부터 이해하기

연결이 Xray 또는 V2Fly 코어에 들어오면 라우팅 모듈은 도메인, 대상 IP, 포트, 네트워크 유형, 인바운드 태그와 프로세스 정보 등의 조건으로 일치하는 규칙을 찾습니다. 일반적으로 처음 일치한 규칙이 아웃바운드를 결정하고 이후 규칙은 더 이상 적용되지 않습니다. 따라서 구체적인 예외 규칙은 앞에, 범위가 넓은 기본 규칙은 뒤에 배치해야 합니다. 예를 들어 특정 도메인은 프록시를 사용해야 하지만 해당 도메인 분류 전체가 기본적으로 직접 연결된다면, 구체적인 도메인 규칙을 분류 규칙보다 앞에 둬야 합니다.

일반적인 아웃바운드 태그에는 proxy, direct, block이 있지만 실제 이름은 클라이언트가 생성한 설정에 따라 달라집니다. 사용자 지정 규칙을 만들 때는 현재 설정에 실제로 존재하는 아웃바운드 태그를 사용해야 합니다. 태그 철자가 다르면 규칙이 예상한 아웃바운드를 가리키지 못합니다. 그래픽 인터페이스의 “프록시”, “직접 연결”, “차단”은 보통 이러한 태그로 변환됩니다. 전체 JSON을 가져오는 경우에는 라우팅 규칙과 outbounds 배열의 tag가 서로 대응하도록 직접 유지해야 합니다.

도메인 규칙과 IP 규칙의 역할

도메인 규칙은 연결에 도메인 정보가 남아 있을 때 작동하며, 전체 도메인, 서브도메인 접미사 또는 내장 도메인 분류에 따라 트래픽을 나눌 때 적합합니다. IP 규칙은 대상이 이미 주소로 해석됐거나 로컬 네트워크 및 예약 주소 대역을 처리해야 할 때 적합합니다. 도메인 스니핑을 활성화하면 처음에는 IP만 포함하던 일부 연결도 도메인 정보를 다시 얻어 도메인 라우팅에 참여할 수 있습니다. 하지만 스니핑이 모든 프로토콜과 애플리케이션에서 도메인을 복원한다고 보장할 수는 없으므로 중요한 규칙을 하나의 경로에만 의존해서는 안 됩니다.

domain:example.com은 일반적으로 해당 도메인과 서브도메인에 일치하고, full:api.example.com은 전체 이름에만 일치하며, regexp:는 정규 표현식 조건에 사용됩니다. 전체 도메인이나 접미사로 표현할 수 있는 규칙에는 정규 표현식을 사용할 필요가 없습니다. IP 규칙에는 CIDR을 사용할 수 있습니다. 예를 들어 192.168.0.0/16은 로컬 네트워크 주소 범위를 뜻합니다. 규칙에 등장하는 예시 도메인은 문법 설명용이므로 실제 사용 시 제어하려는 업무 도메인으로 바꿔야 합니다.

{
  "routing": {
    "domainStrategy": "IPIfNonMatch",
    "rules": [
      {
        "type": "field",
        "domain": [
          "full:api.example.com",
          "domain:assets.example.com"
        ],
        "outboundTag": "proxy"
      },
      {
        "type": "field",
        "ip": [
          "geoip:private"
        ],
        "outboundTag": "direct"
      },
      {
        "type": "field",
        "protocol": [
          "bittorrent"
        ],
        "outboundTag": "direct"
      }
    ]
  }
}

domainStrategy는 라우팅 단계에서 도메인을 언제 IP로 해석할지 결정합니다. AsIs는 도메인을 우선 유지하며 IP 규칙을 위해 적극적으로 해석하지 않습니다. IPIfNonMatch는 도메인 규칙이 일치하지 않을 때 해석한 뒤 IP 규칙을 다시 시도합니다. IPOnDemand는 IP가 필요한 규칙을 만났을 때 더 일찍 해석합니다. 일반적으로는 클라이언트 기본값을 먼저 사용하세요. 단지 “더 완전해 보인다”는 이유로 적극적인 해석 방식으로 바꾸면 DNS 요청 시점이 달라지고 문제 해결 경로가 복잡해질 수 있습니다.

소규모 규칙 집합으로 순서 검증하기

새 라우팅 집합을 만들 때는 먼저 세 종류의 규칙만 작성해도 됩니다. 반드시 프록시를 사용해야 하는 소수의 도메인, 로컬 네트워크 주소 직접 연결, 마지막 기본 아웃바운드입니다. 저장하고 적용한 뒤 브라우저로 일치하는 도메인에 접속하고 로그에서 일치한 아웃바운드 태그를 확인하세요. 검증이 끝난 후 도메인 분류, 포트 또는 프로세스 규칙을 추가합니다. 처음부터 사용자 지정 규칙 수백 개를 가져오면 특정 예외가 앞의 범용 조건에 걸리기 쉽고, 내장 데이터가 현재 코어와 맞는지도 판단하기 어렵습니다.

포트 규칙은 네트워크 유형과 함께 이해해야 합니다. 예를 들어 53만 작성하면 TCP와 UDP DNS 트래픽에 동시에 영향을 줄 수 있습니다. UDP만 제어해야 한다면 네트워크 조건도 함께 지정하세요. 프로세스 규칙은 클라이언트, 운영체제 권한 및 트래픽 인계 방식에 의존하므로 플랫폼마다 기능이 다를 수 있습니다. 소수 애플리케이션의 예외를 처리하는 데 적합하며, 도메인 및 IP 규칙을 대신하는 주요 분기 수단으로 사용해서는 안 됩니다. 애플리케이션을 업데이트하면 실행 파일 이름이 바뀌어 기존 프로세스 규칙이 작동하지 않을 수도 있습니다.

한 웹사이트가 여러 리소스 도메인을 사용한다면 주 도메인에만 라우팅을 설정할 경우 본문은 열리지만 이미지나 API가 실패할 수 있습니다. 이때는 개발자 도구나 클라이언트 로그에서 실패한 리소스의 도메인을 찾아 실제로 관련된 접미사만 규칙에 추가하세요. 모든 트래픽을 바로 프록시로 확대하지 않는 것이 좋습니다. VMess, VLESS, Trojan 및 Shadowsocks의 선택이 궁금하다면 프록시 프로토콜 비교 가이드를 참고하세요. 프로토콜은 연결 방식을 결정하고 라우팅은 연결을 어느 아웃바운드로 보낼지 결정하므로 두 설정을 혼동하지 않아야 합니다.

시스템 DNS와 코어 DNS 구분하기

시스템 DNS는 운영체제와 일반 애플리케이션이 기본으로 사용하는 해석 경로입니다. 코어 DNS는 Xray 또는 V2Fly 설정의 해석 모듈로, 주로 클라이언트에 들어온 연결, 라우팅 판단 및 특정 도메인 정책을 처리합니다. 시스템 프록시를 사용할 때 일부 애플리케이션은 시스템에서 먼저 해석한 뒤 대상 IP를 프록시에 전달할 수 있고, 다른 애플리케이션은 도메인을 유지한 채 프록시를 통해 요청할 수 있습니다. TUN을 활성화하면 DNS 요청이 코어에 의해 가로채일 수도 있습니다. 조회가 어디에서 시작되는지 먼저 판단하지 않고 코어 DNS만 수정하면 실제 문제에 영향을 주지 못할 수 있습니다.

문제 해결 시 로그에 대상 도메인의 해석 기록이 나타나는지 확인할 수 있습니다. 브라우저가 이미 도메인을 IP로 해석했고 스니핑으로 복원되지 않는다면 라우팅은 주소만 확인하게 되어 도메인 규칙이 일치하지 않을 수 있습니다. 반대로 코어가 도메인을 받아 직접 해석한다면 DNS 서버 선택, 조회 유형, 반환 주소와 이후 라우팅을 확인해야 합니다. 모든 해석 실패를 서버 탓으로 돌리지 마세요. 도메인 오탈자, 시스템 캐시, 애플리케이션 내장 보안 DNS, 라우팅 차단 및 불완전한 UDP 인계도 비슷한 현상을 만들 수 있습니다.

DNS 서버의 역할을 명확히 정의하기

관리하기 쉬운 설정은 대개 소수의 DNS 서버만 포함하고 각 서버의 처리 범위를 명확히 합니다. 기본 서버는 일반 조회를 처리하고 지정 서버는 특정 도메인을 처리하며, 필요한 경우에만 폴백을 설정합니다. 주소는 전통적인 UDP DNS일 수도 있고 HTTPS 기반 조회 주소일 수도 있습니다. 구체적인 지원 여부는 현재 코어와 클라이언트 설정 방식에 따라 달라집니다. 선택할 때는 같은 역할의 주소를 여러 개 쌓기보다 기존 라우팅과 호환되고 안정적으로 연결되는 서비스를 우선하세요.

DNS 서버 자체가 도메인으로 지정되면 “DNS 서버 도메인을 먼저 해석해야 하는” 시작 의존성이 생깁니다. 일반적인 해결 방법은 host 매핑을 제공하거나 직접 연결할 수 있는 주소를 사용하거나, 해당 서버 도메인을 해석할 부트스트랩 DNS를 지정하는 것입니다. 설정에 사용자 지정 아웃바운드가 있다면 DNS 조회가 직접 연결되는지 프록시를 거치는지도 확인하세요. 조회 경로와 대상 도메인 트래픽 경로는 다를 수 있지만, 그 차이는 명확하게 설계된 결과여야 합니다.

{
  "dns": {
    "hosts": {
      "router.local": "192.168.1.1"
    },
    "servers": [
      {
        "address": "https://dns.example/dns-query",
        "domains": [
          "domain:example.com"
        ],
        "skipFallback": true
      },
      "1.1.1.1"
    ],
    "queryStrategy": "UseIP"
  }
}

예시의 hosts는 로컬 도메인 매핑을 고정하는 데 사용합니다. domains가 있는 서버는 일치하는 범위만 처리하고 마지막 항목은 일반 조회 경로로 사용합니다. skipFallback은 해당 서버와 일치하는 조회를 폴백 판단에 다시 넣지 않는다는 뜻이며, 결과 출처를 명확히 하고 싶은 도메인에 적합합니다. 예시 주소 dns.example는 구조를 보여 주기 위한 것이므로 실제 설정에서는 사용 가능한 서비스로 바꿔야 합니다. 도메인별 해석이 필요하지 않다면 단순한 서버 목록을 사용하세요. 설정이 짧을수록 문제를 찾기 쉽습니다.

조회 유형과 캐시 이해하기

queryStrategy는 IPv4, IPv6 또는 두 주소를 모두 조회할지 제어합니다. 네트워크 환경에 사용 가능한 IPv6 경로가 없는데 IPv6 주소가 해석되면 연결이 수립되지 않아 기다린 뒤 다시 돌아오는 현상이 발생할 수 있습니다. 이 경우 라우팅 규칙으로 IPv6을 곳곳에서 제외하기보다 실제 네트워크 능력에 맞춰 IPv4만 조회하도록 선택할 수 있습니다. 반대로 시스템과 아웃바운드 모두 안정적인 IPv6을 지원한다면 듀얼 스택을 유지하는 것이 정상적인 네트워크 동작에 가깝습니다. 수정 후에는 새 연결을 만들고 애플리케이션 자체 캐시를 비워 이전 결과가 판단을 방해하지 않게 하세요.

DNS 캐시는 반복 조회를 줄여 주지만 설정을 수정해도 새 결과가 즉시 나타나지 않을 수 있습니다. v2rayN에서 코어를 재시작하면 코어 측 상태는 보통 초기화되지만 브라우저와 운영체제에는 여전히 캐시가 남을 수 있습니다. 확인할 때는 이전에 접속하지 않은 서브도메인을 사용하거나 캐시 만료를 기다리세요. 오랫동안 열어 둔 같은 페이지를 반복 새로 고침해 판단하지 않는 것이 좋습니다. 브라우저가 연결과 해석 결과를 재사용하거나 백그라운드 서비스 프로세스가 요청을 처리할 수 있기 때문입니다.

시스템 프록시와 TUN의 인계 범위

시스템 프록시는 운영체제의 프록시 설정을 따르는 브라우저와 데스크톱 애플리케이션에 적합합니다. 설정이 간단하고 비활성화 후 복구 상태도 확인하기 쉽지만 일부 프로그램은 시스템 프록시를 무시하며 UDP 트래픽 처리 여부도 애플리케이션에 따라 다릅니다. TUN 모드는 가상 네트워크 인터페이스를 통해 더 넓은 범위의 IP 트래픽을 수신하므로 명령줄 도구, 독립 네트워크 스택을 사용하는 애플리케이션 또는 TCP와 UDP를 통합 처리해야 하는 상황에 자주 사용됩니다. 인계 범위가 넓어지면 로컬 네트워크 접근, 개발 환경, 가상 머신과 다른 네트워크 도구 간의 관계도 복잡해집니다.

TUN을 활성화하기 전에 같은 서버가 시스템 프록시 모드에서 정상적으로 작동하는지 확인하고, 라우팅 규칙이 프록시, 직접 연결과 차단을 정확히 구분하는지 확인해야 합니다. 그렇지 않으면 TUN은 기존 설정 오류가 더 많은 프로그램에 영향을 주도록 만들 뿐입니다. 처음 테스트할 때는 가상 네트워크 카드를 만들거나 기본 경로를 수정하는 다른 소프트웨어를 끄고, 로컬 네트워크 대역과 기본 게이트웨이를 기록한 뒤 v2rayN에서 기본 TUN 설정을 활성화하세요. 성공한 후 다른 네트워크 구성 요소를 하나씩 다시 켜면서 라우팅 충돌이 발생하는지 확인합니다.

가상 인터페이스, 라우팅과 엄격 모드 이해하기

TUN이 시작되면 클라이언트는 가상 인터페이스를 만들고 시스템 라우팅을 통해 대상 트래픽을 해당 인터페이스로 보냅니다. 자동 라우팅은 필요한 라우팅 항목을 작성하고, 엄격 라우팅은 트래픽이 가상 인터페이스를 우회할 가능성을 줄입니다. 엄격 모드는 경로를 일관되게 유지하는 데 도움이 되지만 로컬 네트워크 검색, 컨테이너 네트워크 또는 특수 가상 네트워크 카드에 영향을 줄 수 있습니다. 활성화 후 프린터, 라우터 관리 페이지 또는 개발 장치에 접근할 수 없다면 먼저 로컬 네트워크 주소를 직접 연결로 남긴 뒤 엄격도를 낮출 필요가 있는지 판단하세요.

MTU는 가상 인터페이스가 전달할 수 있는 패킷 크기입니다. 너무 크게 설정하면 일부 경로에서 단편화나 패킷 손실이 발생할 수 있고, 너무 작으면 패킷 수와 추가 오버헤드가 늘어납니다. 명확한 근거가 없다면 클라이언트 기본값을 사용하세요. 일반적인 MTU 문제는 연결은 수립되지만 특정 페이지 로딩이 멈추거나 업로드가 실패하거나 일부 프로토콜이 비정상적으로 작동하는 형태로 나타납니다. 문제를 해결할 때는 값을 조금씩 낮추며 같은 테스트를 반복할 수 있지만, 매번 한 단계만 변경하고 원인이 서버나 DNS가 아닌지도 확인해야 합니다.

현상별 TUN 시작 문제 진단

TUN이 인터페이스를 만들지 못하면 먼저 로그에 권한, 인터페이스 이름 충돌 또는 드라이버 구성 요소 문제가 표시되는지 확인하세요. Windows에서는 필요한 권한으로 실행해야 할 수 있고, macOS와 Linux에서는 클라이언트가 가상 인터페이스를 만들도록 시스템이 허용하는지 확인해야 합니다. 로그에 권한 부족이 명확히 표시되는데 서버를 계속 바꾸는 것은 의미가 없습니다. 인터페이스 생성에는 서버가 영향을 주지 않기 때문입니다. 클라이언트를 다시 설치하기 전에도 다운로드 페이지에서 제공하는 해당 플랫폼 버전을 사용 중인지 확인하세요.

TUN은 시작되지만 모든 연결이 실패한다면 기본 경로가 가상 인터페이스를 가리키는지, 코어가 트래픽을 받는지, DNS를 사용할 수 있는지, 프록시 아웃바운드가 실수로 다시 TUN에 들어가 순환을 만드는지 확인하세요. 클라이언트는 일반적으로 자체 연결에 대한 제외 또는 보호 장치를 설정합니다. 사용자 지정 시작 방식, 외부 코어 또는 복잡한 라우팅은 이 관계를 깨뜨릴 수 있습니다. 로그에 연결이 반복해서 나타나고 대상이 로컬 가상 주소를 가리킨다면 라우팅 규칙을 계속 추가하기보다 먼저 루프백을 의심해야 합니다.

로컬 네트워크만 실패한다면 geoip:private 또는 명시적인 사설 네트워크 대역이 직접 연결되는지 확인하고, 로컬 네트워크 공유 설정으로 수신 범위가 바뀌지 않았는지도 확인하세요. 일반적인 사설 네트워크 대역에는 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16이 있습니다. 기업이나 연구실 네트워크는 추가 대역을 사용할 수 있으므로 실제 네트워크에 맞춰 보완해야 합니다. 로컬 서비스가 도메인으로 제공되는 경우에는 로컬 DNS도 필요하므로 IP 직접 연결만 설정해서는 안 됩니다.

TUN을 비활성화한 뒤 네트워크가 즉시 복구되지 않는다면 먼저 클라이언트에서 코어를 정상적으로 중지하고, 가상 인터페이스와 시스템 기본 경로가 철회됐는지 확인한 다음 현재 네트워크에 다시 연결하세요. 프로세스를 바로 종료하면 정리 단계가 실행되지 않을 수 있으므로 일상적인 종료 방법으로 사용해서는 안 됩니다. 문제가 계속되면 도움말 센터에서 “클라이언트는 종료됐지만 네트워크가 비정상임”이라는 관점으로 시스템 프록시, 가상 인터페이스와 DNS를 단계별로 확인하세요. 브라우저만 재시작해서는 안 됩니다.

FakeDNS의 작동 방식

일반 DNS 조회는 대상 서버의 실제 주소를 직접 반환하고 애플리케이션은 이후 해당 주소에 연결합니다. 연결이 코어에 들어올 때 IP만 남아 있으면 도메인 라우팅은 스니핑으로 원래 이름을 복원해야 할 수 있습니다. FakeDNS는 전용 주소 풀에서 가상 주소를 반환하고 코어 내부에 “도메인—가상 주소” 매핑을 저장합니다. 애플리케이션이 이 가상 주소에 연결하면 코어는 매핑을 통해 도메인을 되찾은 뒤 도메인 라우팅과 실제 해석을 수행합니다. 이 방식의 핵심 가치는 서버 성능 향상이 아니라 도메인 맥락을 유지하는 데 있습니다.

FakeDNS는 보통 TUN 모드와 함께 사용합니다. TUN이 애플리케이션이 가상 주소로 보내는 연결을 받아 코어로 전달할 수 있기 때문입니다. FakeDNS만 켜고 DNS 요청을 제대로 가로채지 않으면 애플리케이션은 다른 해석 경로에서 실제 주소를 받을 수 있습니다. DNS만 가로채고 가상 주소 트래픽을 코어로 보내지 않으면 조회는 성공하지만 연결은 실패합니다. 따라서 DNS 조회 진입점, FakeDNS 주소 풀, TUN 라우팅과 코어 매핑은 하나의 순환 구조를 이뤄야 합니다.

주소 풀과 매핑 용량

FakeDNS 주소 풀은 로컬 네트워크, 기업 네트워크, 컨테이너 네트워크 및 다른 가상 인터페이스와 충돌하지 않는 예약 범위를 선택해야 합니다. 클라이언트 기본값은 일반적인 상황을 고려해 설정되어 있으므로 명확한 충돌이 없다면 직접 바꾸지 않는 것이 좋습니다. 충돌이 발생하면 활성화 후 실제 내부 네트워크 주소 일부에 접근할 수 없거나 시스템이 가상 주소를 잘못된 인터페이스로 보낼 수 있습니다. 문제를 해결할 때는 시스템 라우팅 테이블을 확인하고 FakeDNS 주소 풀과 기존 네트워크의 라우팅 범위를 비교하세요.

매핑 용량은 동시에 보존할 수 있는 도메인 기록 수를 결정합니다. 용량이 너무 작으면 오래된 매핑이 자주 교체되어 복잡한 웹페이지에서 여러 도메인을 불러올 때 불일치가 발생하기 쉽습니다. 너무 크게 설정할 뚜렷한 이유는 없습니다. 일반적으로 클라이언트 기본값이면 충분합니다. 애플리케이션이 이전 DNS 결과를 오래 재사용하면 코어 매핑이 이미 정리된 뒤에도 실패한 가상 주소에 계속 연결할 수 있습니다. 이 경우 웹페이지를 반복해서 새로 고치는 대신 애플리케이션 연결과 코어를 함께 재시작하세요.

{
  "dns": {
    "servers": [
      {
        "address": "fakedns",
        "domains": [
          "geosite:geolocation-!cn"
        ]
      },
      "1.1.1.1"
    ],
    "fakedns": [
      {
        "ipPool": "198.18.0.0/15",
        "poolSize": 65535
      }
    ]
  }
}

예시는 FakeDNS의 일반적인 구조를 보여 줍니다. 지정한 도메인 분류는 가상 해석을 사용하고 나머지 조회는 일반 DNS로 보냅니다. 198.18.0.0/15는 이러한 매핑에 자주 사용되는 주소 범위지만 실제 적합성은 로컬 네트워크를 기준으로 판단해야 합니다. 코어마다 설정 형식이 달라 fakedns가 다른 계층에 놓일 수 있으며, v2rayN은 인터페이스를 통해 관련 필드를 자동 생성할 수도 있습니다. 이 조각을 전체 설정에 그대로 덮어쓰지 말고 클라이언트가 내보낸 현재 구조와 먼저 비교하세요.

우선 활성화하지 않는 편이 좋은 상황

로컬 DNS가 내부 네트워크 주소를 반환하는 업무 시스템, 로컬 네트워크 장치 이름과 분할 DNS 환경에서는 FakeDNS를 신중하게 사용해야 합니다. 이러한 도메인은 일반적으로 로컬 DNS로 처리하고 직접 연결해야 하며 가상 주소를 반환해서는 안 됩니다. 지정 도메인 규칙, 도메인 접미사 또는 로컬 hosts 매핑을 사용해 FakeDNS를 우회할 수 있습니다. 기업 내부 도메인에 안정적인 접미사가 없다면 먼저 실제 조회 기록을 수집한 뒤 명확한 목록을 만들고, 지나치게 넓은 제외 조건은 사용하지 마세요.

일부 애플리케이션은 DNS 반환 주소를 검증하거나 내장 DNS를 직접 사용하고, 캐시 시간이 길거나 연결 중 대상 주소를 다시 비교합니다. 이러한 애플리케이션은 FakeDNS와 함께 사용할 때 불안정할 수 있습니다. 하나의 애플리케이션에서만 문제가 발생하면 전체 TUN 설정을 끄기보다 관련 도메인에 일반 해석을 우선 적용하세요. 도메인 범위로도 원인을 찾을 수 없다면 FakeDNS를 사용하지 않는 기준선으로 돌아가 문제가 실제로 가상 매핑에서 발생했는지 확인합니다.

FakeDNS와 도메인 스니핑은 서로 보완할 수 있지만 무조건 모두 활성화해서는 안 됩니다. FakeDNS는 제어된 DNS 조회에 매핑을 보존하고, 스니핑은 매핑을 거치지 않았지만 프로토콜에서 도메인을 복원할 수 있는 연결을 처리합니다. 스니핑을 활성화할 때는 대상 덮어쓰기 설정에 주의하세요. 코어가 스니핑한 도메인으로 원래 대상을 바꾸면 라우팅 결과가 달라질 수 있습니다. 먼저 FakeDNS가 주요 TUN 트래픽을 처리하도록 한 뒤 로그에 여전히 IP만 표시되는 연결이 있을 때 스니핑 활성화를 검토하세요.

로그로 매핑 경로 검증하기

확인할 때는 이전에 캐시되지 않은 도메인을 선택하세요. DNS 요청이 FakeDNS를 통해 가상 주소를 반환하는지 확인한 다음, 바로 이어지는 연결 기록에 원래 도메인이 표시되는지 관찰합니다. 이후 라우팅이 선택한 아웃바운드 태그와 실제 연결 성공 여부를 확인하세요. DNS 기록만 있고 뒤이은 연결이 없다면 보통 가상 주소가 TUN에 인계되지 않았거나 애플리케이션이 즉시 연결을 시작하지 않은 경우입니다. 연결은 있지만 도메인을 복원하지 못한다면 매핑이 정리됐는지, 요청이 같은 코어 인스턴스에서 발생했는지 확인하세요.

각 구독의 용도와 우선순위 정의하기

다중 구독은 모든 서버를 하나의 후보 풀에 섞어야 한다는 뜻이 아닙니다. 더 관리하기 쉬운 방식은 각 구독에 일상 주 사용, 업무 예비, 특정 장치 또는 테스트 소스처럼 용도를 먼저 정한 뒤 별도의 그룹을 만드는 것입니다. 평소에는 현재 용도의 그룹 안에서만 서버를 선택하고, 소스를 바꿔야 할 때 그룹을 전환합니다. 이렇게 하면 이름이 같은 서버로 인한 혼동을 피하고 자동 선택이 출처를 넘나들며 결과를 바꾸는 일도 줄일 수 있습니다.

구독 이름에는 안정적인 정보를 포함하고 서버 수나 업데이트 시간에 의존하지 않아야 합니다. “용도—출처 약칭” 형식을 사용하고 메모에 적용 장치, 자동 업데이트 허용 여부와 특수 라우팅 매개변수 포함 여부를 적을 수 있습니다. 구독 주소에 액세스 토큰이 포함되어 있다면 클라이언트 구독 설정에만 저장하고 스크린샷, 공개 로그 또는 공유 문서에 복사하지 마세요. 자신의 다른 장치로 전달할 때는 통제된 방법을 사용하고 더 이상 쓰지 않는 장치에서는 이전 설정을 삭제해야 합니다.

업데이트 시간을 분산하고 실패 상태 보존하기

모든 구독을 동시에 업데이트하면 단계는 줄어들지만 한 소스가 실패했을 때 로그에 여러 요청이 뒤섞이기 쉽습니다. 처음 설정하거나 문제를 해결하는 중이라면 하나씩 업데이트하세요. 그룹을 선택하고 업데이트를 실행한 뒤 반환된 내용을 정상적으로 해석할 수 있는지 확인하고 다음 그룹으로 넘어갑니다. 안정된 후에는 예약 업데이트를 사용해도 되지만 간격을 지나치게 짧게 설정하지 마세요. 구독 내용은 보통 분 단위로 바뀌지 않으므로 너무 잦은 업데이트는 요청과 목록 재구성만 늘립니다.

업데이트가 실패하면 현재 그룹을 먼저 보존하고 즉시 삭제 후 다시 추가하지 마세요. 실패 원인이 네트워크 연결, 만료된 주소, 잘못된 응답 형식 또는 빈 콘텐츠인지 확인합니다. 주소에는 접근할 수 있지만 해석에 실패한다면 구독 형식이 클라이언트의 예상과 다를 수 있습니다. 현재 활성 프록시에서만 업데이트가 실패한다면 구독 업데이트에 사용하는 아웃바운드 경로를 임시로 바꿔 볼 수 있습니다. 구독 업데이트와 일반 웹페이지 접근은 다른 설정을 사용할 수 있으므로 로그에서 요청이 실제로 직접 연결 또는 프록시 중 어느 경로로 나갔는지 확인하세요.

업데이트 결과가 비어 있을 때는 클라이언트의 유지 정책이 중요합니다. 빈 응답이 기존 서버를 바로 덮어쓰지 않도록 하고 소스가 복구된 것을 확인한 뒤 다시 업데이트하는 것이 안전합니다. 클라이언트가 이미 그룹을 비웠다면 기억에 의존해 서버를 다시 만드는 대신 설정 백업에서 복원하세요. 업데이트가 성공한 뒤에도 프로토콜, 주소, 포트, 전송 방식과 보안 계층 필드가 완전한지 일부 항목을 점검해야 합니다. 서버 이름이 표시된다고 해서 모든 필드로 연결할 수 있는 것은 아닙니다.

중복 항목과 이름 충돌 처리하기

서로 다른 구독에 같은 서버가 포함되거나 별칭이 완전히 같을 수 있습니다. 이름만으로 중복을 제거하면 설정이 다른 항목을 잘못 삭제할 수 있고, 주소와 포트만으로 제거하면 프로토콜이나 사용자 식별자의 차이를 놓칠 수 있습니다. 상위 소스 간 관계를 명확히 아는 경우가 아니라면 그룹을 넘어 자동 병합하지 않는 것이 좋습니다. 목록에 중복 항목이 너무 많다면 원래 구독 구조를 훼손하지 말고 그룹 보기로 숨기세요.

통합 후보 집합이 꼭 필요하다면 원본 그룹을 보존한 뒤 소수의 자주 쓰는 항목만 수동 엄선 그룹에 복사하세요. 엄선 그룹은 구독 업데이트를 자동으로 상속하지 않으므로 상위 소스가 바뀔 때마다 다시 확인해야 합니다. 장기간 안정적인 소수 서버에 적합하며 모든 구독의 복제본으로 사용하기에는 적합하지 않습니다. 서버 필드가 바뀌어도 기존 복사 항목은 자동으로 수정되지 않는다는 점이 수동 그룹의 가장 쉽게 간과되는 유지 비용입니다.

자동 선택과 수동 선택의 경계

자동 선택 기능은 설정이 일관되고 용도가 같은 후보 집합 안으로 제한해야 합니다. 프로토콜, 용도와 출처가 전혀 다른 서버를 하나의 자동 집합에 넣으면 선택이 바뀌는 순간 연결 능력과 라우팅 결과가 함께 달라질 수 있습니다. 고급 설정 단계에서는 먼저 서버를 수동으로 고정하고 DNS, 라우팅과 TUN을 검증한 뒤 자동 선택을 켜는 편이 좋습니다. 이렇게 하면 장애가 발생했을 때 “활성 서버가 방금 바뀌었음”이라는 변수를 배제할 수 있습니다.

한 번의 지연 시간 테스트를 장기 순위 기준으로 사용하지 마세요. 네트워크 경로는 시간과 연결 상태에 따라 바뀌며 테스트 요청에 빠르게 응답하는 서버가 모든 업무에 적합한 것은 아닙니다. 선택할 때는 연결 안정성, 프로토콜 필드의 완전성, 대상 애플리케이션의 정상 작동 여부와 서버 전환 후 기존 연결을 다시 만들어야 하는지도 함께 확인하세요. 클라이언트 인터페이스의 그룹, 서버 목록과 로그 위치를 알고 싶다면 v2rayN 메인 화면 기능 구역 빠르게 살펴보기를 참고하세요.

아웃바운드 객체는 프로토콜, 설정과 태그로 구성됨

코어의 각 아웃바운드에는 최소한 프로토콜 유형, 프로토콜 설정과 라우팅에서 참조할 태그가 포함됩니다. v2rayN은 선택한 서버를 바탕으로 주요 프록시 아웃바운드를 생성하며, 보통 직접 연결과 차단 아웃바운드도 함께 만듭니다. 사용자 지정 아웃바운드는 로컬에 이미 있는 SOCKS 서비스에 연결하거나 특수한 직접 연결 동작을 지정하거나 체인 연결의 한 단계로 사용할 수 있습니다. 용도와 관계없이 태그는 고유하고 안정적이어야 합니다. 라우팅 규칙, DNS 서버 및 다른 아웃바운드가 태그로 이를 참조할 수 있기 때문입니다.

사용자 지정 아웃바운드를 추가하기 전에 트래픽 경로를 그려 보세요. 어떤 인바운드가 트래픽을 받는지, 어느 라우팅이 일치하는지, 사용자 지정 아웃바운드가 어디에 연결하는지, 해당 아웃바운드 자체가 다른 프록시를 거쳐야 하는지를 적습니다. 경로를 한두 문장으로 설명할 수 없다면 설정이 이미 지나치게 복잡할 가능성이 큽니다. 체인 아웃바운드는 장애 지점을 늘립니다. 어느 한 단계에서 DNS, 인증, 수신 주소 또는 네트워크가 작동하지 않아도 최종 연결 실패로 나타납니다. 경로의 끝만 보지 말고 각 단계를 따로 검증해야 합니다.

{
  "outbounds": [
    {
      "tag": "local-socks",
      "protocol": "socks",
      "settings": {
        "servers": [
          {
            "address": "127.0.0.1",
            "port": 1081
          }
        ]
      }
    },
    {
      "tag": "direct",
      "protocol": "freedom",
      "settings": {}
    },
    {
      "tag": "block",
      "protocol": "blackhole",
      "settings": {}
    }
  ]
}

이 예시는 로컬 127.0.0.1:1081의 SOCKS 서비스를 local-socks로 정의하고 직접 연결과 차단 아웃바운드를 유지합니다. 사용하기 전에 해당 포트에서 실제로 서비스가 수신 중인지, 연결이 v2rayN의 현재 인바운드로 되돌아가 루프를 만들지 않는지 확인해야 합니다. 예시에는 인증 필드가 없습니다. 로컬 서비스에 인증이 필요하다면 코어가 지원하는 SOCKS 서버 구조에 맞춰 추가하고 공개 문서나 스크린샷에 실제 인증 정보를 표시하지 마세요.

라우팅으로 제한된 대상만 사용자 지정 아웃바운드에 보내기

새 아웃바운드를 만든 직후 전역 기본값으로 설정하지 마세요. 먼저 테스트 도메인에만 일치하는 라우팅 규칙을 만들고 outboundTag가 새 태그를 가리키게 합니다. 로그에서 규칙 일치를 확인한 뒤 로컬 SOCKS 서비스가 연결을 받는지 확인하세요. 테스트를 통과하면 범위를 조금씩 넓힙니다. 규칙이 일치하지 않으면 라우팅 조건이나 순서의 문제이고, 일치하지만 로컬 서비스에 연결이 없으면 아웃바운드 주소, 포트와 루프를 확인해야 합니다. 로컬 서비스가 연결을 받았지만 최종적으로 실패한다면 다음 단계의 경로를 점검하세요.

{
  "type": "field",
  "domain": [
    "full:test.example.com"
  ],
  "outboundTag": "local-socks"
}

아웃바운드 태그 이름을 바꾼 뒤에는 모든 참조 위치도 함께 수정해야 합니다. 자주 빠뜨리는 곳은 라우팅 규칙, DNS 서버의 outboundTag, 프록시 체인의 proxySettings와 클라이언트 인터페이스에 저장된 사용자 지정 템플릿입니다. 코어 시작 시 “태그를 찾을 수 없음” 오류가 발생하면 outbounds 배열만 보지 말고 생성된 전체 설정을 검색하세요. 클라이언트가 시작할 때마다 설정을 다시 생성한다면 임시 JSON을 직접 수정한 내용은 다음 설정 적용 시 사라질 수 있으므로 클라이언트가 제공하는 사용자 지정 설정 진입점을 우선 사용하세요.

설정 파일 검증 방법

저장하기 전에 JSON 문법을 확인하세요. 객체와 배열 괄호가 쌍을 이루는지, 마지막 멤버 뒤에 불필요한 쉼표가 없는지, 문자열이 큰따옴표를 사용하는지 점검합니다. 문법이 올바르다는 것은 파일을 해석할 수 있다는 뜻일 뿐이며, 현재 코어가 해당 필드를 지원하는지도 확인해야 합니다. 시작 후에는 로그 앞부분에서 설정 로드 결과를 확인하세요. 코어가 바로 종료되면 첫 번째 오류에 필드 경로 또는 태그 이름이 표시되는 경우가 많습니다. 오류 하나를 수정한 뒤 다시 로드하세요. 뒤의 오류는 앞선 오류에 가려진 결과일 수 있습니다.

설정이 시작된 후에는 “인바운드—라우팅—아웃바운드—대상” 순서로 검증하세요. 먼저 테스트 연결이 예상한 인바운드로 들어오는지 확인하고, 라우팅이 대상 태그와 일치하는지 확인한 다음 아웃바운드가 수립되는지 점검하고 마지막으로 애플리케이션 동작을 확인합니다. DNS 관련 아웃바운드는 조회 요청이 해당 태그를 사용하는지도 별도로 확인해야 합니다. 브라우저 페이지가 열리는지만 유일한 판단 기준으로 삼지 마세요. 캐시, 연결 재사용과 애플리케이션 폴백이 설정 문제를 가릴 수 있습니다.

장기 유지 관리 비용 제어

장기간 사용할 수 있는 고급 설정은 세 가지 질문에 답할 수 있어야 합니다. 각 사용자 지정 규칙이 왜 존재하는지, 어느 그룹 또는 아웃바운드에 의존하는지, 실패했을 때 어떻게 되돌릴지입니다. 규칙 이름이나 로컬 설명에 용도를 기록하되 민감한 연결 정보는 적지 않는 것이 좋습니다. 일정한 주기로 더 이상 사용하지 않는 구독, 중복 서버, 작동하지 않는 필터 키워드, 오래된 도메인 예외와 참조되지 않는 아웃바운드 태그를 확인하세요. 삭제하기 전 먼저 비활성화하고 관찰한 뒤 숨은 의존성이 없는지 확인하고 완전히 정리합니다.

클라이언트와 코어를 업데이트한 뒤 모든 이전 설정을 즉시 다시 조정하지 마세요. 먼저 기존 설정으로 기본 연결을 확인하고, 인터페이스에 추가되거나 변경된 옵션을 살펴보며 특히 TUN, DNS, 라우팅 데이터와 설정 생성 방식을 점검하세요. 문제가 발생하면 이 장의 처음에 만든 기준선에서 단계별로 복구합니다. v2rayN은 데스크톱 플랫폼에서 우선 선택할 클라이언트이며, Android에서는 코어 요구에 따라 v2rayNG 또는 v2flyNG를 선택할 수 있습니다. 세 클라이언트의 구체적인 진입점과 플랫폼 설명은 클라이언트 다운로드 페이지에 모아 두었습니다.

특정 문제가 한 기기에서만 발생한다면 먼저 트래픽 인계 방식, 시스템 DNS, 로컬 네트워크 대역과 애플리케이션 프록시 동작을 비교하고 구독 내용이 다르다고 단정하지 마세요. 여러 기기에 같은 구독을 가져와도 서버 출처가 비슷해질 뿐 로컬 라우팅, TUN 권한, 시스템 프록시와 DNS 캐시가 동기화되는 것은 아닙니다. 이러한 기기 측 변수를 목록으로 만들고 하나씩 비교하는 편이 구독을 반복해서 가져오는 것보다 효과적입니다.

고급 설정의 목표는 설정 파일을 계속 길게 만드는 것이 아니라 트래픽 경로를 실제 요구에 맞추는 것입니다. 클라이언트 기본값으로 해결할 수 있는 문제는 우선 기본값을 사용하세요. 로그와 테스트에서 한계가 명확히 드러날 때만 해당 문제를 겨냥한 규칙을 추가합니다. 변경 범위를 작게 유지하고 태그 의미를 명확히 하며 검증 절차를 고정하면 구독, 네트워크 환경 또는 사용 상황이 바뀌어도 조정해야 할 계층을 빠르게 찾을 수 있습니다.