v2rayN 고급 설정 가이드

01 기본 설정과 확인 순서

고급 설정은 규칙을 더하는 것보다 현재 정상 작동하는 상태를 저장하는 데서 시작합니다. 선택한 서버로 실제 웹페이지에 접속할 수 있는지 확인한 뒤, 서버가 속한 그룹, 시스템 프록시 상태, 라우팅 설정 이름, 코어 종류, TUN 사용 여부를 기록하세요. 구독 주소나 서버 인증 정보는 기록할 필요가 없습니다. 이 정도 정보면 이후 변경이 어느 단계에서 발생했는지 파악하고 문제가 생겼을 때 기존 조합으로 되돌릴 수 있습니다.

클라이언트, 코어, 시스템 트래픽 처리를 구분하세요

v2rayN은 그래픽 인터페이스와 구독 관리를 담당하고 설정을 생성하며, 실제 연결은 선택한 코어가 처리합니다. 시스템 프록시는 해당 설정을 따르는 앱이 요청을 로컬 진입점으로 보내도록 지정하는 기능이지, 그 자체가 터널은 아닙니다. TUN은 더 낮은 단계에서 네트워크 패킷을 처리하지만 올바른 라우팅과 아웃바운드 설정이 필요합니다. 화면에 실행 중이라고 표시되어도 관련 프로세스가 시작된 것만 확인할 수 있을 뿐, 도메인 조회와 서버 핸드셰이크, 대상 접속까지 성공했다는 뜻은 아닙니다.

먼저 ‘설정’에서 로컬 수신 포트와 현재 코어를 확인하세요. 튜토리얼 화면에 나온 포트를 그대로 짐작해 사용하지 마세요. 브라우저에서 별도의 프록시 확장 프로그램을 쓴다면 테스트 중에는 시스템 설정을 따르도록 통일하세요. 앱 자체에 프록시 설정이 있다면 시스템 설정을 덮어쓰는지도 확인해야 합니다. 그렇지 않으면 한 컴퓨터에서 여러 트래픽 경로가 동시에 사용되어 어떤 웹페이지는 열리고 다른 페이지는 실패할 수 있으며, 이를 라우팅 규칙 문제로 오해하기 쉽습니다.

작은 범위부터 확인한 뒤 처리 범위를 넓히세요

먼저 TUN을 끄고 ‘시스템 프록시 → 시스템 프록시 자동 설정’만 사용하면서 단순한 라우팅 규칙을 유지하는 것이 좋습니다. 일반 도메인 페이지, 로컬 네트워크 주소, 실제로 사용하려는 앱 순서로 접속해 보세요. 웹페이지는 캐시된 탭을 새로고침하는 데 그치지 말고 닫았다가 다시 열어 테스트하세요. 로컬 네트워크 테스트에는 직접 사용하는 공유기의 관리 주소를 이용할 수 있습니다. 다른 사람의 네트워크 대역을 그대로 쓰거나 공개 서비스 주소를 로컬 네트워크 대상으로 취급하지 마세요.

테스트 결과에는 ‘어떤 앱에서 어떤 유형의 대상에 접속했으며 어떤 오류가 발생했는지’를 기록하세요. 예를 들어 도메인 페이지는 열리지 않지만 로컬 네트워크 관리 페이지는 열린다면 모든 네트워크 인터페이스부터 확인할 필요는 없습니다. 한 앱에서만 실패한다면 해당 앱이 별도 프록시나 암호화 DNS를 사용하는지 먼저 살펴보세요. 오류가 발생한 시각도 기록해 두면 로그에서 해당 연결을 찾기 쉬워집니다.

한 번에 설명 가능한 변수 하나만 변경하세요

매번 설정을 바꾼 뒤 먼저 저장하고, 화면 안내에 따라 설정을 다시 불러오거나 서비스를 재시작하세요. 서버 매개변수, DNS, TUN을 바꾸면 기존 연결이 이전 경로를 계속 사용할 수 있습니다. 확인할 때는 관련 앱의 연결을 끊고 요청을 새로 보내세요. 서버 변경, FakeDNS 활성화, 전체 라우팅 규칙 가져오기를 한꺼번에 하지 마세요. 접속이 다시 되더라도 어떤 설정이 효과가 있었는지 알 수 없고 나머지 설정이 문제를 남겼는지도 확인할 수 없습니다.

로그를 볼 때는 시작 단계 오류와 요청 단계 오류를 먼저 구분하세요. 설정을 읽지 못하거나 수신 주소가 이미 사용 중인 오류는 서비스 시작 단계에서 발생합니다. 연결 시간 초과, 이름 조회 실패, 원격 서버 거부는 요청 단계의 문제입니다. 시작 단계 오류는 먼저 설정 구조를 복구하거나 포트 충돌을 해결해야 합니다. 요청 단계 오류라면 진입점, 이름 조회, 규칙, 아웃바운드 순서로 확인하세요. 로그 상세도를 높이는 것은 짧게 재현할 때만 사용하고, 확인이 끝나면 평소 수준으로 돌려 로그가 계속 쌓이지 않게 하세요.

기본 연결이 아직 되지 않는다면 먼저 설정 가이드로 돌아가 기본 과정을 완료한 뒤 이 페이지를 계속 읽으세요. 설치 파일과 플랫폼 선택은 클라이언트 다운로드 페이지에서 확인할 수 있으며, 증상을 빠르게 확인하려면 자주 묻는 질문을 참고하세요. 이 장에서 정한 기록 방법은 이후 모든 장에 적용됩니다. 모든 설정을 차례로 켜기보다 먼저 문제가 발생한 단계를 확인한 뒤 다음 조치를 선택하세요.

02 구독 그룹 및 서버 필터

구독 그룹은 서버 출처를 관리하는 기능이지 트래픽을 분산하는 기능이 아닙니다. 한 그룹은 하나의 구독 출처에 연결하거나 수동으로 가져온 서버를 담을 수 있습니다. 그룹 이름을 바꿔도 실제 서버 연결 매개변수는 바뀌지 않습니다. 일상용 구독, 백업 구독, 수동 설정처럼 출처와 용도를 기준으로 이름을 정하는 것이 좋습니다. 그룹 이름은 식별용으로만 사용하고 구독 키를 적지 마세요. 메모에 전체 주소를 넣으면 화면을 캡처할 때 인증 정보까지 노출될 수 있습니다.

그룹을 확인한 뒤 업데이트하세요

‘구독 그룹 → 구독 그룹 설정’에서 대상 그룹의 주소, 사용 여부, 적용 가능한 필터 옵션을 확인하세요. 저장한 다음 ‘구독 그룹’ 메뉴에서 업데이트를 실행하고, 현재 명령이 선택한 그룹에 적용되는지 아니면 모든 그룹에 적용되는지 확인하세요. 그룹이 여러 개일 때 화면에 표시된 그룹과 업데이트 명령의 적용 범위가 다를 수 있습니다. 업데이트가 끝나면 완료 메시지만 보지 말고 대상 그룹으로 돌아가 서버 목록이 바뀌었는지 확인하세요.

구독 주소는 보통 여러 서버 정보를 가져오는 네트워크 주소이고, 공유 링크는 단일 연결 설정을 나타냅니다. 공유 링크를 구독 주소 입력란에 넣어도 업데이트 도구가 구독으로 처리한다는 보장은 없습니다. 클립보드에 있는 단일 링크는 ‘서버’ 메뉴의 해당 가져오기 기능을 사용하고, 구독 제공처의 주소는 그룹 설정에 입력하세요. 두 입력 방식의 차이는 공유 링크와 구독 주소의 차이에서 자세히 확인할 수 있습니다.

화면 필터와 업데이트 필터는 다릅니다

메인 창의 검색어나 그룹 선택은 보통 현재 표시 범위를 좁힐 뿐 서버 기록을 삭제하지는 않습니다. 반면 그룹 설정의 필터 조건은 업데이트 후 어떤 서버를 남길지 결정할 수 있습니다. ‘업데이트 후 서버가 사라졌다’면 먼저 메인 창의 검색어를 지우고 선택된 그룹을 확인한 다음 업데이트 필터를 살펴보세요. 이 순서대로 확인하면 잠시 숨겨진 서버를 구독 분석 실패로 오해하는 일을 줄일 수 있습니다.

빌드에 따라 이름 필터나 정규식 옵션이 제공될 수 있습니다. 항목 설명에 정규식을 사용한다고 명시된 경우에만 정규식을 입력하세요. 일반 텍스트 필터는 괄호나 세로줄을 정규식으로 해석하지 않을 수 있습니다. 정규식에서 HK|JP는 둘 중 하나가 포함된 문자열과 일치하고, ^(HK|JP)-는 지정한 접두사로 시작하는 이름을 찾습니다. 먼저 알고 있는 이름 몇 개로 확인한 뒤 범위를 넓히세요. 대소문자, 공백, 전각 기호 차이 때문에 대상 기록이 모두 제외될 수 있습니다.

^(HK|JP)-

위 정규식은 이름 접두사 일치 예시일 뿐 실제 지역을 판별하거나 더 빠른 서버를 자동으로 선택하지 않습니다. 제공처가 이름 형식을 바꾸면 기존 필터가 작동하지 않을 수 있습니다. 이름에 지역명이 있어도 실제 출구 위치와 일치한다는 뜻은 아닙니다. 남길 서버는 제공처 안내와 실제 용도를 기준으로 판단하세요. 복잡한 필터를 연결 품질 검사로 취급하거나 한 번의 테스트 결과만으로 그룹 전체를 영구 삭제하지 마세요.

필터 문제는 데이터 흐름에 따라 확인하세요

업데이트 과정은 가져오기, 분석, 필터링, 표시의 네 단계로 나눠 볼 수 있습니다. 가져오기에 실패하면 주소와 업데이트에 사용한 네트워크를 확인하세요. 분석에 실패하면 응답이 로그인 페이지나 만료 안내가 아니라 실제 구독 데이터인지 확인하세요. 분석은 성공했지만 목록이 비었다면 필터 조건을 확인하고, 목록에 서버가 있지만 보이지 않는다면 검색어와 그룹을 살펴보세요. 단계마다 해결 방법이 다르므로 업데이트를 반복해도 새로운 정보를 얻기 어렵습니다.

수동으로 가져온 서버는 별도 그룹에 보관하는 것이 좋습니다. 구독을 새로고침하면 해당 출처의 서버 목록이 다시 만들어질 수 있어 구독 서버의 이름이나 연결 매개변수를 직접 바꿔도 다음 업데이트에서 덮어써질 수 있습니다. 로컬 수정이 필요하다면 먼저 수동 관리 그룹에 복사하고 수정 이유를 적어 두세요. 복사본은 별도 기록을 만들 뿐, 만료된 인증 정보를 다시 유효하게 만들거나 제공처의 매개변수 업데이트를 대신하지는 않습니다.

서버 목록이 복구되면 현재 선택한 서버가 여전히 유효한 기록을 가리키는지 확인하세요. 구독에서 기존 기록을 삭제하거나 교체하면 이전 선택을 계속 사용할 수 없을 수 있습니다. 서버를 다시 선택하고 실제 연결을 확인하세요. 더 자세한 실패 원인은 구독 업데이트 실패 자가 진단 절차를 참고하세요. 그룹 정리가 끝난 뒤 라우팅을 설정하면 ‘잘못된 서버 선택’과 ‘잘못된 출구를 선택한 규칙’을 구분하기 쉽습니다.

03 라우팅 규칙과 일치 순서

라우팅 규칙은 코어에 전달된 요청을 어떤 아웃바운드로 처리할지 결정하지만 앱 트래픽을 클라이언트로 유도하지는 않습니다. 시스템 프록시를 사용하지 않고 TUN에도 들어오지 않는 앱은 도메인 규칙을 추가해도 해당 규칙을 따르지 않습니다. 설정을 바꾸기 전에 첫 번째 장의 절차에 따라 트래픽 처리 경로를 확인하세요. 그런 다음 ‘설정’에서 라우팅 설정을 열고 기존 설정을 복사해 테스트용으로 사용하면 필요할 때 원래 설정으로 돌아갈 수 있습니다.

대상을 먼저 정하고 출구를 지정하세요

규칙은 도메인, 대상 주소, 포트, 진입점 등의 조건으로 요청을 일치시킬 수 있습니다. 하나의 Xray 필드 규칙에서 서로 다른 조건을 여러 개 지정하면 대개 모든 조건을 만족해야 합니다. 같은 목록에 있는 여러 도메인은 그중 하나만 일치해도 됩니다. 도메인 조건과 주소 조건을 한 규칙에 넣는다고 해서 ‘둘 중 하나만 만족하면 직접 연결’되는 것은 아닙니다. 조건 조합의 의미가 확실하지 않다면 규칙을 두 개로 나누는 편이 로그 확인과 우선순위 파악에 더 쉽습니다.

규칙은 순서대로 확인하며 먼저 일치한 규칙이 트래픽 경로를 결정합니다. 따라서 좁은 범위의 예외는 포괄적인 규칙보다 앞에 두고, 기본 처리 규칙은 뒤에 둡니다. 예를 들어 명시적인 내부 도메인 직접 연결 규칙은 모든 도메인에 적용되는 프록시 규칙보다 앞에 두세요. 규칙을 추가해도 변화가 없다면 위쪽 규칙이 먼저 일치하는지 확인하고 저장되지 않았다고 단정하지 마세요. 그래픽 인터페이스의 정렬 순서도 설정의 일부이므로 가져온 뒤 다시 확인해야 합니다.

도메인 정책이 적용되는 조건을 이해하세요

domainStrategy는 라우팅 규칙을 일치시키는 과정에서 도메인을 언제 주소로 조회할지 제어합니다. 클라이언트 전체의 DNS를 켜고 끄는 설정은 아닙니다. AsIs는 규칙을 확인할 때 도메인 이름을 우선 그대로 사용합니다. IPIfNonMatch는 도메인 규칙에 일치하지 않을 때 주소를 조회한 뒤 IP 규칙을 확인합니다. IPOnDemand는 규칙을 확인하는 데 주소 정보가 필요할 때 조회합니다. 사용할 수 있는 값은 현재 코어가 지원하는 범위를 따르며 다른 코어의 설정을 그대로 가져오면 안 됩니다.

아래는 Xray 설정에서 로컬 네트워크에 직접 연결하는 부분입니다. routing 필드만 보여 주며, 설정에 direct라는 태그의 아웃바운드가 이미 있고 관련 규칙 데이터가 로드되어 있다고 가정합니다. 완전한 클라이언트 설정으로 가져오는 대신 기존 설정의 해당 위치에 합쳐야 합니다. 도메인 규칙과 주소 규칙을 나눠 쓰면 도메인 일치와 주소 일치를 구분하기 쉽습니다.

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

geosite:private와 geoip:private는 코어가 읽을 수 있는 규칙 데이터가 필요하며, 모든 실행 환경에 기본으로 포함된 고정 텍스트 목록이 아닙니다. 로그에 데이터 파일이 없다는 메시지가 나오면 클라이언트가 관리하는 규칙 리소스를 사용할 수 있는지 확인하세요. 특정 내부 도메인에는 정확한 도메인 규칙을 사용하고, 실제 로컬 네트워크 대역에는 해당 주소 범위를 지정해 관련 없는 네트워크까지 직접 연결하지 않도록 하세요.

정확한 규칙부터 확인한 뒤 범위를 넓히세요

도메인 표기 방식에 따라 일치 범위가 달라집니다. Xray에서 full:example.com은 도메인 전체가 일치할 때 적용되고, domain:example.com은 해당 도메인과 하위 도메인에도 적용됩니다. 정규식을 사용하려면 표현식의 의미를 별도로 이해해야 합니다. 특정 사이트 하나를 찾으려고 관련 없는 여러 도메인까지 일치할 수 있는 키워드를 쓰지 마세요. 처음에는 전체 도메인으로 확인하고 출구가 맞는 것을 확인한 뒤 필요에 따라 하위 도메인까지 범위를 넓히세요.

규칙을 확인할 때는 요청을 새로 보내고 해당 아웃바운드 태그를 관찰하세요. 웹페이지 하나도 여러 도메인에 접속하므로 메인 페이지가 직접 연결된다고 이미지, 로그인 API, 미디어 리소스도 같은 경로를 이용하는 것은 아닙니다. 페이지 일부만 로드된다면 전체 규칙을 단일 출구로 바꾸기보다 실제로 실패한 대상을 하나씩 확인하세요. 로그에 도메인 없이 주소만 표시되면 앱이 직접 주소를 조회하는지, 도메인 식별에 필요한 정보가 있는지도 확인해야 합니다.

라우팅 변경이 끝나면 일반 웹페이지, 로컬 네트워크 서비스, 프록시가 필요한 대상을 각각 테스트하세요. 테스트 결과의 의미도 구분해야 합니다. 서버에 Tcping이 된다고 해서 라우팅 규칙이나 대상 접속까지 성공한 것은 아닙니다. 자세한 차이는 지연 시간 테스트 결과 해석을 참고하세요. 서로 덮어쓰는 규칙을 여러 묶음 추가하기보다 단순하고 설명하기 쉬운 규칙을 유지하는 편이 관리하기 좋습니다.

04 DNS 조회 경로와 설정 최적화

DNS 문제는 조회 서버 하나를 선택한다고 해결되지 않습니다. 브라우저, 운영체제, 프록시 코어, 원격 서버가 모두 이름 조회에 관여할 수 있습니다. 먼저 ‘어떤 구성 요소가 어떤 도메인을 조회하는가?’를 확인하세요. 브라우저에서 자체 암호화 DNS를 사용한다면 운영체제의 DNS 설정이 영향을 주지 않을 수 있습니다. 프록시를 통해 도메인 이름을 전달하는 경우 로컬에서 대상 주소를 미리 알아낼 필요가 없을 수도 있습니다. 이름 조회 위치와 연결 위치를 하나의 경로로 함께 살펴봐야 설정이 의미를 갖습니다.

서버 도메인과 대상 도메인을 구분하세요

프록시 서버 자체가 도메인으로 지정되어 있으면 연결을 시작하기 전에 서버 주소를 알아내야 합니다. 아직 연결되지 않은 같은 프록시 경로에 이 조회를 의존할 수는 없습니다. 대상 웹사이트의 도메인은 설정에 따라 로컬 코어나 원격 서버에서 조회할 수 있습니다. 흔히 발생하는 순환 문제는 DNS 요청은 프록시를 통해 보내야 하는데 프록시 서버 도메인은 바로 그 DNS로 조회해야 하는 상황입니다. 실행 후 모든 요청이 멈춘다면 시간 제한만 늘리기보다 이 선후 관계를 먼저 확인하세요.

‘설정’에서 DNS 관련 항목을 찾아 현재 코어와 편집 가능한 필드를 확인하세요. v2rayN은 코어별로 DNS 설정을 따로 관리할 수 있으며 이름이 비슷하다고 구조까지 같은 것은 아닙니다. 내장 템플릿을 사용한다면 기본 구조를 유지하고 실제로 필요한 상위 DNS 서버와 규칙만 수정하세요. 온라인에서 찾은 JSON 전체를 덮어쓰면 클라이언트가 생성한 로컬 수신 설정, 라우팅 연결, TUN 필수 설정이 함께 사라질 수 있습니다.

네트워크 환경에 맞는 조회 정책을 선택하세요

아래는 Xray 내장 DNS 설정의 일부로, 주소 형태의 상위 DNS 서버 하나를 사용해 servers와 queryStrategy의 위치를 보여 줍니다. 해당 서버에 직접 연결할 수 있는지는 로컬 네트워크 환경에 따라 달라집니다. 이 설정만으로 운영체제의 모든 DNS 요청이 코어로 전달되는 것도 아닙니다. 실제로 사용할 때는 신뢰할 수 있는 DNS 서버, 네트워크 요구 사항, 전체 라우팅 설정을 고려해야 합니다. 예시를 모든 환경에 가장 적합한 설정으로 간주하지 마세요.

{
  "dns": {
    "servers": ["1.1.1.1"],
    "queryStrategy": "UseIP"
  }
}

UseIP는 두 주소 계열을 모두 조회할 수 있습니다. 한 주소 계열만 조회하도록 선택하면 대상에 도달하는 경로가 달라집니다. 로컬 네트워크에서 사용할 수 없는 주소를 우선 반환하면 첫 접속이 지연된 뒤에야 성공할 수 있습니다. 반대로 다른 주소 계열만 강제하면 특정 네트워크가 필요한 서비스가 작동하지 않을 수 있습니다. 조회 범위를 좁히기 전에 실제 인터페이스, 기본 라우트, 대상의 지원 여부를 확인하세요.

일반 DNS, 암호화 DNS, 프록시를 통한 전송은 서로 다른 개념입니다. 암호화 DNS는 조회 과정의 전송을 보호하지만 웹사이트 연결이 어떤 출구를 사용하는지 자동으로 정하지는 않습니다. DNS 서버를 목록에 입력해도 요청이 프록시 연결을 통해 전송된다는 뜻은 아닙니다. 암호화된 상위 DNS를 사용한다면 해당 서버의 도메인을 어떻게 조회하고 연결할지도 고려해야 합니다. DNS 서버, 조회 요청의 아웃바운드 경로, 대상 요청의 아웃바운드 경로를 함께 확인하세요.

내부 도메인과 공용 도메인을 나눠 처리하세요

회사나 가정의 내부 도메인은 로컬 DNS 서버에서만 조회될 수 있습니다. 모두 공용 DNS 서버로 보내면 존재하지 않는다는 응답을 받거나 내부 네트워크와 무관한 주소가 반환될 수 있습니다. 명확한 내부 도메인 접미사에는 로컬에서 접근 가능한 조회 경로를 지정하고 로컬 네트워크 직접 연결 규칙도 유지하세요. 프린터나 기기 검색은 로컬 네트워크 이름 검색 기능을 사용하는 경우가 있어 공용 DNS 설정만 바꿔서는 해결되지 않을 수 있습니다.

DNS 설정을 확인할 때는 여러 단계의 캐시를 고려해야 합니다. 운영체제, 브라우저, 코어가 각각 결과를 저장할 수 있습니다. 기존 연결을 닫고 관련 앱을 재시작한 뒤 테스트하세요. 필요한 경우 운영체제의 캐시 삭제 기능을 사용하세요. 시스템 조회 도구의 결과는 해당 조회가 거친 경로에서만 유효하며 프록시 코어의 결과와 반드시 같지는 않습니다. 테스트를 비교할 때 어떤 조회 도구를 사용했는지 기록하세요.

최적화 목표를 명확히 정하세요. 예를 들어 내부 도메인이 올바른 주소를 반환하게 하거나, 사용할 수 없는 주소 계열을 불필요하게 조회하지 않거나, 조회 의존성 순환을 해결하는 것입니다. 웹페이지 하나가 더 빨리 열렸다는 이유만으로 DNS 설정 전체를 바꾸면 캐시 차이를 설정 효과로 오해하기 쉽습니다. 설정을 바꿀 때마다 같은 앱, 같은 대상, 같은 트래픽 처리 방식을 유지하고 로그에서 조회 오류가 실제로 사라졌는지 확인하세요.

05 TUN 모드와 시스템 트래픽 처리

TUN은 가상 네트워크 인터페이스를 통해 시스템 네트워크 패킷을 받아 시스템 프록시를 따르지 않는 앱을 처리하는 데 유용합니다. 연결을 더 강하게 만드는 스위치가 아니며 서버 설정 오류를 해결하지도 않습니다. 사용하기 전에 시스템 프록시로 기본 연결을 확인하고 현재 네트워크 인터페이스, 다른 터널링 프로그램, 로컬 네트워크 접속 상태를 기록하세요. 문제가 생겼을 때 기존 연결 경로의 오류인지 새로 추가한 시스템 처리 단계가 트래픽 경로를 바꾼 것인지 구분하기 쉬워집니다.

권한과 인터페이스부터 확인하세요

v2rayN 메인 창에서 ‘Tun 사용’ 항목을 찾고 ‘설정’에서 TUN 관련 매개변수를 확인한 다음 클라이언트 안내에 따라 시작하세요. Windows에서는 관리자 권한이나 관련 서비스가 필요할 수 있습니다. macOS와 Linux에서도 시스템 권한이나 인터페이스 조작 권한이 필요할 수 있습니다. 다른 플랫폼의 드라이버 설정 방법을 그대로 따라 하지 마세요. 설치 파일과 플랫폼 안내는 클라이언트 다운로드 페이지에서 확인하고, 구체적인 의존 항목은 사용 중인 빌드의 안내를 따르세요.

활성화한 뒤 로그에서 인터페이스와 라우트가 정상적으로 생성되었는지 확인하세요. 권한 부족, 인터페이스 생성 실패, 장치 사용 중 등의 오류가 있다면 웹사이트를 테스트하기 전에 시작 단계 문제를 해결하세요. 이때 서버를 바꿔도 트래픽이 아직 코어에 들어오지 않았을 수 있습니다. 인터페이스 생성은 성공했지만 모든 연결이 실패한다면 기본 라우트, DNS, 올바른 인터페이스를 통한 서버 주소 연결을 확인하세요.

여러 트래픽 처리 프로그램이 같은 경로를 점유하지 않게 하세요

다른 VPN, 가상 머신 네트워크, 컨테이너 브리지, 보안 소프트웨어가 인터페이스 우선순위나 라우트를 바꿀 수 있습니다. 문제를 확인하는 동안에는 전역 트래픽을 처리하는 프로그램을 여러 개 동시에 실행하지 마세요. 잠시 필요하지 않은 프로그램을 종료한 뒤 TUN을 다시 켜세요. 여러 프로그램을 함께 사용해야 한다면 어떤 대상이 어느 라우트를 사용할지 각각 명확히 지정하세요. 작업 표시줄 아이콘만으로 종료 여부를 판단하지 말고 필요하면 시스템 네트워크 설정에서 인터페이스와 라우트 상태를 확인하세요.

설정에 따라 시스템 프록시와 TUN을 함께 사용할 수 있지만 처음에는 한 가지 트래픽 처리 방식만 확인하는 것이 좋습니다. 그렇지 않으면 브라우저 요청이 로컬 프록시로 전달된 뒤 시스템 라우팅까지 거쳐 경로를 파악하기 어려워집니다. 전체 연결 경로를 정확히 이해하지 못한다면 로컬 프록시 포트를 다른 계층 프록시의 상위 서버로 설정하지 마세요. 잘못 연결하면 요청이 되돌아오는 순환이 생기고 자원이 소모될 수 있습니다.

로컬 네트워크와 이름 조회를 함께 확인하세요

TUN을 켠 뒤 공유기 관리 페이지, 로컬 네트워크 공유 폴더, 내부 업무 도메인에 접속해 보세요. 접속 실패는 대상 주소가 잘못 프록시로 전달되었거나 내부 도메인이 공용 DNS에서 조회되었기 때문일 수 있습니다. 전자는 로컬 네트워크 주소 규칙과 시스템 제외 라우트를 확인하고, 후자는 DNS 장의 내용을 참고하세요. 한 기기의 문제를 해결하려고 주소 공간 전체를 직접 연결로 설정하지 마세요. 실제 서브넷과 대상 주소를 확인하고 예외 범위를 명확하게 유지하세요.

기본 라우트를 처리할 때는 프록시 연결이 가상 인터페이스로 되돌아가지 않도록 해야 합니다. 클라이언트가 보통 이를 방지하는 규칙을 생성하지만 네트워크 카드가 여러 개이거나 네트워크가 전환되거나 설정을 직접 수정하면 조건이 달라질 수 있습니다. TUN을 켠 직후 서버 연결이 시간 초과되고 끄면 복구되는 경우 서버 대상의 출구와 실제 네트워크 인터페이스를 중점적으로 확인하세요. 먼저 클라이언트 기본 TUN 설정으로 검증한 뒤 사용자 지정 매개변수를 하나씩 다시 적용하세요.

모바일 기기의 트래픽 처리 방식은 데스크톱 가상 인터페이스와 완전히 같지 않습니다. v2rayNG와 v2flyNG는 Android 시스템의 연결 권한 기능을 사용하며, 다른 비슷한 앱이 같은 권한을 점유할 수 있습니다. 백그라운드 절전 제한으로 연결이 끊길 수도 있습니다. 앱별 프록시는 어떤 앱을 처리할지 정하는 기능으로 데스크톱 라우팅 규칙과는 다릅니다. 권한과 백그라운드 설정은 Android 연결 권한 및 앱별 프록시 안내에서 확인할 수 있습니다.

종료 후 시스템이 정상적으로 복구되었는지 확인하세요

확인이 끝나면 정상적인 순서로 TUN을 끄고 인터페이스, 라우트, DNS 상태가 복구되는지 살펴보세요. 클라이언트가 비정상 종료된 뒤 네트워크가 계속 작동하지 않는다면 클라이언트를 다시 실행한 다음 트래픽 처리를 정상적으로 중지하고 시스템 프록시 설정이 남아 있는지 확인하세요. 필요한 경우 시스템 네트워크 설정에서 원래 상태로 복구하세요. 정체를 알 수 없는 인터페이스나 라우트를 바로 삭제하지 마세요. 무선 네트워크를 전환하거나 절전 모드에서 깨어난 뒤에도 실제 인터페이스가 바뀌어 기존 처리 상태가 유효하지 않을 수 있으므로 다시 확인하세요.

TUN을 확인할 때는 최소 네 가지를 테스트하세요. 기존 웹페이지가 계속 열리는지, 시스템 프록시를 따르지 않는 앱이 연결되는지, 로컬 네트워크 접속이 예상대로 동작하는지, 트래픽 처리를 끈 뒤 일반 네트워크가 복구되는지 확인합니다. 하나라도 실패하면 정상 작동이 확인된 기본 설정으로 돌아가 인터페이스, 라우트, DNS, 아웃바운드 순서로 문제를 찾으세요. 이 순서를 따르면 저수준 매개변수를 반복해서 바꾸는 것보다 원인을 재현하고 확인하기 쉽습니다.

06 FakeDNS와 도메인 매핑

FakeDNS는 도메인 조회 요청을 받으면 전용 주소 풀의 가상 주소를 반환하고 도메인과 주소의 매핑을 저장할 수 있습니다. 앱이 이 주소에 연결하면 트래픽 처리 경로가 이를 바탕으로 원래 도메인을 찾습니다. 주요 목적은 이후 라우팅에서 도메인 정보를 유지하는 것입니다. 웹사이트에 새로운 실제 주소를 할당하거나 연결할 수 없던 서버에 접속할 수 있게 하는 기능은 아닙니다. 실제 연결은 여전히 올바른 아웃바운드에서 처리해야 합니다.

하나의 경로 안에서 매핑 과정을 완성해야 합니다

FakeDNS를 사용하려면 최소 세 단계가 서로 맞물려야 합니다. 조회 요청이 실제로 가상 주소 서비스에 도달하고, 반환된 주소가 시스템 라우팅을 통해 트래픽 처리기로 돌아오며, 코어가 연결 과정에서 해당 도메인을 복원해야 합니다. 스위치 하나만 켜면 앱이 가상 주소를 받아도 일반 네트워크로 연결을 시도할 수 있습니다. 조회 결과에 주소 풀 범위가 표시된다는 이유만으로 기능이 정상이라고 판단하지 말고 전체 경로를 확인하세요.

Xray의 FakeDNS와 다른 코어의 가상 주소 기능은 설정 구조가 서로 다릅니다. v2rayN의 TUN은 현재 프록시 연결에 쓰는 것과 다른 코어 구성 요소를 사용할 수 있습니다. 따라서 메인 창에서 선택한 서버 코어와 TUN 설정의 문법이 같다고 가정하지 마세요. 먼저 어느 단계의 설정을 편집하는지 확인하고 클라이언트에 맞는 템플릿이 있는지 살펴보세요. 지원되는 화면 옵션이 있다면 클라이언트가 관련 필드를 생성하도록 사용하는 것이 좋습니다.

주소 풀과 용량 항목을 이해하세요

아래는 Xray 최상위 fakedns 필드의 예시로 주소 풀과 용량을 지정하는 방법만 보여 줍니다. 198.18.0.0/15는 특수 용도 주소 범위이지 공용 웹사이트의 실제 주소가 아닙니다. 이 조각에는 DNS 조회 진입점이나 트래픽 처리, 도메인 복원 설정이 없으므로 그대로 실행할 수 있는 클라이언트 설정이 아닙니다. 기존 설정에 합치기 전에 해당 범위를 내부 네트워크에서 사용하고 있지 않은지 확인하세요.

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

ipPool은 할당할 주소 범위를 지정하고 poolSize는 매핑 풀의 용량을 조절합니다. 용량을 늘린다고 일반적으로 속도가 빨라지거나 원격 대역폭이 달라지는 것은 아닙니다. 매핑을 유지하는 데 필요한 자원과 저장 가능한 항목 수에 영향을 줍니다. 다양한 도메인에 장기간 접속하는 환경이라면 실행 상태를 관찰하고 근거 없이 값을 지나치게 크게 설정하지 마세요. 주소 풀을 바꾸면 앱에 캐시된 기존 조회 결과에도 영향을 줍니다.

호환성 문제는 우회 경로와 캐시에서 주로 발생합니다

일부 앱은 자체 암호화 DNS를 사용해 FakeDNS를 우회하고 실제 주소에 직접 연결할 수 있습니다. 다른 앱은 조회 결과를 트래픽 처리기를 거치지 않는 하위 프로세스에 전달해 가상 주소에서 도메인을 복원할 기회를 놓칠 수 있습니다. 특수 용도 주소 범위를 허용하지 않는 앱도 있습니다. 이런 경우에는 주소 풀을 계속 바꾸기보다 해당 앱이나 도메인에 실제 DNS 경로를 사용하도록 하고 라우팅 예외도 함께 확인하세요.

내부 도메인은 특히 주의해서 처리해야 합니다. 로컬 기기에 접속하는 도메인이 가상 주소를 반환한 뒤 부적절한 프록시 출구로 보내지면 로컬 네트워크 접속이 실패합니다. 내부 이름에 실제 주소가 필요한지, 로컬 DNS가 응답하는지 확인한 뒤 해당 경로를 예외로 설정하세요. 가상 주소 제외, 상위 DNS 서버 선택, 로컬 네트워크 직접 연결은 각각 다른 설정 단계입니다. 하나만 바꿔도 나머지 두 항목이 자동으로 맞춰진다고 가정하지 마세요.

비교 테스트로 유지 여부를 판단하세요

같은 서버, 같은 라우팅, 같은 앱을 유지한 채 일반 DNS와 FakeDNS를 비교하세요. 도메인 규칙이 안정적으로 일치하는지, 대상에 연결되는지, 로컬 네트워크가 계속 정상인지 확인합니다. 페이지 로딩 시간을 한 번 비교하는 데 그치지 마세요. 캐시, 연결 재사용, 서버 부하가 결과에 영향을 줄 수 있습니다. 명확한 문제를 해결하지 못하면서 호환성 예외만 늘어난다면 일반 DNS를 유지하는 편이 관리하기 쉽습니다.

로그에서는 가상 주소 자체보다 도메인이 복원되는지, 예상한 아웃바운드가 선택되는지 확인하세요. 매핑 정보는 실행 중 상태일 수 있으므로 코어를 재시작한 뒤에도 기존 매핑이 남아 있다고 가정하지 마세요. 앱이 오래된 결과를 보관하면 재시작 후에만 연결 실패가 발생할 수 있습니다. 설정을 바꾸기 전에 앱에서 다시 조회하도록 한 뒤 판단하세요.

일반 DNS, TUN, 라우팅이 모두 안정된 뒤 FakeDNS를 추가하세요. 이 순서로 진행하면 문제가 생겼을 때 새로 추가한 단계만 되돌리면 됩니다. 현재 빌드에 공식적으로 지원되는 설정 화면이 없고 관련 설정 안내도 완전하지 않다면 다른 코어의 설정 조각을 템플릿에 억지로 넣지 마세요. 이해하기 쉬운 실제 DNS 경로를 먼저 유지하고 명확한 필요가 있을 때 추가로 시험하세요.

07 다중 구독 관리와 업데이트 전략

여러 구독 출처를 관리할 때는 출처를 추적할 수 있고 업데이트를 제어할 수 있으며 문제를 분리할 수 있어야 합니다. 출처 표시 없이 모든 서버를 하나의 그룹에 복사하지 마세요. 목록은 통일되어 보여도 업데이트 실패 후 어떤 기록이 유효하지 않은지 파악하기 어렵습니다. 출처별 그룹을 만들고 수동 설정용 그룹을 별도로 두세요. 메모에는 용도와 관리 정보를 적고 구독 주소는 전용 입력란에 보관하세요.

업데이트 대상과 업데이트 경로를 따로 설정하세요

먼저 현재 그룹만 업데이트할지 모든 그룹을 업데이트할지 정한 다음 클라이언트에서 제공하는 업데이트 방법을 선택하세요. 일부 출처는 직접 연결로 가져올 수 있고 다른 출처는 현재 사용 가능한 프록시를 통해야 할 수 있습니다. 이는 구독을 가져오는 요청의 네트워크 경로를 결정할 뿐 업데이트 후 서버의 기본 라우트를 정하지는 않습니다. 업데이트 방법을 바꾸기 전에 구독을 가져오는 데 사용할 기존 연결이 유효한지 확인하세요. 그렇지 않으면 새 서버가 있어야 기존 서버를 업데이트할 수 있는 순환이 생깁니다.

기본 구독이 작동하지 않고 업데이트도 그 구독의 현재 서버에 의존한다면, 이미 사용할 수 있음을 확인한 백업 연결로 전환하거나 출처에서 허용하는 방법으로 직접 가져오세요. 아직 확인되지 않은 서버를 복구 수단으로 간주하지 마세요. 독립적으로 확인할 수 있는 복구 방법을 하나 이상 유지하고 출처와 유효 조건을 기록하세요. 복구 방법의 목적은 의존성을 줄이는 것이지 이름이 비슷한 서버를 더 쌓아 두는 것이 아닙니다.

너무 잦은 업데이트와 중복 가져오기를 피하세요

구독 업데이트는 연결 재시도 버튼이 아닙니다. 출처가 바뀌지 않았다면 계속 새로고침해도 같은 매개변수를 반복해서 가져올 뿐이며 제공처의 요청 제한에 걸릴 수도 있습니다. 자동 업데이트 간격은 제공처 안내와 실제 변경 빈도를 고려해 설정하고, 수동 업데이트는 매개변수 변경을 확인할 때 사용하세요. 연결이 실패하면 인증 만료, 원격 연결 시간 초과, 구독 가져오기 실패를 먼저 구분해야 합니다. 각기 다른 문제를 같은 새로고침 동작으로 해결할 수는 없습니다.

같은 출처를 여러 번 추가하면 서버가 중복으로 표시될 수 있습니다. 정리하기 전에 그룹 주소가 같은지, 서로 다른 용도의 필터가 설정되어 있는지, 현재 선택한 서버가 어느 그룹에 속하는지 확인하세요. 이름이 같다고 기록이 완전히 같은 것은 아닙니다. 서버 주소, 전송 방식, 인증 매개변수가 다를 수 있습니다. 표시 이름만 보고 여러 기록을 한꺼번에 삭제하지 말고, 먼저 정상 작동이 확인된 서버를 남긴 뒤 그룹별로 정리하세요.

수동 수정은 별도 영역에서 관리하세요

구독 기록은 제공처에서 관리하므로 업데이트 후 로컬 변경 사항이 덮어써질 수 있습니다. 전송 매개변수, 서버 주소, 표시 메모를 수정해야 한다면 수동 그룹에 먼저 복사하고 수정 대상을 기록하세요. 이후 제공처의 매개변수가 바뀌어도 수동 복사본은 자동으로 갱신되지 않을 수 있으므로 정기적으로 제공처 안내와 비교해야 합니다. 수동 복사본을 구독 기록과 분리하면 변경 사항이 덮어써지는 것을 막고 추가로 관리해야 할 기록임을 알 수 있습니다.

전체 관리 작업은 정해진 순서대로 진행하세요. 현재 설정을 백업하고, 한 출처를 업데이트한 다음, 기록이 정상인지 확인하고, 현재 서버를 검증한 뒤 다른 그룹을 처리합니다. 모든 출처를 업데이트한 직후 중복 서버를 한꺼번에 정리하고 필터와 라우팅까지 바꾸지 마세요. 작업을 나눠 두면 특정 출처에서 잘못된 응답이 와도 어느 단계에서 변경되었는지 알 수 있으며 서버 목록 전체가 동시에 불확실한 상태가 되는 것을 막을 수 있습니다.

백업 서버가 있다고 자동으로 전환되는 것은 아닙니다

한 그룹에 서버가 여러 개 있어도 클라이언트가 자동으로 사용할 서버를 선택한다는 뜻은 아닙니다. 현재 서버 선택, 라우팅 규칙이 지정한 출구, 선택 정책이 있다면 그 정책을 각각 확인해야 합니다. 일부 테스트는 서버와의 핸드셰이크가 가능한지만 보여 줄 뿐 실제 대상에 접속할 수 있다는 뜻은 아닙니다. 다운로드 속도 테스트도 특정 시점의 처리량만 반영합니다. 테스트 방식의 범위는 Tcping과 실제 연결 지연 시간 안내를 함께 참고하세요.

관리가 끝나면 간단한 기록을 남기세요. 어떤 그룹은 업데이트에 성공했고 어떤 그룹은 보류했는지, 현재 서버를 다시 확인했는지, 수동 복사본에 후속 작업이 필요한지 기록하면 됩니다. 상태만 적고 민감한 정보는 옮겨 적지 마세요. 다음에 문제가 생겨도 전체 목록을 다시 정리하지 않고 마지막으로 확인된 상태에서 이어서 점검할 수 있습니다. 구독이 늘어나도 업데이트 실패는 가져오기, 분석, 필터링, 표시의 네 단계로 나눠 처리하면 됩니다.

08 사용자 지정 아웃바운드와 설정 복구

사용자 지정 아웃바운드는 그래픽 인터페이스의 기존 옵션으로 표현할 수 없고 관리자가 전체 연결 경로를 설명할 수 있는 경우에 적합합니다. 먼저 목적을 정하세요. 특정 대상에 별도의 직접 연결 출구를 만들려는 것인지, 더 복잡한 전달 경로가 필요한 것인지 확인합니다. 도메인 하나를 직접 연결하려는 정도라면 전체 설정을 바꾸지 말고 라우팅 편집기를 우선 사용하세요. 사용자 지정 설정은 자유도를 높이는 대신 필드 호환성, 태그 참조, 업데이트 관리를 직접 맡게 합니다.

먼저 설정이 속한 계층을 확인하세요

v2rayN에서 일반 서버 기록은 보통 클라이언트가 실행 설정을 생성하지만, 사용자 지정 설정은 더 많은 원래 구조를 유지할 수 있습니다. 두 방식이 화면에서 동일하게 연동된다고 가정하면 안 됩니다. ‘서버’ 메뉴에서 사용자 지정 설정 관련 기능을 사용하기 전에 전체 파일을 가져오는지 기존 파일을 참조하는지 확인하고 올바른 코어 종류를 선택하세요. 파일을 가져올 수 있다고 해서 현재 코어가 모든 필드를 지원한다는 뜻은 아닙니다.

편집하기 전에 정상 작동이 확인된 파일을 복사하고 복사본에서 작업하세요. Xray와 V2Fly는 공통 개념이 있지만 구체적인 필드와 확장 기능은 각각 확인해야 합니다. 다른 코어의 아웃바운드 종류와 라우팅 구조도 그대로 바꿔 쓸 수 없습니다. 최상위 필드, 수신 연결, 아웃바운드 태그부터 확인한 뒤 새 기능을 추가하세요. 처음부터 클라이언트가 생성한 진입점을 덮어쓰면 시스템 프록시가 이전 포트를 계속 가리켜 클라이언트 전체가 작동하지 않을 수 있습니다.

간단한 예시로 태그 참조를 이해하세요

아래 Xray 설정은 직접 연결 아웃바운드와 거부 아웃바운드를 정의하고 예시 도메인에 거부 출구를 적용합니다. outbounds와 routing만 포함하며 로컬 수신 설정은 없으므로 완전한 실행 설정이 아닙니다. 기존 설정에 합칠 때는 프록시 아웃바운드와 필요한 규칙을 유지하고 같은 이름의 태그를 덮어쓰지 않도록 하세요. 이 예시는 태그 참조 방식을 설명하기 위한 것이며 실제 업무 도메인을 차단하라는 뜻은 아닙니다.

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

여기서 outboundTag는 아웃바운드의 tag와 완전히 일치해야 합니다. 표시 이름과 태그는 서로 다른 개념이며 대소문자나 철자가 달라져도 참조가 깨질 수 있습니다. 일반적인 Xray 설정에서는 어떤 규칙에도 일치하지 않는 트래픽이 첫 번째 아웃바운드로 전달되므로 배열 순서를 바꾸면 기본 동작도 달라질 수 있습니다. 설정 조각을 합친 뒤에는 새 규칙뿐 아니라 기존 기본 출구가 그대로 유지되는지도 확인하세요.

복잡한 전달 경로는 의존 관계를 먼저 그린 뒤 설정하세요

여러 단계로 전달해야 한다면 로컬 진입점, 첫 번째 서버, 이후 연결, 최종 대상 사이의 관계를 글로 먼저 정리하세요. 각 서버 도메인을 어디서 조회하고 각 연결이 어떤 아웃바운드를 통해 만들어지는지 따로 설명할 수 있어야 합니다. 코어마다 연결을 전달하는 필드가 다르므로 ‘상위 프록시’라는 표현만 보고 설정을 가져다 쓰면 안 됩니다. 경로의 한 단계가 자기 자신에 의존하면 순환 연결이 생기거나 코어가 시작되지 않을 수 있습니다.

먼저 설정 파일의 JSON 문법을 확인한 다음 코어가 설정을 지원하는지 점검하세요. JSON에는 주석이나 끝부분의 불필요한 쉼표를 사용할 수 없습니다. 문자열의 역슬래시와 큰따옴표도 올바르게 처리해야 합니다. 문법 검사를 통과해도 지원하지 않는 필드, 존재하지 않는 태그, 누락된 규칙 데이터 등의 문제가 남을 수 있습니다. 클라이언트 로그에서 처음으로 나타난 유효한 오류를 확인하고 시작 실패 원인부터 수정한 다음 연결 관련 메시지를 살펴보세요. 중복 오류에 묻히지 않도록 주의하세요.

복구할 수 있는 상태인지 확인하세요

시작에 성공하면 먼저 최소 범위의 대상을 테스트한 다음 기존에 정상 작동하던 일반 요청과 로컬 네트워크 요청을 확인하세요. 로그에서 연결 오류가 없다는 것만 보지 말고 예상한 아웃바운드로 연결되었는지 확인해야 합니다. 사용자 지정 설정으로 기존 설정을 대체했다면 시스템 프록시나 TUN을 끈 뒤 로컬 포트 설정이 남아 있는지도 점검하세요. 원래 설정으로 복구하는 방법을 명확히 마련하고 몇 가지 스위치에 대한 임시 기억에 의존하지 마세요.

클라이언트를 업데이트하거나 코어를 바꾼 뒤에는 사용자 지정 필드와 기본 동작을 다시 확인하세요. 기존에 정상 작동하는 설정을 보존하고 복사본에서 이전 작업을 진행하세요. 유일한 설정에 새 템플릿을 바로 덧붙이지 마세요. 그래픽 라우팅, DNS 설정, 그룹 관리로 요구 사항을 다시 표현할 수 있다면 클라이언트가 관리하는 방식으로 돌아가 수동 동기화 작업을 줄이세요. 사용자 지정 설정은 분명한 요구를 해결하는 데 사용해야 하며 유지 관리 자체가 목적이 되어서는 안 됩니다.

이 페이지의 확인 순서는 문제 해결 순서이기도 합니다. 먼저 서버와 진입점을 확인하고 라우팅과 DNS를 살펴본 뒤 TUN, FakeDNS, 사용자 지정 연결 경로를 점검하세요. 기본 설정은 빠른 시작 가이드에서, 일반적인 증상은 자주 묻는 질문에서, 클라이언트 선택과 설치는 다운로드 페이지에서 확인할 수 있습니다. 검증된 상태를 항상 하나 보존해 두면 다음 설정 변경 때 신뢰할 수 있는 비교 기준이 됩니다.