v2rayN 고급 설정 가이드

구독 그룹과 서버 필터링

구독 그룹은 구독 출처와 업데이트 방식을 관리하고, 서버 항목은 개별 연결 매개변수를 저장합니다. 둘은 서로 다른 계층입니다. 그룹 메모를 바꿔도 프로토콜은 바뀌지 않으며, 현재 서버를 변경해도 구독이 업데이트되지는 않습니다. 먼저 출처를 정리한 다음 필터링하고 서버를 선택하면, 목록 변경을 연결 오류로 오해할 가능성을 줄일 수 있습니다. 그룹 이름은 용도나 출처를 기준으로 정하고, 메모에 비밀번호·액세스 토큰·개인 계정을 적지 마세요.

그룹을 만든 뒤 업데이트 결과 확인

v2rayN의 구독 그룹 설정에서 새 그룹을 만들고 메모와 구독 주소를 입력한 뒤 저장합니다. 그런 다음 해당 그룹을 업데이트하세요. 주소는 물음표 뒤의 매개변수를 포함해 전체를 입력해야 합니다. 채팅 창에서 복사할 때는 끝부분의 공백, 줄바꿈, 문장 부호가 들어가지 않았는지 확인하세요. 업데이트 후 그룹의 서버 목록을 확인하고 항목을 선택해 현재 서버로 지정합니다. 그룹을 추가하는 것만으로는 출처가 저장될 뿐, 구독 내용이 다운로드되어 파싱되지는 않습니다.

구독 업데이트는 별도의 요청 경로를 사용합니다. 환경에 따라 구독 출처에 직접 연결할 수도 있고, 이미 작동 중인 프록시를 통해 업데이트해야 할 수도 있습니다. 두 방식을 각각 시도하고 연결 매개변수를 반복해서 바꾸지 마세요. 목록이 비어 있으면 먼저 업데이트 로그의 응답 상태와 파싱 안내를 확인합니다. 웹 페이지나 로그인 화면, 접근 오류가 반환되면 네트워크 요청에 성공했더라도 유효한 서버 목록을 얻을 수 없습니다. 클라이언트를 재설치하기보다 구독 주소의 유효 기간부터 확인하는 편이 효과적입니다.

필터는 표시 범위를 바꿀 뿐 프로토콜 기능은 바꾸지 않습니다

서버 필터는 보통 메모 텍스트를 기준으로 일치 항목을 찾습니다. 필터 메뉴는 그룹 설정이나 목록 필터 영역에 있을 수 있습니다. 처음에는 분명한 키워드 하나만 입력해 원하는 항목이 표시되는지 확인한 다음 조건을 추가하세요. 필터 입력란에 일반 텍스트를 쓰는 경우도 있고 정규식을 쓰는 경우도 있으므로 필드 안내를 확인해야 합니다. 목록 검색과 구독 필터를 혼동하지 마세요. 검색은 대개 현재 화면만 일시적으로 바꾸지만, 업데이트 필터는 남겨 둘 항목을 결정할 수 있습니다.

정규식을 지원하는 필드에서는 아래와 같은 패턴으로 일치 범위를 이해할 수 있습니다. 세로줄은 여러 단어 중 하나를 찾고, 줄 시작 기호는 메모의 첫 부분을 제한하며, 부정형 전방 탐색은 특정 단어를 제외합니다. 메모 규칙은 출처마다 다르므로 텍스트 라벨만으로 연결 기능을 단정할 수 없습니다. 프로토콜 이름이 메모에 있어도 실제 매개변수가 해당 프로토콜을 사용한다는 뜻은 아닙니다. 먼저 항목의 프로토콜, 전송 방식, 보안 필드를 확인하고 선택한 코어에서 실행할 수 있는지 판단하세요.

업무|예비
^업무
^(?!.*테스트).*$

수동 수정과 구독 업데이트는 별도로 관리

구독에서 제공하는 항목은 업데이트 과정에서 다시 생성될 수 있습니다. 해당 항목의 주소, 포트 또는 보안 매개변수를 수정하면 다음 업데이트에서 변경 내용이 덮어써지거나 중복 항목이 생길 수 있습니다. 실험 설정을 계속 유지해야 한다면 별도의 수동 그룹에 복사하고 수정 이유를 메모해 두세요. 이렇게 하면 출처 업데이트를 계속 받으면서 서버에서 받은 데이터와 로컬 테스트 데이터를 구분할 수 있습니다.

Android 클라이언트에서도 식별하기 쉬운 구독 그룹을 먼저 만들고 업데이트한 뒤 결과를 확인하세요. v2rayNG와 v2flyNG의 그룹 화면 및 필터 기능은 서로 다를 수 있습니다. 전용 필터 메뉴가 없다면 그룹 선택이나 목록 검색을 사용하고 데스크톱 절차를 억지로 적용하지 마세요. 가져오기에 성공했다는 것은 형식을 인식했다는 뜻일 뿐입니다. 현재 코어가 프로토콜 필드를 지원하는지는 시작 로그와 실제 요청으로 확인해야 합니다.

출처 이름, 사용한 업데이트 방식, 결과, 필터 조건 변경 여부를 간단히 기록해 두세요. 업데이트 후 항목 수가 갑자기 줄었다면 먼저 필터를 잠시 비우고 다시 업데이트합니다. 항목이 복구되면 문제는 필터 조건에 있으며 코어 문제는 아닙니다. 여전히 파싱되지 않으면 연결 확인과 복구에서 구독 요청과 서버 연결을 나누어 점검하세요. 같은 주소를 계속 가져와 중복 그룹을 만들지 마세요.

라우팅 규칙 실전

라우팅은 코어에 들어온 요청을 받아 어떤 아웃바운드로 보낼지 결정합니다. 시스템 프록시 설정은 앱이 요청을 로컬 프록시에 전달할지를 결정합니다. 앱이 프록시 진입 경로를 완전히 우회하면 라우팅을 수정해도 효과가 없습니다. 규칙을 작성하기 전에 앱 트래픽이 실제로 클라이언트에 들어오는지 확인하고, 생성된 설정에서 프록시·직접 연결·차단 태그를 확인하세요. 화면에 표시된 이름만 보고 실제 태그를 추측해서는 안 됩니다.

먼저 일치하는 규칙을 기준으로 순서 설계

일반 필드 규칙은 순서대로 확인하며, 처음 일치하는 유효한 규칙이 출구를 결정합니다. 구체적인 예외를 앞에 두고 넓은 지역 또는 범주 규칙은 뒤에 배치하세요. 예를 들어 테스트 도메인이 뒤쪽의 직접 연결 목록에 포함되더라도 프록시를 사용해야 한다면 해당 도메인의 프록시 규칙을 먼저 작성해야 합니다. 여러 개의 독립 규칙이 투표처럼 합쳐지는 것은 아닙니다. 한 규칙에 서로 다른 필드를 여러 개 지정하면 대개 모든 조건을 충족해야 합니다.

아래는 Xray 설정에 넣을 수 있는 라우팅 객체입니다. 지정 도메인과 하위 도메인을 먼저 프록시로 보내고, 사설 주소와 중국 주소는 직접 연결한 다음, 사용 중인 도메인 목록에 따라 나머지 요청을 직접 연결합니다. 예시에는 proxy와 direct 태그를 가진 아웃바운드가 이미 있고 코어에서 필요한 규칙 데이터를 읽을 수 있다고 가정합니다. 실제 클라이언트에서 생성되는 태그는 다를 수 있으므로 적용 전에 반드시 확인하세요.

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

도메인 일치, 주소 일치, DNS 확인 방식 구분

full:example.com은 정확히 일치하는 도메인만 찾고, domain:example.com은 하위 도메인도 포함합니다. 접두사 없는 도메인 텍스트는 포함 여부를 기준으로 처리될 수 있어 범위가 넓어질 수 있습니다. 경계를 명확히 해야 한다면 접두사를 지정하세요. 정규식은 명확한 작명 규칙이 있는 도메인에 적합하며 일반 규칙을 전부 대체하는 용도로는 적합하지 않습니다. 규칙이 복잡할수록 문제 발생 시 실제로 어떤 조건이 일치했는지 파악하기 어렵습니다.

주소 규칙은 요청의 목적지 주소를 처리할 뿐, 도메인 뒤에 있는 서비스의 의미를 자동으로 알지는 못합니다. 도메인 규칙이 일치하지 않을 때 IPIfNonMatch는 주소를 조회한 뒤 IP 주소 규칙을 적용합니다. 이 경우 DNS에 의존하게 됩니다. 앱이 주소만 전달하면 코어가 원래 도메인을 알아내지 못할 수도 있습니다. 스니핑으로 일부 프로토콜에서 도메인 정보를 얻을 수는 있지만 모든 트래픽에 적용되는 것은 아니므로, 도메인을 확실히 복원하는 도구로 여겨서는 안 됩니다.

웹 페이지 접속 여부만 보지 말고 규칙 검증

규칙을 추가한 뒤 코어를 다시 시작하거나 설정을 다시 불러오고, 알 수 없는 태그나 필드 오류, 규칙 파일 누락이 로그에 없는지 확인하세요. 그런 다음 단일 대상으로 새 요청을 보내고 액세스 로그에서 사용된 출구를 확인합니다. 브라우저가 기존 연결을 재사용하면 규칙을 바꾼 뒤에도 연결이 이전 경로를 계속 사용할 수 있습니다. 관련 탭을 닫거나 새 연결을 만들어 연결 재사용을 규칙 오류로 오해하지 않도록 하세요.

일치하는 규칙이 없으면 일반 설정에서는 기본 아웃바운드로 연결됩니다. 보통 아웃바운드 목록의 첫 번째 항목이 기본값이므로 기본 출구도 라우팅 설계에 포함해야 합니다. 차단 규칙으로 문제를 확인할 때는 범위가 명확한 테스트 대상 하나만 제한하고 복구 방법을 마련하세요. 넓은 범위의 트래픽을 차단하면 DNS, 구독 업데이트, 연결 수립까지 영향을 받아 단순한 규칙 문제에 여러 문제가 더해질 수 있습니다.

클라이언트의 기본 라우팅과 사용자 지정 규칙이 함께 설정 생성에 반영될 수 있습니다. 저장한 뒤에는 편집 화면의 순서만 보지 말고 실제 적용된 규칙 순서를 확인하세요. 문법을 자세히 알아보려면 사용자 지정 라우팅 규칙 작성법을, 진입 경로와 모드의 차이를 알아보려면 시스템 프록시와 라우팅 모드 비교를 참고하세요. 테스트 중에는 한 번에 규칙 하나만 이동하고 복구할 수 있는 순서를 기록해 두세요.

DNS 설정 최적화

DNS를 설정할 때는 먼저 ‘누가 이름을 조회하는가’를 확인해야 합니다. 브라우저, 운영체제, 클라이언트 코어, 원격 출구가 모두 도메인 조회에 관여할 수 있습니다. 클라이언트 DNS만 바꿔도 브라우저의 암호화 DNS나 시스템 캐시에는 변화가 없을 수 있습니다. 요청 경로를 기준으로 최적화하세요. 먼저 앱이 도메인과 주소 중 무엇을 보내는지 확인하고, 어느 단계에서 업스트림을 조회하는지 파악한 다음 DNS 요청이 어디로 나가는지 점검합니다.

대상 도메인 조회와 서버 연결 주소 조회 구분

대상 웹사이트의 도메인 조회와 서버 주소의 도메인 조회는 모두 DNS를 사용하지만 역할은 다릅니다. 서버 주소를 도메인으로 입력했다면 프록시 연결을 수립하기 전에 그 주소를 조회해야 할 수 있습니다. 이때 아직 연결되지 않은 프록시만을 유일한 조회 경로로 설정하면 순환 의존이 발생합니다. 먼저 기본 네트워크를 통해 서버 주소를 조회할 수 있게 한 뒤 대상 웹사이트의 분할 조회를 설정하는 편이 안전합니다.

클라이언트의 ‘원격 DNS’, ‘직접 연결 DNS’ 같은 옵션은 대개 설정 생성기의 추상화이며 코어 필드와 일대일로 대응하지 않을 수 있습니다. 변경할 때는 필드 설명을 확인하고 생성된 결과도 점검하세요. Android VPN 모드는 앱에 전용 DNS 진입점을 제공할 수 있지만 데스크톱 시스템 프록시가 모든 DNS 요청을 가로채는 것은 아닙니다. 브라우저에서 사이트가 열린다는 이유만으로 시스템 전체가 같은 경로를 통해 조회된다고 판단해서는 안 됩니다.

설명 가능한 업스트림과 정책부터 설정

아래 예시는 Xray 내장 DNS의 기본 객체입니다. 지정한 도메인 목록에는 한 업스트림을 사용하고 나머지 요청은 다른 업스트림으로 보냅니다. UseIP는 두 종류의 주소를 반환하도록 허용하지만 실제 결과는 업스트림과 네트워크에 따라 달라집니다. 예시의 공용 DNS 주소는 필드 설명용일 뿐 모든 네트워크에 적합한 것은 아닙니다. 현재 연결 환경에서 접근 가능한지 먼저 확인한 뒤 설정에 사용하세요. 해당 조회가 사용할 출구는 라우팅 객체에서 별도로 지정해야 합니다.

{
  "dns": {
    "queryStrategy": "UseIP",
    "servers": [
      {
        "address": "223.5.5.5",
        "domains": ["geosite:cn"]
      },
      "1.1.1.1"
    ]
  }
}

도메인 조건은 업스트림 선택 기준 중 하나이며 실패한 요청의 재시도 경로를 완전히 격리한다는 뜻은 아닙니다. 일부 업스트림에 문제가 생기면 코어가 다른 서버를 계속 시도할 수 있습니다. 재시도를 제한할 수 있는지는 현재 코어가 지원하는 필드를 기준으로 확인하세요. 형식적인 분할을 위해 모든 재시도를 끄면 일시적인 업스트림 장애가 모든 도메인의 조회 실패로 이어질 수 있습니다. 기본 조회가 성공하는지 먼저 확인한 다음 범위를 조금씩 좁히세요.

암호화된 DNS도 올바른 출구가 필요합니다

암호화 DNS는 전송 방식을 바꿀 수 있지만 업스트림에 접근할 수 없는 문제나 연결 순환을 자동으로 해결하지는 않습니다. HTTPS 업스트림을 사용한다면 업스트림 호스트 이름의 최초 조회, 연결 주소, 인증서 검증, 라우팅도 처리해야 합니다. 암호화 업스트림을 프록시 출구로 설정하기 전에 프록시 자체가 해당 조회 경로에 의존하지 않는지 확인하세요. 앱에서도 암호화 DNS를 사용하면 클라이언트의 도메인 목록 규칙은 조회된 주소만 볼 수 있습니다.

주소 계열 문제는 네트워크에서 IPv4와 IPv6를 각각 사용할 수 있는지 확인하세요. 한 종류의 주소만 반환하면 일시적으로 문제 범위를 좁힐 수 있지만 일반적인 성능 최적화 방법은 아닙니다. 시스템이 IPv6 주소를 받았지만 사용할 출구가 없으면 앱이 연결할 수 없는 경로를 먼저 시도할 수 있습니다. 반대로 서비스가 IPv6만 제공하는데 IPv4만 강제하면 연결이 바로 실패합니다. 기존 정책을 보존하고 조회 정책을 한 번에 하나씩 바꿔 결과를 비교하세요.

캐시 때문에 설정 변경 효과가 늦게 나타날 수 있습니다. 테스트 전에 앱 연결을 새로 만들고, 필요하다면 운영체제가 제공하는 방법으로 DNS 캐시를 비우세요. 다만 캐시 삭제를 지속적인 해결책으로 삼아서는 안 됩니다. 명령줄의 시스템 조회는 보통 시스템 리졸버만 테스트하며 코어 DNS를 자동으로 거치지 않습니다. 새 설정이 요청에 사용됐는지 확인하려면 코어 로그와 함께 살펴보세요. 테스트 도메인, 반환된 주소, 출구 기록을 남기고 ‘열리는 속도’만으로 판단하지 마세요.

최종 설정은 여러 DNS 서버를 쌓아 두는 대신 각 유형의 조회가 어디로 가는지 설명할 수 있어야 합니다. TUN이나 FakeDNS를 추가하면 DNS 진입점과 반환 결과가 달라지므로 해당 절도 확인하세요. 조회 오류가 발생하면 먼저 접근 가능한 단일 업스트림으로 되돌려 기본 연결을 복구한 뒤 분할 조회, 암호화, 캐시 설정을 하나씩 다시 추가합니다. 이렇게 하면 업스트림, 라우팅, 트래픽 가로채기 문제를 구분할 수 있습니다.

TUN 모드

TUN은 가상 네트워크 인터페이스를 통해 시스템 라우팅이 전달한 IP 트래픽을 받으며, 시스템 프록시를 따르지 않는 앱에 적합합니다. 트래픽을 가로채는 범위가 넓어지지만 시스템 프록시 설정을 바꾸는 것과 같지는 않으며 모든 요청이 프록시 출구를 사용해야 하는 것도 아닙니다. 트래픽이 가로채기 구성 요소에 들어온 뒤에도 라우팅 규칙으로 직접 연결, 프록시 또는 차단을 결정해야 합니다. 시작하기 전에 일반 프록시 진입점에서 현재 서버가 작동하는지 확인해 진입 경로와 원격 연결을 동시에 점검하지 않도록 하세요.

권한, 라우팅, 코어의 역할 이해

v2rayN의 TUN은 클라이언트에 통합된 트래픽 가로채기 구성 요소와 관련 설정에 따라 동작합니다. 일반 Xray 설정 조각을 모든 환경에 통용되는 TUN 설정으로 간주해서는 안 됩니다. 가상 인터페이스 생성, 시스템 라우팅 설정, DNS 가로채기는 서로 다른 작업이며 일부에는 권한 상승이 필요합니다. 화면 안내에 따라 필요한 권한을 부여한 다음 로그에서 인터페이스 초기화가 완료됐는지 확인하세요. 스위치가 켜져 있다는 사실만으로 라우팅이 적용됐다고 볼 수 없습니다.

활성화하기 전에 현재 기본 경로, DNS 설정, 다른 네트워크 가로채기 도구의 실행 여부를 기록하세요. 여러 구성 요소가 기본 경로를 동시에 변경하면 요청 순환이나 출구 충돌이 발생할 수 있습니다. 테스트할 때는 가로채기 방식을 하나만 남기고 트래픽을 가로채는 다른 프로그램은 잠시 끄세요. LAN 기기, 공유 폴더, 회사 네트워크에 접근해야 한다면 대상 네트워크 대역을 미리 기록해 두세요. 활성화 후 설정 화면에 접근하지 못할 수 있습니다.

프록시 연결이 가로채기 경로로 되돌아가지 않도록 설정

프록시 연결 자체가 가로채기 순환 경로를 벗어날 수 있어야 합니다. 원격 서버로 가는 트래픽이 다시 가상 인터페이스로 보내지면 코어가 자기 자신을 통해 출구를 만들려고 계속 시도합니다. 클라이언트는 구현에 따라 출구 바인딩, 프로세스 제외, 라우팅 예외 등을 제공할 수 있습니다. 서버 주소에 대한 예외를 직접 추가할 때는 도메인 조회 결과가 바뀔 가능성도 고려하세요. 이전 주소를 고정으로 지정하면 출처 변경 후 작동하지 않을 수 있습니다.

LAN 직접 연결과 시스템 라우팅 제외도 서로 다른 개념입니다. 라우팅의 직접 연결 아웃바운드는 코어가 대신 연결을 만들게 하고, 시스템 제외는 요청이 코어에 들어오지 않게 합니다. 프린터 검색, 브로드캐스트, 일부 로컬 서비스는 후자에 의존할 수 있어 사설 주소 직접 연결만으로는 모든 요구를 충족하지 못할 수 있습니다. 먼저 명확한 로컬 주소 하나로 연결을 확인한 뒤 검색 기능을 테스트하고 결과에 따라 어느 계층을 조정할지 결정하세요.

최소 범위부터 가로채기 테스트

첫 테스트에서는 기본값을 사용해 가로채기 설정을 명확하게 유지하세요. 먼저 접속이 확인된 대상을 열고 시스템 프록시를 따르지 않는 앱도 테스트합니다. 해당 앱의 요청이 코어 로그에 실제로 기록되는지 확인하세요. 기록이 없다면 서버를 바꾸기보다 시스템 라우팅과 앱 제외 설정을 점검해야 합니다. 요청이 기록되지만 실패한다면 출구와 DNS를 확인하세요. 앱 선택 기능에 포함 모드와 제외 모드가 모두 있다면 현재 모드가 무엇을 의미하는지 먼저 확인합니다.

UDP, 주소 계열, MTU는 흔히 마주치는 제한 요소입니다. 웹페이지는 정상인데 일부 실시간 앱이 실패한다면 UDP 전달 기능이나 방화벽이 원인일 수 있습니다. 작은 요청은 성공하지만 대용량 전송이 멈출 때는 경로 MTU를 추가로 점검할 수 있습니다. 정해진 MTU 값을 무작정 따라 쓰지 마세요. 먼저 로그와 네트워크 진단으로 증상을 확인한 뒤 값을 조금씩 조정하며 비교하세요. ICMP가 필요한 기능도 일반 TCP와 같은 방식으로 처리되지 않을 수 있습니다.

테스트를 마칠 때는 먼저 TUN을 끄고 일반 네트워크와 LAN이 복구됐는지 확인하세요. 클라이언트를 종료한 뒤에도 문제가 남으면 가상 인터페이스, 기본 경로, DNS가 복원됐는지 확인합니다. 프로세스를 강제로 종료하는 것보다 클라이언트를 다시 실행한 뒤 가로채기를 정상적으로 끄는 편이 설정을 정리하기 쉽기도 합니다. 기록 없이 시스템 라우팅을 삭제하지 마세요. 장기간 사용하려면 일반 프록시 모드를 복구 경로로 남기고 제외해야 하는 앱이나 네트워크 대역을 기록하세요.

FakeDNS

FakeDNS는 도메인에 내부용 합성 주소를 할당하고 코어가 매핑을 통해 원래 도메인을 찾도록 합니다. 목적은 공용 DNS 조회를 빠르게 하는 것이 아니라 도메인 정보를 보존해 도메인 기준으로 트래픽을 분할하는 것입니다. 합성 주소는 실제 서비스 주소가 아니므로 이를 생성한 매핑과 가로채기 경로 없이는 사용할 수 없습니다. 기본 가속 스위치처럼 켜기보다 앱이 주소를 제출한 뒤 도메인 정보를 잃는 실제 문제가 있을 때 사용하세요.

조회와 연결 전반에 매핑이 유지되어야 합니다

정상적인 흐름에는 세 단계가 있습니다. 앱이 가로채기된 DNS 진입점에 조회를 요청하고, FakeDNS가 합성 주소를 반환한 뒤, 앱이 해당 주소에 연결하면 코어가 매핑을 이용해 도메인을 복원합니다. 주소 풀만 활성화하고 앱 조회를 해당 진입점으로 보내지 않으면 매핑은 작동하지 않습니다. 합성 주소만 반환하고 이후 연결을 가로채지 않으면 앱은 공용 네트워크에서 사용할 수 없는 주소로 접속하려 합니다. 따라서 FakeDNS는 투명 가로채기와 함께 쓰는 경우가 많지만 두 기능은 각각 확인해야 합니다.

아래는 Xray의 FakeDNS 관련 설정 예시입니다. fakedns에서 주소 풀을 정의하고 DNS 서버 목록에서 이를 참조합니다. 198.18.0.0/15는 테스트용 주소 대역이지 실제 사이트 주소가 아닙니다. 이 예시에는 가로채기 진입점과 전체 스니핑 설정이 포함되어 있지 않아 단독으로 실행할 수 없습니다. v2rayN의 가로채기 구성 요소가 합성 주소 기능을 자체 구현했다면 다른 코어 설정을 섞지 말고 해당 구성 요소의 필드를 사용하세요.

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

주소 풀 크기와 회수 정책은 매핑 수명에 영향을 줍니다

주소 풀은 충분한 공간을 확보해야 하며 기존 네트워크 대역과 겹치면 안 됩니다. 기업 네트워크나 실험 환경에서 비슷한 테스트 주소를 사용 중일 수 있으므로 먼저 라우팅 테이블을 확인하세요. 풀 크기는 유지할 수 있는 매핑 범위를 결정하며 네트워크 용량이나 연결 속도를 나타내지 않습니다. 오래 실행하면 매핑이 회수될 수 있지만 앱은 이전 캐시를 계속 사용할 수 있습니다. 코어를 재시작해 매핑을 다시 만들면 같은 합성 주소가 다른 도메인을 가리킬 수도 있습니다.

스니핑 관련 설정은 코어가 도메인 정보를 얻는 데 도움이 될 수 있지만 정보 읽기와 목적지 변경은 구분해야 합니다. FakeDNS 매핑을 통한 복원은 HTTP나 TLS에서 도메인을 추출하는 것과 다릅니다. 라우팅용 스니핑만 활성화해도 현재 조합의 목적지 복원 요구를 충족하는지는 가로채기 구성 요소의 구현을 확인해야 합니다. 먼저 클라이언트에서 제공하는 관련 옵션을 사용하고 생성된 설정에서 모든 옵션이 함께 적용됐는지 확인하세요.

실제 주소가 필요한 경우를 위한 예외 설정

일부 앱은 DNS 결과를 다른 프로세스에 전달하거나 설정에 저장하고, 반환된 주소로 LAN 세션을 만들 수 있습니다. 이런 동작은 합성 주소를 기존 가로채기 경로 밖으로 보낼 수 있습니다. 이 경우 도메인 또는 앱 단위로 실제 주소 조회 예외를 설정하세요. LAN 기기 검색, 주소로 동작을 판단하는 서비스, 다른 기기와 조회 결과를 공유해야 하는 작업은 따로 테스트할 필요가 있습니다. 모든 조회를 한꺼번에 합성 주소로 바꾸지 마세요.

앱에 자체 암호화 DNS가 있으면 조회가 FakeDNS를 거치지 않아 실제 주소가 반환될 수 있습니다. 이 경우 연결이 반드시 실패하는 것은 아니지만 도메인 규칙의 판단 기준은 달라집니다. 반대로 시스템 DNS가 합성 주소를 반환했는데 앱 연결은 가로채기 대상에서 제외되면 연결이 바로 실패할 수 있습니다. 조회 진입점과 연결 진입점을 모두 확인하세요. DNS 반환 내용만 보고 기능이 정상이라고 판단해서는 안 됩니다.

FakeDNS를 끈 뒤에는 먼저 앱이 이전 결과를 사용하지 않게 한 다음 연결을 새로 만드세요. 필요하다면 시스템과 앱의 DNS 캐시를 각각 비웁니다. 그렇지 않으면 이전 합성 주소가 계속 요청되어 기능을 끈 뒤 오히려 네트워크가 나빠진 것처럼 보일 수 있습니다. 복구를 확인할 때는 조회 결과가 실제 주소로 돌아왔는지, 같은 대상에 기존 DNS 및 라우팅 경로로 접속할 수 있는지 확인하세요. 캐시 복구와 코어 복구는 별도로 점검해야 합니다.

도메인 보존이 실제로 필요한 범위에서만 활성화하세요. 특정 앱에서 문제가 생기면 주소 풀을 넓히거나 계속 재시작하기보다 해당 앱을 실제 주소 조회로 전환해 비교합니다. 일반 DNS와 일반 프록시 모드로 충분하다면 더 단순한 구성을 유지해도 됩니다. 코어별 기능 차이는 Xray와 V2Fly 코어 비교에서 확인해 한 가지 구현의 필드를 모든 클라이언트가 지원한다고 오해하지 않도록 하세요.

다중 구독 관리

다중 구독 관리의 핵심은 모든 주소를 하나의 큰 목록으로 합치는 것이 아니라 출처를 분리하고 업데이트를 추적하며 현재 서버를 확인할 수 있게 하는 것입니다. 출처마다 같은 메모를 사용하거나 프로토콜과 업데이트 주기가 다를 수 있으므로 한데 섞으면 항목을 잘못 선택하기 쉽습니다. 출처별로 그룹을 만들고 용도 메모를 추가하면 삭제, 업데이트, 장애 복구 범위를 명확히 할 수 있습니다.

출처 정보와 로컬 사용 정책 구분

출처 정보에는 구독 주소, 반환된 항목, 서버 매개변수가 포함됩니다. 로컬 정책에는 그룹 메모, 목록 필터, 현재 선택, 라우팅 규칙이 포함됩니다. 구독 업데이트로 바뀔 수 있는 매개변수에 로컬 정책을 섞지 마세요. 특정 그룹을 업무용으로 지정해도 업무 앱이 자동으로 해당 그룹을 사용하는 것은 아닙니다. 앱과 출구를 연결하려면 라우팅 규칙이나 클라이언트의 관련 기능이 필요합니다.

새 출처를 처음 추가할 때는 별도 그룹에서 업데이트하고 항목을 확인하세요. 사용 중인 서버를 바로 교체하지 않는 것이 좋습니다. 형식, 코어 지원 여부, 연결 경로를 확인한 뒤 일상적으로 사용할지 결정하세요. 출처에서 서버 목록이 아닌 클라이언트 설정을 반환한다면 해당 가져오기 유형에 맞춰 처리해야 합니다. 업데이트 버튼을 계속 바꿔 눌러 강제로 파싱하려 하지 마세요. 업데이트 로그의 형식 오류와 네트워크 시간 초과는 구분해 기록해야 합니다.

업데이트 일정과 장애 범위를 함께 관리

출처별로 적절한 업데이트 일정을 설정해 짧은 시간에 요청을 반복하지 않도록 하세요. 자주 업데이트해도 만료된 액세스 자격 증명은 복구되지 않으며 출처에서 접근을 제한할 수 있습니다. 업데이트가 실패하면 먼저 그룹 하나만 업데이트하고 모든 출처를 한꺼번에 새로 고치지 마세요. 특정 출처에만 문제가 있으면 일반적으로 시스템 DNS를 변경하거나 다른 그룹을 삭제할 필요가 없습니다. 모든 출처가 동시에 실패할 때는 공통 기본 네트워크와 업데이트 출구를 확인하세요.

업데이트 전에 현재 항목이 어느 출처에 속하는지 확인하고, 업데이트 후에도 선택 항목이 남아 있는지 살펴보세요. 출처에서 항목을 삭제하거나 식별자를 바꾸면 클라이언트가 이전 선택을 유지하거나 다른 항목을 선택할 수 있으며 다시 선택해야 할 수도 있습니다. 실제 동작은 목록과 로그로 확인하세요. 클라이언트의 ‘업데이트 성공’ 표시는 처리가 완료됐다는 뜻일 뿐 현재 항목이 새 매개변수로 바뀌었거나 원격 연결까지 확인됐다는 뜻은 아닙니다.

메모만 보고 중복을 판단하지 마세요

메모가 같아도 같은 항목이라고 볼 수 없으며 주소와 포트가 같더라도 사용자 정보와 보안 매개변수는 다를 수 있습니다. 중복을 정리하기 전에 프로토콜, 주소, 포트, 사용자 식별자, 전송 방식, 보안 필드를 비교하세요. 목록을 깔끔하게 만들려고 출처의 유사한 항목을 전부 수동으로 삭제하지 마세요. 출처에서 서로 다른 연결 방식을 의도적으로 제공했을 수 있습니다. 클라이언트에 중복 제거 기능이 있다면 어떤 필드를 비교하는지 확인하고 복구할 수 있도록 원본 그룹을 남겨 두세요.

예비 출처는 주 출처에 장애가 생긴 뒤 처음 사용하는 것이 아니라 별도로 미리 검증해야 합니다. 테스트할 때 현재 서버를 명확히 바꾸고 새 요청을 실행하세요. 목록에서 행을 선택하는 것만으로는 현재 서버로 지정되지 않을 수 있습니다. 출처가 여러 개라고 자동으로 장애 전환되는 것도 아닙니다. 자동 선택이나 부하 분산을 구현하려면 지원되는 기능, 가용성 판단 방식, 아웃바운드 설정을 명확히 해야 합니다. 그룹이 여러 개 있다는 이유만으로 자동 전환 풀을 구성했다고 생각하지 마세요.

기기를 바꿀 때는 구독 주소를 옮기는 것과 클라이언트 설정 전체를 옮기는 것을 구분하세요. 전체 설정을 내보내면 로컬 리스너, 라우팅, DNS, 기기별 옵션이 포함될 수 있어 다른 플랫폼에서 부적절한 매개변수가 적용될 수 있습니다. 보통은 출처를 먼저 가져온 뒤 새 기기의 진입점과 라우팅을 설정하는 편이 검증하기 쉽습니다. 데스크톱과 Android에서 코어 지원 여부를 각각 확인해 한 기기에서 작동하는 프로토콜 조합이 다른 기기에서도 시작된다고 가정하지 마세요.

더 이상 사용하지 않는 출처를 정리하되 먼저 라우팅, 고정 출구, 수동 테스트가 해당 항목에 의존하지 않는지 확인하세요. 그룹을 삭제하기 전에 용도를 기록하고 작동하는 서버로 전환합니다. 출처 주소가 바뀌었다면 제공자의 안내에 따라 기존 그룹을 수정하세요. 같은 이름의 그룹을 계속 늘리지 마세요. 구독 업데이트에 실패하면 구독 그룹 절에서 주소와 필터를 확인하고 단계별 문제 해결에서 업데이트 경로를 점검하세요. 모든 실패를 서버 문제로 돌릴 필요는 없습니다.

사용자 지정 아웃바운드

아웃바운드는 코어가 실제로 연결을 시작하는 방식이고 라우팅 태그는 요청이 사용할 아웃바운드를 가리키는 이름입니다. 출구를 고정하거나 일부 트래픽을 차단하거나 로컬 프록시에 연결해야 할 때 사용자 지정 아웃바운드가 유용합니다. 일반 사용자는 서버 하나를 선택하고 기본 라우팅을 사용해도 대부분의 기본 작업을 처리할 수 있습니다. 새 아웃바운드가 필요한 이유를 명확히 설명할 수 있을 때 전체 설정을 편집하세요. 설정이 많아질수록 시작 확인과 복구 기록이 중요해집니다.

편집 메뉴가 전체 설정을 받는지 먼저 확인

v2rayN의 서버 편집, 라우팅 편집, 사용자 지정 설정 메뉴는 서로 다른 계층을 다룹니다. 서버 입력 폼은 임의의 최상위 JSON을 받을 수 없고, 라우팅 편집만으로 아웃바운드가 생성되지도 않습니다. 사용자 지정 설정을 사용하기 전에 클라이언트가 파일을 직접 불러오는지, 조각을 생성된 설정에 병합하는지 확인하세요. 실행 디렉터리에 저장한 파일은 다음 시작 때 다시 생성될 수 있습니다. 임시 수정을 기대하지 말고 클라이언트에서 제공하는 영구 설정 메뉴를 사용하세요.

아래는 로컬에서만 수신하는 완전한 Xray 학습용 설정입니다. SOCKS 진입점을 제공하고 기본적으로 직접 연결하며 지정한 테스트 도메인을 차단합니다. 원격 프록시 서버가 포함되어 있지 않으므로 구독 연결을 대신할 수 없습니다. 진입점, 태그, 라우팅 참조를 확인하기 위한 예시입니다. 포트는 예시일 뿐이므로 이미 사용 중이라면 설정과 테스트 명령을 함께 변경하세요. 접근 제어를 설정하지 않은 상태에서 수신 주소를 모든 네트워크 인터페이스로 바꾸지 마세요.

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

태그, 기본 출구, 참조 관계 확인

참조할 각 아웃바운드에 명확하고 고유한 태그를 지정해야 합니다. 라우팅의 outboundTag는 실제로 존재하는 아웃바운드와 일치해야 합니다. 대소문자나 앞뒤 공백이 다르면 설정 오류가 나거나 예상과 다르게 동작할 수 있습니다. 어떤 규칙에도 일치하지 않는 요청은 보통 첫 번째 아웃바운드를 사용하므로 목록 순서를 바꾸면 기본 동작이 달라집니다. 규칙 텍스트만 기록하기보다 기본 출구와 예외 출구를 각각 기록하세요.

직접 연결 아웃바운드는 코어가 로컬 네트워크를 통해 대상에 연결한다는 뜻이지 요청이 클라이언트에 들어오지 않았다는 뜻은 아닙니다. 차단 아웃바운드는 일치하는 트래픽을 종료합니다. 다른 로컬 SOCKS 서비스에 연결하려면 수신 주소, 포트, 인증 방식을 명확히 지정하고 해당 서비스가 요청을 다시 현재 진입점으로 보내지 않도록 하세요. 동일한 수신 포트를 진입점과 하위 출구로 함께 사용하는 것은 흔한 순환 오류입니다. 두 서비스가 같은 주소와 포트를 동시에 사용할 수도 없습니다.

원격 매개변수는 서버 설정을 기준으로 확인

원격 프로토콜 아웃바운드를 추가할 때는 주소, 포트, 사용자 정보 외에도 전송 경로, 서비스 이름, 서버 이름, 공개 키 등이 필요할 수 있습니다. 각 항목은 서버 설정과 대응해야 하며 다른 항목의 필드를 조합해서는 안 됩니다. REALITY는 전송 보안 방식이므로 프로토콜 이름만 REALITY로 바꾼다고 활성화되지 않습니다. 관련 매개변수는 REALITY 개념 안내에서 확인하세요.

클라이언트에 프로토콜이 표시된다고 해서 선택한 코어가 모든 보안 및 전송 조합을 실행할 수 있는 것은 아닙니다. Xray와 V2Fly의 지원 범위는 다르며 Android의 v2rayNG와 v2flyNG도 필드를 완전히 서로 바꿔 쓸 수 있는 클라이언트가 아닙니다. 설정을 불러오기 전에 코어를 확인하고 시작 로그도 살펴보세요. 지원하지 않는 필드가 표시되면 해당 필드가 어느 구현에 속하는지 확인해야 합니다. 설정이 억지로 시작될 때까지 보안 매개변수를 계속 지우지 마세요.

체인 프록시는 각 단계의 연결 경로와 DNS 조회 경로를 추가로 확인해야 합니다. 바깥쪽 출구가 만들어지기 전에는 안쪽 연결을 그 출구로 보낼 수 없습니다. 시간 초과, 인증서, 주소 계열 문제가 겹칠 수도 있습니다. 처음 설정할 때는 각 출구가 따로 작동하는지 확인한 다음 코어가 지원하는 체인 방식으로 연결하세요. 화면에 서버 두 개가 있다고 체인 프록시가 구성된 것은 아니며 트래픽이 목록 순서대로 두 서버를 거친다는 뜻도 아닙니다.

사용자 지정 설정은 시작 성공, 진입점 접근, 단일 라우팅 순서로 검증하세요. 일반 그래픽 설정을 기준선으로 보관하고 실험에 실패하면 기준선으로 돌아가세요. 실패한 상태에 아웃바운드를 계속 추가하지 마세요. 로그에서는 프로토콜 필드, 태그 참조, 포트 충돌을 중점적으로 확인하며 사용자 정보가 포함된 전체 파일을 공개할 필요는 없습니다. 이 세 가지 연결 관계를 확인한 뒤 더 복잡한 출구 조합을 시도하면 유지 관리 부담을 훨씬 잘 통제할 수 있습니다.

연결 확인과 복구

연결 문제는 앱 진입점, 로컬 코어, DNS 조회, 라우팅 출구, 원격 핸드셰이크, 대상 서비스 순서로 확인해야 합니다. 오류가 발생한 계층마다 원인이 다르므로 모두 ‘서버 문제’라고 부르면 쉽게 확인할 수 있는 단계를 건너뛰게 됩니다. 안정적으로 반복할 수 있는 테스트 대상을 정하고 클라이언트, 코어, 진입 모드, 현재 서버를 기록한 뒤 변경을 시작하세요. 변수를 한 번에 하나씩 바꿔야 어떤 설정이 복구에 효과가 있었는지 알 수 있습니다.

로컬 진입점과 코어 시작부터 확인

코어 시작에 실패하면 시스템 프록시가 설정되어 있어도 앱이 로컬 리스너에 연결하지 못할 수 있습니다. 먼저 로그에서 필드 오류, 포트 사용 중, 권한 부족을 확인한 다음 리스너 주소와 포트를 점검하세요. 화면에 표시된 로컬 포트와 사용자 지정 설정의 포트가 다를 수 있으므로 실제 실행 설정을 기준으로 확인해야 합니다. HTTP 프록시 포트를 SOCKS 포트로 테스트하지 마세요. 두 진입점은 핸드셰이크 방식이 달라 포트를 잘못 입력하면 바로 실패할 수 있습니다.

아래 명령은 SOCKS 진입점을 명시하고 프록시 경로를 통해 도메인을 조회합니다. curl을 사용할 수 있고 진입점이 예시 포트인 환경에서만 사용하세요. 모든 앱이나 TUN 가로채기를 검증하는 명령은 아닙니다. 연결이 거부되면 로컬 리스너부터 확인하고 프록시 요청이 시작된 뒤 실패하면 라우팅과 원격 로그를 살펴보세요. 테스트 도메인은 일반 요청을 보내기 위한 것으로 모든 서비스 대상에 같은 네트워크 조건이 적용된다는 뜻은 아닙니다.

curl --proxy socks5h://127.0.0.1:10808 --connect-timeout 10 --max-time 20 -I https://example.com/

조회 실패와 핸드셰이크 실패 구분

서버 도메인을 조회할 수 없다면 원격 핸드셰이크는 아직 시작되지 않은 상태입니다. 먼저 기본 DNS, 현재 네트워크, 프록시 조회 순환 여부를 확인하세요. 조회는 되지만 연결 시간이 초과되면 포트 접근성, 방화벽, 출처 상태를 점검합니다. 시간 초과만으로 프로토콜 매개변수가 올바르다고 볼 수는 없습니다. 단지 대기 중인 작업이 제한 시간 안에 끝나지 않았다는 뜻입니다. 연결 직후 종료된다면 프로토콜, 보안, 전송 매개변수가 서버 설정과 일치하는지 확인하세요.

인증서 오류가 발생하면 검증을 꺼서 원인을 숨기지 말고 시스템 시간, 서버 이름, 인증서 체인을 먼저 확인하세요. 전송에 경로나 서비스 이름을 사용하는 경우 대소문자, 앞쪽 슬래시, 공백이 일치 여부에 영향을 줄 수 있습니다. REALITY 매개변수도 출처와 원문 그대로 비교해야 하며 비슷한 항목에서 가져오면 안 됩니다. 문제 정보를 공개할 때는 오류 유형과 필드 이름만 남기고 사용자 식별자와 주소 토큰 등 민감한 내용은 숨기세요.

기능을 역순으로 비활성화해 복잡한 설정 되돌리기

특정 기능을 켠 뒤 문제가 생겼다면 먼저 해당 기능을 되돌리세요. FakeDNS, TUN, 사용자 지정 DNS, 사용자 지정 라우팅 순으로 복잡한 구성을 일반 프록시 기준선까지 되돌릴 수 있지만 매번 복구 후 다시 테스트해야 합니다. FakeDNS를 끈 뒤에는 이전 캐시를 처리하고, TUN을 끈 뒤에는 시스템 라우팅이 복구됐는지 확인하세요. 화면 스위치만 원래대로 바꿔도 기존 연결과 캐시의 영향이 모두 사라지는 것은 아닙니다.

구독 업데이트 실패와 웹페이지 접속 실패는 나누어 테스트해야 합니다. 프록시 요청은 정상이지만 구독이 실패하면 주소, 응답 내용, 업데이트 방식을 확인하세요. 구독 업데이트는 정상인데 서버에 연결할 수 없다면 업데이트 성공만으로 연결 매개변수가 유효하다고 볼 수 없습니다. 여러 출처에서 동시에 문제가 생기면 공통 진입점과 기본 네트워크부터 확인하세요. 특정 항목만 실패할 때는 다른 정상 항목을 비교 대상으로 남기고 모든 출처를 한꺼번에 삭제하지 마세요.

일부 앱에서만 문제가 생기면 정상 앱과 진입 방식, 앱 자체 DNS, UDP 사용 여부, 앱 제외 설정을 비교하세요. 웹페이지가 열린다고 UDP도 정상인 것은 아니며 시스템 프록시가 작동한다고 가상 인터페이스도 정상인 것은 아닙니다. 앱의 기존 장기 연결은 이전 출구를 계속 사용할 수 있으므로 새 연결을 만든 뒤 판단하세요. 원격 연결을 더 자세히 확인하려면 노드 연결 시간 초과 점검 가이드를 참고하세요.

문제가 해결되면 증상, 확인된 실패 단계, 실제 변경 내용, 복구 테스트를 간단히 기록하세요. 로그 수준을 일시적으로 높였다면 평소 설정으로 되돌려 대상 주소가 포함된 기록이 계속 쌓이지 않게 합니다. 문제가 재현되지 않으면 안정된 기준 설정을 유지하고 검증하지 않은 최적화를 더하지 마세요. 첫 연결 절차를 다시 확인하려면 빠른 시작으로 돌아가고, 플랫폼별 설치 파일이 필요하면 클라이언트 다운로드 페이지를 이용하세요. 설명하고 검증하고 되돌릴 수 있는 설정 경로가 스위치를 계속 추가하는 것보다 장기적으로 관리하기 쉽습니다.