v2rayN 고급 설정

기본 설정과 코어별 차이

고급 설정은 정상 작동이 확인된 기본 구성에서 시작하세요. 데스크톱에서는 v2rayN을 우선 사용하고, 설치 파일은 클라이언트 설치 파일 페이지에서 받을 수 있습니다. Android에서는 코어 요구 사항에 따라 v2rayNG 또는 v2flyNG를 선택할 수 있습니다. 클라이언트는 서버 정보를 저장하고 설정을 생성하며 실행 상태를 제어하고, 코어는 프로토콜 연결과 라우팅, DNS 확인을 담당합니다. 화면에 옵션이 있다고 해서 현재 실행 중인 모든 코어가 같은 방식으로 처리하는 것은 아닙니다. 문제를 점검하기 전에 사용 중인 클라이언트, 연결 프로토콜, 코어와 트래픽 처리 모드를 확인해 서로 다른 계층의 문제를 혼동하지 않도록 하세요.

정상 작동이 확인된 연결 경로 유지

먼저 추가 트래픽 처리 기능을 끄고, 사용 가능한 서버와 단순한 라우팅 설정으로 시스템 프록시를 통해 브라우저에서 정상적으로 접속되는지 확인하세요. 그런 다음 로컬 수신 주소, HTTP 또는 SOCKS 포트, 현재 라우팅 방식과 DNS 옵션을 기록합니다. 이 단계에서 이미 실패한다면 TUN이나 FakeDNS를 켜지 마세요. 변수를 늘릴 뿐 잘못된 노드 주소, 포트 또는 인증 설정을 해결하지는 못합니다. 서버 이름에 '기본 설정' 같은 메모를 붙여 두면 목록의 고정된 행 번호에 의존하는 것보다 확실합니다.

테스트는 클라이언트의 한 번짜리 테스트 결과만 볼 것이 아니라 실제 사용 상황을 재현해야 합니다. 서버 테스트 성공은 보통 해당 설정으로 테스트 대상에 요청을 보냈다는 뜻입니다. 모든 앱이 시스템 프록시를 따르거나 대상 서비스의 모든 연결 방식이 작동한다는 보장은 아닙니다. 자주 사용하는 웹페이지를 열고 로그인이 필요한 정상 작업을 한 번 수행한 뒤 로그에서 아웃바운드 선택을 확인하세요. 특정 앱만 실패하고 브라우저는 정상이라면 전체 설정을 바로 바꾸기보다 앱 자체의 프록시 설정, 연결 프로토콜과 캐시부터 확인하세요.

화면 설정과 원시 설정 구분

v2rayN의 서버 편집, 라우팅 편집 및 DNS 설정은 설정을 입력하는 곳이고, 실행 시 생성되는 파일은 그 결과입니다. 생성 파일을 직접 수정하면 서버를 바꾸거나 코어를 다시 시작할 때 변경 사항이 덮어써질 수 있습니다. 장기간 유지할 설정은 우선 클라이언트가 지원하는 메뉴에서 조정하세요. 사용자 지정 설정이 꼭 필요하다면 해당 기능을 이용하고 원본을 별도로 저장하세요. 메뉴 이름과 위치는 화면 구성에 따라 바뀔 수 있으므로, 예전 스크린샷의 위치가 아니라 기능과 실제 생성 결과를 기준으로 판단해야 합니다.

이 페이지의 JSON 예시는 Xray 설정 일부를 보여 주며, 해당 필드만 담은 조각이지 단독 실행 가능한 전체 클라이언트 설정이 아닙니다. 전체 설정에는 인바운드와 서버 아웃바운드 및 기타 필수 매개변수가 필요합니다. 다른 코어를 사용할 때 필드를 그대로 옮기지 마세요. '라우팅'이나 'DNS'라는 개념이 같아도 필드 구조, 기본값과 처리 과정은 다를 수 있습니다. 특히 데스크톱 TUN에 사용하는 실행 구성 요소는 클라이언트가 실제로 실행한 것을 기준으로 확인해야 하며, 선택한 서버 프로토콜만 보고 추측해서는 안 됩니다.

한 번에 변수 하나만 변경

설정을 변경하기 전에 복구 가능한 사본을 저장하고, '네트워크 최적화'처럼 막연한 표현 대신 '테스트 도메인을 지정한 아웃바운드로 연결'처럼 조정 목적을 기록하세요. 관련 변수는 한 번에 하나만 바꾸고, 필요한 구성 요소를 다시 시작한 뒤 같은 테스트를 반복해 결과를 기록합니다. 라우팅, DNS와 트래픽 처리는 서로 영향을 주므로 세 가지를 한꺼번에 변경하면 연결이 복구되어도 원인을 알기 어렵습니다. 다음 업데이트나 재시작 후 문제가 다시 생길 수도 있습니다.

로그는 문제 해결에 필요한 만큼만 기록하세요. 일시적으로 로그 수준을 높이면 설정 로드와 규칙 일치 과정을 확인하는 데 도움이 되지만, 로그에 도메인, 주소와 연결 정보가 포함될 수 있습니다. 도움을 요청할 때는 오류 전후의 필요한 부분만 남기고 구독 링크, 인증 정보와 개인 접속 기록은 삭제하세요. 시간 초과가 발생하면 노드 시간 초과 점검 순서에 따라 확인할 수 있습니다. 기본 설정이 안정되면 아래의 구독 및 라우팅 섹션으로 넘어가세요.

구독 그룹 및 서버 필터링

구독은 서버 설정을 업데이트하는 경로이고, 그룹은 클라이언트에서 설정을 저장하고 표시하는 방식입니다. 서로 관련은 있지만 같은 개념은 아닙니다. 하나의 그룹에 구독을 연결할 수도 있고, 직접 추가한 서버를 저장할 수도 있습니다. 설정 출처별로 그룹을 만들고 모든 서버를 한 목록에 몰아넣지 않는 것이 좋습니다. 그러면 업데이트 실패 시 출처를 파악하기 쉽고, 구독을 삭제하거나 중지할 때 영향 범위도 확인할 수 있습니다. 그룹 이름은 용도나 출처를 설명하면 충분하며, 홍보 문구가 긴 노드 이름을 그대로 복사할 필요는 없습니다.

먼저 출처를 정리한 뒤 서버 업데이트

구독 그룹 설정에서 그룹을 만들고 직접 발급받은 구독 주소를 입력한 다음 저장한 뒤 해당 그룹만 업데이트하세요. 업데이트가 끝나면 항목 수와 오류 메시지를 확인하고 서버 목록에서 주소, 프로토콜과 메모가 적절한지 살펴보세요. 처음 가져올 때는 자동 업데이트를 바로 켜거나 여러 출처를 동시에 추가하지 마세요. 우선 한 출처의 가져오기, 파싱, 저장과 연결이 모두 정상인지 확인해야 네트워크 문제인지, 구독 내용 문제인지, 새 그룹과의 설정 충돌인지 구분할 수 있습니다.

구독 링크에는 계정 식별에 쓰이는 매개변수가 들어 있는 경우가 많으므로 계정 정보처럼 관리하세요. 전체 링크를 서버 메모, 공개 스크린샷이나 도움 요청 로그에 올리지 말고, 링크를 줄이려고 출처가 불분명한 리디렉션 서비스에 입력하지도 마세요. 서비스 제공자가 주소나 계정 식별 정보를 변경했다면 그룹 설정에서 이전 링크를 새 링크로 바꿔야 합니다. 링크가 열려도 서버가 표시되지 않는다고 해서 반드시 클라이언트 문제인 것은 아닙니다. 계정 상태, 콘텐츠 형식 또는 서버가 반환한 안내 페이지도 파싱 결과에 영향을 줍니다.

필터링은 범위를 좁힐 뿐

필터링은 보통 서버 메모나 클라이언트가 지원하는 조건을 기준으로 목록의 후보를 줄이며, 서버의 실제 위치, 프로토콜 기능이나 사용 가능 상태를 바꾸지는 않습니다. 화면 검색과 구독 필터링도 구분해야 합니다. 검색은 일치하지 않는 행을 일시적으로 숨겼다가 검색어를 지우면 다시 표시합니다. 구독 필터링은 업데이트 시 항목 자체를 제외해 로컬 그룹에 가져오지 않을 수 있습니다. 설정을 바꾸기 전에 어떤 종류인지 확인해 '필터에서 제외됨'을 '제공자가 서버를 삭제함'으로 오해하지 않도록 하세요.

화면에 따라 필터 입력란은 일반 키워드, 여러 조건 또는 정규식을 받을 수 있으므로 입력란의 안내를 따라야 합니다. 정규식을 지원한다고 명시된 경우 ^(테스트|예비)는 메모가 '테스트' 또는 '예비'로 시작하는 항목을 찾을 수 있습니다. 이는 정규식 예시일 뿐 모든 클라이언트의 필터 입력란에서 사용할 수 있다는 뜻은 아닙니다. 업데이트 후 목록이 비었다면 필터 조건을 모두 지운 뒤 다시 업데이트하고 조건을 하나씩 추가하세요. 대소문자, 공백, 전각 기호와 서비스 제공자의 이름 변경 때문에 기존 필터가 갑자기 작동하지 않을 수도 있습니다.

로컬 수정과 현재 선택 보호

구독에서 가져온 항목은 이후 업데이트의 관리 대상인 경우가 많습니다. 주소, 포트 또는 전송 필드를 로컬에서 수정해도 다음 업데이트 때 구독에 있는 값으로 되돌아갈 수 있습니다. 메모 같은 필드를 유지하는지는 클라이언트의 병합 방식에 따라 다릅니다. 다른 매개변수로 별도 설정을 관리해야 한다면 해당 항목을 독립된 수동 그룹에 복사하고 수정 이유를 메모로 남기세요. 그러면 구독 항목은 출처에 따라 업데이트되고 수동 항목은 관리 가능한 실험에 활용되어 두 관리 방식을 혼동하지 않습니다.

업데이트 후에는 현재 사용하는 서버를 다시 확인하세요. 목록 순서 변경, 항목 이름 변경 또는 구독에서 이전 기록 삭제로 기존 선택이 더 이상 적합하지 않을 수 있습니다. '업데이트 성공'만 확인하지 말고 실제 활성 서버가 예상한 그룹에 속해 있는지 확인한 뒤 실제 요청으로 테스트하세요. 여러 서버를 테스트해야 한다면 현재 용도와 관련된 항목으로 범위를 좁히세요. 과도한 동시 테스트는 네트워크와 기기 자원을 사용하고 테스트 대상의 제한에도 영향을 받으므로 서버 품질 순위로 볼 수 없습니다.

빈 목록과 파싱 오류 해결

업데이트가 실패하면 먼저 어느 단계에서 오류가 발생했는지 확인하세요. 요청 자체가 완료되지 않으면 링크, 네트워크와 업데이트 시 프록시가 필요한지 확인합니다. 요청은 완료됐지만 파싱에 실패했다면 응답이 실제 구독인지, 로그인 페이지나 만료 안내인지 살펴보세요. 업데이트 성공 후 목록이 비었다면 필터 조건과 프로토콜 호환성을 확인합니다. 출처가 유효한지 확인하기도 전에 클라이언트를 연달아 초기화하지 마세요. 자세한 점검 절차는 구독 업데이트 실패 및 파싱 오류 해결에서 확인할 수 있습니다. 기존 그룹을 보존한 채 새 설정을 시도하는 편이 모든 항목을 바로 삭제하는 것보다 복구하기 쉽습니다.

라우팅 규칙과 트래픽 분할

라우팅은 연결이 어떤 아웃바운드를 사용할지 결정하며, 구독을 생성하거나 서버 매개변수를 수정하는 기능은 아닙니다. 조건을 순서대로 확인하는 의사결정 표처럼 생각할 수 있습니다. 규칙이 일치하면 트래픽은 해당 규칙에 지정된 아웃바운드로 전달됩니다. Xray의 일반적인 규칙 라우팅에서는 앞선 규칙이 먼저 적용되므로 구체적인 예외를 포괄적인 규칙보다 위에 두는 것이 보통입니다. 클라이언트에서 '전역'이나 사전 설정 방식을 선택하면 생성되는 규칙이 달라질 수 있습니다. 직접 규칙을 만들기 전에 실제로 어떤 라우팅 설정이 활성화되어 있는지 확인하세요.

명확한 목표 하나부터 시작

먼저 바꾸려는 동작을 구체적으로 정하세요. 예를 들어 특정 테스트 도메인을 직접 연결하거나, 분명히 필요하지 않은 대상 주소를 차단하는 방식입니다. 출처가 불분명한 규칙을 잔뜩 가져온 뒤 웹페이지가 열리는지만 보고 효과를 짐작하지 마세요. 도메인 규칙은 호스트 이름이 안정적인 서비스에, IP 규칙은 주소 범위가 명확한 네트워크에 적합합니다. 포트 규칙은 앱의 용도를 고려해 신중하게 설정하세요. 서비스 하나가 여러 도메인, CDN 주소와 로그인 인터페이스에 접속할 수 있어 메인 페이지 도메인만 처리하면 전체 과정에 적용되지 않을 수 있습니다.

Xray 규칙에서 full:example.com은 도메인 전체와 정확히 일치하고, domain:example.com은 해당 도메인과 하위 도메인을 포함합니다. 이런 접두사가 없는 일반 문자열은 서로 다른 일치 방식으로 처리될 수 있으므로 '키워드 포함'과 '특정 도메인에 속함'을 혼동하지 마세요. IP 조건에는 개별 주소나 CIDR 대역을 사용할 수 있습니다. 규칙을 관리할 때는 각 규칙의 용도, 적용 대상과 테스트 방법을 기록하세요. '규칙 최적화'처럼 모호한 이름만 남기면 시간이 지난 뒤 삭제해도 되는지 판단하기 어렵습니다.

한 규칙 안에서 조건이 결합되는 방식 이해

같은 규칙의 여러 조건은 모두 충족해야 일치하는 경우가 많습니다. 예를 들어 도메인과 포트가 모두 맞아야 합니다. 한 목록 안의 후보 여러 개는 선택 가능한 범위를 나타냅니다. 특정 도메인과 별개의 IP 대역을 각각 같은 아웃바운드로 보내려면 보통 규칙을 두 개로 나누어야 합니다. 둘을 한 규칙에 넣고 '둘 중 하나'로 처리될 것이라고 기대하면 안 됩니다. 이런 세부 사항 때문에 규칙이 있어도 한 번도 일치하지 않을 수 있습니다. 규칙을 추가한 뒤에는 실제 조건을 충족하는 요청으로 테스트하고 일치한 아웃바운드를 확인하세요.

아래 예시는 간단한 규칙 순서를 보여 줍니다. 특정 테스트 도메인은 먼저 직접 연결하고, 사설 주소 대역도 그다음 직접 연결하며, 마지막에는 TCP와 UDP 규칙으로 프록시를 명시합니다. 예시의 direct와 proxy는 실제 아웃바운드 태그와 일치해야 합니다. 코어가 자동으로 만드는 예약 이름이 아닙니다. 이 조각은 유효한 Xray 설정에 병합해야 하며 단독으로 실행할 수 없습니다. 사설 주소 규칙도 실제 네트워크 용도에 맞게 조정해야 합니다. 모든 사설 주소가 현재 기기의 로컬 네트워크에 속하는 것은 아닙니다.

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

도메인, DNS 확인과 기본 아웃바운드

AsIs는 라우팅 단계에서 IP 규칙과 일치시키기 위해 도메인을 적극적으로 확인하지 않는다는 뜻입니다. 기존에 IP 대상이 있다면 IP 규칙에 계속 사용할 수 있습니다. 대상이 도메인만 있는 경우 일부 IP 규칙이 예상대로 작동하지 않을 수 있습니다. IPIfNonMatch는 도메인 규칙이 일치하지 않을 때 DNS 확인을 시도한 뒤 IP 규칙을 적용합니다. 이 설정은 DNS 서버와 확인 경로에도 의존하게 됩니다. IP 규칙 하나를 작동시키려는 이유로 DNS 요청 자체에 접근할 수 있는지 확인하는 일을 빼먹지 마세요. 일치하지 않는 연결의 기본 아웃바운드 동작도 확인해야 합니다. 마지막 규칙을 명시하면 설정을 이해하기 쉽습니다.

규칙이 있다고 해서 클라이언트가 일치에 필요한 도메인을 반드시 확인할 수 있는 것은 아닙니다. 앱이 IP에 직접 연결하거나 자체적으로 DNS 확인을 마친 뒤 연결을 시작할 수 있습니다. 스니핑 활성화 여부, 인식 가능한 프로토콜과 스니핑 결과를 라우팅에 사용하는지에 따라 확인 가능한 정보가 달라집니다. 스니핑으로 암호화된 트래픽의 도메인을 모두 복원할 수는 없으며 만능 해결책으로 봐서는 안 됩니다. 요청에 도메인과 IP 중 무엇이 포함되는지 먼저 확인한 뒤 규칙, DNS 또는 트래픽 처리 방식을 조정하세요. 조건을 계속 추가하는 것보다 효과적인 경우가 많습니다.

검증할 때는 규칙에 포함된 대상, 규칙에 포함되지 않은 대상과 로컬 서비스를 각각 테스트해 한 경로만 작동하는 상황을 피하세요. 새 규칙을 추가한 뒤 많은 요청이 실패하면 규칙을 먼저 비활성화해 기본 설정을 복구한 다음 순서, 조건 관계와 아웃바운드 태그를 확인하세요. 차단 규칙은 범위가 명확한 위치에 둬야 DNS 확인, 인증이나 업데이트 요청까지 함께 막히지 않습니다. 라우팅 규칙은 오래된 예외를 주기적으로 정리하고 클라이언트 업데이트나 코어 변경 후에는 생성 결과를 다시 확인하세요. 이전 설정이 계속 그대로 적용될 것이라고 가정하면 안 됩니다.

DNS 설정과 확인 경로

DNS 문제는 단순히 '다른 DNS 주소로 바꾸는 것'만으로 해결되지 않는 경우가 많습니다. 앱은 시스템 DNS 확인기를 사용할 수 있고, 클라이언트 코어는 라우팅이나 직접 연결을 위한 자체 DNS 처리 과정을 사용할 수 있습니다. 프록시 서버가 대상 도메인을 원격에서 확인하기도 합니다. 이런 요청은 서로 다른 위치에서 발생하며 라우팅과 네트워크 조건도 다릅니다. 앱의 DNS 확인, 코어의 DNS 확인과 원격 연결 중 어느 단계에서 실패하는지 먼저 파악해야 올바른 설정 메뉴를 선택할 수 있습니다. 브라우저에서 웹페이지가 열리지 않아도 서버 테스트가 정상이라면 DNS뿐 아니라 앱이 예상한 프록시를 사용하지 않는 문제일 수도 있습니다.

세 가지 DNS 확인 경로 구분

첫 번째는 기기에서 로컬 DNS 확인기로 보내는 경로로, 앱에서 일반적으로 사용하는 도메인 조회를 처리합니다. 두 번째는 코어가 설정된 DNS 서버로 요청하는 경로로, IP 라우팅 일치나 직접 연결에 사용될 수 있습니다. 세 번째는 프록시 아웃바운드가 도메인을 서버로 넘기고 서버가 DNS 확인을 수행하는 경로입니다. 모든 연결이 세 경로를 전부 거치는 것은 아닙니다. 현재 모드에 따라 요청이 어디서 발생하고 어떤 아웃바운드를 거쳐 어떤 주소 형식으로 돌아오는지 정리하면, DNS 설정이 일부 사이트에는 영향을 주고 다른 사이트에는 영향을 주지 않는 이유를 파악할 수 있습니다.

DNS 서버가 어떤 방식으로 연결되는지도 확인해야 합니다. 기존 UDP 조회와 암호화된 HTTPS 조회는 전송 방식이 다르므로 주소를 URL로 바꾸기만 하면 모든 코어가 자동으로 처리할 것이라고 기대할 수 없습니다. Xray DNS 설정은 주소 형식에 따라 코어 라우팅을 사용하는지 로컬로 연결하는지 등 특정한 처리 방식이 있습니다. 다른 구성 요소는 필드가 다를 수 있습니다. 현재 코어가 지원하는 형식을 확인한 뒤 DNS 요청이 원하는 아웃바운드를 실제로 거치는지 점검하세요.

DNS 부트스트랩 순환부터 해결

도메인 형식의 DNS 서버를 사용하려면 먼저 DNS 서버의 IP를 알아야 합니다. 프록시 서버 주소도 도메인이라면 프록시 연결 전에 필요한 DNS 확인을 해야 합니다. '모든 DNS 요청을 아직 연결되지 않은 프록시로 보내도록' 설정했는데 프록시 서버에 연결하려면 같은 DNS가 필요하다면 순환이 발생합니다. 시작 후 모든 요청이 시간 초과될 수 있습니다. 서버 주소나 DNS 서버에 도달할 수 있는 부트스트랩 경로를 제공하고, 아직 연결되지 않은 경로와 분리하세요. 시간 초과와 재시도를 계속 추가하는 방식으로 해결하려 하지 마세요.

아래는 Xray 내장 DNS의 간략한 예시입니다. 정적 매핑은 테스트 도메인 하나를 덮어쓰는 방법을 보여 주고, 서버 목록과 쿼리 정책은 내장 DNS의 조회 방식을 제어합니다. 이 예시만으로 운영체제의 모든 DNS 요청을 가로채는 것은 아니며 DNS 요청을 보낼 아웃바운드도 정의하지 않습니다. example.com과 문서용 예시 주소는 구조를 이해하는 데만 사용하세요. 실제 DNS 서버는 네트워크 접근성과 관리 요구 사항에 맞게 선택해야 합니다.

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

정적 매핑을 사용하면 해당 도메인의 일반적인 동적 DNS 확인 과정을 건너뜁니다. 일시적인 진단에는 쓸 수 있지만 CDN 서비스 주소를 무턱대고 고정하는 용도로는 적합하지 않습니다. 서비스는 지역, 부하와 시간에 따라 다른 주소를 반환할 수 있으며 고정값이 만료되면 연결에 실패합니다. 진단이 끝나면 임시 매핑을 삭제하고 요청을 다시 보내세요. DNS 결과가 올바르더라도 서비스 접속이 보장되는 것은 아니므로 대상 포트, 전송 프로토콜과 서버의 연결 처리도 확인해 이후 연결 오류까지 DNS 문제로 돌리지 않도록 하세요.

IPv4, IPv6 및 캐시

UseIP는 IPv4와 IPv6 주소를 모두 조회하고, UseIPv4 또는 UseIPv6는 조회할 주소 유형을 제한합니다. IPv4로 제한하는 것은 IPv6 경로 문제를 확인하기 위한 비교 테스트로 사용할 수 있지만, 일반적으로 더 빠른 설정이라고 설명해서는 안 됩니다. 기기에서 IPv6 주소를 받을 수 있어도 선택한 아웃바운드가 해당 주소에 정상적으로 연결된다는 뜻은 아닙니다. 반대로 IPv6만 지원하는 대상은 IPv4로 제한해도 해결되지 않습니다. 기기 네트워크, 프록시 서버와 대상 서비스의 기능을 함께 고려하세요.

DNS 캐시는 운영체제, 브라우저, 앱과 코어에 각각 존재할 수 있습니다. DNS를 바꾼 직후 이미 열린 페이지를 새로고침하면 이전 주소나 기존 연결을 계속 사용할 수 있으므로 새 연결을 만들어 테스트하세요. 필요에 따라 영향을 받은 앱과 코어를 다시 시작해야 합니다. Windows에서는 시스템의 DNS 캐시 삭제 도구를 사용할 수 있습니다. macOS와 Linux의 캐시 관리 방식은 시스템 서비스에 따라 다르므로 다른 플랫폼의 명령을 그대로 적용하지 마세요. 설정을 반복해서 모두 초기화하는 것보다 변경 전후의 DNS 결과를 기록하는 편이 유용합니다.

DNS 서버 이름보다 증상으로 원인 파악

도메인 연결은 실패하지만 같은 서비스의 IP 연결은 정상이라면 DNS 요청 시간 초과, 주소 유형과 반환 결과를 먼저 확인하세요. 도메인은 확인되지만 연결이 실패한다면 라우팅, 포트와 서버 설정을 점검합니다. TUN 모드에서만 실패하면 DNS 트래픽 처리와 가상 네트워크 인터페이스 경로를 추가로 살펴보세요. DNS 서버를 바꾼 뒤 문제가 해결됐다고 해서 새 서버가 모든 앱에 더 적합하다는 뜻은 아닙니다. 라우팅 목적에 맞는 설정을 사용하고 기본 상태로 복구할 수 있는 DNS 구성을 보존하세요.

TUN 모드와 트래픽 처리

시스템 프록시는 시스템 설정을 따르는 앱이 사용합니다. TUN은 가상 네트워크 인터페이스로 지정된 IP 트래픽을 처리 구성 요소에 전달하므로 트래픽이 처리되는 계층이 다릅니다. 시스템 프록시를 사용하지 않는 앱에는 TUN이 대안 경로가 될 수 있지만, 그렇다고 모든 트래픽이 반드시 프록시를 거치는 것은 아닙니다. 실제 동작은 시스템 라우팅, 제외 규칙, DNS 처리, UDP 지원과 아웃바운드 설정에도 영향을 받습니다. 시스템 프록시에서 이미 작동하는 기본 구성을 TUN을 켜기 전 비교 기준으로 사용하세요. TUN을 서버 연결 실패의 해결 버튼처럼 취급해서는 안 됩니다.

실행 구성 요소와 시스템 권한 확인

v2rayN에서 TUN을 켜기 전에 클라이언트에서 제공하는 관련 설정과 시작 로그에 표시된 실행 구성 요소를 확인하세요. 서버가 Xray 프로토콜을 사용한다고 해서 TUN 인터페이스도 같은 코어가 직접 생성하는 것은 아닙니다. 구성 요소마다 설정 구조, 트래픽 처리 방식과 DNS 동작이 다를 수 있으므로 원시 Xray 필드를 다른 구성 요소의 TUN 설정에 그대로 적용하지 마세요. 처음 켤 때는 기본값 또는 변경 사항이 적은 설정을 유지하고 인터페이스 생성, 라우팅 설치와 요청 경로를 확인한 뒤 세부 매개변수를 조정하세요.

가상 인터페이스 생성과 시스템 라우팅 변경에는 추가 권한이 필요한 경우가 많습니다. Windows에서는 클라이언트가 요구하는 권한을 부여하고, Linux에서는 인터페이스 생성과 라우팅 변경 권한이 있는지 확인하세요. macOS에서는 클라이언트가 요청하는 시스템 권한을 승인해야 합니다. 권한 오류는 로그와 시스템 알림에서 확인해야 하며 스위치 상태만 보고 성공 여부를 판단해서는 안 됩니다. 스위치가 켜져도 인터페이스가 생성되지 않거나 라우팅이 설치되지 않으면 앱은 기존 경로를 계속 사용할 수 있습니다. 이 경우 분할 라우팅을 바꾸기 전에 권한이나 시작 오류부터 해결하세요.

루프와 이중 트래픽 처리 방지

TUN이 캡처한 연결은 아웃바운드를 통해 네트워크 연결을 다시 설정합니다. 아웃바운드 자체의 연결이 그대로 입구로 돌아가면 순환이 발생할 수 있습니다. 클라이언트는 보통 인터페이스 선택, 라우팅 제외 또는 다른 방식으로 이를 처리합니다. 기기에서 다른 VPN, 게이트웨이 소프트웨어나 두 번째 트래픽 처리 도구를 함께 실행하면 각 기능이 서로 덮어쓸 수 있습니다. 다른 도구를 먼저 끄고 비교한 다음 하나씩 다시 켜면서 라우팅 충돌이 생기는지 확인하세요. 각각 '연결됨'으로 표시된다고 두 소프트웨어가 함께 작동한다고 단정할 수는 없습니다.

TUN을 켠 뒤 시스템 프록시를 유지할지도 결정해야 합니다. 앱 요청이 먼저 로컬 프록시로 전송된 뒤 다른 경로에서 다시 처리되면 중복 처리, 우회 또는 이해하기 어려운 로그가 생길 수 있습니다. 클라이언트마다 모드 설계가 다르므로 두 기능을 반드시 함께 켜거나 꺼야 한다고 단정하지 마세요. 현재 모드의 안내에 따라 설정하고 각각 테스트하세요. 로컬 프록시 포트가 여전히 요청을 처리하는지 살펴보면 시스템 프록시를 끈 뒤 일부 앱의 동작이 달라지는 이유를 파악하는 데 도움이 됩니다.

MTU, UDP 및 로컬 네트워크 접근

MTU는 인터페이스에서 허용하는 패킷 크기를 결정합니다. 경로에 추가된 캡슐화와 네트워크 조건으로 큰 패킷에 문제가 생길 수 있지만, MTU를 지나치게 낮추면 분할과 처리 부담이 증가할 수 있습니다. '핸드셰이크는 성공하지만 전송이 멈춤' 또는 특정 대용량 요청 실패 같은 징후가 있을 때만 MTU를 점검하세요. 값을 조금씩 조정하고 같은 요청을 다시 테스트해야 합니다. 특정 값을 모든 플랫폼에 공통으로 적용할 수 있다고 생각하지 마세요. UDP는 별도로 검증해야 합니다. 웹페이지에서 TCP가 정상이라고 UDP를 사용하는 앱도 정상이라는 뜻은 아닙니다.

로컬 네트워크 프린터, 파일 공유와 장치 검색은 별도로 확인해야 합니다. 일부 기능은 브로드캐스트나 멀티캐스트에 의존하므로 사설 주소 직접 연결 규칙 하나로 모두 복구되지는 않습니다. 우선 일반 로컬 네트워크 주소에 연결되는지 확인한 다음 가상 인터페이스나 방화벽이 장치 검색에 영향을 주는지 살펴보세요. TUN이 기기의 트래픽을 처리한다고 해서 다른 기기가 이 기기의 프록시를 사용할 수 있는 것은 아닙니다. 프록시 공유에는 수신 범위와 방화벽을 별도로 설정해야 합니다. 자세한 내용은 로컬 네트워크 연결 허용 안내를 참고하세요.

단계별 검증과 종료 후 복구

활성화 후에는 구성 요소 시작 여부, 인터페이스와 라우팅, DNS 순으로 확인한 다음 브라우저, 기존에 시스템 프록시를 따르지 않던 앱과 로컬 서비스를 각각 테스트하세요. Android에서 시스템 VPN으로 트래픽을 처리할 때는 앱 포함·제외 범위와 백그라운드 실행 제한도 확인해야 합니다. 트래픽 처리를 끈 뒤에도 네트워크가 비정상이라면 스위치를 반복해서 켜고 끄지 말고 시스템 프록시, DNS와 남아 있는 라우팅이 복구됐는지 확인하세요. 기본 상태를 복구한 뒤 도움말 센터에서 증상에 맞는 항목을 찾아 계속 점검할 수 있습니다.

FakeDNS와 도메인 복원

FakeDNS는 대상 서비스의 실제 주소를 반환하지 않고 도메인에 관리용 주소를 할당해 둘 사이의 매핑을 저장합니다. 앱이 이 주소에 연결하면 처리 구성 요소가 매핑을 통해 도메인을 복원한 뒤 라우팅과 아웃바운드를 결정합니다. 앱이 네트워크 계층에 IP만 제공하는 상황에서도 도메인 정보를 유지할 수 있지만, DNS 조회와 이후 연결이 모두 서로 연동되는 처리 경로를 통과해야 합니다. 일반 DNS의 별칭이 아니며 DNS 서버 주소 하나를 입력한다고 전체 설정이 끝나는 것도 아닙니다.

요청 전체 경로부터 확인

전체 경로에는 앱의 DNS 조회, FakeDNS가 매핑 주소를 반환하는 과정, 앱이 매핑 주소에 연결하는 과정, 입구에서 도메인을 복원하는 과정이 포함됩니다. 한 단계라도 처리 구성 요소를 우회하면 앱이 접근할 수 없는 관리용 주소에 연결할 수 있습니다. 시스템 DNS가 처리되지 않거나 앱이 자체 DNS 경로를 사용하거나 대상 주소가 예상한 인터페이스로 들어오지 않거나 클라이언트 입구에서 도메인 복원을 활성화하지 않은 경우가 흔한 원인입니다. DNS와 트래픽 처리가 정상임을 먼저 확인한 다음 FakeDNS를 도입하세요. DNS가 이미 불안정한 상태에서 기능을 더 얹지 마세요.

코어와 TUN 구성 요소에 따라 비슷한 개념이라도 지원 필드가 다를 수 있습니다. Xray의 FakeDNS는 내장 DNS 및 입구 스니핑 설정과 함께 사용해야 합니다. 다른 구성 요소의 fake-IP 기능에 Xray 필드를 그대로 적용해서는 안 됩니다. 현재 실행 중인 구성 요소가 해당 기능과 적절한 입구를 명시적으로 지원할 때만 설정하세요. 클라이언트에서 일반 DNS 방식만 선택할 수 있다면 아래 조각을 정체를 알 수 없는 입력란에 붙여 넣지 마세요. 매핑을 흉내 내려고 구독 항목의 서버 주소를 수정해서도 안 됩니다.

주소 풀과 매핑 용량

아래는 Xray 주소 풀 설정 예시이며, 이것만으로 FakeDNS 요청 경로 전체가 활성화되지는 않습니다. ipPool은 관리용 주소 범위를 지정하고 poolSize는 매핑 풀의 용량을 지정합니다. 예시의 네트워크 대역은 특수 용도로 사용되므로 앱이 직접 접근할 수 있는 공용 서비스 주소가 아닙니다. 기기의 기존 네트워크나 다른 트래픽 처리 도구의 주소 범위와 충돌하지 않는지도 확인해야 합니다. 용량은 구성 요소가 지원하는 범위에 맞춰야 합니다. 성능을 이유로 무작정 늘리거나 선택한 주소 범위의 수용량을 초과하지 마세요.

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

매핑 풀은 용량에 한계가 있어 부하가 높으면 구성 요소가 오래된 매핑을 회수할 수 있습니다. 앱이 관리용 주소를 오래 캐시하면 이후 연결에서 매핑이 없거나 달라지는 문제가 생길 수 있으므로 매핑 수명과 앱 캐시를 함께 고려해야 합니다. 장시간 실행 후에만 문제가 나타났다가 재시작하면 잠시 해결된다고 해서 서버 불안정으로 단정할 수 없습니다. 앱이 이전 주소를 보유하고 있거나 트래픽 처리 구성 요소가 다시 시작되면서 기존 매핑이 사라졌을 수도 있습니다. 문제를 점검할 때 재시작 시각, 캐시와 재현 시점의 관계를 기록하세요.

매핑 사용에 적합하지 않은 상황

로컬 네트워크 서비스, 실제 IP만 받는 도구, DNS 결과를 다른 기기로 전달하는 앱은 관리용 주소를 사용하기에 적합하지 않을 수 있습니다. 예를 들어 이 기기에서 받은 매핑 주소를 로컬 네트워크의 다른 기기에 전달해도, 그 기기에 같은 매핑이 없으면 연결할 수 없습니다. 예외가 필요하다면 현재 구성 요소가 지원하는 도메인 제외 또는 실제 DNS 확인 방식을 사용하고, 예외 요청의 후속 라우팅도 일치하는지 확인하세요. DNS 조회만 제외하고 실제 연결은 부적합한 아웃바운드로 보내는 실수를 피해야 합니다.

앱이 암호화된 DNS를 자체적으로 사용하거나 IP에 직접 연결한다면 FakeDNS가 전혀 관여하지 않을 수 있습니다. 이때 로그에 매핑이 보이지 않는다고 기능이 고장 난 것은 아닙니다. 요청이 다른 경로로 전달된 것일 수 있습니다. 앱의 DNS 동작을 바꿔야 한다면 앱에서 제공하는 설정에 따라 조정하세요. 모든 조회가 가로채질 것이라고 투명하게 가정하면 오판하기 쉽습니다. 스니핑에도 프로토콜 한계가 있으며, 특히 식별 가능한 호스트 정보가 없는 요청에서 원래 도메인을 항상 복원할 수는 없습니다.

작은 범위의 테스트로 효과 확인

반복 테스트가 가능한 일반 대상 하나를 선택해 조회 결과가 관리용 주소인지, 연결이 처리되는지, 로그에서 원래 도메인을 확인할 수 있는지, 최종적으로 예상한 아웃바운드가 선택되는지 확인하세요. 이어서 로컬 네트워크 대상 하나와 설정에서 예외 처리한 대상 하나를 검사해 실제 DNS 확인을 계속 사용하는지 살펴보세요. 현재 요청에 이미 도메인이 포함되어 있어 기존 도메인 규칙이 작동한다면 FakeDNS가 별다른 이점을 주지 않을 수 있습니다. 단순한 라우팅과 DNS 설정이 대개 유지 관리하기 쉬우므로 기능을 켜기 위해 설정을 복잡하게 만들 필요는 없습니다.

되돌릴 때는 관련 매핑 설정을 순서대로 끄고 DNS 방식을 복구한 다음 영향을 받은 구성 요소와 앱을 다시 시작하고 기본 설정을 재테스트하세요. 스위치 하나만 끄고 이전 주소 풀 라우팅을 남겨 두거나 DNS만 바꾼 채 앱이 매핑 주소를 계속 보유하게 두면 문제가 이어질 수 있습니다. 실험 설정과 안정적인 설정을 각각 저장해 두면 다음 유지 관리 때 FakeDNS를 위해 설정한 항목을 구분할 수 있어 필드 하나를 삭제한 뒤 이해하기 어려운 요청 경로 일부만 남기는 일을 방지할 수 있습니다.

다중 구독 관리와 업데이트 제어

다중 구독 관리의 핵심은 목록을 길게 만드는 것이 아니라 각 출처의 관리 범위를 명확히 하는 것입니다. 한 출처는 일상 연결용이고 다른 출처는 특정 환경이나 대체용이라면 그룹을 각각 만들고 용도를 설명하세요. 구독 가져오기 성공, 서버 매개변수의 정확성, 실제 연결 가능 여부는 서로 다른 결과이므로 각각 확인해야 합니다. 출처끼리 출처를 알 수 없는 인증 정보를 공유해서도 안 됩니다. 누가 제공했는지, 왜 필요한지 설명할 수 없는 링크는 장기간 자동 업데이트에 추가하기에 적합하지 않습니다.

출처 목록과 업데이트 주기 관리

각 구독의 출처 이름, 용도, 마지막 수동 확인 결과와 업데이트에 프록시가 필요한지를 기록하세요. 공개 파일에 기록할 필요도 없고 전체 링크를 저장할 필요도 없습니다. 문제가 생겼을 때 어느 출처에 확인해야 하는지 알 수 있으면 됩니다. 자동 업데이트 주기는 제공 방식과 사용 목적에 맞춰 설정하세요. 너무 자주 가져오면 서버 측 요청 제한에 걸리거나 클라이언트 목록이 빈번하게 바뀔 수 있습니다. 사용 빈도가 낮거나 호환성을 테스트 중인 그룹은 수동 업데이트가 적합합니다.

시작 시 자동 업데이트는 편리하지만 네트워크가 아직 안정되지 않은 상황도 고려해야 합니다. 기기가 무선 네트워크에 막 연결됐거나 프록시가 아직 실행되지 않았거나 계정 페이지 인증이 필요한 경우 구독 요청이 실패할 수 있습니다. 먼저 저장된 연결을 사용할 수 있게 만든 다음 필요하면 프록시를 통해 업데이트해야 하는 출처를 갱신하세요. 유일하게 작동하는 연결을 구독에서 가져와야 하는데 구독을 가져오려면 아직 없는 그 연결이 필요한 상황을 만들면 업데이트 과정이 순환 의존에 빠집니다.

모든 출처를 한꺼번에 바꾸지 말고 그룹별로 업데이트

여러 출처를 관리할 때는 그룹 하나를 먼저 업데이트하고 항목 추가·삭제와 오류를 확인한 뒤 주요 서버를 테스트하세요. 결과를 확인한 후 다음 그룹으로 넘어가면 한 출처가 잘못된 내용을 반환해도 비교 대상 전체를 동시에 잃지 않습니다. 중요한 수동 수정은 미리 독립 그룹에 복사해 두세요. 구독 내용의 변경은 출처가 관리한다는 점을 받아들이고, 제공자가 철회한 서버를 클라이언트가 계속 보존할 것이라고 기대하지 마세요. 업데이트 방식과 로컬 수정 방식은 따로 설계해야 합니다.

업데이트 후 노드 수가 크게 변했다면 필터 조건, 프로토콜 호환성과 서버 안내 메시지를 먼저 확인한 뒤 실제 내용 변경 여부를 판단하세요. 개수만 비교해서는 품질을 알 수 없습니다. 같은 서버에 여러 전송 포트가 있을 수 있고 이름이 같은 항목이 서로 다른 주소를 가리킬 수도 있습니다. 필요하다면 메모뿐 아니라 주소, 포트, 프로토콜과 전송 매개변수를 비교하세요. 클라이언트가 항목을 파싱하지 못하면 필요한 코어 기능을 확인해야 합니다. 소프트웨어 업데이트로 호환성 문제 일부를 해결할 수는 있지만 올바른 서버 매개변수를 대신해 주지는 않습니다.

중복 항목과 장애 연관성

두 출처에 같은 메모가 있다고 서로 다른 대체 서버라는 뜻은 아닙니다. 주소, 포트, 인증과 전송 조건이 같다면 같은 설정을 중복 배포했을 수 있습니다. 주소가 달라도 동일한 서비스 인프라를 공유할 수 있으므로 구독 수만 보고 장애가 분산됐다고 생각해서는 안 됩니다. 정리할 때는 출처 정보를 보존하고 중복 항목을 함께 관리해야 하는지 확인한 뒤 숨기거나 삭제하세요. 목록을 깔끔하게 만들겠다고 모든 출처 태그를 합쳐 버리면 이후 업데이트와 문제 해결에 필요한 단서를 잃게 됩니다.

장애가 발생하면 먼저 범위를 구분하세요. 항목 하나만 실패하면 해당 항목의 매개변수를 확인합니다. 그룹 전체가 실패하면 출처 상태와 공통 설정을 살펴보세요. 모든 출처에서 실패하면 기기의 네트워크, 시간, 실행 코어, DNS와 트래픽 처리 모드를 확인합니다. 이 순서로 점검하면 불필요한 일괄 삭제와 재가져오기를 줄일 수 있습니다. 대체 출처도 목록에만 두지 말고 실제 요청을 소량 정기적으로 테스트해야 합니다. 사용 가능하다는 기록이 있어야 서버가 많이 보인다는 인상보다 신뢰할 만한 기준이 됩니다.

출처 비활성화 및 설정 복구

더 이상 사용하지 않는 출처는 자동 업데이트를 먼저 중지하고, 현재 활성 서버가 해당 그룹에서 선택된 것인지 확인한 다음 필요에 따라 삭제하세요. 삭제 전에 라우팅이나 사용자 지정 설정이 해당 항목에 간접적으로 의존하지 않는지, 사용 가능한 연결을 유일하게 그 그룹에 남겨 두지 않았는지 확인해야 합니다. 기기를 옮길 때 설정 사본에 구독 주소와 인증 정보가 포함될 수 있으므로 직접 관리하는 안전한 방법으로 옮기세요. 새 기기에서 테스트를 마친 뒤 기존 사본을 정리하면 됩니다. 클라이언트 설정 백업은 공개적으로 공유할 사용 설명서 첨부 파일이 아닙니다.

간단한 유지 관리 기록만으로 충분합니다. 어떤 출처를 업데이트했는지, 어떤 필터를 조정했는지, 현재 안정적으로 사용하는 그룹이 무엇인지, 문제가 생겼을 때 어떻게 되돌리는지 기록하세요. 모든 요청을 번거로운 로그로 남길 필요는 없지만 중요한 변경 사항은 읽기 쉽게 설명해야 합니다. 구독을 파싱할 수 없는 문제가 계속된다면 그룹 및 필터링으로 돌아가 가져오기 과정을 확인하세요. 구독은 정상인데 특정 앱만 실패한다면 출처를 더 추가해 설정 문제를 덮으려 하지 말고 라우팅, DNS 또는 TUN을 점검하세요.

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

아웃바운드는 트래픽이 코어를 빠져나가는 방식을 설명하고, 라우팅은 사용할 아웃바운드를 선택합니다. 서버 목록의 항목을 사용자 지정 규칙에서 메모 이름으로 바로 참조할 수 있는 것은 아닙니다. 규칙은 보통 실행 설정에 정의된 아웃바운드 태그를 참조합니다. 사용자 지정 설정을 시작하기 전에 추가 직접 연결, 명시적 차단, 특정 서버 아웃바운드 또는 여러 아웃바운드의 체인 연결 중 무엇이 필요한지 정하세요. 목적에 따라 필요한 필드가 달라집니다. 사용자 지정 기능은 클라이언트의 일반 설정으로 표현할 수 없는 요구를 해결할 때 사용하며 일상 설정의 첫 단계로 삼지 않는 것이 좋습니다.

태그는 같은 설정 안에서 연결되어야 함

각 아웃바운드에 알아보기 쉽고 고유한 tag를 지정하고, 규칙의 outboundTag 값을 정확히 일치시켜야 합니다. 태그는 표시용 이름이 아니며 대소문자가 비슷하다고 자동으로 연결되지 않습니다. 규칙을 복사할 때 다른 사람의 태그를 참조하면서 해당 아웃바운드를 정의하지 않는 실수가 흔합니다. 클라이언트가 설정을 다시 생성하면서 아웃바운드 구성을 바꾸는 경우도 있으므로 장기간 사용할 규칙은 지원되는 메뉴를 통해 저장하고 실제 생성된 설정을 확인하세요. 편집 상자에 텍스트가 있는지만 확인해서는 안 됩니다.

아래 Xray 예시는 두 가지 기본 아웃바운드만 정의합니다. freedom은 직접 연결, blackhole은 차단에 사용합니다. 프록시 서버 아웃바운드와 인바운드, 완전한 라우팅 설정은 포함하지 않으므로 전체 설정으로 실행할 수 없습니다. 기존 설정에 병합할 때는 태그가 중복되지 않는지 확인하세요. 앞서 라우팅 예시에서 사용한 proxy를 사용하려면 같은 설정 안에 실제 프록시 아웃바운드가 정의되어 있어야 합니다. 서버 매개변수를 빈 객체로 대신할 수는 없습니다.

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

직접 연결 시 DNS 확인과 서버 프로토콜 설정

직접 연결 아웃바운드는 최종적으로 실제 대상 주소에 연결해야 하므로 도메인이 포함되면 DNS 확인 경로도 고려해야 합니다. Xray의 freedom 설정에서 domainStrategy는 직접 연결 단계의 도메인 처리 방식을 바꿀 수 있지만, routing.domainStrategy와는 다른 설정입니다. 전자는 아웃바운드 연결 설정에, 후자는 라우팅 일치에 사용됩니다. 이름이 같다고 두 설정을 함께 바꾸지 마세요. 문제가 규칙 선택 전인지 연결 설정 중인지 먼저 판단한 뒤 해당 계층을 조정하세요.

프록시 아웃바운드에는 서비스 제공자가 안내한 프로토콜과 매개변수를 사용해야 합니다. 프로토콜 이름 하나만 보고 나머지 필드를 추측할 수는 없습니다. 주소, 포트, 인증, 전송과 보안 설정은 서로 맞아야 합니다. REALITY를 사용할 때는 서버가 제공한 관련 매개변수도 필요하므로 필드의 용도는 REALITY 용어 설명을 참고하세요. 코어마다 지원 범위가 다르며 코어 간 관계는 Xray 항목에서 확인할 수 있습니다. 구문 검사를 통과시키려고 필수 매개변수를 비워 두지 마세요.

아웃바운드 체인이 자동 장애 조치를 뜻하지는 않음

한 아웃바운드가 다른 아웃바운드를 통해 연결을 설정한다면 하위 연결의 접근 가능 여부, DNS 확인 위치와 UDP 지원을 모두 고려해야 합니다. Xray에서는 proxySettings로 아웃바운드 프록시 관계를 설정할 수 있지만 다른 구성 요소는 필드가 다를 수 있으므로 현재 코어 구조에 맞게 참조해야 합니다. 한 아웃바운드가 다른 아웃바운드에 의존하고 다시 그 아웃바운드가 처음 아웃바운드에 의존하는 순환도 피해야 합니다. 연결 계층이 늘면 장애 요인도 증가합니다. 체인 연결이 자동으로 가용성을 높이지 않으며 태그 순서만으로 서버가 자동 전환되는 것도 아닙니다.

자동 선택이나 장애 조치에는 적절한 상태 확인과 선택 기능이 필요합니다. 어떤 조건을 실패로 볼지, 언제 전환할지, 기존 연결을 어떻게 처리할지도 명확히 정해야 합니다. 이런 기능이 없다면 아웃바운드를 여러 개 정의해도 코어가 자동으로 차례대로 시도하지 않습니다. 대부분의 설정 검토에서는 각 아웃바운드를 따로 검증한 뒤 명확한 대상에 고정 규칙을 지정하는 방식이 더 안전합니다. 체인 연결은 하위 아웃바운드, 상위 서버 연결, 최종 대상 요청 순서로 검증해 세 계층의 오류를 '노드 시간 초과' 하나로 뭉뚱그리지 않도록 하세요.

구조를 확인한 뒤 비교 테스트 실행

설정은 세 단계로 검증하세요. 먼저 JSON에 불필요한 쉼표, 닫히지 않은 따옴표나 중복 필드가 있는지 확인합니다. 다음으로 현재 코어가 각 필드를 지원하는지, 태그 참조가 모두 정의되어 있는지 살펴봅니다. 마지막으로 구성 요소를 시작해 실제 요청을 확인합니다. 구문이 올바르다고 필드가 유효한 것은 아니며 코어 시작에 성공해도 규칙 선택이 목표와 일치한다는 보장은 없습니다. 다른 구성 요소에서 복사한 이름이 같은 필드와 잘못된 계층에 조각을 넣는 경우에 특히 주의하세요. 설정 오류가 발생하면 저장한 원본을 복구한 뒤 필요한 내용을 하나씩 추가합니다.

실행 검증에는 대상 규칙, 기본 경로, DNS와 로컬 서비스가 최소한 포함되어야 합니다. 로그에서 새 설정이 로드됐는지, 예상한 아웃바운드를 선택했는지, DNS 확인·핸드셰이크·전송 중 어느 단계에서 실패했는지 확인하세요. 테스트가 끝나면 임시로 높인 로그 수준을 일상 사용에 적합하게 되돌리고 불필요한 실험 규칙을 삭제합니다. 안정적인 설정은 각 아웃바운드의 용도와 예외 규칙의 이유를 설명할 수 있어야 합니다. 설명할 수 없는 텍스트가 길게 남으면 처음 문제보다 유지 관리 위험이 더 커질 수 있습니다.

사용자 지정 설정으로 기본 연결에 문제가 생기면 먼저 사용 가이드에 따라 빠른 시작 경로를 복구한 다음 증상에 맞는 섹션을 다시 확인하세요. 클라이언트 설치 파일을 교체해야 한다면 다운로드 페이지를 이용하세요. 설정 문제를 설치 파일 탓으로 바로 돌려서는 안 됩니다. 고급 설정의 기준은 필드 수가 아니라 요청 경로가 명확하고, 문제가 재현 가능하며, 변경 사항을 되돌릴 수 있고, 일상적으로 사용하는 앱이 실제로 검증됐는지에 있습니다.