V2Ray 고급 설정 가이드

01 · 구독과 항목

구독 그룹과 서버 필터링

구독 주소는 서버 설정을 가져오는 경로이고, 그룹은 클라이언트에서 항목을 정리하는 방식입니다. 둘은 같은 개념이 아닙니다. 하나의 그룹은 보통 하나의 출처와 연결되지만, 직접 추가한 서버를 함께 저장할 수도 있습니다. 고급 설정에 앞서 ‘출처, 표시 이름, 사용 목적’을 따로 기록해 두세요. 출처는 업데이트에, 이름은 식별에, 목적은 필터링에 쓰입니다. 그룹 이름을 ‘업무’로 지정한다고 해서 업무용 앱이 해당 그룹의 서버를 자동으로 사용하는 것은 아닙니다. 실제 트래픽 경로는 현재 선택된 서버, 라우팅 규칙, 프록시 적용 방식에 따라 결정됩니다.

추적하기 쉬운 그룹부터 만들기

v2rayN의 구독 그룹 설정에서 새 그룹을 만들고, 짧고 일관된 메모를 입력한 뒤 구독 주소 전체를 붙여 넣습니다. 주소에 쿼리 매개변수가 있다면 빠짐없이 그대로 유지해야 합니다. 복사 과정에서 줄바꿈, 공백, 웹페이지의 문장 부호가 섞이면 요청 결과가 달라질 수 있습니다. 저장한 다음 해당 그룹만 업데이트하고, 업데이트 알림과 항목 수 변화를 확인한 뒤 서버의 프로토콜, 주소, 포트가 온전한지 살펴보세요. 여러 출처를 한꺼번에 추가해 바로 일괄 업데이트하면 목록이 비었을 때 주소 오류인지, 요청 실패인지, 출처에서 빈 내용을 반환한 것인지 구분하기 어렵습니다.

구독 링크에는 계정 접근 정보가 포함될 수 있으므로 스크린샷이나 로그를 공유하거나 설정을 내보내기 전에 전체 주소를 가리세요. 일반적인 정리에 출처를 모르는 변환 도구로 구독 주소를 보낼 필요는 없습니다. 출처에서 특정 클라이언트용 형식을 제공한다면 현재 클라이언트에 맞는 주소를 우선 사용하세요. 브라우저에서 내용이 표시된다고 해서 클라이언트가 이를 파싱할 수 있는 것은 아닙니다. 로그인 페이지, 만료 알림, 오류 페이지도 네트워크 요청 자체는 성공으로 표시될 수 있지만 유효한 서버 목록은 아닙니다. 페이지가 열리는지만 보지 말고 클라이언트 업데이트 로그도 확인하세요.

표시 필터와 업데이트 필터의 차이

목록 검색은 대개 조건에 맞지 않는 항목을 일시적으로 숨길 뿐이라 검색을 해제하면 전체 서버를 다시 볼 수 있습니다. 반면 일부 구독 그룹의 필터 설정은 가져오기 결과에 영향을 주므로, 업데이트 후 제외된 서버가 로컬 목록에 아예 추가되지 않을 수 있습니다. 설정하기 전에 필드 설명을 읽고 필터가 표시 항목에 적용되는지 업데이트 결과에 적용되는지 확인하세요. 먼저 메모의 지역 표기처럼 일반적인 키워드로 검색해 보는 것이 좋습니다. 정규식을 명시적으로 지원하는 필드에서만 정규식을 사용하세요. 모든 입력란이 같은 방식으로 검색한다고 가정하면 안 됩니다.

정규식을 지원하는 메모 필터의 예를 들면 업무|예비는 두 단어 중 하나를 포함한 항목을 찾고, ^업무는 메모가 ‘업무’로 시작하는 항목을 찾습니다. 대소문자 구분, 메모가 비어 있을 때의 처리, 제외 문법은 해당 필드의 구현에 따라 달라지므로 다른 도구의 사용법을 그대로 적용하지 마세요. 복잡한 필터를 저장하기 전에 현재 목록에서 조건에 맞는 항목이 하나 이상 있는지 확인하고, 그룹 하나만 업데이트해 보세요. 결과가 갑자기 비었다면 필터를 취소하고 다시 업데이트하세요. 로컬 메모와 직접 추가한 항목까지 함께 삭제될 수 있으니 그룹 전체를 바로 지우지 마세요.

업데이트와 전환을 위한 복구 지점 마련

구독을 업데이트하면 서버 매개변수가 덮어써지거나 식별 정보가 바뀌고, 출처에서 삭제된 항목이 사라질 수 있습니다. 수동으로 바꾼 설정을 오래 유지해야 한다면 별도의 로컬 그룹에 복사하고 변경 이유를 기록하세요. 구독 항목에 사용자 지정 값을 계속 의존하는 것은 피하는 편이 좋습니다. 업데이트가 끝나면 현재 선택된 서버가 여전히 있는지 확인하고 실제 웹 요청도 테스트하세요. 지연 시간 테스트는 특정 방식으로 측정한 결과일 뿐, 서비스가 정상 작동한다는 뜻은 아닙니다. 노드 선택 기준은 지연 시간, 배율, 지역, 프로토콜 유형을 고려한 선택 방법을 참고하세요.

02 · 매칭과 트래픽 분기

V2Ray 라우팅 규칙 실전

라우팅은 ‘코어에 들어온 연결을 어떤 아웃바운드로 보낼지’를 결정합니다. 모든 앱의 트래픽을 자동으로 클라이언트에 전달하는 기능이 아니며, 시스템 프록시 설정과도 다릅니다. 앱이 로컬 프록시를 우회하면 코어의 규칙은 적용될 기회가 없습니다. 트래픽 분기를 점검할 때는 먼저 요청이 실제로 클라이언트에 들어왔는지 확인하고, 이어서 대상 도메인이나 주소, 적용된 규칙, 최종 아웃바운드를 살펴보세요. 트래픽 전달, 규칙 매칭, 연결 전달을 각각 확인하면 라우팅 프리셋 전체를 바꾸는 것보다 문제를 쉽게 찾을 수 있습니다.

규칙 순서와 매칭 필드 이해하기

일반적인 코어는 규칙을 순서대로 확인하므로 앞쪽의 넓은 규칙이 뒤쪽의 구체적인 규칙에 먼저 적용될 수 있습니다. 명확한 로컬 서비스와 특정 도메인을 앞에 두고, 범위가 넓은 주소 목록을 그다음에 배치한 뒤, 마지막에 기본 경로를 처리하세요. 한 규칙 안에 서로 다른 유형의 조건이 여러 개 있으면 보통 모든 조건이 함께 충족되어야 합니다. 같은 도메인 목록의 여러 값은 후보 매칭을 나타냅니다. 서로 관계없는 도메인 조건과 주소 조건을 한 규칙에 넣고 각각 따로 적용되기를 기대하지 마세요. 설정을 읽을 때는 각 규칙의 조건 전체를 기준으로 판단해야 합니다.

도메인 표기에도 차이가 있습니다. full:example.com은 지정한 도메인만 정확히 매칭하고, domain:example.com은 해당 도메인과 하위 도메인까지 매칭합니다. 일반 문자열은 더 넓은 키워드 매칭으로 처리될 수 있습니다. 특정 서비스만 대상으로 삼으려면 정확한 도메인이나 명시적인 도메인 접미사를 우선 사용하세요. IP 규칙을 직접 지정할 때는 대상이 여러 주소를 사용하거나 네트워크에 따라 다른 주소를 반환할 수 있다는 점을 고려해야 합니다. IP 주소 하나만으로 웹사이트 전체를 안정적으로 지정할 수는 없습니다. 지리 정보 데이터베이스를 사용하는 규칙이라면 해당 데이터 파일이 있고 현재 코어에서 읽을 수 있는지도 확인하세요.

최소 규칙부터 시작해 확인하기

다음은 Xray 형식의 라우팅 예시이며 완전한 설정 파일은 아닙니다. 테스트 도메인과 내부 네트워크 주소는 직접 연결 아웃바운드로 보내고 나머지 연결은 기존 기본 동작을 유지합니다. 이 예시는 direct라는 태그의 아웃바운드가 이미 있다고 가정합니다. 실제 태그가 다르면 예시에서도 함께 수정해야 합니다. 사용자 지정 설정에 합칠 때는 기존 인바운드와 프록시 아웃바운드를 보존하고, 이 예시로 파일 전체를 덮어쓰지 마세요. GUI의 라우팅 편집기가 해당 필드를 자동으로 생성한다면 인터페이스에서 수정해야 다음 시작 때 변경 내용이 덮어써지지 않습니다.

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

도메인 해석 전략은 라우팅 프리셋과 다릅니다

AsIs는 라우팅 단계에서 기존 대상 정보를 최대한 활용하며, IP 규칙에 맞추려고 도메인을 적극적으로 해석하지 않습니다. IPIfNonMatch는 도메인 규칙이 매칭되지 않을 때 해석을 시도한 뒤 IP 주소 규칙을 적용합니다. IPOnDemand는 주소 조건을 만나면 더 일찍 해석할 수 있습니다. 해석 전략에 따라 조회 횟수와 매칭 결과는 달라지지만 DNS 요청을 올바른 서버로 자동 전송하지는 않습니다. 주소 목록을 사용하기 전에 DNS 설정과 해석 경로를 확인하고, 라우팅 단계에서 직접 해석을 시도할 필요가 있는지 판단하세요. 도메인 규칙만으로 해결할 수 있는 문제에 불필요한 의존성을 추가하지 않는 것이 좋습니다.

검증할 대상을 하나 정해 새 요청을 한 번 보내고, 접속 로그에서 대상과 아웃바운드 태그를 확인하세요. 브라우저가 기존 연결을 재사용할 수 있으므로 규칙을 바꾼 뒤에는 관련 연결을 닫거나 앱을 다시 열어 테스트해야 합니다. 도메인 규칙이 계속 적용되지 않는다면 앱에서 코어로 IP 주소만 전달하는지, 스니핑으로 도메인 정보를 얻을 수 있는지 확인하세요. 정보가 없는 문제는 규칙 순서를 계속 바꿔도 해결되지 않습니다. 시스템 프록시 모드의 기본적인 차이는 프록시 모드 안내를 참고하고, 연결 후에도 접속할 수 없다면 단계별 문제 해결 목록을 확인하세요.

03 · 조회와 해석 경로

DNS 설정 최적화

DNS 설정은 단순히 ‘서버 주소를 바꾸는 것’이 아닙니다. 한 번의 접속에도 앱 자체 해석기, 운영체제 해석기, 클라이언트 내장 DNS, 원격 프록시가 대상 도메인을 처리하는 경로가 관여할 수 있습니다. 브라우저에서 암호화 DNS를 사용하면 시스템의 일반 DNS 요청을 거치지 않을 수도 있습니다. 먼저 누가 조회하는지, 요청이 어디로 가는지, 결과를 누가 사용하는지 정리하세요. 특정 모듈이 실제 요청을 처리하는 경우에만 그 모듈의 설정을 바꿔야 효과가 있습니다.

부트스트랩 해석과 일반 DNS 조회 구분하기

프록시 서버 주소가 도메인 이름이라면 프록시에 연결하기 전에 실제 주소를 알아내야 합니다. 이 과정이 부트스트랩 해석입니다. 아직 연결되지 않은 프록시를 모든 DNS 조회의 목적지로 강제하면 ‘프록시에 연결하려면 프록시 주소를 먼저 해석해야 한다’는 순환 문제가 생길 수 있습니다. 서버 도메인에 직접 사용할 수 있는 해석 경로를 남기거나 출처에서 명시한 서버 주소를 사용하세요. 출처에서 주소를 바꿀 수 있으므로 도메인을 임의로 해석해 얻은 IP를 영구적으로 고정하지 마세요. 일반 웹사이트의 DNS 조회 경로는 실제 아웃바운드 요구에 맞춰 별도로 설계해야 합니다.

v2rayN에서 DNS를 변경하기 전에 현재 라우팅 프리셋, 코어 종류, DNS 편집 방식을 기록하세요. 인터페이스에 일반 프록시와 TUN용 DNS 템플릿이 따로 있거나, 고급 설정에서 코어 설정을 직접 편집할 수 있습니다. 현재 모드에서 사용하지 않는 템플릿만 수정해도 실행 결과는 달라지지 않습니다. 저장한 다음 관련 코어를 다시 시작하고 로그에서 설정이 정상적으로 불러와졌는지 확인하세요. 필드를 인식하지 못한다는 오류가 뜨면 먼저 기존 설정으로 복구하고, 현재 코어에서 지원하는 문법을 확인하세요. 다른 코어에 있는 동명 설정을 추측해 대체하지 마세요.

주요 매개변수의 영향 이해하기

다음은 Xray 내장 DNS에서 흔히 사용하는 최소 필드 조합을 구조 설명용으로 보여 주는 예시입니다. 공용 DNS 주소가 모든 네트워크에 적합한 것은 아니므로 현재 네트워크에서 접속 가능한지 먼저 확인하세요. UseIPv4는 IPv4만 조회하는 테스트 조건을 지정하며, 모든 환경에서 영구 설정으로 사용해서는 안 됩니다. IPv6가 필요하다면 시스템, 네트워크, 프록시 경로가 모두 정상적으로 작동하는지 확인한 뒤 해당 조회 전략을 다시 사용하세요. 이 설정은 시스템의 모든 DNS 요청을 받아 처리하지 않으며 TUN에서 DNS를 자동으로 가로채지도 않습니다.

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

증상에 따라 단계별로 점검하기

모든 도메인 조회가 실패하지만 숫자 주소에는 접속할 수 있다면 해석기 연결과 DNS 조회 아웃바운드부터 확인하세요. 특정 도메인만 실패한다면 도메인별 해석 규칙, 캐시, 상위 DNS 서버의 응답을 확인하세요. 해석은 성공하지만 연결 시간이 초과되면 반환된 주소에 실제로 접속할 수 있는지 살펴보세요. 암호화 DNS는 인증서 검증을 위해 정확한 시스템 시간이 필요하며, 도메인 형식의 DNS 서버를 사용하면 부트스트랩 해석이 추가로 필요할 수 있습니다. 테스트할 때는 한 번에 변수 하나만 바꾸고 조회 시간과 오류 유형을 기록하세요. 해석기, 라우팅 전략, 프록시 서버를 동시에 바꾸지 마세요.

IPv6 문제는 DNS 문제와 혼동하기 쉽습니다. IPv6 주소를 받았더라도 로컬 네트워크나 프록시 아웃바운드가 해당 주소에 연결하지 못할 수 있습니다. 반대로 IPv6를 전부 비활성화하면 원래 사용할 수 있던 서비스에 영향을 줄 수도 있습니다. 통제된 테스트에서 조회 주소 유형을 제한하고 주소 계열에 따라 실패가 달라지는지 확인한 뒤, 네트워크를 수정할지 조회 전략을 조정할지 결정하세요. Wi-Fi, 유선 네트워크, 모바일 네트워크를 바꾼 뒤에는 필요에 따라 연결을 다시 설정하고 관련 캐시를 비우세요. 브라우저와 운영체제는 각각 캐시를 관리하므로 클라이언트만 다시 시작해도 오래된 결과가 모두 지워지지는 않습니다.

04 · 트래픽 가로채기

TUN 모드 사용과 복구

TUN은 가상 네트워크 인터페이스를 통해 IP 패킷을 받는 트래픽 처리 방식으로, 시스템 프록시 설정을 따르지 않는 앱에 사용할 수 있습니다. 하지만 프록시 프로토콜은 아닙니다. TUN에 들어온 데이터도 라우팅, DNS 처리, 아웃바운드 연결을 거치며, 실제 기능은 사용 중인 백엔드에 따라 달라집니다. v2rayN에서는 전용 TUN 백엔드가 트래픽 처리를 담당할 수 있으므로 인터페이스의 TUN 스위치를 Xray 코어 설정의 특정 필드로 이해해서는 안 됩니다. 스택, 라우팅, DNS 매개변수를 살펴보기 전에 현재 클라이언트 안내와 실행 로그에서 어떤 백엔드를 사용하는지 확인하세요.

활성화 전에 기본 연결 확인하기

먼저 일반 시스템 프록시 방식으로 노드가 대상 서비스에 접속할 수 있는지 확인하고, 운영체제에서 가상 인터페이스 생성과 라우팅 변경을 허용하는지 살펴보세요. Windows에서는 적절한 권한으로 클라이언트를 실행하거나 클라이언트 서비스를 활성화해야 할 수 있습니다. macOS와 Linux에서는 권한 승인이나 관련 서비스가 필요할 수 있습니다. 권한 부족, 인터페이스 생성 실패, 서버 연결 실패는 서로 다른 문제이므로 로그에 따라 구분해 처리하세요. 데스크톱 설치 파일은 다운로드 센터에서 받으세요. 원인을 파악하지 못한 오류를 해결하려고 출처가 불분명한 추가 구성 요소를 설치하지 마세요.

활성화하기 전에 기본 라우팅, DNS, 가상 인터페이스를 변경하는 다른 프로그램을 잠시 종료하고 기존 네트워크가 정상인지 기록하세요. 원격으로 다른 기기에 접속해 작업한다면 라우팅 전환으로 관리 연결이 끊길 수 있으므로 특히 주의해야 합니다. 먼저 로컬에서 복구할 방법을 준비하세요. 첫 테스트에서는 엄격한 라우팅, 사용자 지정 제외 대역, FakeDNS를 동시에 활성화하지 마세요. 기본 매개변수를 유지한 채 인터페이스 생성, 프록시 서버 연결, 일반 웹페이지 접속을 확인한 다음 필요한 기능을 하나씩 추가하세요.

스택, 자동 라우팅, 제외 항목 이해하기

네트워크 스택은 수신한 패킷을 처리 가능한 연결로 변환합니다. 구현에 따라 시스템 호환성, UDP 지원, 리소스 사용량이 다를 수 있습니다. 한 시스템에서 잘 작동하는 스택이 모든 기기에서 최선의 선택이라는 뜻은 아닙니다. 자동 라우팅은 대상 트래픽을 가상 인터페이스로 보내고, 제외 항목은 로컬 서비스, LAN, 특정 연결이 기존 경로를 유지하도록 설정합니다. 백엔드가 프록시 서버 자체의 연결을 제대로 제외하는지 먼저 확인하세요. 그렇지 않으면 아웃바운드 연결이 다시 TUN으로 들어가 트래픽을 반복해서 가로챌 수 있습니다.

MTU는 인터페이스가 처리할 수 있는 패킷 크기를 의미하며, 값이 클수록 빠른 것은 아닙니다. 작은 페이지는 열리지만 대용량 파일이나 특정 앱이 멈추거나 연결이 끊긴다면 노드와 DNS 외에 경로 MTU와 패킷 분할 문제도 확인할 수 있습니다. 값을 조정할 때는 백엔드가 지원하는 범위에서 조금씩 바꾸고, 매번 테스트 연결을 새로 만들어 기존 값을 기록해 두세요. 웹페이지 한 번 열린 결과만 보고 인터넷에서 찾은 특정 MTU 값으로 고정하면 실제 원인을 놓치기 쉽고, 네트워크를 바꾼 뒤 문제가 다시 발생할 수도 있습니다.

플랫폼별 차이와 검증 순서

Android의 v2rayNG와 v2flyNG는 일반적으로 시스템 VPN 인터페이스를 통해 앱 트래픽을 처리합니다. 권한 승인 방식은 데스크톱의 가상 인터페이스 관리 방식과 다릅니다. 앱별 프록시 설정, LAN 우회, 백그라운드 실행 제한은 실제로 처리되는 트래픽 범위에 영향을 줄 수 있습니다. 클라이언트를 사용할 때 같은 인터페이스를 점유하는 다른 연결은 먼저 중지하세요. 절전 설정으로 백그라운드 프로세스가 종료되면 화면을 잠근 뒤 연결이 끊길 수도 있습니다. 데스크톱 클라이언트 서비스 설치 방법을 Android에 그대로 적용하지 마세요.

검증할 때는 일반 웹페이지, 로컬 게이트웨이나 LAN 서비스, UDP가 필요한 앱 순서로 확인하고 네트워크 전환과 기기 깨우기도 테스트하세요. 활성화 후 인터넷이 전혀 되지 않는다면 먼저 TUN을 끄고 일반 네트워크가 복구되는지 확인한 다음 인터페이스, 라우팅, DNS 로그를 살펴보세요. 끈 뒤에도 문제가 남으면 클라이언트를 종료하고 시스템 프록시 설정이 남아 있는지 확인한 뒤 네트워크를 다시 연결하세요. 트래픽 처리 계층이 안정적으로 작동한 다음에 엄격한 라우팅과 제외 대역을 조정하세요. 고급 매개변수를 계속 추가하기보다 네트워크 복구가 우선입니다.

05 · 도메인 매핑

FakeDNS와 DNS 가로채기

FakeDNS는 도메인에 합성 주소를 할당하고, 이후 연결이 들어오면 매핑을 이용해 원래 도메인을 찾아냅니다. 합성 주소는 클라이언트 내부에서 식별용으로 사용되며 웹사이트의 실제 서버 주소가 아닙니다. 앱이 먼저 직접 도메인을 해석한 뒤 IP 주소만으로 연결하더라도 프록시가 원래 도메인을 복원해 도메인 라우팅을 적용하거나 이름을 원격으로 전달할 수 있다는 점이 유용합니다. FakeDNS가 노드 품질을 높여 주는 것은 아니며, DNS와 트래픽 가로채기 없이 단독으로 작동하지도 않습니다.

도메인 매핑 경로가 완성되어 있는지 확인하기

정상적인 경로는 네 단계로 이루어집니다. 앱의 DNS 조회가 지정된 해석 모듈에 들어가고, 모듈이 합성 주소를 반환하며, 앱이 그 주소로 연결하고, 클라이언트가 연결을 받은 뒤 도메인을 복원해야 합니다. 어느 단계든 클라이언트를 우회하면 실패할 수 있습니다. 예를 들어 브라우저가 자체 암호화 DNS를 사용해 조회가 매핑 모듈에 도달하지 않을 수 있습니다. 시스템이 합성 주소를 받았더라도 제외 라우팅 때문에 물리 네트워크로 직접 연결할 수 있습니다. 매핑을 만든 모듈과 연결을 받은 모듈이 서로 다른 구현일 수도 있습니다. 이런 경우에는 스니핑만 켜도 해결되지 않을 수 있습니다.

먼저 일반 TUN과 실제 DNS 해석이 안정적으로 작동하는지 확인한 뒤 FakeDNS 사용 여부를 결정하세요. v2rayN의 TUN 백엔드가 자체 합성 주소 기능을 제공할 수 있는데, 이름이 비슷하다는 이유로 이를 Xray 설정의 FakeDNS와 서로 대체할 수 있다고 보면 안 됩니다. 필드 이름, 주소 풀, 캐시 방식, 라우팅 요구 사항은 실제 백엔드에 맞춰 확인해야 합니다. 호환성이 명확하게 보장되지 않는다면 두 기능을 동시에 켜거나 주소 대역을 공유하지 마세요. 모듈마다 다른 매핑을 저장하면 같은 합성 주소가 서로 다른 도메인을 가리킬 수 있습니다.

주소 풀과 매핑 용량

다음은 주소 풀, DNS 서버 선택, 인바운드 스니핑의 관계를 보여 주는 Xray 형식의 예시입니다. 클라이언트 설정 파일 전체를 그대로 대체할 수 있는 구성은 아닙니다. 인바운드의 스니핑 필드는 해당 트래픽을 실제로 받는 인바운드에 합쳐야 하며 루트 객체에 임의로 추가하면 안 됩니다. 198.18.0.0/15는 흔히 쓰이는 합성 주소 풀입니다. 활성화하기 전에 로컬 네트워크에서 이 범위를 사용하거나 특수 라우팅하는지 확인하고, 관련 연결이 프록시 처리 경로를 벗어나지 않도록 하세요.

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

{
  "sniffing": {
    "enabled": true,
    "destOverride": ["fakedns"]
  }
}

poolSize는 매핑 용량을 조정하는 값이지 동시에 지원할 수 있는 서버 수가 아닙니다. 서로 다른 도메인을 많이 방문하면 용량과 제거 방식에 따라 오래된 주소에서 원래 도메인을 복원할 수 있는지가 달라집니다. 앱이 해석 결과를 오랫동안 보관하는 동안 코어가 재시작되어 기존 매핑이 사라질 수도 있습니다. 이때 앱이 오래된 합성 주소로 계속 연결하면 실패할 수 있습니다. 클라이언트를 재시작한 뒤 특정 앱에서만 문제가 생기면 프록시 프로토콜을 바로 바꾸지 말고, 먼저 앱을 종료하고 관련 DNS 캐시를 지운 다음 연결을 다시 설정하세요.

예외 도메인과 문제 증상

LAN 이름, 기기 검색, 실제 주소에 의존하는 앱, 특수 DNS 레코드가 필요한 서비스는 합성 주소 사용에 적합한지 각각 확인해야 합니다. 앱에 따라 DNS 결과가 예상 네트워크에 속하는지 검사하거나 결과를 클라이언트가 처리하지 않는 다른 프로세스에 넘길 수 있으므로 백엔드가 지원하는 방식으로 예외 해석을 설정해야 합니다. 예외 도메인은 실제 주소를 반환하도록 하고 관련 직접 연결 또는 프록시 규칙과 조정하세요. 합성 주소를 반환하면서 해당 대역을 클라이언트 우회 목록에 넣으면 안 됩니다.

문제를 찾을 때는 시스템이나 앱이 합성 주소를 받았는지 확인하고, 연결이 트래픽 처리 인터페이스에 도달하는지 살펴본 뒤 로그에서 원래 도메인이 복원되었는지 확인하세요. 물리 네트워크 연결에서 합성 주소가 보이면 DNS 서버를 바꾸기보다 트래픽 처리와 라우팅을 먼저 바로잡으세요. FakeDNS를 끌 때도 캐시를 정리해야 합니다. 실제 DNS 해석으로 되돌리고 영향을 받은 앱을 다시 시작한 뒤, 필요하면 시스템 캐시를 갱신하고 오래된 매핑에 의존하는 연결이 없는지 확인하세요. 스위치만 끄고 이전 주소를 그대로 두면 설정을 복구한 뒤에도 문제가 이어질 수 있습니다.

06 · 출처와 유지 관리

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

다중 구독 관리의 핵심은 출처를 분리하고 업데이트 영향을 제한하며 복구 가능한 상태를 유지하는 것입니다. 모든 서버를 알아보기 어려운 긴 목록 하나로 합치는 것이 목적은 아닙니다. 출처마다 별도 그룹을 만들고 ‘출처 식별자와 용도’처럼 일관된 형식으로 메모를 작성하세요. 임시 테스트용 출처는 따로 보관하는 것이 좋습니다. 출처가 늘어나면 일괄 업데이트에 앞서 관리 규칙을 정하세요. 그렇지 않으면 같은 이름의 항목, 서로 다른 프로토콜, 구독 변경 사항이 뒤섞여 서버를 잘못 선택하기 쉽고, 설정이 어느 출처에서 왔는지 확인하기도 어렵습니다.

그룹, 항목, 활성 연결의 관계 파악하기

그룹을 선택하면 현재 목록 화면만 바뀌고 실제 활성 서버는 그대로일 수 있습니다. 일부 인터페이스에서는 그룹 안의 서버를 다시 선택하는 즉시 연결이 바뀌기도 합니다. 화면 상단의 그룹 이름만 보지 말고 실제 활성 표시를 확인하세요. 서버 메모는 고유한 식별자가 아닙니다. 출처가 다른 서버에 같은 이름이 붙을 수 있고, 같은 출처의 항목도 업데이트 중 이름이 바뀔 수 있습니다. 업데이트 영향을 확인할 때는 표시 이름만 비교하지 말고 프로토콜, 대상 주소, 포트, 전송 매개변수를 살펴보세요.

자동 중복 제거도 신중하게 해야 합니다. 주소와 포트가 같다고 설정까지 같은 것은 아닙니다. 식별 정보, TLS 이름, 경로, 흐름 제어 매개변수가 다르면 연결 방식도 달라질 수 있습니다. 클라이언트가 어떤 필드로 중복을 판단하는지 확실하지 않다면 목록을 줄이려고 항목을 일괄 삭제하지 마세요. 꼭 정리해야 한다면 먼저 그룹별로 필터링하고 필요한 로컬 기록을 저장하세요. 작업 후 그룹을 업데이트해 출처에서 같은 항목이 다시 내려오지는 않는지 확인합니다.

자동 업데이트 범위 설정하기

업데이트 주기는 출처가 실제로 바뀌는 빈도와 클라이언트 사용 방식에 맞춰 정하세요. 너무 자주 업데이트하면 요청과 문제 해결 로그만 늘어날 뿐, 이미 중단된 출처가 복구되지는 않습니다. 처음 추가할 때는 수동으로 업데이트하세요. 내용이 안정적인 것을 확인한 다음 클라이언트에서 지원하는 예약 업데이트를 설정하면 됩니다. 기기가 절전 모드에 있거나 네트워크 연결이 아직 준비되지 않았거나 백그라운드 프로세스가 중지되면 예약 작업이 예상대로 실행되지 않을 수 있습니다. 자주 사용하는 작업을 시작하기 전에 최근 업데이트 결과를 확인하고, 예약이 설정되어 있다는 사실만 믿지 마세요.

‘프록시를 통해 업데이트’와 ‘직접 업데이트’가 실제로 필요한 상황도 구분해야 합니다. 특정 경로에서만 접속할 수 있는 출처라면 업데이트 요청에 사용할 경로를 명시하되, 곧 교체할 활성 서버 하나에 유일한 구독 업데이트 경로를 의존하지 마세요. 업데이트 방식을 바꾼 뒤에는 그룹 하나만 테스트하고, 실패 로그의 네트워크 오류 유형을 기록하면서 구독 주소 전체는 숨기세요. 여러 그룹에서 동시에 실패한다면 출처를 하나씩 다시 만들기보다 공통 네트워크와 프록시 의존성을 먼저 확인하세요.

백업, 이전, 출처 종료

클라이언트를 이전하기 전에 인터페이스의 내보내기 또는 백업 기능을 사용하고, 구독 주소, 수동 추가 서버, 라우팅, DNS 설정이 내보낸 데이터에 포함되는지 확인하세요. 백업 범위마다 차이가 있으므로 공유 링크 하나만으로 전체 사용 환경을 복원할 수는 없습니다. 백업 파일에 계정 정보가 포함될 수 있으니 안전한 위치에 보관하세요. 다른 기기에서 복원한 뒤에는 로컬 포트, 파일 경로, 서비스 권한, 가상 인터페이스 설정이 새 환경에 적합한지 확인하세요. 이전 기기의 네트워크 설정을 모두 보편적인 설정으로 간주하지 마세요.

출처를 더 이상 사용하지 않는다면 먼저 검증된 서버로 전환하고 해당 그룹의 자동 업데이트를 끈 다음, 로컬 기록을 삭제할지 보관할지 결정하세요. 현재 활성 항목을 바로 삭제하면 연결이 끊길 수 있고, 앱이 이전 연결을 계속 재사용해 ‘목록은 바뀌었는데 요청은 예전 경로로 나간다’고 착각할 수도 있습니다. 삭제한 뒤에는 연결을 새로 테스트하고 해당 항목을 참조하는 라우팅이나 사용자 지정 아웃바운드가 남아 있지 않은지 확인하세요. 장기간 사용하지 않는 구독은 자동 업데이트 목록에서 빼 불필요한 실패 알림을 줄이세요.

관리 규모가 커지면 변경 내용을 간단히 기록해 두세요. 어떤 그룹을 바꿨는지, 어떤 종류의 매개변수를 업데이트했는지, 어떤 상황을 확인했는지, 어떻게 복구할 수 있는지 정리하면 됩니다. 기록에 전체 구독 주소나 계정 정보를 포함하지 마세요. 기록의 목적은 문제와 최근 작업을 연결하는 것이지 복잡한 설정 시스템을 새로 만드는 것이 아닙니다. 출처 업데이트와 로컬 설정 중 무엇이 문제인지 판단하기 어렵다면 별도 그룹에 같은 출처를 가져와 항목과 연결 결과만 비교하고, 기존의 안정적인 그룹은 그대로 두세요.

07 · 태그와 연결 전달

사용자 지정 아웃바운드와 설정 병합

아웃바운드는 코어가 연결을 만드는 방식을 지정하고, 라우팅은 태그를 통해 요청을 해당 아웃바운드로 보냅니다. 규칙에 outboundTag를 적었다고 해서 클라이언트가 해당 아웃바운드를 만든 것은 아닙니다. 최종 실행 설정에 그 태그가 실제로 있어야 하며 철자와 대소문자도 일치해야 합니다. 사용자 지정 아웃바운드는 명확한 연결 전달 요구에 적합하며 GUI 설정 전체를 대체하는 용도로는 적합하지 않습니다. 일반적인 사용에서는 v2rayN이 표준 서버 설정을 관리하도록 두고, 꼭 필요한 부분만 사용자 지정 설정으로 추가해 업데이트와 이전에 드는 비용을 줄이세요.

최종 설정을 관리하는 주체부터 확인하기

GUI 클라이언트는 보통 선택된 서버, 라우팅 프리셋, DNS 템플릿을 바탕으로 실행 설정을 생성합니다. 임시로 생성된 파일을 직접 수정하면 서버를 바꾸거나 코어를 다시 시작할 때 변경 내용이 덮어써질 수 있습니다. 현재 설정 경로가 ‘서버 편집’, ‘라우팅 편집’, ‘전체 사용자 지정 설정’ 중 무엇인지 먼저 확인하세요. 각각 제어하는 범위가 다릅니다. 전체 사용자 지정 설정을 사용하더라도 클라이언트가 로컬 인바운드, 로그, 관리 인터페이스를 계속 추가하는지 확인해야 합니다. 화면에 보이는 모든 설정이 계속 적용된다고 가정하지 마세요.

수정하기 전에 정상 작동하는 현재 설정을 내보내고 로그에서 실제 사용 중인 코어를 확인하세요. Xray와 V2Fly는 모두 JSON 형식의 설정을 사용하지만 지원하는 필드와 프로토콜이 완전히 같지는 않습니다. 다른 TUN 백엔드의 설정 구조는 더더욱 서로 섞어 쓸 수 없습니다. 기존 파일에 예시를 병합할 때는 루트 객체, 배열, 쉼표가 올바른지 확인하세요. 같은 객체에 중복 키가 있으면 파서에서 별다른 오류 없이 기존 값이 덮일 수 있습니다. 문법 검사에 통과했다는 것은 형식이 올바르다는 뜻일 뿐, 코어가 해당 필드를 지원하고 연결까지 성공한다는 의미는 아닙니다.

직접 연결과 로컬 전달로 태그 이해하기

다음은 두 개의 태그를 보여 주는 Xray 형식 아웃바운드 예시입니다. direct는 직접 연결을 뜻하고, local-socks는 요청을 로컬 루프백 주소의 SOCKS 서비스로 전달합니다. 두 번째 아웃바운드는 지정된 로컬 포트에서 해당 서비스가 실제로 수신 중일 때만 사용할 수 있습니다. 예시의 포트가 모든 클라이언트의 기본 포트라는 뜻은 아닙니다. 현재 설정의 인바운드 포트를 대상으로 지정하면 연결이 순환할 수 있으니 주의하세요. 기존 아웃바운드 배열이 있다면 프록시 아웃바운드를 덮어쓰지 말고 필요한 객체를 추가하세요.

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

이런 설정에서는 라우팅 규칙에 매칭되지 않은 트래픽이 보통 아웃바운드 배열의 첫 번째 항목을 사용합니다. 따라서 예시의 기본 경로는 직접 연결이며, 일반적인 프록시 설정 전체를 나타내는 것은 아닙니다. 실제로 병합할 때는 기존 기본 아웃바운드를 유지하고 구체적인 규칙에서 새 태그를 지정하세요. 테스트 도메인 하나만 local-socks로 보내 로컬 서비스가 작동하는지 확인한 뒤 매칭 범위를 넓히세요. 아웃바운드를 추가하자마자 모든 연결에 적용되는 규칙으로 테스트하면 전체 접속 경로에 문제가 생길 수 있습니다.

체인 연결과 출구 선택 구분하기

아웃바운드가 여러 개 있다고 요청이 차례대로 모든 아웃바운드를 거치는 것은 아닙니다. 일반적으로 연결 하나는 아웃바운드 하나를 선택합니다. 코어에서 지원하는 체인 연결 기능을 명시적으로 설정해야만 단계별 의존 관계가 만들어집니다. 체인 연결에서는 어느 단계에서 서버 도메인을 해석하는지, 어느 단계가 UDP를 처리하는지, 앞 단계가 실패하면 어떻게 되는지, 어느 쪽 로그를 확인해야 하는지도 고려해야 합니다. 분명한 요구가 없다면 단순히 ‘한 단계 더 거치기’ 위해 연결 전달을 추가하지 마세요. 연결 시간이 늘고 문제를 찾기 어려워집니다.

사용자 지정 아웃바운드를 검증할 때는 먼저 하위 서비스의 수신 주소와 포트를 확인하고, 태그가 존재하는지 살펴본 뒤 규칙 매칭과 연결 오류를 확인하세요. 로그에 연결 거부가 표시되면 수신 서비스 상태를, 아웃바운드를 찾을 수 없다고 표시되면 태그와 설정 병합을 점검하세요. 순환 연결이나 반복 연결이 발생하면 관련 코어를 즉시 중지하고 정상 설정으로 복구하세요. 복구한 뒤 변경 사항을 하나씩 다시 적용합니다. 코어와 GUI 클라이언트의 역할은 Project V 오픈소스 생태계 안내를 참고하세요. 클라이언트 이름을 아웃바운드 프로토콜 이름으로 착각하지 마세요.

08 · 호환성과 최종 확인

프로토콜, 코어, 설정 검증

고급 설정을 마치기 전에 호환성을 네 단계로 확인해야 합니다. 클라이언트가 해당 매개변수를 표현할 수 있는지, 선택한 코어가 해당 필드를 파싱할 수 있는지, 서버에 필요한 기능이 설정되어 있는지, 현재 네트워크에서 연결이 가능한지 살펴보세요. 하나라도 충족되지 않으면 실패합니다. 클라이언트에 옵션이 있다고 해서 모든 서버에서 쓸 수 있는 것은 아닙니다. 가져온 항목에 메모가 표시된다고 설정이 완전히 적용되었다는 뜻도 아닙니다. 데스크톱에서는 주로 v2rayN으로 설정을 관리하고, Android에서는 필요에 따라 v2rayNG 또는 v2flyNG를 선택하세요. 지원 범위는 실제 코어와 가져오기 결과를 기준으로 확인해야 합니다.

프로토콜, 전송 방식, 암호화 계층을 구분해 확인하기

VLESS, VMess, Trojan, Shadowsocks는 서로 다른 인증 및 연결 방식을 설명하므로 프로토콜 이름만 바꿔 서로 변환할 수 없습니다. 전송 방식은 연결을 어떻게 전달할지 정하고, TLS나 REALITY 같은 설정은 핸드셰이크와 대상 식별 매개변수를 다룹니다. 문제를 찾을 때는 계층별로 확인하세요. 먼저 프로토콜과 인증 정보를 살펴보고, 다음으로 주소와 포트, 전송 경로와 서비스 이름을 확인한 뒤 TLS 이름 또는 REALITY에 필요한 필드를 점검합니다. 출처에서 제공하지 않은 값을 다른 서버 설정에서 가져와 임의로 채우지 마세요.

VLESS 자체에는 TLS와 같은 전송 암호화 기능이 없으므로 서버 요구 사항에 맞는 보안 계층을 함께 사용해야 합니다. REALITY와 XTLS Vision은 서로 바꿔 쓸 수 있는 프로토콜 태그가 아니며, 보안 계층, 흐름 제어, 코어 지원이 함께 맞아야 합니다. 핸드셰이크 실패는 라우팅 규칙보다 서버 이름, 키 관련 필드, Short ID, 시스템 시간 불일치 때문에 발생하는 경우가 많습니다. 원리와 설정 항목의 관계는 REALITY와 XTLS Vision 원리 안내를 참고하세요. 테스트할 때는 출처에서 제공한 전체 매개변수를 기준으로 삼으세요.

코어를 바꾸는 것이 모든 문제의 해결책은 아닙니다

Xray와 V2Fly는 Project V 생태계에 속하는 서로 다른 코어 계열이며, GUI 클라이언트는 인터페이스 설정을 코어 실행 설정으로 변환합니다. v2rayNG는 주로 Xray 계열 코어를 사용하고, v2flyNG는 V2Fly를 대상으로 합니다. 특정 확장 기능을 포함한 설정이 두 클라이언트 사이에서 그대로 호환된다고 기대하면 안 됩니다. v2rayN에서 코어를 선택할 때도 사용하는 프로토콜과 설정 템플릿을 고려해야 합니다. 코어를 바꾸기 전 기존 코어와 활성화된 고급 기능을 기록하고 기존 연결을 중지하세요. 인터페이스의 실행 아이콘만 보지 말고 새 코어가 정상적으로 시작되는지 확인하세요.

가져온 뒤 일부 필드가 사라졌다면 먼저 공유 형식이 해당 매개변수를 표현할 수 있는지, 현재 클라이언트가 그 형식을 지원하는지 확인하세요. 필요한 경우 GUI에서 항목을 하나씩 비교하되 실제 인증 정보를 공개 질문에 붙여 넣지 마세요. 코어 시작에 실패했다면 먼저 설정 문법, 알 수 없는 필드, 포트 충돌, 의존 파일을 확인합니다. 코어는 시작했지만 핸드셰이크에 실패하면 서버 매개변수, 시스템 시간, 네트워크 연결을 살펴보세요. 두 문제의 해결 경로는 다릅니다. 근거를 혼란스럽게 만들 수 있으니 무작정 코어를 바꾸지 마세요.

반복 가능한 검증 절차 만들기

설정을 바꿀 때마다 같은 순서로 확인하세요. 먼저 코어가 설정을 정상적으로 불러왔는지 확인하고, 로컬 인바운드가 작동하는지 살펴본 다음 일반 도메인, 직접 연결 대상, 프록시가 필요한 대상을 각각 테스트합니다. TUN, UDP, IPv6, 합성 주소 같은 추가 기능은 그 뒤에 확인하세요. 브라우저에서 페이지 하나가 열렸다는 것은 그때 해당 요청이 사용한 경로만 작동했다는 뜻입니다. 장시간 연결, 백그라운드 앱, 네트워크 전환은 별도로 연결을 다시 설정해 테스트해야 새 설정의 실제 상태를 기존 연결이 가리지 않습니다.

로그에는 시간, 대상, 인바운드, 적용된 규칙, 아웃바운드 태그를 중심으로 기록하세요. 오류 유형은 원문 그대로 남기되 구독 주소, 인증 정보, 불필요한 개인 접속 기록은 숨깁니다. 문제를 찾기 위해 로그 수준을 잠시 높일 수 있지만 해결한 뒤에는 적절한 수준으로 되돌려 장기 기록을 줄이세요. 한 번의 변경에 여러 항목이 포함되었다면 마지막으로 정상 작동한 상태로 돌아간 뒤 구독, 라우팅, DNS, 트래픽 처리, 추가 기능 순서로 하나씩 복원하세요. 비정상 상태에서 계속 조금씩 수정하는 것보다 재현하기 쉽습니다.

이 페이지의 목적은 설정 간 의존성을 이해하는 것이며 모든 기능을 켜야 하는 것은 아닙니다. 최종적으로는 설명할 수 있고, 검증할 수 있으며, 복구할 수 있는 설정만 유지하세요. 일반 앱의 트래픽은 예상대로 처리되고, 로컬 서비스에 접속할 수 있으며, DNS 해석 경로와 라우팅이 일치하고, 구독 업데이트가 수동 설정을 망가뜨리지 않아야 합니다. 처음부터 연결을 다시 설정해야 한다면 빠른 시작 안내로 돌아가세요. 증상별 해결 방법은 자주 묻는 질문에서 찾아볼 수 있습니다. 각 테스트 결과를 최근 변경 사항과 연결해 기록해야 고급 설정을 일회성 시도가 아닌 관리 가능한 환경으로 유지할 수 있습니다.