V2Ray 고급 설정 가이드

구독 그룹 및 서버 필터링

구독 출처와 서버 선택을 구분하세요

구독은 원격에서 제공하는 서버 설정 모음이고, 그룹은 클라이언트에서 이 설정들을 정리하는 로컬 단위이며, 현재 선택한 서버는 실제 연결에 사용되는 출구입니다. 세 가지는 서로 대체할 수 없습니다. 출처별로 서버 주소를 다른 구독 그룹에 넣으면 업데이트가 실패했을 때 문제의 원인을 쉽게 찾고, 이름이 비슷한 서버가 한 목록에 뒤섞이는 것도 방지할 수 있습니다. 구독을 추가할 때는 먼저 그룹을 알아보기 쉬운 이름으로 지정하고 주소를 입력한 뒤 직접 한 번 업데이트하세요. 업데이트가 끝나면 성공 알림만 확인하지 말고 그룹 안의 서버 수와 프로토콜 유형도 살펴보세요.

v2rayN의 구독 설정과 서버 목록에서 그룹을 선택할 수 있습니다. 버전에 따라 그룹 메뉴가 사이드바, 상단 옵션 또는 구독 설정 안에 있을 수 있습니다. 작업 순서는 동일합니다. 그룹을 선택하고 업데이트한 다음 현재 목록을 좁혀 서버를 고르세요. 업데이트 후에도 이전 항목이 보인다면 방금 업데이트한 그룹을 보고 있는지 먼저 확인하세요. 그룹을 바꾸면 대개 목록 범위만 달라지며, 현재 활성 서버가 자동으로 바뀌지는 않습니다. 활성 서버는 별도로 확인해야 합니다. 목록에서 첫 번째로 보이는 항목이 실제 연결 중인 서버라고 단정하지 마세요.

필터는 표시 항목만 바꾸며 구독 내용은 수정하지 않습니다

서버 필터는 항목이 많은 구독을 정리할 때 유용합니다. 예를 들어 이름의 지역 표기로 범위를 좁힌 다음 프로토콜이나 메모를 보고 원하는 서버를 찾을 수 있습니다. 이름은 구독 제공자가 관리하고 표기 방식도 제각각이므로, 필터 검색어만으로 서버의 위치나 가용성, 보안성을 판단할 수는 없습니다. 필터 결과에서 기존 항목이 보이지 않으면 업데이트 중 삭제됐다고 판단하기 전에 검색어를 지우고 그룹 필터도 해제하세요. 특히 여러 구독에서 같은 서버 이름을 쓸 수 있으므로 필터 결과만 보고 여러 항목을 한꺼번에 삭제하지 마세요.

서버를 비교할 때는 같은 테스트 방법과 네트워크 환경을 유지하세요. TCP 연결 테스트는 연결 수립 과정의 일부만 확인합니다. 웹 페이지 로딩에는 TLS 핸드셰이크, 도메인 조회, 라우팅, 대상 서비스 상태도 영향을 줍니다. 한 번 측정한 지연 시간 순위만으로 안정성을 판단하면 이런 차이를 놓칠 수 있습니다. 먼저 지연 시간 테스트 방법 비교를 확인한 뒤 후보 서버에 실제로 접속해 보세요. 속도 측정 결과는 선택을 돕는 참고 자료일 뿐, 구독 메모에 장기간 변하지 않는 수치처럼 기록하지 않는 것이 좋습니다.

로컬 수정 범위를 분리하세요

구독 서버의 주소, 포트, 인증 정보는 구독 제공자가 관리합니다. 구독이 관리하는 항목을 직접 수정하면 다음 업데이트에서 변경 내용이 덮어써질 수 있습니다. 서버 하나를 임시로 조정해야 한다면 먼저 별도의 로컬 항목으로 복사하고, 메모에 변경 목적을 적어 두세요. 연결을 확인한 뒤 유지할지 결정하면 됩니다. 항목을 복사해도 원격 구독 내용은 바뀌지 않으므로 원본과 테스트 항목을 구분하세요. 특히 전송 설정을 점검할 때는 한 번에 매개변수 하나만 수정해 구독 변경과 로컬 테스트가 뒤섞이지 않도록 하세요.

구독 업데이트 후 이름이 같은 항목이 많이 나타나면 목록을 바로 삭제하지 말고 같은 출처를 중복으로 추가했는지 먼저 확인하세요. 두 그룹이 같은 구독 주소를 가리키면서 업데이트 설정만 다를 수도 있고, 제공자가 같은 이름을 반복해서 사용했을 수도 있습니다. 처리하기 전에 그룹 출처와 각 항목의 소속을 비교하세요. 그룹을 정리하기 전에는 현재 활성 서버가 어느 그룹에 속하는지 기록하고, 문제가 생겼을 때 되돌릴 수 있는 대안을 마련하세요. 목록에 표시된 항목을 삭제하는 것과 구독 출처를 제거하는 것은 영향이 다르므로 실행 전 확인 문구를 꼼꼼히 읽으세요.

업데이트 요청 자체가 실패하면 먼저 구독 주소에 접속할 수 있는지 확인한 다음, 현재 시스템 프록시 때문에 업데이트 트래픽이 사용할 수 없는 출구로 전달되는지 살펴보세요. 일부 클라이언트는 구독 업데이트에 별도의 연결 방식을 지정할 수 있습니다. 현재 네트워크 환경에 맞는 방식을 선택하세요. 오류가 DNS 조회 실패나 연결 시간 초과를 가리킨다면 네트워크 경로부터 해결하고, 업데이트는 성공했지만 서버가 나타나지 않는다면 응답 내용이 클라이언트가 인식하는 구독 형식인지 확인하세요. 오류 내용을 살펴보지 않은 채 업데이트 버튼만 반복해서 누르지 마세요. 구독 출처가 정상화된 뒤 다시 업데이트하고 항목 변화를 확인해야 점검이 끝납니다.

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

모든 출처를 합치지 말고 용도별로 그룹을 만드세요

구독을 여러 개 관리할 때 흔히 겪는 문제는 항목이 너무 많은 것보다 설정의 출처를 알아보기 어렵다는 점입니다. 업무 환경, 사용 기기 또는 출처별 관리 방식에 따라 그룹을 나누고 각각 이름과 업데이트 설정을 따로 유지하세요. 이름만 보고도 출처 차이를 알 수 있게 정하고 모두 '기본'이나 '자주 사용'으로 지정하지 마세요. 두 구독에 이름이 같은 서버가 있어도 그룹을 기준으로 구분할 수 있습니다. 데스크톱은 주로 v2rayN을 기준으로 설명합니다. Android용 v2rayNG와 v2flyNG는 각자 구독 기록을 관리하므로 데스크톱 그룹이 모바일 기기에 자동 동기화된다고 가정하면 안 됩니다.

새 출처를 등록했다면 먼저 해당 그룹만 업데이트하세요. 예상한 수의 항목이 나타나는지, 서버 프로토콜이 올바르게 인식되는지, 기존 활성 서버를 계속 사용할 수 있는지 확인한 뒤 자동 업데이트를 설정하면 됩니다. 이렇게 하면 최초 가져오기 오류와 이후 출처 변경을 구분할 수 있습니다. 자동 업데이트 주기는 짧을수록 좋은 것이 아닙니다. 요청이 잦으면 실패 기록이 불필요하게 늘고 사용 중 목록이 바뀔 수도 있습니다. 출처에 변화가 드물다면 수동으로 업데이트하고 설정 조정 전후의 결과를 비교하는 편이 원인을 추적하기 쉽습니다.

업데이트가 영향을 주는 범위를 파악하세요

구독 업데이트는 해당 출처의 서버를 추가하거나 수정하거나 제거할 수 있습니다. 클라이언트의 모든 설정을 초기화하는 작업은 아닙니다. 로컬 라우팅, DNS, 시스템 프록시 상태, 다른 그룹은 각각 따로 확인해야 합니다. 반대로 로컬 라우팅을 수정해도 구독 내용에는 반영되지 않습니다. 업데이트 후 접속할 수 없다면 서버 설정이 바뀐 것인지, 라우팅이나 DNS도 동시에 변경한 것인지 먼저 구분하세요. 이전에 작동했던 로컬 항목 하나를 비교 대상으로 삼고 업데이트 로그와 활성 항목을 확인하면 클라이언트를 바로 재설치하는 것보다 원인을 빨리 찾을 수 있습니다.

일부 구독 제공자는 항목 이름은 그대로 두면서 실제 주소나 전송 매개변수를 바꾸기도 합니다. 따라서 이름이 같다는 이유만으로 설정도 그대로라고 볼 수 없습니다. 복잡한 라우팅 테스트 중이라면 업데이트 전에 클라이언트 설정을 내보내거나 민감한 정보가 없는 변경 기록을 남겨 두세요. 업데이트 후에는 활성 서버가 사용하는 필드를 중점적으로 확인하세요. 전체 설정 내보내기 파일에는 구독 주소나 서버 인증 정보가 포함될 수 있으므로 안전한 위치에 보관하고 공개 게시물에 그대로 붙여 넣지 마세요. 문제 해결 자료를 공유할 때는 관련 필드만 추려 인증 정보를 삭제하세요.

사용하지 않는 출처와 중복 항목 정리

한 출처의 업데이트가 계속 실패하더라도 다른 출처의 점검까지 막히게 두지 마세요. 해당 주소에 접속할 수 있는지, 응답 내용이 비어 있지는 않은지 따로 확인한 뒤 업데이트를 일시 중지할지 그룹을 삭제할지 결정하세요. 일시 중지와 삭제는 서로 다른 작업입니다. 일시 중지하면 비교를 위해 기존 서버를 유지할 수 있지만, 삭제하면 해당 그룹의 로컬 목록도 함께 정리될 수 있습니다. 삭제 전에 다른 사용 가능한 서버로 전환하고, 해당 그룹을 참조하는 자동 선택이나 라우팅 규칙이 남아 있지 않은지 확인하세요. 네트워크 시간 초과 한 번만으로 구독이 영구적으로 만료됐다고 판단하지 마세요.

중복 서버가 항상 오류인 것은 아닙니다. 같은 이름이라도 프로토콜, 포트, 전송 방식이 다를 수 있고, 주소가 같더라도 출처마다 매개변수가 다를 수 있습니다. 정리할 때는 표시 이름만 보고 일괄 삭제하지 말고 항목별로 비교하세요. 실제로 출처가 중복됐다면 업데이트가 안정적이고 설명이 명확한 쪽을 남기고 나머지는 업데이트 대상에서 제외하세요. 그런 다음 목록 필터를 모두 해제하고 현재 활성 항목이 남긴 그룹에 속하는지 확인한 뒤 실제 접속을 테스트하세요. 이 순서를 따르면 목록 정리는 끝났지만 현재 연결은 끊기는 상황을 피할 수 있습니다.

조정할 때마다 최소한의 변경 기록을 한 줄씩 남기세요. 변경한 그룹, 실행한 작업, 활성 서버, 검증 결과면 충분합니다. 서버 인증 정보는 기록하지 않아도 됩니다. 구독이 여러 개라면 이 기록으로 업데이트 이후 문제가 시작된 시점과 되돌릴 그룹을 빠르게 찾을 수 있습니다. 특정 기기에서만 문제가 재현된다면 두 기기의 구독 업데이트 시각과 로컬 라우팅도 각각 확인하세요. 같은 출처 주소를 사용해도 클라이언트마다 현재 항목 상태가 완전히 같다고 보장할 수는 없습니다.

라우팅 규칙 실전: 매칭과 아웃바운드 순서

트래픽이 라우터까지 들어오는지 먼저 확인하세요

라우팅 규칙은 코어에 들어온 연결을 어떤 아웃바운드로 보낼지 결정합니다. 클라이언트로 들어오지 않은 앱 트래픽을 규칙만으로 프록시에 연결할 수는 없습니다. 시스템 프록시를 사용하는 브라우저는 보통 로컬 HTTP 또는 SOCKS 포트로 요청을 보냅니다. 시스템 프록시를 따르지 않는 프로그램은 별도로 설정하거나 TUN으로 트래픽을 받아야 합니다. 규칙을 작성하기 전에 대상 앱의 트래픽이 어디로 들어오는지 확인하세요. 그렇지 않으면 규칙이 올바르더라도 기대한 결과가 나타나지 않습니다. 규칙 매칭은 도메인을 식별할 수 있는지에도 영향을 받습니다. 대상 IP만 있는 연결에서 도메인 분류를 자동으로 알아낼 수는 없습니다.

라우팅 방식은 대체로 규칙 기반, 전체 프록시, 전체 직접 연결로 나뉘지만 실제 동작은 클라이언트가 생성한 설정에 따라 달라집니다. 규칙 기반 모드에서는 보통 위에서 아래로 규칙을 확인하고, 일치하는 규칙이 있으면 지정된 아웃바운드를 사용합니다. 어느 규칙에도 일치하지 않으면 기본 아웃바운드로 연결됩니다. 규칙을 검토할 때는 조건, 순서, 아웃바운드 식별자, 기본 경로를 함께 확인하세요. 범위가 넓은 규칙을 앞에 두면 뒤의 세부 규칙이 적용되지 않을 수 있습니다. 테스트는 설명하기 쉬운 소수의 규칙부터 시작해 한 줄씩 늘리세요. 출처가 다른 규칙 세트를 한꺼번에 가져오지 마세요.

명확한 매칭 조건부터 설정하세요

아래 예시는 도메인 분류, 특정 도메인, 로컬 네트워크 주소가 각각 어떻게 쓰이는지 보여 줍니다. 설정 구조를 설명하는 예제이므로 클라이언트에서 사용하려면 proxy와 direct 두 아웃바운드 식별자가 존재하는지, 코어에 규칙이 사용하는 도메인 분류 데이터가 있는지 확인해야 합니다. geosite:는 분류 데이터를 기준으로 매칭하며 문자열 포함 여부를 검색하는 방식과 다릅니다. domain:과 full:은 매칭 범위가 다르므로 정확한 대상을 검증할 때는 먼저 full:을 사용하세요.

{
  "routing": {
    "domainStrategy": "AsIs",
    "rules": [
      {
        "type": "field",
        "domain": ["full:example.com"],
        "outboundTag": "proxy"
      },
      {
        "type": "field",
        "domain": ["geosite:private"],
        "outboundTag": "direct"
      },
      {
        "type": "field",
        "ip": ["geoip:private"],
        "outboundTag": "direct"
      }
    ]
  }
}

AsIs는 도메인을 유지해 도메인 규칙으로 판단하는 방식입니다. IP 주소로 판단해야 한다면 선택한 도메인 전략이 언제 조회를 시작하는지, 조회 결과가 IP 규칙에 전달되는지 이해해야 합니다. 이 설정을 바꾸면 DNS 요청 수와 라우팅 규칙의 매칭 결과가 함께 달라질 수 있으므로 특정 웹사이트의 접속 결과만으로 전체 트래픽 동작을 추측하면 안 됩니다. geoip:private는 사설 IP 주소 범위를 대상으로 합니다. 로컬 네트워크 기기에 접속할 수 없다면 이 규칙뿐 아니라 DNS 응답 주소와 시스템이 로컬 네트워크 트래픽을 클라이언트로 보내는지도 확인하세요.

대조 테스트로 규칙 충돌을 찾으세요

새 규칙이 적용되지 않으면 먼저 앞에 있는 규칙이 이미 매칭되는지 확인한 다음 규칙이 참조하는 아웃바운드 식별자를 살펴보세요. 도메인 규칙이 매칭되지 않는다면 요청이 도메인 형태로 들어오는지, 앱이 먼저 직접 조회하지는 않는지, 필요한 분류 데이터를 사용할 수 있는지 확인하세요. IP 규칙이 매칭되지 않으면 연결 대상 주소와 도메인 전략의 처리 결과를 확인하세요. '웹 페이지가 열리지 않음'보다 로그에 기록된 라우팅 대상이 원인을 찾는 데 더 유용합니다. 서로 다른 단계의 문제를 혼동하지 마세요. DNS 조회 실패는 대상 연결을 시도하기 전에 발생하지만, 프록시 서버 연결 실패는 대상 도메인 규칙과 무관할 수 있습니다.

특정 사이트를 임시로 테스트하려면 정확한 도메인 규칙을 범위가 넓은 분류 규칙보다 앞에 놓고, 기존 순서를 먼저 기록하세요. 테스트가 끝나면 순서를 복원한 뒤 직접 연결 대상, 프록시 대상, 로컬 네트워크 주소를 각각 확인하세요. 그중 한 종류만 실패하면 해당 아웃바운드나 규칙을 살펴보고, 세 종류가 모두 실패하면 트래픽 진입점과 시스템 프록시 상태부터 확인하세요. 연결 테스트와 실제 접속의 차이는 지연 시간 테스트 안내를 참고하세요. 속도 테스트 성공은 테스트한 경로 일부가 작동한다는 뜻일 뿐, 모든 라우팅 분기가 올바르다는 의미는 아닙니다.

규칙 세트를 업데이트할 때는 파일을 불러왔는지만 보지 말고 분류의 의미와 항목 범위를 확인하세요. 범위가 넓은 분류가 별도로 처리하려던 도메인까지 포함할 수 있습니다. 접속 결과가 갑자기 달라지면 서버를 바꾸기 전에 최근 업데이트된 규칙과 매칭 순서를 확인하세요. 중요한 대상에는 진단용 정확한 규칙 하나를 남겨 두는 편이 예외 규칙을 계속 쌓는 것보다 관리하기 쉽습니다. 좋은 라우팅 설정은 규칙 수가 많은 구성이 아니라 각 규칙의 대상과 출구를 설명할 수 있는 구성입니다.

DNS 설정 최적화와 조회 경로

DNS 조회, 라우팅, 연결을 나눠서 확인하세요

DNS는 도메인을 IP 주소로 변환하지만, 프록시 클라이언트는 누가 조회하는지, 조회 요청을 어느 아웃바운드로 보내는지, 결과를 라우팅 판단에 사용할지도 결정해야 합니다. 브라우저에서 특정 사이트가 열린다고 해서 모든 앱이 같은 DNS를 사용한다는 뜻은 아닙니다. 앱에 자체 조회 기능이 있거나 이전 결과를 캐시했을 수 있습니다. 문제를 확인할 때는 먼저 대상 앱의 연결 방식을 기록하고 클라이언트 로그에서 도메인, 조회 오류, 아웃바운드 선택을 살펴보세요. 트래픽 진입점을 확인하지 않은 채 시스템 DNS, 클라이언트 DNS, 라우팅 모드를 한꺼번에 바꾸면 무엇이 결과를 바꿨는지 알기 어렵습니다.

v2rayN에서는 그래픽 설정이 최종 코어 설정으로 변환되는 과정이 있을 수 있습니다. DNS 설정을 저장한 다음 코어가 다시 로드됐는지 확인하고, 생성된 설정의 dns와 routing 항목을 살펴보세요. 시스템 프록시 모드는 프록시 설정을 따르는 앱의 트래픽을 주로 처리하며, 시스템 자체의 DNS 조회가 프록시 포트를 통과하는 것은 아닐 수 있습니다. TUN 모드는 더 넓은 범위의 트래픽을 처리하지만 앱 자체의 DNS 조회 방식에 영향을 받을 수 있습니다. 따라서 시스템 프록시를 켰다고 해서 모든 DNS 요청이 클라이언트에서 처리되는 것은 아닙니다. 실제 경로를 확인하려면 요청이 코어에 들어오는지, 코어가 어떤 아웃바운드로 보내는지 살펴보세요.

조회 서버를 명확히 지정하세요

아래는 대체 조회 주소와 특정 도메인 규칙 구조를 보여 주는 Xray 코어 DNS 설정의 간략한 예시입니다. 주소는 필드 관계를 설명하기 위한 것이므로 실제 사용 시 현재 네트워크에서 연결할 수 있고 요구 사항에 맞는 DNS 서비스를 선택하세요. 로컬 네트워크 이름, 사내 도메인, 공개 도메인은 서로 다른 조회 경로가 필요할 수 있습니다. domains는 DNS 서버를 적용할 대상을 지정하며 해당 도메인의 최종 프록시 출구를 정하는 설정은 아닙니다.

{
  "dns": {
    "servers": [
      {
        "address": "localhost",
        "domains": ["geosite:private"]
      },
      "1.1.1.1"
    ]
  }
}

로컬 네트워크 기기가 내부 조회 서비스에 의존한다면 모든 요청을 공개 DNS 서버로 보내는 경우 내부 이름을 찾지 못할 수 있습니다. 반대로 모든 공개 도메인을 내부 이름만 처리하는 DNS 서버에 보내면 시간 초과가 발생할 수 있습니다. 먼저 대상 도메인과 로컬 네트워크 이름을 각각 조회해 어느 쪽에서 문제가 생기는지 확인하세요. DNS 서버 주소로 가는 연결을 라우팅 규칙이 예상한 출구로 허용하는지도 살펴보세요. DNS 서버 자체에 연결할 수 없다면 도메인 매칭 표를 바꿔도 네트워크 경로 문제는 해결되지 않습니다.

캐시와 중복 조회로 인한 오판을 방지하세요

DNS를 바꾼 뒤에도 기존 연결과 앱 캐시가 이전 주소를 사용할 수 있습니다. 확인할 때는 해당 앱의 연결을 종료하고 새 요청을 보내세요. 필요하면 페이지 새로고침만 하지 말고 시스템 캐시와 브라우저 동작도 각각 살펴보세요. 도메인 조회는 성공했는데 접속이 되지 않으면 조회된 대상 주소를 기록하고 라우팅이 직접 연결과 프록시 중 어느 쪽을 선택했는지 확인하세요. 브라우저만 실패하고 다른 앱은 정상이라면 브라우저가 별도의 프록시나 보안 DNS를 사용하는지 먼저 확인하세요. 명령줄 도구 하나만 실패한다면 환경 변수와 로컬 SOCKS/HTTP 포트를 점검하세요.

DNS와 라우팅이 교차하는 지점도 있습니다. IP 분류 규칙은 주소가 필요하고 도메인 분류 규칙은 식별 가능한 도메인을 유지해야 합니다. 도메인을 너무 일찍 IP로 변환하면 매칭될 예정이던 도메인 규칙이 조건을 잃을 수 있고, 전혀 조회하지 않으면 주소 기반 판단을 사용할 수 없습니다. 도메인 전략을 선택하기 전에 어떤 대상에 도메인 분류가 필요한지, 어떤 대상에 IP 분류가 필요한지 명확히 한 다음 생성된 설정의 실제 동작을 확인하세요. 특정 전략이 모든 네트워크에서 정답이라고 단정하지 마세요.

설정을 조정한 뒤에는 일관된 테스트 대상을 정해 두세요. 로컬 네트워크 이름 하나, 직접 연결이 명확한 도메인 하나, 프록시 사용이 명확한 도메인 하나를 사용하면 됩니다. 각 대상의 조회 성공 여부와 선택된 아웃바운드를 기록하세요. 이후 구독이나 규칙 세트를 업데이트할 때도 같은 대상으로 다시 테스트하세요. 그러면 조회, 규칙 매칭, 원격 연결 중 어디에서 변화가 생겼는지 알 수 있습니다. 조회 응답은 정상인데 예상과 다른 주소가 반환되면 DNS 구성을 전부 바꾸기보다 로컬 네트워크가 제공한 조회 결과, 앱 캐시, 도메인 적용 규칙을 확인하세요.

TUN 모드와 시스템 프록시의 차이

트래픽 연결 방식 선택

시스템 프록시는 해당 설정을 지원하는 앱에 로컬 프록시 주소를 제공합니다. 브라우저와 일부 데스크톱 프로그램은 이 주소로 연결하지만 모든 프로그램이 시스템 프록시를 읽는 것은 아닙니다. TUN 모드는 가상 네트워크 인터페이스를 만들어 지정된 범위의 IP 트래픽을 클라이언트에서 처리합니다. 더 많은 앱을 연결할 수 있지만 라우팅 테이블, 가상 인터페이스, DNS 가로채기, 권한 등 추가로 확인할 요소가 생깁니다. 먼저 시스템 프록시로 서버, 구독, 기본 라우팅을 확인하세요. 앱이 시스템 프록시를 따르지 않거나 더 넓은 범위의 트래픽 처리가 꼭 필요한 경우에만 TUN을 켜세요.

데스크톱용 v2rayN의 TUN 설정은 시스템 권한이나 추가 네트워크 구성 요소가 필요할 수 있으며, 설정 위치는 운영체제와 클라이언트 화면에 따라 다릅니다. 켜기 전에 활성 서버, 시스템 프록시 모드, DNS 설정, 라우팅 모드 등 현재 정상 작동 상태를 기록하세요. 시작할 때 스위치가 켜졌는지만 보지 말고 클라이언트가 가상 인터페이스 생성에 성공했다고 표시하는지 확인하세요. 일부 시스템에서는 네트워크 확장 기능이나 관리자 권한을 허용해야 합니다. 권한을 거부한 상태에서 스위치를 반복해서 켜고 끄는 것만으로는 인터페이스 생성 실패를 해결하기 어렵습니다. 먼저 로그가 가리키는 권한이나 구성 요소 문제를 해결하세요.

플랫폼별 네트워크 환경 확인

표는 문제를 살펴볼 방향을 정리한 것으로, 운영체제가 달라도 같은 명령을 적용할 수 있다는 뜻은 아닙니다. 가상 네트워크 도구가 이미 실행 중이면 두 프로그램이 기본 경로나 DNS를 모두 수정하려 할 수 있습니다. 이때는 프로그램을 하나씩 종료한 뒤 v2rayN만 실행해 확인하세요. 시스템 프록시에서는 앱이 작동하지만 TUN으로 전환한 뒤 작동하지 않는다면 서버를 바로 바꾸지 말고 두 모드의 트래픽 진입점과 DNS 경로를 비교하세요. 서버는 그대로인데 연결 방식만 달라졌다면 로컬 네트워크 트래픽을 처리하는 단계에서 문제가 생겼을 가능성이 높습니다.

최소한의 범위부터 트래픽 가로채기를 확인하세요

TUN을 켠 뒤에는 일반 웹사이트, 로컬 네트워크 기기, 이전에 시스템 프록시를 따르지 않던 앱 하나를 테스트하세요. 세 대상은 서로 다른 문제를 보여 줍니다. 웹사이트는 DNS나 기본 출구 문제일 수 있고, 로컬 네트워크 연결 실패는 사설 주소가 프록시로 잘못 전달된 경우일 수 있으며, 특정 앱의 실패는 앱 자체 네트워크 스택이나 프로토콜과 관련될 수 있습니다. 테스트 중에는 활성 서버를 그대로 유지하세요. TUN 스위치만 바꿔도 문제가 재현된다면 구독을 다시 가져오기보다 인터페이스 시작 로그, 라우팅 테이블, DNS 상태를 확인하세요.

TUN을 켠 뒤에도 다른 프로그램이 로컬 프록시 포트를 사용할 수 있지만, 같은 앱에 여러 연결 방식을 중복으로 지정하는 것은 피해야 합니다. 앱에 수동 SOCKS를 설정한 상태에서 TUN까지 적용하면 트래픽 경로를 파악하기 어려워집니다. 문제를 확인하는 동안에는 한 가지 명확한 연결 방식만 남기세요. 정상 작동을 확인한 뒤 앱별 설정을 복원할지 결정하면 됩니다. 터미널 프로그램도 마찬가지로 환경 변수가 로컬 HTTP 또는 SOCKS 포트를 계속 가리키는지 확인하세요. TUN을 끈 뒤에는 가상 인터페이스와 관련 경로가 제거됐는지 확인하고 시스템 네트워크가 정상으로 복구됐는지 살펴보세요.

TUN을 꺼도 네트워크에 접속할 수 없다면 시스템 프록시가 중지된 로컬 포트를 계속 가리키는지, DNS가 접속할 수 없는 주소를 사용하는지, 기본 경로가 복구됐는지 차례로 확인하세요. 네트워크 설정을 한꺼번에 초기화하지 말고 남아 있는 변경 사항부터 찾으세요. 회사와 집 네트워크를 자주 오가는 기기라면 두 네트워크에서 로컬 네트워크 접속을 각각 테스트하세요. 사설 주소 범위와 내부 DNS 구성이 다를 수 있습니다. TUN 설정이 제대로 됐는지는 스위치가 켜져 있는지가 아니라 트래픽 처리 범위, 로컬 네트워크 예외, 종료 후 복구 동작이 예상대로 작동하는지로 판단해야 합니다.

FakeDNS의 용도와 한계

합성 주소가 작동하는 방식

FakeDNS는 적용 대상 트래픽 경로에서 도메인 조회에 임시 합성 주소를 반환하고, 해당 주소와 원래 도메인의 매핑을 저장합니다. 앱이 이후 합성 주소에 연결하면 코어가 매핑에서 원래 도메인을 찾아 도메인 라우팅을 계속 적용할 수 있습니다. 일부 네트워크 경로에서 도메인 정보가 너무 일찍 사라지는 문제를 해결하는 기능이지, 모든 DNS 서버를 대체하는 공개 DNS 서비스는 아닙니다. 합성 주소는 대상 사이트의 실제 주소도 아닙니다. 클라이언트와 무관한 네트워크 도구에 이 주소를 입력해도 같은 접속 결과를 얻기 어렵습니다.

FakeDNS를 켜기 전에 현재 문제가 도메인 규칙에서 도메인을 식별하지 못하는 상황인지 확인하세요. 로그에 대상 도메인이 이미 기록되고 규칙도 정상적으로 매칭된다면 FakeDNS를 추가해도 설정만 복잡해질 수 있습니다. 점검은 앱 트래픽이 코어에 들어오는지, DNS 요청도 해당 경로에서 처리되는지, 앱의 연결이 다시 코어를 통과하는지 순서대로 진행하세요. 조회만 가로채고 이후 연결은 처리하지 않거나, 연결만 가로채고 다른 시스템 DNS가 실제 주소를 반환하면 매핑 경로가 완성되지 않습니다.

주소 풀과 라우팅 확인

아래 예시는 Xray의 FakeDNS 주소 풀 구조를 보여 줍니다. fakedns 필드만 보여 주는 예시이며 완전한 클라이언트 설정은 아닙니다. IPv6 주소 풀을 사용할지는 현재 트래픽 처리 방식과 네트워크 환경에 맞춰 결정하세요. 예시의 주소 풀이 실제 사용 중인 네트워크와 겹치지 않아야 합니다. 해당 DNS 요청을 FakeDNS로 보내고 합성 주소로 이어지는 연결도 클라이언트가 처리하도록 설정해야 합니다. 이 필드만 추가하고 트래픽 진입점을 처리하지 않으면 기능이 자동으로 적용되지 않습니다.

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

주소 풀을 정할 때는 현재 네트워크와 다른 가상 네트워크 도구의 라우팅 범위를 먼저 확인하세요. 합성 주소가 기존 업무용 경로와 겹치면 앱 연결이 잘못된 인터페이스로 전달될 수 있습니다. 테스트할 때는 기존 DNS와 TUN 설정을 보관하고 FakeDNS 관련 옵션을 한 번에 하나씩 켜세요. 활성화 후에는 도메인 대상과 IP 주소를 직접 사용하는 대상을 각각 테스트하세요. FakeDNS는 주로 도메인 매핑을 처리하므로 모든 IP 연결 문제의 원인으로 볼 수는 없습니다. 잘못된 조회 경로로 내부 서비스에 접속할 수 없는 상황을 방지하려면 로컬 네트워크 이름도 테스트하세요.

매핑 누락과 앱 동작 점검

앱이 이전 합성 주소를 오래 캐시한 상태에서 클라이언트를 다시 시작하거나 매핑이 바뀌면 접속이 일시적으로 실패할 수 있습니다. 먼저 앱에서 다시 조회하도록 한 다음 새 요청이 예상한 진입 경로로 들어오는지 확인하세요. 일부 앱은 자체 조회 방식을 구현하거나 고정 IP에 직접 연결하므로 FakeDNS의 영향이 제한적일 수 있습니다. 앱 하나만 실패한다면 해당 앱의 네트워크 설정과 DNS 동작을 확인하고, 모든 도메인 접속이 실패한다면 DNS 처리와 코어 로그를 살펴보세요. 브라우저 화면에 표시된 주소만 보고 매핑이 올바르다고 판단하지 말고 코어가 대상 도메인을 복원했는지 확인하세요.

도메인 분류 라우팅과 FakeDNS를 함께 사용할 때는 규칙 순서를 살펴보세요. 합성 주소가 범위가 넓은 IP 규칙에 먼저 처리되면 기대했던 도메인 분기가 적용되지 않을 수 있습니다. 로그에서 조회, 매핑 복원, 라우팅 규칙 매칭, 아웃바운드 연결의 네 단계를 각각 확인하세요. 빠진 단계가 있다면 그 단계의 진입 경로와 설정부터 살펴보세요. DNS가 합성 주소를 반환했다는 사실은 조회 단계만 작동한다는 뜻입니다. 실제 대상에 연결하려면 이후 연결이 코어로 들어오고 아웃바운드가 대상에 접속할 수 있어야 합니다.

일반 DNS와 현재 라우팅 설정으로 안정적으로 접속할 수 있다면 설정을 단순하게 유지해도 됩니다. FakeDNS는 특정 상황에서 도메인 식별 문제를 해결하는 도구이지, 기본으로 켜야 하는 성능 옵션이 아닙니다. 계속 사용하기로 했다면 주소 풀, 트래픽 처리 모드, 테스트한 앱, 복구 방법을 기록하세요. 나중에 TUN이나 DNS를 바꿀 때 전체 연결 경로를 다시 검증해야 합니다. 사용을 중단할 때도 앱에서 다시 조회하도록 해 캐시된 합성 주소를 계속 사용하지 않게 하세요. 그렇지 않으면 이전 캐시로 인한 문제를 비활성화 후 새로 생긴 오류로 오해할 수 있습니다.

사용자 지정 아웃바운드와 규칙 참조

아웃바운드는 라우팅의 목적지입니다

아웃바운드는 트래픽이 코어를 빠져나가는 방식을 정의합니다. 일반적인 freedom 아웃바운드는 직접 연결에, blackhole 아웃바운드는 차단에 사용합니다. 프록시 서버 아웃바운드의 연결 방식은 서버 매개변수에 따라 달라집니다. 라우팅 규칙은 outboundTag로 아웃바운드의 tag를 참조합니다. 따라서 사용자 지정 아웃바운드를 추가할 때는 식별자가 고유한지, 규칙이 올바르게 참조하는지, 기본 아웃바운드가 여전히 적절한지 함께 확인하세요. 의미를 알 수 있는 이름을 쓰면 모호한 숫자보다 로그를 확인하기 쉽습니다.

v2rayN은 보통 선택한 서버를 기반으로 프록시 아웃바운드를 생성합니다. 생성된 파일을 직접 수정하면 서버 전환, 구독 업데이트, 코어 재시작 후 변경 사항이 사라질 수 있습니다. 사용자 지정 동작을 계속 유지하려면 클라이언트의 사용자 지정 설정이나 병합 기능을 사용하고 저장 후 최종 생성 결과를 확인하세요. 설정을 입력하는 위치에 따라 필드 병합 방식이 다를 수 있습니다. 일부는 배열 전체를 대체하고 일부는 특정 부분만 수정합니다. 작업 전에 원본 설정을 백업하고 수정 후 코어가 JSON 구조를 받아들이는지 확인한 다음 실제 트래픽을 테스트하세요.

확인하기 쉬운 직접 연결 및 차단 출구 만들기

아래 예시는 두 아웃바운드와 정확한 도메인 규칙 하나가 서로 참조되는 구조를 보여 줍니다. 프록시 서버 매개변수와 인바운드는 포함하지 않으므로 이 예시만으로는 실행 가능한 전체 설정이 되지 않습니다. 도메인은 규칙 구조를 설명하기 위한 예시입니다. 특히 문제를 진단할 때는 차단 규칙을 신중하게 사용하세요. 범위가 지나치게 넓은 규칙이 DNS 서비스나 업무용 인터페이스에 먼저 적용되면 이후 규칙으로 해당 연결을 되돌릴 수 없습니다.

{
  "outbounds": [
    {
      "tag": "direct",
      "protocol": "freedom"
    },
    {
      "tag": "blocked",
      "protocol": "blackhole"
    }
  ],
  "routing": {
    "rules": [
      {
        "type": "field",
        "domain": ["full:example.com"],
        "outboundTag": "blocked"
      }
    ]
  }
}

사용자 지정 아웃바운드를 테스트할 때는 정확한 규칙 하나부터 시작해 로그에 예상한 아웃바운드 식별자가 표시되는지 확인한 뒤 매칭 범위를 넓히세요. 차단 규칙이 적용되면 앱에 시간 초과나 연결 실패가 나타날 수 있지만, 이것만으로 프록시 서버에 문제가 있다고 판단할 수는 없습니다. 직접 연결 규칙이 적용돼도 로컬 DNS나 네트워크 상태 때문에 대상에 접속하지 못할 수 있습니다. 라우팅 선택이 올바르다는 것은 트래픽이 해당 아웃바운드로 전달됐다는 뜻일 뿐, 대상까지 연결되는지는 별도로 확인해야 합니다.

서버 설정과 아웃바운드 식별자가 겹치지 않게 하세요

활성 서버를 바꾸면 클라이언트가 자동 생성하는 프록시 아웃바운드 내용은 달라질 수 있지만 규칙에서 참조하는 식별자는 계속 확인할 수 있어야 합니다. 사용자 지정 아웃바운드를 추가하기 전에 최종 설정에 이미 존재하는 식별자를 확인해 중복 정의를 방지하세요. 식별자가 중복되면 로그를 해석하기 어렵고 규칙이 예상치 못한 출구로 연결될 수도 있습니다. 사용자 지정 프록시 출구를 여러 개 쓴다면 일반 대상용과 특정 규칙 전용 출구를 구분하고, 참조하는 서버 설정이 남아 있는지 확인하세요. 공개 예시에 실제 서버 주소나 인증 정보를 복사하지 마세요.

연결 경로의 로컬 SOCKS 인바운드도 아웃바운드와 구분해야 합니다. 인바운드는 앱 트래픽을 받는 입구이지 원격 서버가 아닙니다. 아래 예시는 수신 주소와 포트 필드의 위치만 보여 줍니다. 수신 주소를 로컬 기기로 제한하면 계획하지 않은 상태로 로컬 네트워크에 프록시를 제공하는 일을 막을 수 있습니다. 실제 포트는 클라이언트 화면의 설정 및 해당 포트를 사용하는 앱과 일치해야 합니다. 다른 프로세스가 포트를 이미 사용 중이면 코어가 시작되지 않을 수 있습니다. 점검 방법은 로컬 포트 충돌 안내를 확인하세요.

{
  "inbounds": [
    {
      "tag": "local-socks",
      "listen": "127.0.0.1",
      "port": 10808,
      "protocol": "socks",
      "settings": {
        "auth": "noauth",
        "udp": true
      }
    }
  ]
}

사용자 지정 설정을 되돌릴 때는 새 규칙을 먼저 비활성화하고, 해당 규칙에서만 사용하는 아웃바운드를 제거한 다음 코어를 다시 불러오세요. 먼저 아웃바운드를 삭제하면 적용 중인 규칙이 존재하지 않는 대상을 가리키게 됩니다. 복구 후에는 직접 연결 대상과 프록시 대상 하나씩 테스트해 기본 경로에 남은 규칙이 영향을 주지 않는지 확인하세요. 클라이언트가 시작되지 않으면 오류가 가리키는 필드나 식별자를 확인하고 오류 상태에서 새 설정을 계속 추가하지 마세요. 설정 규모가 커질수록 새 규칙마다 명확한 목적과 개별 검증 결과가 있어야 합니다.

설정 검증, 복구, 일상적인 유지 관리

연결 경로 순서대로 문제를 확인하세요

고급 설정은 여러 단계로 이루어집니다. 문제를 해결할 때도 연결 경로를 따라 확인하세요. 앱이 트래픽을 클라이언트로 보내는지, 로컬 인바운드가 실행 중인지, DNS 결과가 예상과 일치하는지, 라우팅이 올바른 아웃바운드를 선택하는지, 아웃바운드가 대상에 연결되는지 차례로 살펴보세요. 앞 단계를 건너뛰고 서버부터 바꾸면 증상이 달라질 수는 있지만 원인을 알 수 없습니다. 한 번에 관찰 가능한 변수 하나만 바꾸고 같은 대상을 기준으로 변경 전후 결과를 기록하세요. 모든 앱이 접속할 수 없다면 클라이언트 실행 상태와 시스템 프록시를 우선 확인하고, 도메인 하나만 실패한다면 DNS와 규칙을 살펴보세요.

로그에는 웹 페이지 오류보다 구체적인 단서가 담겨 있지만 문제가 발생한 시각과 함께 확인해야 합니다. 문제를 한 번 명확하게 재현한 다음 해당 시간대의 인바운드, 조회, 라우팅, 연결 기록을 살펴보세요. 시작 직후 종료되거나 코어가 로드되지 않았다면 대상 연결 로그가 온전히 남지 않습니다. 이 경우 실행 환경과 시스템 권한을 먼저 확인하고 시작 시 충돌 문제 해결을 참고하세요. 로그에 대상 요청이 없다면 도메인 규칙부터 바꾸지 말고 앱 프록시 설정이나 TUN 적용 범위를 확인하세요.

재현 가능한 테스트 항목 만들기

네 가지 대상을 고정해 두는 것이 좋습니다. 일반 웹사이트 하나, 규칙상 직접 연결되어야 하는 대상 하나, 규칙상 프록시를 사용해야 하는 대상 하나, 로컬 네트워크 서비스 하나입니다. 각 대상에 대해 '앱 진입 경로, DNS 결과, 매칭된 규칙, 아웃바운드, 최종 결과'를 기록하고 단순히 '접속됨' 또는 '접속 안 됨'만 남기지 마세요. DNS를 바꿨다면 조회 결과와 이후 연결을 비교하고, 라우팅을 바꿨다면 매칭 규칙과 아웃바운드를 비교하세요. TUN을 바꿨다면 요청이 클라이언트에 들어오는지 확인하세요. 테스트 대상을 유지해야 결과를 비교할 수 있습니다.

표는 문제를 살펴볼 출발점이지 증상만으로 원인을 확정하는 기준은 아닙니다. 예를 들어 도메인 조회에 성공해도 라우팅 단계에서 잘못된 출구를 선택할 수 있습니다. 출구가 올바르더라도 대상 네트워크나 서버 연결 문제로 실패할 수 있습니다. 한 번 측정한 지연 시간은 실제 접속 테스트를 대신할 수 없습니다. 흔히 사용하는 세 가지 측정 방법의 범위는 연결 테스트와 다운로드 속도 측정 비교를 참고하세요. 판단하기 전에 테스트에 사용한 활성 서버와 현재 브라우저가 사용하는 출구가 같은지 확인해야 합니다.

최소 복구 절차 마련하기

수정 작업을 시작할 때마다 현재 정상 작동 상태를 저장하세요. 활성 서버의 구독 그룹, 라우팅 모드, DNS 설정, TUN 상태, 새로 추가한 설정이 필요합니다. 설정 항목만 기록하면 충분하며 인증 정보가 포함된 전체 내보내기 파일은 안전하게 보관하세요. 변경 후 문제가 발생하면 변경한 순서의 반대로 복구하세요. 새 규칙이나 기능을 먼저 비활성화하고 DNS와 연결 방식을 복구한 다음 시스템 프록시 상태를 확인하세요. 한 번에 하나씩 되돌리고 같은 테스트를 반복해야 어떤 설정이 문제와 관련 있는지 알 수 있습니다.

클라이언트 업데이트, 구독 업데이트, 규칙 데이터 업데이트는 서로 다른 작업으로 기록하세요. 각각 영향을 주는 대상이 다릅니다. 클라이언트 업데이트는 화면이나 설정 생성 방식에 영향을 줄 수 있고, 구독 업데이트는 서버 목록을 바꾸며, 규칙 데이터 업데이트는 분류 매칭을 바꿉니다. 같은 날 세 가지를 연속으로 업데이트한 뒤 라우팅 문제가 생기면 원인을 찾기 어려워집니다. 업데이트 하나를 마친 뒤 고정 테스트를 실행해 문제가 없는지 확인하고 다음 작업을 진행하세요. 데스크톱이나 Android 클라이언트를 설치하려면 설치 파일 페이지에서 플랫폼에 맞는 파일을 선택하세요. 규칙 문제를 점검하는 과정에 다운로드 작업을 섞지 마세요.

다른 사람에게 문제를 설명할 때는 운영체제, 클라이언트 이름, 연결 방식, 문제가 발생한 단계, 관련 오류 문구, 수행한 대조 테스트를 알려 주세요. v2rayN, v2rayNG, v2flyNG는 화면과 코어 선택 방식이 완전히 같지 않으므로 구체적인 클라이언트를 적어야 합니다. 로그를 공유하기 전에는 구독 주소, 서버 인증 정보, 개인 네트워크 정보를 가리세요. 처음 가져오기나 첫 연결 단계에서만 문제가 생긴다면 빠른 시작 가이드에 따라 기본 과정을 다시 확인하세요. 구독, 라우팅, TUN을 조합한 설정에서 발생한 문제라면 이 가이드를 따라 단계별로 범위를 좁히면 됩니다.