V2Ray 고급 설정

구독 그룹 및 서버 필터

구독 그룹은 구독 출처와 업데이트 범위를 관리하고, 서버 필터는 현재 목록을 좁히는 기능입니다. 두 기능 모두 서버 측 프로토콜을 바꾸지 않으며 라우팅 분기와도 다릅니다. 먼저 출처별 그룹을 만들고 용도에 따라 필터링하세요. 모든 항목을 한데 모은 뒤 이름만 보고 출처를 추측하지 마세요. 문제를 진단할 때는 항목의 구독 주소, 마지막 업데이트 성공 여부, 선택한 항목이 여전히 해당 그룹에 속하는지 확인해야 합니다.

출처를 추적할 수 있는 그룹 만들기

v2rayN의 구독 그룹 설정에서 새 그룹을 만들고 짧은 별칭과 구독 주소를 입력한 뒤 저장하고 해당 그룹만 업데이트하세요. 새 그룹을 먼저 단독으로 업데이트하고 모든 구독을 한꺼번에 갱신하지 마세요. 서버 목록에 항목이 나타나는지 확인한 다음, 항목 편집 화면에서 주소, 포트, 전송 유형을 확인하세요. 버전에 따라 UI 문구가 다를 수 있으니 특정 버튼 위치가 아니라 구독·그룹·업데이트 기능을 기준으로 찾으세요.

v2rayNG와 v2flyNG에서도 먼저 구독 항목을 추가한 뒤 선택한 구독을 업데이트하세요. 클립보드에서 공유 링크 하나를 가져오면 대개 서버 항목만 생성되며, 지속적으로 업데이트되는 구독 관계가 자동으로 만들어지지는 않습니다. 출처 변경 사항을 이후 업데이트에 반영하려면 응답 내용을 목록에 하나씩 붙여 넣지 말고 구독 주소를 등록하세요. 자세한 내용은 구독 링크 가져오기 단계 및 형식 안내를 참고하세요.

그룹 이름에는 ‘일상 연결’, ‘테스트 설정’, ‘예비 출처’처럼 관리 목적을 드러내세요. 이름만으로 프로토콜 기능을 판단할 수는 없으며 같은 그룹 안에서도 프로토콜과 전송 방식이 다를 수 있습니다. 구독 주소에는 접근 정보가 포함될 수 있으므로 스크린샷, 공개 문서, 공유 로그에 노출하지 마세요. 출처 기록에는 식별 가능한 별칭과 필요한 메모만 남기고 전체 주소는 클라이언트에 보관하세요. 기기를 옮길 때는 통제된 방법으로 처리해야 합니다.

전체 목록을 확인한 뒤 단계적으로 필터링

필터링하기 전에 검색창, 지역 조건, 프로토콜 조건을 모두 지우고 전체 목록이 표시되는지 확인하세요. 그런 다음 이름 키워드, 프로토콜 유형처럼 조건을 한 번에 하나씩 추가하세요. 이름 검색은 텍스트만 찾으므로 서버의 실제 위치나 출구를 증명하지 않습니다. 목록이 갑자기 비어 보이면 먼저 필터를 초기화한 뒤 구독 업데이트를 확인하세요. 숨겨진 항목을 출처가 끊긴 것으로 단정하거나 그룹 전체를 삭제하지 마세요.

일부 클라이언트나 배포판은 정규식 필터를 지원하지만 일반 검색창이 정규식으로 해석되는 것은 아닙니다. UI에 정규식 모드가 명시된 경우에만 정규식을 사용하세요. 아래 표현식은 용도 태그 세 개가 각각 독립된 단어로 나타나는 경우를 찾는 예시이며, 코어 JSON이 아닙니다. 적용 전 기존 이름 몇 개로 테스트해 대소문자, 구분자, 공백 처리 방식이 맞는지 확인하세요. 해당 모드가 없다면 키워드를 하나씩 검색하고 표현식을 무리하게 붙여 넣지 마세요.

(^|[\s_-])(work|daily|backup)([\s_-]|$)

정렬과 필터링은 구분해야 합니다. 테스트 결과순 정렬은 표시 순서만 바꿀 뿐 현재 활성 서버를 바꾸지 않을 수 있습니다. 테스트에 성공했더라도 모든 대상에 접근할 수 있다는 뜻은 아닙니다. 항목을 선택한 뒤 활성 표시를 확인하고 실제 웹사이트에 접속해 보세요. 목록 맨 위 항목만 보고 서버가 전환됐다고 판단하지 마세요. 테스트용 항목은 별도 그룹에 보관해 임시 정렬 후 부적절한 설정을 일상 연결로 지정하는 일을 막으세요.

업데이트로 인한 덮어쓰기와 로컬 수정 관리

구독을 업데이트하면 클라이언트 정책에 따라 구독 항목이 재생성되거나 교체되는 경우가 많습니다. 로컬에서 바꾼 이름, 포트, 전송 매개변수가 덮어써질 수 있습니다. 수동 설정을 오래 유지해야 한다면 별도의 수동 관리 영역에 복사하고 변경 이유를 기록하세요. 구독 항목만 수정한 뒤 다음 업데이트에서도 유지될 것이라고 기대하지 마세요. 복사하기 전에는 표시 이름뿐 아니라 인증 및 전송 정보를 포함한 연결 매개변수 전체가 복사됐는지 확인하세요.

업데이트 후 항목이 줄었다면 먼저 필터를 해제하고 해당 그룹의 업데이트 결과를 확인하세요. 그다음 구독 출처에서 항목이 삭제됐는지, 형식이 호환되지 않는지, 요청이 실패했는지 살펴보세요. 작동 중인 연결은 유지하고, 증거가 사라질 수 있으니 항목을 연달아 삭제하거나 다시 가져오지 마세요. 응답이 비어 있거나 파싱에 실패하면 구독 업데이트 실패 자가 점검을 참고하세요. 문제를 해결한 뒤 오류가 난 그룹만 업데이트하고 성공을 확인한 다음 전체 관리를 재개하세요.

라우팅 규칙 실전

라우팅은 코어에 들어온 연결을 지정한 아웃바운드로 보내는 기능이며, 앱 트래픽을 클라이언트로 자동 유입시키지는 않습니다. 시스템 프록시가 작동하지 않는 상태에서는 도메인 규칙을 아무리 추가해도 해당 앱의 직접 연결 경로가 바뀌지 않습니다. 라우팅을 점검하기 전에 로컬 리스너, 앱 프록시, 코어가 정상적으로 작동하는지 확인하고 연결 로그에서 대상과 아웃바운드 태그를 살펴보세요. 트래픽이 코어에 들어온 경우에만 규칙 적용 여부를 논할 수 있습니다.

구체적인 규칙을 포괄적인 규칙보다 앞에 배치

일반적으로 필드 규칙은 순서대로 검사되며 먼저 일치한 규칙이 처리 방향을 결정합니다. 규칙 안의 서로 다른 조건은 대개 모두 충족해야 하며, 도메인 목록의 여러 항목은 선택적 일치 대상을 나타냅니다. 명확한 예외 몇 개를 앞에 두고 큰 도메인 목록은 뒤에 배치하세요. 모든 트래픽을 포괄하는 조건을 먼저 작성한 뒤 뒤쪽 예외가 적용되기를 기대하면 안 됩니다. 순서를 바꾼 후에는 같은 대상에 새 연결을 만들어야 차이를 확인할 수 있습니다.

도메인 조건에서 full:은 전체 도메인 일치, domain:은 도메인과 하위 도메인 범위, regexp:는 정규식 일치에 사용합니다. 앞의 두 방식으로 표현할 수 있다면 정규식을 사용할 필요가 없습니다. 일반 문자열은 예상보다 넓게 일치해 관련 없는 도메인까지 규칙에 포함할 수 있습니다. IP 조건에는 주소나 네트워크 대역을 입력하고 프로토콜이 포함된 웹 주소는 넣지 마세요. 포트와 네트워크 유형도 각각 해당 필드 형식에 맞게 입력해야 합니다.

아래는 전체 설정이 아닌 라우팅 조각입니다. 정확히 지정한 테스트 도메인은 block 아웃바운드로 보내고, 루프백 및 자주 쓰이는 사설 IPv4 대역은 direct로 보냅니다. 이 두 태그는 실제 outbounds에 있어야 합니다. 기존 규칙을 유지하려면 필요에 따라 이 조각의 규칙을 배열에 추가하세요. 전체 라우팅 설정을 그대로 대체하는 용도로 사용하지 마세요.

{
  "routing": {
    "domainStrategy": "AsIs",
    "rules": [
      {
        "type": "field",
        "domain": ["full:blocked.example"],
        "outboundTag": "block"
      },
      {
        "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만 전달하면 도메인 규칙에 필요한 정보가 없을 수 있고, 앱이 도메인을 전달하더라도 이 정책에서는 IP 규칙이 조회된 주소를 얻지 못할 수 있습니다. IPIfNonMatch는 도메인 규칙에서 일치 항목을 찾지 못했을 때 주소를 조회한 뒤 다시 판단하고, IPOnDemand는 관련 IP 조건을 만났을 때 조회를 수행할 수 있습니다. 이 기능을 켜면 DNS 경로도 함께 확인하세요.

일부 프로토콜의 핸드셰이크를 스니핑해 도메인을 추출할 수 있지만 모든 연결에서 가능한 것은 아닙니다. 암호화 핸드셰이크의 특성, 비표준 프로토콜, IP 주소로 직접 접속하는 경우에는 추출이 제한될 수 있습니다. 스니핑을 올바른 DNS 설정을 대신하는 만능 옵션으로 여기지 마세요. 클라이언트에 ‘라우팅에만 사용’과 같은 옵션이 있다면 매칭 정보만 보완하는지, 이후 연결 대상까지 바꾸는지 구분하세요. 실제 동작은 사용 중인 코어 필드에 따라 달라집니다.

웹페이지 결과만 보지 말고 로그로 확인

규칙을 검증할 때는 기존 연결을 끊고 정확한 대상 하나에 접속한 뒤 로그에서 인바운드 태그, 대상 도메인 또는 주소, 선택된 아웃바운드를 확인하세요. 브라우저가 기존 연결을 재사용하면 새로고침해도 이전 경로가 계속 사용될 수 있으므로 규칙을 바꾼 뒤 관련 앱을 다시 시작하거나 새 연결을 만드세요. 규칙이 적용되지 않으면 트래픽이 프록시를 거치는지, 도메인 형식이 일치하는지, 태그 철자가 맞는지 먼저 확인하고 규칙 순서와 조회 정책을 차례로 점검하세요.

‘규칙은 일치했지만 아웃바운드 연결에 실패한 경우’와 ‘규칙이 일치하지 않은 경우’를 구분해야 합니다. 전자는 해당 서버와 프로토콜을 확인하고, 후자일 때 매칭 조건을 조정하세요. 일치하는 규칙이 없으면 일반적인 설정에서는 첫 번째 아웃바운드가 사용될 수 있으므로 반드시 프록시나 직결로 연결된다고 가정하면 안 됩니다. 클라이언트가 생성 과정에서 아웃바운드 순서를 바꿀 수 있으니 UI의 서버 순서만 기억하지 말고 실제 실행 설정을 확인하세요.

지리 정보 기반 도메인 또는 주소 목록을 사용할 때는 리소스 파일이 존재하는지, 현재 코어와 형식이 호환되는지, 목록이 어떻게 업데이트되는지 확인하세요. 리소스가 없으면 규칙 하나를 건너뛰는 대신 코어가 시작되지 않을 수 있습니다. 먼저 정확한 도메인 하나로 최소 규칙을 검증한 다음 큰 목록을 추가하세요. 문제가 생기면 직전의 작동 설정으로 되돌리고 연결 후 웹페이지가 열리지 않을 때의 점검 순서에 따라 원인을 찾으세요.

DNS 설정 최적화

DNS 설정에서는 단순히 주소 하나를 고르는 대신 누가 조회를 시작하고, 어디로 요청을 보내며, 결과를 어느 단계에서 사용하는지 파악해야 합니다. 한 번의 접속에도 시스템 리졸버, 브라우저 보안 DNS, 코어 내장 DNS, 원격 서버 조회가 관여할 수 있습니다. 한 경로를 바꿔도 나머지 경로가 자동으로 전환되지는 않습니다. 먼저 앱에서 리졸버까지 실제 경로를 정리한 다음 코어 조회, 특정 도메인 전용 서버, 암호화된 조회 전송이 필요한지 판단하세요.

세 가지 도메인을 나눠 점검

첫째, 프록시 서버 도메인은 연결을 시작하기 전에 사용할 수 있는 주소로 조회해야 합니다. 둘째, 사용자가 접속하는 대상 도메인은 로컬 또는 원격에서 조회할 수 있습니다. 셋째, DNS 서비스 자체의 도메인은 암호화된 조회 주소를 사용할 경우 초기 조회도 필요합니다. 이 세 종류의 도메인 조회를 아직 연결되지 않은 프록시 경로에 모두 의존하게 하면 순환 의존성이 생길 수 있습니다. 연결의 첫 단계에 명확하고 도달 가능한 조회 경로를 확보하세요.

아래 조각은 시스템 리졸버를 사용하고 IPv4와 IPv6 결과를 모두 조회하도록 허용하는 간단한 기준 설정입니다. 필드의 의미를 파악하는 데 적합합니다. localhost는 시스템의 이름 조회 기능을 호출한다는 뜻이지, 코어가 로컬에서 DNS 서비스 포트를 연다는 의미가 아닙니다. 브라우저가 자체 보안 DNS를 사용하지 않도록 강제하지도 않습니다. 모든 네트워크 환경에 최적화된 설정은 아니며, 조회 출처를 분명히 한 뒤 필요에 따라 세부 설정을 추가하는 것이 목적입니다.

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

UseIPv4와 UseIPv6로 필요한 주소 계열을 제한할 수 있지만, 특정 접속이 한 번 느렸다는 이유만으로 한쪽을 영구적으로 끄면 안 됩니다. 먼저 시스템에서 해당 주소를 받았는지, 라우팅이 가능한지, 아웃바운드가 지원하는지 각각 확인한 뒤 정책을 정하세요. 조회 결과에 IPv6 주소가 있다고 해서 연결에 반드시 IPv6를 사용하는 것은 아닙니다. 최종 선택은 앱, 코어, 아웃바운드 설정, 시스템 네트워크 스택의 영향을 모두 받습니다.

실패 단계에 따라 점검 범위 좁히기

DNS 조회 시간 초과와 연결 시간 초과는 서로 다른 문제입니다. 전자는 주소를 받지 못할 수 있고, 후자는 주소를 받은 뒤 연결을 완료하지 못한 경우입니다. 웹페이지가 열리지 않는 현상만으로는 둘을 구분할 수 없습니다. 코어 로그에서 조회 결과와 이어지는 연결 오류를 비교하고, 필요한 경우 일시적으로 정보 수준 로그를 사용하세요. 지나치게 상세한 로그를 장기간 남기지 말고 대상 도메인이나 구독 주소가 포함된 전체 로그를 공개하지 마세요.

시스템에서 nslookup example.com을 실행하면 시스템 조회 상태를 확인할 수 있습니다. 이 명령만으로 조회가 코어 내장 DNS를 거쳤다고 볼 수는 없습니다. 결과를 비교할 때는 현재 네트워크, 시간, 앱의 조회 설정을 기록해 서로 다른 조회 경로의 차이를 설정 오류로 오인하지 않도록 하세요. 시스템 조회는 정상인데 클라이언트에서만 실패하면 코어의 조회 전송 경로, 관련 라우팅 조건, 프록시 서버 도메인이 같은 장애 경로에 의존하는지를 중점적으로 확인하세요.

도메인별 조회와 캐시는 그다음에 점검

내부망 도메인은 보통 해당 네트워크의 리졸버에 의존하므로 모든 조회를 공용 DNS로 바꾸면 내부 이름이 해석되지 않을 수 있습니다. 특정 도메인에 전용 조회 서버를 지정할 때는 사용 중인 코어가 지원하는 도메인 매칭 방식을 선택하고, 보조 조회 정책이 해당 요청을 다른 서버로 보내는지 확인하세요. 코어마다 대체 필드와 우선순위 지원이 다르므로 v2rayNG의 고급 필드를 v2flyNG에 그대로 복사하지 마세요.

암호화 DNS는 조회 전송 방식을 바꿀 수 있지만, DNS 서비스에 접속할 수 있어야 하고 인증서 검증과 시스템 시간이 정상이어야 합니다. 서비스 주소가 도메인 형식이면 먼저 초기 조회를 해결하세요. 주소 형식을 사용하더라도 필요한 인증서와 서버 이름 조건을 확인해야 합니다. 조회 주소, 라우팅 모드, TUN 설정을 동시에 바꾸면 성공이나 실패의 원인을 파악하기 어려워집니다. 변경할 때마다 복구할 수 있는 설정 사본을 보관하세요.

캐시 때문에 설정을 바꾼 뒤에도 이전 결과가 잠시 사용될 수 있습니다. 검증할 때 관련 앱과 클라이언트를 다시 시작하고, 필요한 경우 운영체제에서 제공하는 방법으로 조회 캐시를 지우세요. 주소를 반복해서 바꾸며 ‘새로고침’하지 마세요. 가정 네트워크에서 사무실 네트워크로 이동한 뒤에는 내부 도메인과 인터페이스 관련 설정도 다시 점검해야 합니다. 이 장의 검증 완료 기준은 특정 웹사이트가 우연히 다시 열리는 것이 아니라 각 조회의 출처와 목적지를 설명할 수 있는 것입니다.

TUN 모드와 트래픽 가로채기

TUN 모드는 가상 네트워크 인터페이스로 네트워크 계층의 트래픽을 받아 시스템 프록시 설정을 따르지 않는 앱을 처리합니다. 트래픽을 가로채는 범위를 넓히는 기능이지, 잘못된 서버 설정을 자동으로 고치거나 모든 프로토콜을 같은 경로로 처리해 주는 기능은 아닙니다. 켜기 전에 일반 프록시 모드가 작동하는지 확인하고 권한, 라우팅, DNS를 점검하세요. 그렇지 않으면 기존 연결 오류에 가로채기 오류까지 더해져 시스템 전체가 네트워크에 접속하지 못할 수 있습니다.

복구 가능한 기준 상태부터 만들기

데스크톱에서는 먼저 v2rayN의 시스템 프록시로 연결이 되는지 확인하고 활성 서버, 라우팅 모드, DNS 설정을 기록하세요. 트래픽을 가로채는 다른 가상 네트워크 인터페이스나 터널 도구는 중지한 뒤 클라이언트의 TUN 기능을 켜세요. 일부 구현은 관리자 권한이나 보조 서비스가 필요하고, 별도 구성 요소가 트래픽 처리를 맡을 수도 있습니다. 클라이언트에서 현재 제공하는 기능을 기준으로 판단하고 UI의 TUN 스위치를 코어의 최상위 필드 하나와 동일시하지 마세요.

Android의 v2rayNG와 v2flyNG는 대개 시스템 VPN 인터페이스를 통해 앱 트래픽을 가로챕니다. 처음 시작할 때 시스템 권한 안내를 읽고 현재 클라이언트에 권한을 부여하는지 확인하세요. 일반적으로 이런 트래픽 가로채기 서비스는 여러 개를 동시에 활성화할 수 없으므로 클라이언트를 바꿀 때는 이전 서비스를 먼저 중지하세요. 여기서 말하는 시스템 인터페이스는 트래픽을 가로채는 방식이며, 연결 가능한 원격 서버가 준비됐다는 뜻은 아닙니다. 서버 설정은 별도로 준비해야 합니다.

권한, 기본 경로, 루프백 확인

활성화한 뒤 가상 인터페이스가 생성됐는지, 코어가 계속 실행되는지, 기본 트래픽 방향이 예상과 일치하는지 확인하세요. 클라이언트를 켜자마자 계속 재연결한다면 프록시 서버로 나가는 연결이 다시 가상 인터페이스로 들어가는 루프가 생겼을 수 있습니다. 올바른 구현은 자체 아웃바운드 트래픽을 제외하거나 실제 네트워크 인터페이스에 바인딩해야 합니다. 문제를 넓은 직결 규칙으로 덮지 말고 인터페이스 선택, 자동 라우팅, 프로세스 제외 기능을 먼저 확인하세요.

LAN 접속은 별도로 검증해야 합니다. 프린터, 공유 폴더, 내부 서비스는 사설 주소, 링크 로컬 주소, 전용 도메인을 사용할 수 있습니다. 자주 쓰는 사설 주소를 직결로 설정하는 것만으로는 부족하며 가상 인터페이스 라우팅, 이름 조회, 방화벽도 점검해야 합니다. IP 주소로는 접속되지만 이름으로 접속되지 않는다면 DNS 장으로 돌아가세요. IP로도 접속되지 않으면 인터페이스 라우팅과 네트워크 대역 충돌을 확인하고, 서버 프로토콜부터 바꾸지는 마세요.

트래픽 가로채기 범위와 전송 기능을 구분

트래픽이 TUN에 들어온 뒤 UDP를 처리할 수 있는지는 가로채기 구성 요소, 선택한 프로토콜, 서버 측 기능, 라우팅 규칙에 따라 달라집니다. 브라우저 웹페이지가 열린다고 실시간 통신이나 다른 UDP 앱도 작동하는 것은 아닙니다. 실제로 사용할 앱을 골라 별도로 테스트하고 네트워크 유형과 오류 기록을 확인하세요. 호환되지 않으면 먼저 가로채기 범위를 줄이거나 앱이 지원하는 프록시 기능을 사용하세요. 모든 매개변수를 무작정 바꾸지 마세요.

MTU 조정은 기본 연결 경로를 확인한 뒤 진행하세요. 일부 큰 데이터 전송만 멈출 때 네트워크 환경을 고려해 패킷 분할이나 경로 MTU 문제를 살펴보면 됩니다. 모든 네트워크에 공통으로 적용되는 고정값은 없습니다. 한 번에 한 단계씩 바꾸고 같은 대상에 다시 접속해 보며 기존 값을 기록하세요. 실패하면 즉시 원래대로 복구하세요. 기본 도메인 조회와 짧은 연결조차 실패한다면 MTU를 반복해서 시험하기보다 권한, 라우팅, DNS를 먼저 해결하세요.

절전 모드에서 복귀하거나 무선 네트워크를 바꾸거나 유선 네트워크를 연결하면 실제 인터페이스 이름과 게이트웨이가 달라질 수 있습니다. 시작 직후에는 정상이지만 네트워크를 전환한 뒤 실패한다면 가로채기를 중지했다가 다시 설정하고 자동 인터페이스 선택이 갱신되는지 확인하세요. 장기적으로는 구독을 다시 가져오는 것보다 문제가 발생하는 조건을 기록하는 편이 유용합니다. 구독 관리는 시스템 라우팅을 관리하지 않으므로 서버 목록을 다시 받아도 이미 사용할 수 없는 인터페이스 문제는 해결되지 않습니다.

이 장을 마친 뒤에는 일반 웹페이지, 원래 시스템 프록시를 사용하지 않는 앱 하나, 실제로 사용할 LAN 서비스 하나를 각각 테스트하세요. 세 가지 결과를 비교하면 가로채기 범위, 원격 전송, 내부망 예외를 구분할 수 있습니다. 시스템에 서비스가 실행 중이라고 표시되는 것만으로는 가로채기가 올바르다는 증거가 되지 않습니다. 클라이언트를 종료했을 때 네트워크가 복구되는지도 확인해 오래된 라우팅을 정리하지 않은 상태에서만 잠시 작동하는 상황을 피하세요.

FakeDNS 주소 매핑

FakeDNS는 도메인을 관리되는 주소 풀의 합성 주소로 매핑한 뒤 트래픽이 코어에 들어오면 도메인으로 복원합니다. 도메인 정보를 유지하고 라우팅을 돕는 기능이지, 모든 조회를 대신하는 공용 DNS 서비스는 아닙니다. 실제 연결에는 여전히 유효한 대상과 아웃바운드가 필요합니다. 사용하기 전에 DNS 조회 경로와 TUN 가로채기 범위를 파악하세요. 그렇지 않으면 앱이 합성 주소를 받았지만 매핑을 복원할 코어로 연결이 들어가지 않을 수 있습니다.

조회와 연결의 전체 경로를 확인

전체 경로는 세 단계로 이루어집니다. 앱의 조회가 FakeDNS를 제공하는 경로로 전달되고, 합성 주소를 받은 앱이 연결을 시작하며, 해당 연결을 관련 코어가 가로채 도메인으로 복원합니다. 어느 한 단계라도 빠지면 실패합니다. 설정에 주소 풀만 추가해도 시스템 조회가 자동으로 그 경로에 전달되는 것은 아닙니다. TUN을 켰다고 모든 DNS 조회가 FakeDNS로 전달되는 것도 아닙니다. 조회 출처, 응답 주소, 연결 인바운드를 각각 확인하세요.

아래는 Xray 방식의 코어 설정 조각으로 주소 풀, 조회 서버, SOCKS 인바운드 스니핑의 관계를 보여줍니다. 완성된 클라이언트 설정도 아니고 모든 코어에서 사용할 수 있는 공통 템플릿도 아닙니다. 여기서는 로컬에서만 수신하도록 설정했습니다. SOCKS 인바운드 스니핑은 해당 인바운드가 받은 연결만 처리하며 시스템 DNS를 자동으로 가로채지 않습니다. TUN에 비슷한 설정을 적용하려면 클라이언트가 실제로 제공하는 트래픽 가로채기 및 DNS 설정을 사용해야 하며 이 인바운드 설정을 그대로 복사하면 안 됩니다.

{
  "fakedns": [
    {
      "ipPool": "198.18.0.0/15",
      "poolSize": 65535
    }
  ],
  "dns": {
    "servers": ["fakedns"]
  },
  "inbounds": [
    {
      "tag": "local-socks",
      "listen": "127.0.0.1",
      "port": 10808,
      "protocol": "socks",
      "settings": {
        "auth": "noauth",
        "udp": true
      },
      "sniffing": {
        "enabled": true,
        "destOverride": ["fakedns"]
      }
    }
  ]
}

주소 풀은 서버 목록이 아닙니다

ipPool은 합성 매핑에 사용할 주소 범위를 나타내고, poolSize는 매핑 풀의 크기를 설정합니다. 주소 개수는 서버 수나 연결 가능 수를 뜻하지 않습니다. 풀에 포함된 주소를 실제 원격 서버 주소로 구독이나 수동 항목에 저장하면 안 됩니다. 네트워크에서 같은 범위를 사용 중이라면 충돌이 생길 수 있으니 설정 파일의 문법만 확인하지 말고 기존 라우팅과 내부 네트워크 구성을 먼저 점검하세요.

위 예시의 주소 범위는 기준 테스트 등 특정 용도에 사용되며 공용 인터넷에서 접속할 수 있는 대상이 아닙니다. 앱이 이 주소를 받은 뒤에는 올바른 복원 경로를 거쳐야 합니다. 로그에 해당 범위로 실제 네트워크에 직접 연결을 시도한 흔적이 있다면 매핑이 처리되지 않았거나 연결이 가로채기 경로를 우회한 것입니다. 이때 일반 프록시 규칙을 추가하는 것은 근본적인 해결이 아닐 수 있습니다. 스니핑 기능, 인바운드 위치, DNS 응답이 같은 실행 인스턴스에서 제공되는지 먼저 확인하세요.

코어 차이와 앱 동작에 유의

v2rayNG와 v2flyNG는 서로 다른 코어를 사용하므로 FakeDNS의 필드 지원, 설정 형식, 연동 방식을 각각 확인해야 합니다. 두 클라이언트의 UI가 비슷하다는 이유로 사용자 지정 JSON 전체를 복사하지 마세요. v2rayN도 서로 다른 구성 요소로 트래픽을 가로챌 수 있으므로 현재 실행 중인 코어와 설정 생성 방식을 먼저 확인해야 합니다. 분기 배경은 Xray와 V2Fly 코어 관계 안내를 참고하세요.

앱이 암호화 DNS를 자체적으로 사용하면 미리 설정한 시스템 조회 경로를 우회해 합성 주소가 아닌 실제 주소를 받을 수 있습니다. 일부 앱은 캐시된 주소나 고정 IP를 직접 사용해 복원할 도메인 매핑이 없을 수도 있습니다. 브라우저 하나가 작동한다고 모든 앱이 FakeDNS를 거친다고 단정하지 마세요. 새 도메인 하나를 골라 테스트하고 조회 로그와 연결 로그를 함께 살펴보세요. 필요한 경우 테스트 앱의 조회 설정을 일시적으로 통일하세요.

매핑은 일반적으로 현재 코어 실행 상태에 종속되며, 코어를 다시 시작하면 캐시에 남은 합성 주소가 이전 도메인과 연결되지 않을 수 있습니다. 클라이언트를 다시 시작한 뒤 일부 앱만 실패한다면 구독을 다시 가져오기보다 해당 앱의 조회 캐시를 지우거나 앱을 다시 실행하세요. FakeDNS를 끌 때도 캐시를 정리해 클라이언트가 중지된 뒤 합성 주소를 실제 대상으로 계속 취급하지 않도록 하세요. 네트워크 전환이나 절전 복귀 후에도 확인이 필요합니다.

도메인을 성공적으로 복원한 뒤에야 라우팅 규칙이 도메인 조건에 따라 추가로 대상을 선택할 수 있습니다. 라우팅이 올바르다고 원격 조회까지 정상이라는 뜻은 아닙니다. 로그에 원래 도메인과 예상 아웃바운드가 표시된다면 실제 DNS 조회와 연결 단계를 이어서 점검하세요. 먼저 테스트 환경에서만 FakeDNS를 활성화하고, 끈 뒤 일반 조회로 복구되는지 확인한 다음 적용 범위를 넓히세요. 도메인을 유지해야 할 명확한 이유가 없다면 기존의 정상적인 조회 설정을 유지하는 편이 관리하기 쉽습니다.

다중 구독 관리와 업데이트 정책

다중 구독 관리의 핵심은 목록을 길게 만드는 것이 아니라 업데이트 위험을 분리하고 전환 기준을 명확히 하는 것입니다. 각 출처에는 고유한 주소, 형식, 유효 기간, 연결 조건이 있습니다. 한 출처의 업데이트 실패가 작동 중인 다른 그룹에 영향을 주면 안 됩니다. 출처, 용도, 현재 활성 항목을 따로 기록해 이름이 같은 항목을 같은 서버로 착각하거나 업데이트 후 철회된 이전 항목에 계속 의존하지 않도록 하세요.

출처별로 나누고 용도에 따라 선택

구독 주소마다 별도의 그룹을 만들고 별칭으로 일상용, 테스트용, 예비용을 구분하세요. 서로 다른 출처의 원본 주소를 하나로 이어 붙이거나 여러 구독 응답을 한 가져오기 창에 붙여 넣은 뒤 클라이언트가 출처 관계를 자동으로 관리할 것이라고 기대하지 마세요. 병합된 정적 항목은 업데이트 연결이 끊길 수 있습니다. 그때 접속이 되더라도 이후 추가·철회·매개변수 변경을 추적하기 어렵습니다. 클라이언트의 기본 구독 관리 기능을 사용하는 편이 좋습니다.

이름이 같다고 연결 매개변수까지 같은 것은 아닙니다. 중복 항목을 판단할 때는 최소한 프로토콜, 서버 주소, 포트, 전송 설정을 비교하고 인증 정보는 로컬에서 확인하세요. 출처가 달라도 같은 별칭을 사용할 수 있고 같은 주소라도 인증이나 전송 설정에 따라 별도 항목일 수 있습니다. 정리하기 전에 현재 활성 연결이 어느 그룹에 속하는지 확인하고 작동 기준을 유지하세요. 목록을 깔끔하게 만들려다 유일하게 작동하는 설정을 삭제하지 마세요.

그룹은 자동 장애 조치 기능이 아닙니다. 그룹 이름을 ‘예비’로 지정해도 현재 연결이 실패했을 때 클라이언트가 자동으로 그 그룹을 사용하지는 않습니다. 자동 선택, 부하 분산, 상태 확인은 별도의 기능이며 지원 여부와 동작 방식은 클라이언트와 코어에 따라 다릅니다. 이런 기능을 명시적으로 설정하지 않았다면 예비 그룹은 수동 전환용으로 보고 선택 위치와 검증 방법을 기록하세요. 그룹 이름만으로 실행 동작을 추측하지 마세요.

일정한 순서로 업데이트하기

새 출처를 추가하면 먼저 단독 업데이트를 실행해 파싱 결과와 대표 항목 하나를 확인한 뒤 정기 업데이트를 설정하세요. 예약 업데이트를 사용하기 전에 실행 시점에 클라이언트가 켜져 있는지, 네트워크에 연결되어 있는지, 업데이트 요청이 어떤 경로를 사용하는지 확인해야 합니다. 업데이트 요청이 현재 프록시를 사용하는지는 클라이언트마다 다르므로 관련 옵션을 찾아 직접 테스트하세요. 구독 업데이트 성공과 서버 연결 성공은 별개의 지표입니다.

업데이트가 실패하면 오류 유형부터 확인한 뒤 요청 경로를 바꿀지 판단하세요. 연결 시간 초과는 현재 네트워크 문제일 수 있고, 인증 실패나 만료된 주소는 구독 출처의 상태를 확인해야 합니다. 조회 결과가 비어 있다면 형식이 호환되지 않는 문제일 수도 있습니다. 모든 출처를 짧은 시간에 연속으로 재시도하지 마세요. 문제 해결이 복잡해지고 출처 측 요청 제한이 걸릴 수 있습니다. 오류가 난 그룹만 점검하고 다른 그룹은 그대로 유지하면서 마지막 성공 상태와 비교하세요.

서버 목록을 업데이트한 뒤 활성 항목이 남아 있는지, 재생성됐는지, 기본 항목으로 바뀌었는지 확인하세요. 선택 상태를 유지하는 클라이언트도 있지만 작업에 따라 현재 항목이 바뀔 수 있으므로 동작이 모두 같다고 가정하면 안 됩니다. 활성 표시를 확인한 뒤 연결을 새로 만들고 자주 사용하는 대상과 필요한 LAN 접속을 테스트하세요. 표시 이름만 바뀌고 실제 연결 매개변수는 그대로라면 라우팅 설정을 불필요하게 다시 구성하지 마세요.

이전할 때 관리 데이터와 연결 데이터를 분리

기기를 옮길 때는 구독 기록, 수동 항목, 라우팅 규칙, DNS 설정, 시스템 트래픽 가로채기 옵션을 각각 확인하세요. 서버 공유 링크 하나를 내보내도 그룹별 업데이트 일정은 대개 포함되지 않으며 시스템 프록시나 TUN 상태도 그대로 옮겨지지 않습니다. 이전 후에는 먼저 일반 프록시 모드에서 연결을 확인하고 고급 설정을 하나씩 복원하세요. 다른 기기의 인터페이스 이름, 네트워크 대역 가정, 권한 상태를 새 환경에 그대로 적용하지 마세요.

백업에는 구독 접근 정보, 서버 인증 정보, 개인별 접속 설정이 포함될 수 있으므로 통제된 저장소에 보관하고 공개 문제 해결 자료로 사용하지 마세요. 문제를 공유할 때는 오류 유형, 필드 이름, 민감한 정보를 제거한 일부 내용만 제공하세요. 텍스트 파일이라고 해서 바로 업로드해도 된다고 생각하면 안 됩니다. 복원하기 전에 백업이 어떤 클라이언트와 코어용인지 확인해 작동 중인 관리 설정을 자동으로 덮어쓰지 않도록 하세요.

출처를 삭제할 때는 먼저 검증된 다른 연결로 전환하고 해당 그룹의 업데이트 일정을 중지한 다음 구독 기록과 더 이상 필요하지 않은 항목을 삭제하세요. 마지막으로 클라이언트 규칙이나 사용자 지정 아웃바운드가 삭제된 항목을 계속 참조하는지 확인하세요. 목록을 정리한 뒤에는 연결을 다시 테스트해 끊지 않은 이전 세션에 의존하고 있지 않은지 확인해야 합니다. 그래야 다중 구독을 과거 캐시로 겉만 정상인 상태에 기대지 않고 추적 가능한 방식으로 관리할 수 있습니다.

사용자 지정 아웃바운드와 설정 검증

아웃바운드는 연결이 코어에서 나가는 방식을 정의하고, 라우팅은 태그를 사용해 아웃바운드를 선택합니다. 서버 항목, 아웃바운드 객체, 라우팅 규칙은 서로 연결되어 있지만 같은 객체는 아닙니다. 클라이언트는 대개 선택한 서버를 바탕으로 아웃바운드를 생성합니다. 전체 사용자 지정 설정을 사용하면 UI에서 서버를 바꿔도 설정이 자동으로 변경되지 않을 수 있습니다. 작업 전에 현재 입력란이 완전한 JSON을 받는지, 아웃바운드 조각을 받는지, 클라이언트 전용 규칙 형식을 받는지 확인하세요.

원격 인증 정보 없이 최소 설정으로 구조 확인

아래는 로컬 기능 테스트용 완전한 기본 설정입니다. V2Fly와 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": {
    "domainStrategy": "AsIs",
    "rules": [
      {
        "type": "field",
        "domain": ["full:blocked.example"],
        "outboundTag": "block"
      }
    ]
  }
}

설정의 direct와 block은 사용자가 정한 태그이지 이름만으로 작동하는 예약어가 아닙니다. 실제 동작은 protocol이 결정하며 태그를 바꾸면 모든 참조도 함께 수정해야 합니다. 이 예시에서는 규칙에 일치하지 않는 연결은 첫 번째 직결 아웃바운드를 사용하고, 정확히 지정한 테스트 도메인은 차단 아웃바운드로 보냅니다. 테스트 도메인은 규칙 동작을 확인하기 위한 것으로 실제 사이트 콘텐츠를 제공하지 않습니다.

문법·의미·실행 세 단계로 점검

먼저 문법을 확인하며 큰따옴표, 쉼표, 배열, 객체가 올바르게 닫혔는지 점검하세요. 표준 JSON에서는 주석과 마지막 항목 뒤의 쉼표를 허용하지 않습니다. 다음으로 현재 코어에서 지원하는 필드인지, 태그 참조가 존재하는지, 포트와 주소 형식이 올바른지 확인하세요. 마지막으로 코어를 시작해 실행 결과를 살펴봅니다. JSON 도구로 파일을 읽을 수 있다는 것은 문법이 올바르다는 뜻일 뿐, 프로토콜 지원, 서버 접속, 라우팅이 정상이라는 뜻은 아닙니다.

실행할 때는 먼저 리스너가 정상적으로 시작됐는지 확인한 뒤 테스트 앱에서 로컬 SOCKS 주소와 포트를 사용하세요. 도메인 규칙을 확인하려면 앱이 도메인 이름을 프록시에 전달해야 합니다. 앱이 로컬에서 먼저 조회해 IP만 전달하면 정확한 도메인 규칙이 일치할 조건이 없을 수 있습니다. 일반 접속을 확인한 뒤 테스트 도메인으로 차단 동작을 시험하고, 앱이 프록시를 우회해 실패한 것이 아니라 현재 코어가 처리한 결과인지 확인하세요.

예시 리스너는 루프백 주소에서 수신하므로 로컬 테스트에 적합합니다. 모든 인터페이스에서 수신하도록 바꾸면 접근 범위가 달라집니다. 특히 인증이 없는 SOCKS 서비스는 같은 네트워크의 다른 기기에서도 사용할 수 있습니다. 공유가 필요하다면 수신 주소만 임의로 바꾸지 말고 인증, 방화벽, 허용할 출처를 별도로 설계하세요. 클라이언트의 ‘LAN 허용’ 옵션도 개방 범위를 이해한 뒤 사용해야 하며, 문제 해결을 위해 잠시 켠 설정을 장기간 그대로 두지 마세요.

실제 아웃바운드 연결에도 복구 경로 유지

실제 원격 아웃바운드는 검증된 서버 매개변수로 생성한 뒤 현재 코어가 지원하는 프로토콜 필드에 맞춰 조정하세요. V2Fly와 Xray 전용 매개변수를 섞지 말고 프로토콜 이름만 복사하면서 전송 방식, 보안 계층, 서버 이름 같은 관련 설정을 빠뜨리지 마세요. 매개변수가 부족하다면 클라이언트의 기본 서버 편집 화면으로 돌아가 확인하세요. 코어를 선택해야 한다면 클라이언트 비교를 참고하고, 매개변수 누락을 가리기 위해 클라이언트를 계속 바꾸지 마세요.

아웃바운드가 여러 개라면 용도를 알 수 있는 고유 태그를 사용하고 각 라우팅 규칙에 선택 이유를 기록하세요. 체인 방식으로 전달하려면 코어가 실제로 지원하는 연결 방식과 필드를 확인하고 ‘아웃바운드 하나 선택’과 ‘다른 아웃바운드를 통해 연결’을 구분해야 합니다. 객체 두 개를 추가한다고 이 관계가 자동으로 만들어지는 것은 아닙니다. 처음에는 실제 아웃바운드 하나와 구체적인 규칙 하나만 추가해 확인하고, 성공한 뒤 확장해 순환 참조나 추적하기 어려운 기본 경로를 방지하세요.

클라이언트는 시작하거나 서버를 전환하거나 구독을 업데이트할 때 실행 설정을 다시 생성할 수 있습니다. 임시 생성 파일을 직접 수정하면 변경 사항이 사라질 수 있습니다. 장기간 유지할 설정은 클라이언트가 공식 지원하는 입력란에 저장하고 재시작 후에도 적용되는지 확인하세요. 복구할 때는 이전 설정을 되돌리고 코어를 다시 시작한 뒤 시스템 프록시와 TUN 상태를 점검하세요. 파일만 교체하고 이전 프로세스를 계속 사용해 UI와 실제 실행 상태가 달라지는 상황을 피하세요.