V2Ray 고급 설정 가이드

구독 그룹과 서버 필터링

구독 그룹은 설정의 출처를 구분하기 위한 기능이지, 트래픽 경로를 직접 결정하는 기능은 아닙니다. 일반적으로 그룹에는 구독 주소, 표시 이름, 업데이트 옵션, 필터 조건이 저장되고, 서버 목록은 구독을 업데이트한 뒤 생성됩니다. 서버를 다른 표시 그룹으로 옮겨도 특정 앱에 프록시 규칙이 설정되는 것은 아닙니다. 설정을 시작하기 전에 출처 관리, 현재 서버 선택, 라우팅 분기를 구분하세요. 그래야 엉뚱한 곳에서 관련 옵션을 찾는 일을 피할 수 있습니다.

출처별로 추적 가능한 그룹 만들기

v2rayN 구독 그룹 설정에서 출처마다 항목을 따로 만드세요. 이름은 ‘용도－출처’ 형식으로 지정할 수 있습니다. 예를 들면 ‘일상－주 구독’, ‘테스트－예비 구독’과 같습니다. 구독 주소를 빠짐없이 붙여 넣고 앞뒤 공백이나 줄바꿈이 없는지 확인하세요. 저장한 다음에는 모든 출처를 한꺼번에 업데이트하지 말고 해당 그룹만 업데이트합니다. 첫 업데이트에서는 해당 그룹의 결과만 확인해 서버가 생성되는지 살펴본 뒤 다른 구독을 추가하세요.

서버 이름은 원격에서 제공하는 메모일 뿐, 서버의 기능을 보증하는 정보가 아닙니다. 이름에 적힌 지역, 회선, 배율만으로 프로토콜 필드를 확인하거나 실제 출구 위치를 보장할 수는 없습니다. 서버를 고를 때는 프로토콜, 전송 방식, 암호화와 보안 설정이 코어에서 지원되는지 확인하세요. 코어를 선택할 때는 먼저 Xray와 V2Fly 코어 차이를 읽고 어떤 설정을 유지할지 결정할 수 있습니다.

임시 검색과 지속 필터를 구분하기

목록 검색은 일반적으로 현재 화면만 바꿉니다. 검색어를 지우면 서버는 그대로 남아 있습니다. 반면 구독 필터는 다음 업데이트에서 실제로 가져올 항목에 영향을 줄 수 있습니다. 검색어를 지운 뒤 원래 서버가 다시 보이는지 확인하면 두 기능을 구분하기 쉽습니다. 지속 필터를 켜기 전에는 필터가 없는 상태의 목록을 기록하고, 사용 가능 여부를 확인한 서버를 하나 이상 남겨 두세요. 필터 표현식을 잘못 입력하면 빈 목록을 구독 오류로 오해할 수 있습니다.

클라이언트에 따라 필터 입력란에서 일반 키워드를 받기도 하고 정규식을 지원하기도 합니다. 입력란 이름만 보고 기능을 단정하지 마세요. 정규식 사용이 명시된 경우 테스트|예비는 두 단어 중 하나와 일치한다는 뜻입니다. 일치 항목을 남길지 제외할지는 해당 옵션의 의미에 따라 달라집니다. 먼저 목록에 있는 서버 이름 하나로 시험한 다음 범위를 넓히세요. 구현마다 정규식 지원이 다를 수 있으므로 처음부터 복잡한 전방·후방 탐색을 사용하지 마세요.

업데이트 후 중복 이름, 사라진 항목, 선택 상태 확인

구독 업데이트 과정에서 항목이 다시 만들어지거나 클라이언트 정책에 따라 기존 항목과 병합될 수 있습니다. 따라서 현재 선택한 서버가 그대로 유지된다고 단정할 수 없습니다. 업데이트 후에는 현재 서버 표시를 확인하고 프로토콜 매개변수와 연결 가능 여부를 살펴보세요. 오래 유지해야 하는 수동 항목은 별도의 로컬 그룹에 보관하거나 업데이트 전에 백업으로 내보내세요. 원격 서버 이름을 수정해 개인 설정을 보존하려 하지 마세요. 다음 업데이트에서 변경 사항이 덮어써질 수 있습니다.

업데이트에 성공했는데 서버가 보이지 않으면 목록 검색어를 지우고 현재 그룹을 확인한 다음 구독 필터를 잠시 해제하세요. 이어서 응답 내용을 클라이언트가 인식할 수 있는지 확인합니다. 업데이트에 실패해도 기존 그룹을 바로 삭제하지 마세요. 기존 목록은 여전히 사용할 수 있습니다. Android에서도 구독 그룹과 현재 목록 화면을 구분해야 합니다. v2rayNG와 v2flyNG는 메뉴 위치가 다르지만, ‘그룹 하나 업데이트, 결과 확인, 서버 선택’ 순서로 진행하면 됩니다. 출처를 명확히 해 두면 이후 문제 해결 과정에서 어떤 업데이트가 설정을 바꿨는지 파악하기 쉽습니다.

라우팅 규칙 실전

라우팅은 연결이 코어에 들어온 뒤 사용할 아웃바운드를 선택하는 과정입니다. 대상 도메인, 주소, 포트, 네트워크 유형, 인바운드 태그 등을 기준으로 판단할 수 있습니다. 클라이언트의 ‘규칙 모드’는 대개 미리 정의된 라우팅 설정을 선택하는 기능이지, 코어가 모든 앱의 용도를 자동으로 이해한다는 뜻은 아닙니다. 직접 규칙을 만들기 전에 현재 활성화된 설정을 확인하고 기존 규칙을 백업하세요. 편집기에서 규칙을 저장해도 실행 중인 코어에 반영되지 않을 수 있습니다.

규칙 순서와 조건 조합 이해하기

일반적으로 라우팅 규칙은 위에서 아래로 확인하며, 처음 일치한 규칙이 아웃바운드를 결정합니다. 따라서 구체적인 규칙을 포괄적인 규칙보다 앞에 두세요. 예를 들어 프록시를 사용할 전체 도메인 규칙, 로컬 주소 직접 연결 규칙, 마지막으로 기본 동작 순서로 배치할 수 있습니다. 한 규칙 안의 서로 다른 조건은 보통 모두 충족해야 하며, 같은 조건 필드의 여러 값은 대개 하나만 일치해도 됩니다. 도메인, 포트, 네트워크 유형을 한 줄에 모두 입력하면 독립적인 일치 조건이 세 개 생기는 것이 아니라 일치 범위가 좁아집니다.

도메인 일치 방식에도 범위 차이가 있습니다. 전체 도메인 일치는 단일 호스트에 적합하고, 도메인 및 하위 도메인 일치는 서비스 전체에 적합합니다. 키워드 일치는 이름이 비슷한 다른 사이트까지 뜻하지 않게 포함할 수 있습니다. 가장 좁은 범위부터 확인한 뒤 단계적으로 넓히세요. 다운로드 도메인 하나의 문제를 해결하려고 모든 트래픽을 프록시로 보내지 마세요. 당장은 접속이 복구될 수 있지만 규칙 범위가 너무 넓거나, 필요한 도메인이 빠졌거나, DNS 경로가 잘못된 문제를 가리게 됩니다.

명확한 규칙 하나부터 검증하기

다음은 Xray에서 자주 사용하는 JSON 라우팅 필드의 일부 예시로, 전체 도메인, 사설 주소, 아웃바운드 태그의 관계를 보여 줍니다. 완전한 클라이언트 설정이 아니므로 이미 존재하는 실행 설정에 병합해야 하며 proxy와 direct 아웃바운드도 정의되어 있어야 합니다. 예시 도메인은 일치 문법을 설명하기 위한 것입니다. 실제로 테스트할 때는 자신의 설정에서 처리하려는 실제 대상으로 바꾸세요.

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

AsIs는 IP 규칙을 적용하기 위해 도메인을 능동적으로 조회하지 않습니다. 다만 연결에 원래 대상 IP가 포함되어 있으면 IP 규칙과 일치할 수 있습니다. 도메인 연결이 도메인 규칙과 일치하지 않는 경우, 사설 주소 규칙을 작성했다고 해서 먼저 도메인을 조회해 로컬 네트워크 속성을 판별하는 것은 아닙니다. 내부 도메인을 처리하려면 명시적인 도메인 규칙을 추가하거나 조회의 영향을 이해한 뒤 다른 도메인 전략을 선택하세요. geoip:private를 사용하려면 해당 데이터 파일을 읽을 수 있어야 합니다. 파일을 찾지 못한다면 먼저 로드 오류를 해결하세요.

기본 동작, 스니핑, 기존 연결

어떤 규칙에도 일치하지 않으면 코어는 일반적으로 아웃바운드 목록의 첫 항목을 사용합니다. 클라이언트가 마지막 규칙을 추가할 수도 있습니다. 화면에서 마지막 줄만 보지 말고 실제 생성된 설정을 확인하세요. 특정 아웃바운드를 기본 동작으로 사용하려면 클라이언트의 최종 아웃바운드 설정을 사용할 수 있습니다. 수동으로 설정할 때는 어떤 인바운드나 네트워크 유형에 적용되는지 분명히 지정하세요. 의미가 불분명한 빈 조건으로 규칙을 만들지 마세요. 기본 아웃바운드 순서를 바꾸면 기존에 규칙과 일치하지 않던 연결의 경로도 달라질 수 있습니다.

스니핑은 일부 연결에서 HTTP 호스트 이름이나 TLS 서버 이름을 복원할 수 있지만 모든 암호화 프로토콜을 식별하지는 못합니다. 암호화 핸드셰이크 정보를 보호하는 도메인은 확인하지 못할 수도 있습니다. 스니핑은 DNS를 대체하는 기능이 아니라 보조 정보원입니다. 규칙을 바꾼 뒤에는 새 연결을 만들어 테스트하세요. 이미 열린 장기 연결은 출구가 자동으로 바뀌지 않는 경우가 많습니다. 필요하면 테스트 앱을 완전히 종료한 뒤 다시 실행하세요. 같은 페이지를 계속 새로고침하는 것만으로는 충분하지 않습니다.

규칙이 적용되지 않으면 먼저 트래픽이 클라이언트에 들어오는지 확인하세요. 다음으로 규칙 활성화 여부, 대상 일치 여부, 앞쪽에 더 포괄적인 규칙이 있는지, 대상 아웃바운드 태그가 정확한지 살펴봅니다. 시스템 프록시 모드에서 시스템 프록시를 따르지 않는 앱은 라우팅 체인에 들어오지 않습니다. 그래도 원인을 찾지 못했다면 도움말 센터의 프록시 모드 설명을 참고해 먼저 트래픽 진입 경로를 해결한 뒤 라우팅 규칙을 조정하세요.

DNS 설정 최적화

DNS 설정에서는 두 가지를 구분해야 합니다. 도메인을 누가 조회하는지, 그리고 조회 요청이 어떤 네트워크 경로로 나가는지입니다. 브라우저, 운영체제, 클라이언트 코어, 원격 서버가 모두 조회 과정에 관여할 수 있습니다. 웹사이트에 접속된다고 모든 앱이 같은 경로로 도메인을 조회하는 것은 아닙니다. 시스템 DNS를 바꿨는데 특정 앱에서 차이가 없어도 변경 실패라고 단정할 수 없습니다. 앱이 자체 암호화 DNS를 사용하거나 별도의 캐시를 보유할 수 있습니다.

먼저 DNS 조회 경로 파악하기

시스템 프록시를 사용할 때 앱은 도메인을 로컬 프록시에 전달한 뒤 아웃바운드나 원격 서버에서 처리하게 할 수도 있고, 로컬에서 IP로 변환한 뒤 IP를 프록시에 전달할 수도 있습니다. TUN 모드에서 클라이언트가 DNS를 가로채는지는 가상 인터페이스, DNS 하이재킹, 앱의 요청 방식에 따라 달라집니다. 최적화를 시작하기 전에 현재 시스템 리졸버, 클라이언트 DNS 옵션, 브라우저의 보안 DNS 설정을 기록하세요. 한 번에 하나만 바꿔야 어느 단계가 결과를 바꿨는지 확인할 수 있습니다.

프록시 서버 도메인 조회는 특히 중요합니다. 클라이언트는 서버를 찾아야 그 서버를 통해 후속 트래픽을 보낼 수 있습니다. 서버 도메인의 조회를 아직 연결되지 않은 프록시를 통해 강제로 보내면 시작 단계에서 의존성 순환이 발생할 수 있습니다. 서버 주소가 도달 가능한 부트스트랩 조회 경로를 유지하고 직접 연결 조건을 명확히 지정하는 편이 안전합니다. 프록시가 끊겨도 서버 조회를 계속할 수 있어야 재연결이 반복해서 실패하는 일을 막을 수 있습니다.

도메인 전략과 주소 패밀리 전략 구분하기

라우팅의 domainStrategy는 IP 규칙에 맞추기 위해 도메인을 조회할지 결정합니다. DNS의 queryStrategy는 조회에 사용할 주소 패밀리를 지정합니다. 직접 연결 아웃바운드의 도메인 전략은 실제 연결을 시작하기 전에 도메인을 어떻게 처리할지 결정합니다. 이름이 비슷해도 서로 다른 위치의 필드이므로 대체해서 사용할 수 없습니다. 다음은 시스템 리졸버를 기준으로 복잡한 분기 DNS 설정이 원인인지 먼저 확인하기 위한 최소한의 내장 DNS 예시입니다.

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

이 설정 조각은 시스템의 모든 DNS 요청을 자동으로 가로채지 않으며 모든 아웃바운드가 내장 리졸버를 사용한다고 보장하지도 않습니다. 실제 호출은 라우팅 정책, 아웃바운드 설정, 클라이언트 통합 방식에 따라 달라집니다. 기존 설정에 도메인 필터가 있는 리졸버 항목이 있다면 DNS 객체 전체를 바로 바꾸지 마세요. 해당 규칙이 사라질 수 있습니다. 먼저 원래 설정을 내보내고 시험하세요. 기준 설정으로 복원했을 때 문제가 사라진다면 기존 서버와 필터 조건을 하나씩 다시 추가합니다.

IPv6, 캐시, 내부 도메인 처리

듀얼 스택 네트워크에서는 로컬 네트워크, 프록시 서버, 대상 서비스의 세 구간에서 IPv6에 실제로 연결할 수 있는지 먼저 확인하세요. IPv6 주소를 받았다고 연결이 된다는 뜻은 아닙니다. 로그에서 주소 패밀리 관련 연결 오류가 계속 발생한다면 비교를 위해 잠시 IPv4만 사용해 볼 수 있지만, IPv6를 영구적으로 끄는 것은 모든 DNS 문제의 해결책이 아닙니다. 비교 테스트가 끝나면 제한을 유지할지 결정하고, 기존에 사용할 수 있던 내부 서비스에 영향이 없는지도 확인하세요.

회사 내부 도메인, 라우터 관리 주소, 기기 검색 이름은 로컬 DNS 환경에 의존하는 경우가 많습니다. 모든 도메인 조회를 공용 리졸버로 보내면 이러한 이름을 찾지 못할 수 있습니다. 내부 도메인은 시스템 리졸버나 지정한 로컬 리졸버를 사용하도록 하고 관련 대상은 직접 연결로 보내세요. DNS를 바꾼 뒤에는 시스템과 앱의 캐시 만료 시간이 서로 다를 수 있습니다. 리졸버를 계속 바꾸는 것보다 테스트 앱을 다시 시작하는 편이 유용한 경우가 많습니다. 이미 연결된 세션은 도메인을 다시 조회하지 않을 수 있습니다.

문제 해결 시 ‘조회 시간 초과’, ‘부적절한 주소 반환’, ‘주소는 맞지만 연결 실패’를 구분해 기록하세요. 조회 시간 초과는 리졸버 접근성과 요청 라우팅을 확인하고, 부적절한 주소는 필터 규칙과 캐시를 살펴봅니다. 연결 실패라면 아웃바운드, 대상 포트, 네트워크 환경을 추가로 확인하세요. 암호화 DNS는 조회 전송 방식을 바꾸는 기능이지, 잘못된 라우팅 선택을 자동으로 바로잡거나 도달할 수 없는 서버에 연결해 주는 기능은 아닙니다.

TUN 모드와 시스템 네트워크 가로채기

TUN은 가상 네트워크 인터페이스를 통해 IP 계층의 트래픽을 사용자 공간으로 전달합니다. 시스템 프록시를 따르지 않지만 트래픽을 한곳에서 분기해야 하는 앱에 적합합니다. 그렇다고 ‘더 강력한 전역 프록시’ 스위치는 아닙니다. 트래픽이 TUN에 들어온 뒤에도 라우팅 규칙이 직접 연결 또는 프록시를 결정해야 하며, 아웃바운드 프로토콜, UDP 지원, DNS 처리 방식의 제약도 받습니다. 시스템 프록시와 TUN은 진입 경로가 다릅니다. 각각 먼저 따로 확인한 뒤 함께 사용할 필요가 있는지 판단하세요.

가로채기 구성 요소, 권한, 기본 동작 확인

v2rayN의 TUN은 별도 구성 요소가 처리할 수 있으므로 GUI의 TUN 스위치를 Xray에 같은 이름의 필드를 추가하는 기능으로 이해해서는 안 됩니다. 시작하기 전에 일반 프록시 모드가 안정적으로 작동하는지 확인하고 현재 서버의 연결 가능 여부, 클라이언트가 요구하는 실행 권한, 구성 요소 상태와 로그를 살펴보세요. Android의 VPN 권한은 트래픽 가로채기를 허용하는 권한입니다. 데스크톱과 완전히 같은 가상 인터페이스 구현이나 설정 형식을 사용한다는 뜻은 아닙니다.

처음 활성화할 때는 설정을 복구할 수 있는 로컬 조작 수단을 남겨 두세요. 네트워크를 이미 가로채고 있는 다른 도구를 먼저 종료하고 현재 Wi-Fi 또는 유선 네트워크의 DNS와 프록시 설정을 저장한 뒤 TUN을 켭니다. 가상 인터페이스가 만들어졌는지, 기본 경로가 바뀌었는지, 테스트 트래픽이 로그에 들어오는지 확인하세요. 화면에는 활성화로 표시되는데 연결 기록이 없다면 서버를 바꾸기 전에 인터페이스와 라우팅을 먼저 확인합니다.

루프를 방지하고 로컬 네트워크 접근 유지

프록시 클라이언트가 서버에 연결할 때 그 연결이 다시 자신이 처리할 프록시 대상 트래픽으로 가로채지면 루프가 발생하거나 재시도가 반복됩니다. 잘 구성된 가로채기 구성 요소는 보통 자동 라우팅이나 인터페이스 바인딩을 제공하지만 라우팅을 수동으로 바꾸면 이러한 보호 기능이 깨질 수 있습니다. TUN을 켠 직후 프록시 연결이 끊기면 먼저 서버 주소가 잘못 가로채지는지 확인한 다음 여러 가상 인터페이스가 기본 경로를 두고 경쟁하는지 살펴보세요.

로컬 네트워크 기기, 프린터 서비스, 라우터 관리 페이지는 대개 직접 연결이 필요하지만 사설 주소 규칙만으로 기기 검색까지 처리할 수 있는 것은 아닙니다. 브로드캐스트, 멀티캐스트, 이름 기반 검색은 별도의 문제이며 가상 네트워크를 통과할 수 있는지는 구현과 시스템 환경에 따라 다릅니다. 기기 IP로는 연결되지만 이름을 찾을 수 없다면 프록시 범위를 계속 넓히지 말고 DNS나 검색 프로토콜을 점검하세요. 기업 네트워크에서는 사설 주소 대역이 로컬 네트워크와 겹칠 수 있으므로 라우팅 범위를 더 구체적으로 지정해야 합니다.

TCP, UDP, 앱 범위를 나눠 단계별로 확인

먼저 명확한 TCP 요청 하나로 트래픽 진입과 아웃바운드를 확인한 뒤 실제로 필요한 UDP 앱을 테스트하세요. 웹페이지는 열리지만 음성 통화나 실시간 통신이 실패한다면 UDP 전달, 서버 기능, 네트워크 정책 문제일 수 있습니다. TUN 전체가 작동하지 않는다고 단정할 수는 없습니다. 앱에서 QUIC 관련 문제가 발생하면 UDP 경로를 별도로 기록하세요. 앱의 해당 기능을 잠시 끄는 것은 비교를 위한 방법일 뿐, 하위 계층의 전달 기능을 점검하는 일을 대신하지 않습니다.

시스템 프록시와 TUN을 동시에 켜는 것이 클라이언트에서 의도한 동작일 수도 있고, 앱이 먼저 로컬 프록시에 연결한 뒤 그 트래픽이 다시 TUN에 잡히는 원인일 수도 있습니다. 문제를 해결하는 동안에는 확인된 진입 방식 하나만 남기고 작동을 확인한 뒤 조합 설정을 다시 적용하세요. Android에서 앱별 제외를 사용하면 제외된 앱은 클라이언트 라우팅을 완전히 우회할 수 있습니다. 따라서 해당 앱의 접속 결과로 코어 규칙을 검증할 수 없습니다. 백그라운드 절전 제한으로 가로채기 세션이 끊길 수도 있으므로 프로세스 종료와 서버 연결 끊김을 구분하세요.

TUN을 끈 뒤에도 네트워크가 복구되지 않으면 가상 인터페이스, 기본 경로, 시스템 DNS가 원래 상태로 돌아왔는지 확인하세요. 시스템 프록시가 이미 종료된 로컬 포트를 가리키고 있는지도 살펴봅니다. 모든 네트워크 어댑터를 삭제하거나 네트워크 설정 전체를 초기화하지 마세요. 영향 범위가 지나치게 커집니다. 이번에 추가한 가로채기 설정만 되돌리고 현재 네트워크에 다시 연결하면 기존 기업 네트워크와 로컬 기기 설정을 유지하기 쉽습니다.

FakeDNS의 작동 방식과 사용 범위

FakeDNS는 도메인에 로컬 매핑용 합성 주소를 반환한 뒤 연결이 프록시 처리 경로에 들어오면 매핑을 통해 원래 도메인을 복원합니다. 앱이 도메인을 IP로 바꾼 뒤에도 라우팅에서 도메인 기준으로 판단할 수 있도록 정보를 보존하는 기능이지, 대상 사이트에 실제 주소를 할당하는 기능은 아닙니다. 이 점을 이해하는 것이 중요합니다. 합성 주소는 해당 주소를 이해하는 가로채기 및 매핑 경로 안에서만 사용할 수 있으며 일반 네트워크 기기는 그 주소가 어떤 도메인을 가리키는지 알지 못합니다.

조회, 매핑, 연결 복원이 한 흐름으로 이어져야 합니다

전체 경로는 최소 세 단계로 이뤄집니다. 앱이 도메인을 조회해 합성 주소를 받고, 해당 주소로 연결을 시작한 뒤, 가로채기 구성 요소가 주소에서 도메인을 찾아 후속 라우팅에 전달합니다. 첫 단계만 활성화하면 앱이 직접 연결할 수 없는 주소를 받을 수 있습니다. 도메인 스니핑만 켜도 FakeDNS 매핑을 복원할 수 있다고 보장할 수는 없습니다. 클라이언트가 제공하는 통합 옵션을 사용하고 DNS와 트래픽 가로채기를 호환되는 구성 요소가 함께 처리하는지 확인하세요.

v2rayN에서는 온라인에서 찾은 코어 설정 조각을 모든 입력란에 붙여 넣기보다 현재 TUN 구성 요소가 해당 기능을 제공하는지 먼저 확인하세요. v2rayNG, v2flyNG, 데스크톱 클라이언트의 통합 방식도 다를 수 있으며 지원 여부는 코어와 클라이언트 구현에 따라 달라집니다. 메뉴에 해당 기능이 없다면 필드 하나를 추가하는 것만으로 인터페이스, DNS 하이재킹, 주소 복원까지 모두 해결된다고 가정하지 마세요.

주소 풀과 매핑 용량 이해하기

다음은 Xray에서 자주 사용하는 FakeDNS 객체 형식으로, 합성 풀에 테스트 전용 주소 범위를 지정합니다. 독립 실행이 가능한 가로채기 설정이 아니라 문법 예시일 뿐입니다. 내장 DNS에서 FakeDNS를 호출하고 호환되는 인바운드에서 매핑을 복원하는 설정도 필요합니다. 현재 클라이언트가 다른 가로채기 구성 요소를 사용한다면 해당 구성 요소의 문법을 사용하고 필드를 혼용하지 마세요.

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

ipPool은 매핑에 사용할 합성 주소 범위를 정하고 poolSize는 매핑 풀의 용량을 정합니다. 동시 연결 수를 뜻하지 않으며 값이 클수록 빠른 것도 아닙니다. 설정 전에 합성 주소 대역이 현재 테스트 네트워크나 특수 라우팅에서 사용되고 있지 않은지 확인하세요. 흔한 가정용 로컬 네트워크 대역을 주소 풀로 임의 지정하지 마세요. 실제 기기 주소와 합성 주소가 충돌해 일부 기기에 갑자기 연결되지 않을 수 있습니다.

매핑의 수명도 고려해야 합니다. 코어를 다시 시작하면 이전 매핑이 사라질 수 있지만 시스템이나 앱에는 기존 합성 주소가 캐시되어 있을 수 있습니다. 이 상태에서 새 연결이 클라이언트에 들어와도 대응하는 도메인을 찾지 못해 ‘처음에는 작동했지만 재시작 후 일부 앱이 실패하는’ 문제가 생깁니다. 주소 풀을 계속 늘려 수명 불일치를 감추지 말고 앱이 DNS를 다시 조회하도록 하세요. 필요하면 앱을 종료하고 관련 캐시를 비웁니다.

실제 주소가 필요한 앱 확인하기

일부 앱은 DNS 응답 주소를 검사하거나 주소와 인증서 정보를 비교하며, 조회 결과를 프록시를 거치지 않는 다른 프로세스에 전달하기도 합니다. 이런 경우에는 합성 주소가 적합하지 않을 수 있습니다. 로컬 네트워크 관리, 기기 검색, 일부 실시간 통신, 실제 주소를 기준으로 판단하는 프로그램은 따로 확인해야 합니다. 클라이언트가 도메인별 실제 조회를 지원한다면 해당 대상에 예외를 만들 수 있지만, 관련 라우팅과 DNS 요청 경로도 함께 확인하세요.

브라우저의 자체 암호화 DNS가 예상한 FakeDNS 조회 경로를 우회하면 같은 기기에서도 일부 앱은 실제 주소를, 다른 앱은 합성 주소를 받을 수 있습니다. 이런 혼합 상태에서는 앱별 조회 방식을 먼저 기록하세요. 웹페이지가 열린다는 이유만으로 전체 경로가 정상이라고 판단하지 마세요. 테스트에는 일반 웹페이지, 도메인 분기가 필요한 대상, 로컬 네트워크 주소, 프록시를 사용하지 않아야 하는 앱을 하나씩 포함해야 합니다.

기능을 끌 때 관련 설정도 함께 되돌리기

FakeDNS를 끌 때는 매핑 풀만 비활성화하면 끝나지 않습니다. 정상적인 조회 경로를 복구하고 클라이언트가 앱에 더 이상 합성 주소를 반환하지 않는지 확인한 뒤 기존 캐시도 만료시켜야 합니다. 가로채기 기능은 끈 채 합성 DNS 응답을 남기면 앱이 일반 네트워크에서 사용할 수 없는 합성 주소로 트래픽을 보내므로 문제가 계속됩니다. 복구 순서는 클라이언트 통합 방식에 맞추되, 마지막에는 DNS 결과와 트래픽 가로채기 방식이 다시 일치해야 합니다.

일반 DNS, 라우팅, TUN이 안정적으로 작동한 뒤에 FakeDNS를 도입하는 것이 좋습니다. 도메인 하나의 분기 문제를 해결하려는 목적이라면 먼저 명시적인 도메인 규칙으로 해결할 수 있는지 확인하세요. 도메인 정보가 실제로 유실되고 가로채기 경로가 복원 기능을 지원할 때만 이 매핑 계층을 추가할 가치가 있습니다. 기능을 켠 뒤 한 번 접속했을 때의 주관적인 속도 변화만 보지 말고 로그에서 이점이 확인되는지 살펴보세요.

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

다중 구독 관리는 출처, 용도, 변경 이력을 추적하기 쉽게 유지하는 것이 핵심입니다. 모든 서버를 하나의 긴 목록으로 합치는 기능이 아닙니다. 먼저 주 구독, 예비 구독, 테스트 구독의 역할을 정하세요. 주 구독은 일상적으로 사용하고, 예비 구독은 수동으로 전환할 서버를 제공하며, 테스트 구독은 새 프로토콜이나 설정을 확인하는 데 사용합니다. 서버가 다른 그룹에 있다는 사실만으로 자동 장애 조치가 가능하거나 그룹 이름에 따라 트래픽이 자동 분배되는 것은 아닙니다.

출처마다 독립된 경계 유지하기

새 출처를 추가할 때는 별도 그룹을 만들고 해당 그룹만 업데이트한 뒤 프로토콜 유형, 항목 이름, 필터 결과를 확인하세요. 두 출처에서 같은 이름을 제공하더라도 출처 정보는 유지해야 합니다. 이름이 같다고 같은 서버라는 뜻은 아닙니다. 주소, 포트, 전송 매개변수를 비교할 때는 로컬에서 확인하고 문제 해결 자료를 공유할 때 자격 증명을 가리세요. 목록을 깔끔하게 만들려고 출처를 바로 합치면 나중에 특정 항목이 어느 업데이트에서 추가됐는지 파악하기 어렵습니다.

중복 항목인지 판단할 때는 실제 용도를 고려해야 합니다. 서버 주소와 포트가 같아도 사용자 자격 증명, 전송 경로, 보안 매개변수가 다르면 서로 다른 설정일 수 있습니다. 이름이 달라도 같은 서비스를 가리킬 수 있습니다. 클라이언트의 중복 제거 기능은 제한된 필드를 기준으로 판단하는 경우가 많으므로 직접 확인을 대신할 수 없습니다. 일괄 중복 제거 전에 로컬 백업을 내보내고 연결 가능한 항목을 하나 이상 남기세요. 실수로 삭제하면 원격에서 다시 제공될 때까지 기다려야 할 수 있습니다.

결과를 확인할 수 있는 업데이트 절차 만들기

구독 업데이트는 서버 목록을 바꾸므로 장시간 다운로드, 원격 관리, 중요한 통신 중에는 가급적 피하세요. 먼저 예비 또는 테스트 그룹을 업데이트해 이상이 없는지 확인한 다음 주 그룹을 업데이트합니다. 자동 업데이트 주기를 설정할 수 있다면 실제 변경 빈도에 맞추세요. 업데이트를 자주 할수록 좋은 것은 아닙니다. 너무 잦은 요청은 구독 제공자의 제한을 유발할 수 있고 로컬 목록을 계속 바꿔 문제 해결을 어렵게 합니다.

구독 업데이트에 프록시가 필요한지는 별도로 확인해야 합니다. 일부 출처는 현재 네트워크에서 직접 연결해 사용할 수 있지만, 다른 출처는 기존 프록시 경로가 필요할 수 있습니다. 현재 서버가 업데이트에 필요하지만 이미 작동하지 않는다면 ‘복구하려면 업데이트해야 하지만 업데이트에 실패한 연결이 필요하다’는 순환이 생깁니다. 클라이언트가 업데이트 경로를 선택할 수 있다면 출처의 안전성을 확인한 뒤 요청 경로를 바꾸세요. 구독 주소를 출처를 알 수 없는 온라인 변환 서비스에 붙여 넣어 해결하려 하지 마세요.

개인 설정과 원격 콘텐츠 분리하기

구독에서 제공하는 서버 정보와 개인 라우팅 설정은 따로 관리해야 합니다. 로컬 네트워크 직접 연결 규칙, 앱 범위, DNS 예외는 구독에서 생성되는 임시 설정을 직접 수정하지 말고 클라이언트가 지원하는 독립 설정으로 저장하는 편이 좋습니다. 생성 파일은 서버 전환, 구독 업데이트, 재시작 때 다시 만들어질 수 있습니다. 변경 사항이 임시 파일에만 있으면 다음 생성 과정에서 사라져 클라이언트가 설정을 저장하지 않았다고 오해하기 쉽습니다.

원격 구독에 복잡한 설정이 포함될 수도 있으므로 클라이언트가 서버 목록을 가져오는지 전체 설정을 가져오는지 먼저 확인하세요. 두 방식의 권한 범위는 다릅니다. 서버 목록은 보통 연결 매개변수만 추가하지만 전체 설정은 라우팅, DNS, 리스닝 동작까지 바꿀 수 있습니다. 가져오기 전에 형식 안내를 읽고, 가져온 뒤에는 실제 실행 설정을 확인하세요. 특히 로컬 네트워크 리스닝과 기본 아웃바운드를 살펴보고 파일 확장자만으로 내용을 판단하지 마세요.

업데이트 실패 후 기존 항목 보존 및 복구

업데이트가 한 번 실패했다고 기존 목록을 바로 삭제하지 마세요. 연결 시간 초과, 비정상 응답 상태, 빈 응답, 형식 파싱 실패 중 어떤 상황인지 먼저 확인합니다. 상황에 따라 해결 방법이 달라집니다. 기존 서버에 계속 연결할 수 있다면 잠시 보존하고 반복해서 새로고침하지 마세요. 구독 주소가 바뀌었다면 신뢰할 수 있는 출처에서 새 주소를 확인한 뒤 기존 그룹에서 교체하세요. 의미는 같지만 상태가 다른 항목을 여러 개 만들지 않는 편이 좋습니다.

예비 구독은 주 구독과 독립적으로 확인할 수 있다는 장점이 있습니다. 주 구독에 문제가 생길 때까지 기다리지 말고 평소에도 업데이트 가능 여부, 사용 가능한 서버, 코어 지원 여부를 간혹 확인하세요. 관련 클라이언트의 기능 범위는 세 클라이언트의 플랫폼 및 기능 비교를 참고하세요. 출처를 분리한 뒤 자동 선택이나 부하 분산을 고려해야 구독 관리 문제와 아웃바운드 스케줄링 문제를 혼동하지 않습니다.

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

아웃바운드는 코어에서 연결이 나가는 방식을 정의하고, 라우팅은 아웃바운드 태그를 참조해 사용할 방식을 결정합니다. 일반적인 아웃바운드에는 프록시 프로토콜, 직접 연결, 차단이 있습니다. 아웃바운드 객체를 추가한다고 트래픽이 자동으로 그 객체를 사용하는 것은 아닙니다. 라우팅 규칙이 해당 객체와 일치하거나 기본 아웃바운드로 지정되어야 합니다. 반대로 라우팅에서 존재하지 않는 태그를 참조해도 해당 연결 방식이 만들어지지 않습니다. 따라서 사용자 지정 설정에서는 태그가 일치하는지 먼저 확인해야 합니다.

먼저 설정 생성 주체 확인하기

v2rayN의 일반 서버 모드는 보통 현재 선택과 인터페이스 설정에 따라 실행 설정을 생성합니다. 생성된 결과를 직접 수정하면 다음에 서버를 전환할 때 변경 사항이 사라질 수 있습니다. 사용자 지정 아웃바운드가 필요하면 클라이언트가 명시적으로 제공하는 고급 설정 입력란을 먼저 사용하세요. 전체 사용자 지정 설정을 선택한다면 어떤 인터페이스 스위치가 계속 적용되고 어떤 필드를 사용자 지정 파일이 담당하는지 확인해야 합니다. 두 관리 방식을 섞으면 ‘화면 설정은 바뀌었는데 실행 결과는 그대로인’ 문제가 쉽게 생깁니다.

Android 클라이언트에서도 일반 설정 편집과 전체 설정 가져오기를 구분해야 합니다. v2rayNG는 주로 Xray를 사용하고 v2flyNG는 V2Fly를 사용합니다. 두 클라이언트 모두 같은 서버 목록을 처리한다고 해서 모든 아웃바운드 필드가 호환되는 것은 아닙니다. 특정 프로토콜이나 보안 계층 매개변수를 사용할 때는 대상 코어의 지원 범위를 먼저 확인하세요. 커뮤니티 생태계 관계는 Project V 오픈소스 생태계 살펴보기를 참고하고 클라이언트 이름만으로 내부 기능을 추측하지 마세요.

직접 연결과 차단으로 태그 경로 확인하기

다음은 Xray에서 사용할 수 있는 최소 구성의 로컬 SOCKS 설정입니다. 인바운드, 라우팅, 아웃바운드 태그의 관계를 확인하기 위한 예시입니다. 직접 연결과 예시 도메인 차단만 제공하며 프록시 서버는 포함하지 않습니다. 리스닝 주소를 로컬 루프백으로 제한하고 UDP를 끄므로 독립된 테스트에 적합합니다. 사용 중인 주 설정을 덮어쓰지 말고 테스트 전에 로컬 포트가 사용 중인지 확인하세요.

{
  "log": {
    "loglevel": "warning"
  },
  "inbounds": [
    {
      "tag": "local-socks",
      "listen": "127.0.0.1",
      "port": 10808,
      "protocol": "socks",
      "settings": {
        "auth": "noauth",
        "udp": false
      }
    }
  ],
  "outbounds": [
    {
      "tag": "direct",
      "protocol": "freedom",
      "settings": {}
    },
    {
      "tag": "block",
      "protocol": "blackhole",
      "settings": {}
    }
  ],
  "routing": {
    "domainStrategy": "AsIs",
    "rules": [
      {
        "type": "field",
        "domain": ["full:example.com"],
        "outboundTag": "block"
      }
    ]
  }
}

테스트 앱은 도메인을 로컬에서 먼저 IP로 변환하지 말고 SOCKS 프록시에 전달해야 예시의 전체 도메인 규칙과 일치할 수 있습니다. 이 설정에는 도메인 정보를 보완하는 스니핑이 활성화되어 있지 않아 검증 조건이 명확합니다. 일치하지 않는 연결은 첫 번째 아웃바운드인 direct를 사용합니다. 아웃바운드 순서를 바꾸면 기본 동작도 달라지므로 설정을 관리할 때 태그뿐 아니라 배열 순서도 확인하세요.

프록시 아웃바운드 추가와 체인 연결 이해하기

실제로 프록시 아웃바운드를 추가할 때는 연결을 확인한 서버 설정을 기준으로 프로토콜, 서버 주소, 포트, 사용자 매개변수, 전송 및 보안 설정을 유지한 뒤 고유한 태그를 지정하세요. 주소와 포트만 복사하면 전송 경로, 서버 이름, 보안 매개변수가 맞지 않아 핸드셰이크에 실패할 수 있습니다. 각 태그에는 주 프록시, 예비 프록시처럼 역할을 하나씩 명확히 지정해 로그에서 실제 출구를 쉽게 확인할 수 있도록 하세요.

체인 연결은 하나의 아웃바운드가 다른 아웃바운드를 통해 하위 연결을 만드는 방식입니다. 라우팅 규칙 두 개를 차례로 실행하는 것과는 다릅니다. 보통 첫 번째 라우팅 규칙과 일치하면 같은 연결이 다음 규칙으로 이어지지 않습니다. 코어마다 아웃바운드 전달 필드와 전송 방식 지원이 다르므로 대상 코어의 문법에 맞춰 설정하세요. A가 B에 의존하고 B가 다시 A에 의존하는 구조나, 아직 연결되지 않은 경로 자체에 도메인 조회를 의존시키는 구성은 피해야 합니다.

부하 분산은 후보 아웃바운드를 선택하는 기능으로, 사용 가능 여부 확인, 선택 정책, 세션 유지도 고려해야 합니다. 여러 아웃바운드를 배열에 넣는다고 자동으로 순환 선택되거나 장애가 감지되는 것은 아닙니다. 가끔 예비 서버로 전환하는 정도라면 직접 선택하는 편이 검증하기 쉽습니다. 자동 스케줄링이 분명히 필요하고 각 후보의 상태를 파악할 수 있을 때만 더 복잡한 구성을 도입하세요.

설정 검증, 로그 확인, 되돌리기

설정을 저장할 수 있다고 해서 실행할 수 있는 것은 아니며, 코어가 실행된다고 대상 트래픽이 예상한 아웃바운드를 사용한다는 보장도 없습니다. 고급 설정은 단계별로 확인하세요. 먼저 문법과 리소스 로드를 확인하고, 로컬 진입 경로, 라우팅과 DNS, 원격 연결을 차례로 살펴봅니다. 변경 전에는 ‘지정한 전체 도메인만 프록시로 보내고 로컬 네트워크는 직접 연결한다’처럼 예상 결과를 분명히 적어 두세요. 그래야 테스트가 실패했을 때 어느 단계에서 조건을 충족하지 못했는지 알 수 있습니다.

재현 가능한 변경 기록 남기기

백업에는 서버 목록만이 아니라 구독 그룹, 수동 서버, 라우팅 규칙, DNS, 트래픽 가로채기 설정을 포함해야 합니다. 내보낸 파일에는 자격 증명이 들어 있을 수 있으므로 안전한 곳에 보관하세요. 변경할 때는 필드, 이전 값, 새 값을 기록하고 클라이언트가 생성한 설정과 전체 사용자 지정 설정을 구분해 두세요. 여러 인터페이스 스위치가 함께 적용되는 변경이라면 각각 스크린샷을 저장해 두는 편이 좋습니다. 그래야 되돌릴 때 특정 옵션을 빠뜨리지 않습니다.

한 번에 한 주제만 변경하세요. 먼저 구독 업데이트를 확인하고, 그다음 라우팅을 조정한 뒤 DNS를 처리하고, 마지막으로 TUN과 FakeDNS를 추가합니다. 변경 후에는 코어를 다시 시작하거나 클라이언트가 명시적으로 제공하는 다시 로드 기능을 사용하고, 실행 성공을 확인한 다음 실제 트래픽을 테스트하세요. 같은 작업 중에 구독 업데이트, 코어 전환, DNS 변경을 모두 하면 연결이 복구되어도 어느 변경이 효과가 있었는지 파악하기 어렵습니다.

트래픽 경로 순서에 따라 로그 읽기

먼저 로컬 진입점에 연결이 도착했는지 확인하세요. 진입 기록이 없다면 원격 핸드셰이크를 분석할 것이 아니라 앱의 프록시 설정, 포트, TUN 범위, 앱별 제외를 점검해야 합니다. 진입 기록이 있으면 라우팅 대상과 아웃바운드 태그를 확인하세요. 태그가 예상과 다르면 규칙 순서와 대상 정보를 살펴봅니다. 태그가 맞는 것을 확인한 뒤에야 DNS 조회, 연결 시도, 핸드셰이크, 서버 응답을 점검하세요. 이 순서를 따르면 잘못된 단계에서 매개변수를 계속 바꾸는 일을 줄일 수 있습니다.

로그 상세 수준을 일시적으로 높일 때는 테스트 시간을 제한하고 완료 후 평소 설정으로 되돌리세요. 로그에 접속 도메인, 서버 주소, 연결 세부 정보가 기록될 수 있으므로 공유 전에 민감한 정보를 가려야 합니다. 연결 시간 초과는 발생 단계와 함께 판단하세요. DNS 조회 시간 초과는 DNS를, 연결 시도 시간 초과는 네트워크와 포트를, 핸드셰이크 오류는 프로토콜과 보안 설정, 시스템 시간을 확인해야 합니다. 마지막 한 줄만 잘라 공유하면 실제 원인을 파악하기 어려운 경우가 많습니다.

단일 속도 측정 대신 비교 테스트 수행

테스트 대상에는 프록시를 사용해야 하는 대상, 직접 연결해야 하는 대상, 로컬 네트워크 주소, 실제 사용하는 앱을 포함하세요. 기존 세션의 재사용으로 규칙 변경이 가려지지 않도록 대상마다 새 연결을 만듭니다. 가용성, 연결 지연 시간, 실제 전송 속도는 서로 다른 항목입니다. 지연 시간 테스트 한 번에 성공했다고 DNS, UDP, 대용량 파일 전송까지 정상인 것은 아닙니다. 대상 서비스 자체의 오류 응답을 프록시 설정 문제로 단정하지 마세요.

앱 하나에서만 문제가 발생하면 같은 기기의 다른 앱과 비교하고, 자체 DNS 사용 여부, 프록시 준수 방식, 캐시를 확인하세요. 모든 앱에서 실패하면 시스템 네트워크와 클라이언트 진입점부터 범위를 좁힙니다. 일반 프록시는 정상인데 TUN에서만 실패한다면 같은 서버를 유지하고 진입 방식만 바꿔 비교하세요. 서버를 바꿔도 실패가 계속되면 여러 서버를 계속 교체하기보다 공통으로 사용하는 로컬 설정을 먼저 점검해야 합니다.

변경 사항을 역순으로 되돌리기

되돌릴 때는 마지막으로 추가한 복잡한 계층부터 해제한 다음 기존 라우팅과 DNS를 복원하세요. FakeDNS를 끈 뒤에는 합성 주소 캐시를 처리하고, TUN을 끈 뒤에는 시스템 경로와 리졸버가 복구됐는지 확인합니다. 클라이언트를 종료하기 전에 시스템 프록시가 종료할 포트를 가리키지 않는지도 확인하세요. 구독 업데이트 때문에 문제가 생겼다면 해당 그룹의 백업을 복원하면 됩니다. 관련 없는 로컬 규칙까지 함께 삭제할 필요는 없습니다. 되돌리는 범위가 정확할수록 이미 검증한 설정을 보존하기 쉽습니다.

문제를 계속 찾지 못하면 클라이언트 이름, 운영체제, 진입 모드, 코어 종류, 재현 절차, 민감 정보를 가린 로그 일부를 정리한 뒤 실행 로그 오류 원인 확인 방법을 참고해 하나씩 확인하세요. 처음의 기본 설정으로 되돌린 뒤에도 연결되지 않으면 빠른 시작 가이드로 돌아가 기본 연결 경로부터 다시 확인합니다. 설정 관리의 목표는 옵션을 더 많이 켜는 것이 아니라, 각 옵션의 용도와 확인 방법, 신뢰할 수 있는 되돌리기 방법을 명확히 하는 것입니다.