V2Ray 고급 설정 가이드

구독 그룹 및 서버 필터링

구독 출처, 표시 목록, 활성 노드를 구분하세요

구독 그룹은 클라이언트에서 서버 항목을 관리하는 단위입니다. 라우팅 그룹과는 다르며, 특정 앱이 특정 노드를 자동으로 사용하게 하지도 않습니다. 구독 주소는 서버 항목을 제공하고, 그룹은 항목을 정리하며, 현재 선택된 활성 서버가 일반 프록시 아웃바운드의 연결 대상을 결정합니다. 이 세 가지를 구분해야 “그룹을 바꿨는데 출구가 그대로”인 상황을 오해하지 않습니다. 목록을 전환한 뒤에는 서버를 직접 선택하고, 새 활성 설정이 적용됐는지도 확인하세요.

v2rayN에서 구독 그룹 설정을 열고 출처별로 그룹을 따로 만드세요. 이름에는 용도와 출처의 약칭을 함께 쓰는 것이 좋습니다. 예를 들어 “일상용”, “예비 연결”처럼 지정하고 전체 구독 주소를 이름에 붙여 넣지는 마세요. 주소를 추가한 뒤 저장하고 해당 그룹을 업데이트하세요. 첫 업데이트가 끝나면 서버 이름, 프로토콜 유형, 전송 매개변수가 올바르게 인식됐는지 확인합니다. 목록이 비어 있다면 업데이트 로그부터 확인하세요. 같은 주소를 반복해서 추가해 빈 그룹을 여러 개 만들지 마세요.

필터는 항목 범위만 좁힙니다. 연결 품질을 보장하지 않습니다

서버 필터는 표시하거나 가져올 항목의 범위를 줄이는 기능이며, 정확한 적용 시점은 클라이언트의 필터 옵션에 따라 다릅니다. 현재 표시 목록에만 적용되는 경우도 있고, 구독 업데이트 시 항목을 걸러 내는 경우도 있습니다. 변경하기 전에 필드 설명을 확인하고, 비교를 위해 필터를 적용하지 않은 원본 그룹을 보존하세요. 지역, 회선 용도, 배율은 대개 제공업체가 붙인 이름이지 클라이언트가 독립적으로 측정한 사실이 아닙니다. 이름에 특정 지역이 들어 있어도 실제 출구 위치를 이름만으로 단정할 수 없습니다.

먼저 일반 키워드 검색으로 원하는 항목을 찾을 수 있는지 확인한 다음 정규식을 검토하세요. 정규식을 지원한다고 명시된 필드에서만 아래 표현식을 사용해야 합니다. 이 표현식은 이름에 “홍콩” 또는 “싱가포르”가 포함된 항목과 일치합니다. 제공업체가 다른 이름을 사용한다면 표현식도 바꿔야 합니다. 일반 텍스트만 지원하는 검색창에 그대로 입력하지 마세요. 세로줄과 괄호가 문자 그대로 처리되어 검색 결과가 비어 있을 수 있습니다.

(홍콩|싱가포르)

필터가 제대로 작동하는지 확인하려면 먼저 필터를 해제해 전체 항목을 본 다음 필터를 적용해 목록이 예상대로 바뀌는지 비교하세요. 결과가 없다면 구독이 만료된 것이 아니라 대소문자, 전각 문자, 숨은 공백, 이름 변경이 원인일 수 있습니다. 제외 키워드와 포함 키워드를 함께 사용할 때는 서로 상쇄되는 조건이 없는지 살펴보세요. 복잡한 조건은 하나씩 추가하세요. 긴 표현식을 한 번에 작성하면 오류 위치를 찾기 어렵고 유지 관리도 힘들어집니다.

구독 업데이트 전 복구에 필요한 정보를 남기세요

원격 업데이트로 그룹 내 서버 항목이 교체될 수 있으며, 로컬에서 직접 수정한 메모나 매개변수는 유지되지 않을 수 있습니다. 장기간 보존해야 할 사용자 지정 서버는 별도의 수동 그룹에 두는 편이 좋습니다. 업데이트 전에는 활성 서버가 속한 그룹과 알아볼 수 있는 이름을 기록하되, 업데이트 후에도 항목 순서가 같을 것이라고 가정하지 마세요. 제공업체가 이름을 바꾸거나 회선을 삭제하거나 순서를 조정할 수 있습니다. 목록 위치만 보고 서버를 선택하면 업데이트 후 예상과 다른 대상에 연결될 수 있습니다.

구독 업데이트에 실패하면 먼저 ‘주소 가져오기 실패’와 ‘콘텐츠 파싱 실패’를 구분하세요. 전자는 주소가 유효한지, 현재 네트워크가 정상인지, 업데이트 시 프록시를 사용했는지 확인합니다. 후자는 응답이 실제 구독 콘텐츠인지, 로그인 페이지나 만료 안내 또는 오류 페이지인지 살펴보세요. 프록시를 통해 업데이트하려면 연결 가능한 활성 노드가 먼저 있어야 합니다. 모든 노드를 사용할 수 없다면 업데이트 경로가 서로 의존하는 상황일 수 있으므로, 현재 네트워크에서 가능한 다른 방법을 시도하세요.

v2rayNG나 v2flyNG로 가져온 뒤에도 그룹과 활성 노드를 다시 확인하세요. 클라이언트마다 메모, 정렬, 필터 조건을 저장하는 방식이 다를 수 있으므로 데스크톱 목록 상태가 휴대폰에 동기화됐다고 볼 수는 없습니다. 구독 링크에는 보통 접속 인증 정보가 포함되므로 클립보드에 복사한 뒤 공개 채팅방에 보내지 마세요. 문제를 문의할 때는 민감 정보를 제거한 오류 요약만 제공하고, 전체 링크를 댓글이나 스크린샷에 올리지 마세요.

라우팅 규칙 실전과 우선순위

기본 출구를 정한 다음 예외 규칙을 작성하세요

라우팅 분기는 코어에 들어온 연결을 특정 아웃바운드로 전달합니다. 앱 트래픽을 자동으로 클라이언트에 넣어 주는 기능이 아니며 시스템 프록시 설정과도 다릅니다. 규칙은 일반적으로 순서대로 평가되며, 먼저 일치한 유효 규칙이 경로를 결정합니다. 일치하는 규칙이 없으면 설정된 기본 아웃바운드 동작을 사용합니다. 변경하기 전에 기본 경로를 프록시와 직접 연결 중 무엇으로 할지 정하고, 예외 몇 개를 앞쪽에 배치하세요. 범위가 지나치게 넓은 규칙이 앞에 있으면 뒤의 세부 규칙이 적용되지 않을 수 있습니다.

v2rayN의 기본 라우팅 모드는 시작점으로 적합하지만 여러 기본 규칙을 그대로 겹쳐 쓰는 것은 피하세요. 용도에 가까운 모드를 하나 선택한 뒤 라우팅 설정에서 실제 규칙을 확인하세요. 사설망 주소, 지정 도메인, 지역별 목록, 기본 처리 규칙이 명확한 계층을 이루어야 합니다. 특히 프록시 서버 자체 연결의 우회 처리가 중요합니다. TUN을 켰다면 프록시 연결이 다시 가로채지지 않도록 확인하세요. 클라이언트가 일부 예외를 자동 처리할 수 있으므로 변경 전에 현재 동작을 파악해야 합니다.

도메인, 주소, 목록은 각각 매칭 조건이 다릅니다

full:은 완전한 도메인 하나만 일치시킬 때 적합합니다. domain:은 지정한 도메인과 하위 도메인을 함께 포함할 때 사용합니다. regexp:는 정규식 매칭을 제공하고, geosite:는 도메인 목록을 참조합니다. 주소 규칙의 ip에는 단일 주소, 네트워크 대역 또는 지원되는 주소 목록을 사용할 수 있습니다. 목록 이름은 고정된 내장 기능을 보장하지 않습니다. 현재 데이터 파일에 따라 지원 여부가 달라지므로 사용 전에 해당 파일이 있고 항목 이름이 올바른지 확인하세요.

아래 예시는 예시 도메인과 그 하위 도메인의 연결을 direct 아웃바운드로 전달합니다. 라우팅 구조를 보여 주는 예시이므로 설정에 합칠 때 같은 태그를 가진 아웃바운드가 이미 있는지 확인하세요. 예시 도메인은 직접 연결할 실제 대상으로 바꾸되, 전체 웹 주소를 입력하지 마세요. 프로토콜 접두사, 포트, 경로는 도메인 매칭 필드에 해당하지 않습니다. 그래픽 인터페이스에서 같은 규칙을 추가할 때도 도메인 조건과 대상 아웃바운드를 각각 선택해야 합니다.

{
  "routing": {
    "domainStrategy": "AsIs",
    "rules": [
      {
        "type": "field",
        "domain": ["domain:example.com"],
        "outboundTag": "direct"
      }
    ]
  }
}

여러 조건은 어떻게 조합되나요?

한 규칙에서 서로 다른 조건 필드는 일반적으로 모두 충족해야 합니다. 같은 목록에 있는 후보 항목은 보통 그중 하나와 일치하면 됩니다. 따라서 도메인, 포트, 네트워크 유형을 한 규칙에 넣으면 세 종류의 트래픽에 각각 규칙이 생기는 것이 아니라 매칭 범위가 좁아집니다. 서로 다른 상황을 처리하려면 규칙을 분리하는 편이 검증하기 쉽습니다. 도메인이 분명히 맞는데도 규칙이 적용되지 않는다면 순서 외에도 실제 요청과 맞지 않는 포트나 인바운드 조건이 추가됐는지 확인하세요.

도메인 규칙을 사용하려면 코어가 도메인 정보를 확보할 수 있어야 합니다. 명시적 프록시 요청에는 도메인이 포함될 수 있지만, 일부 투명 프록시 트래픽에는 대상 주소만 있어 스니핑이나 FakeDNS 매핑으로 정보를 보완해야 할 수 있습니다. domainStrategy는 주소 규칙을 위해 도메인을 언제 조회할지에도 영향을 줍니다. 이를 DNS 모듈의 조회 정책과 혼동하지 마세요. 더 일찍 조회한다고 라우팅이 반드시 정확해지는 것은 아닙니다. 대기 시간이 늘거나 주소 규칙의 매칭 결과가 달라질 수도 있습니다.

규칙 검증은 구체적인 대상을 기준으로 하세요. 예상 아웃바운드를 기록하고 새 연결을 만든 뒤 로그에서 대상과 아웃바운드 태그를 확인합니다. 브라우저가 기존 연결을 재사용할 수 있으므로 규칙을 바꾼 뒤 페이지를 새로고침하는 것만으로는 새 라우팅이 적용되지 않을 수 있습니다. 필요하다면 해당 앱을 완전히 종료한 뒤 다시 시도하세요. 결과가 예상과 다르면 테스트를 위해 대상 규칙을 잠시 앞쪽으로 옮기세요. 적용되는 것을 확인한 뒤 적절한 위치로 되돌리세요. 다른 규칙의 범위가 지나치게 넓은 문제를 영구적으로 맨 앞 배치로 덮어서는 안 됩니다.

DNS 설정 최적화와 조회 경로

누가 조회하는지, 요청이 어디서 나가는지부터 확인하세요

한 번 접속할 때 앱 자체 조회, 시스템 조회, 클라이언트 내장 DNS, 프록시 서버 측 조회가 모두 관여할 수 있습니다. 클라이언트에 원격 DNS를 입력했다고 모든 앱의 조회가 자동으로 그쪽으로 전달되는 것은 아닙니다. 브라우저의 보안 DNS, 앱 내장 확인자, 시스템 캐시가 예상한 경로를 우회할 수 있습니다. 문제를 살펴보기 전에 테스트 앱, 트래픽 가로채기 방식, 대상 도메인을 먼저 정리해 서로 다른 계층의 조회를 혼동하지 마세요. 웹 접속 시 보이는 출구 주소만으로는 조회 경로가 올바른지 확인할 수 없습니다.

직접 연결용 DNS와 원격 DNS는 용도에 따른 구분이지 단순한 지리적 구분이 아닙니다. 직접 연결 대상은 중국 본토에서 접속하기 적합한 주소를 반환해야 하고, 프록시 대상은 프록시 접속 경로에 맞는 주소를 반환해야 합니다. 조회 결과가 지역에 따라 크게 다르다면 잘못된 DNS 경로 때문에 콘텐츠 전송 네트워크가 실제 출구와 맞지 않는 대상을 선택할 수 있습니다. 먼저 클라이언트 기본 설정으로 작동 기준을 만든 다음 대상 범위에 따라 조회를 나누세요. 처음부터 여러 확인자와 복잡한 폴백, 특수 조회 정책을 동시에 적용하지 마세요.

조회 정책과 라우팅 정책은 따로 확인하세요

아래는 공개 DNS 주소를 사용하고 IPv4 조회 결과를 우선하도록 제한한 핵심 DNS 설정 예시입니다. servers와 queryStrategy의 위치를 설명하기 위한 것으로, 모든 네트워크에 권장되는 설정은 아닙니다. 공개 DNS 주소에 실제 환경에서 접속할 수 있는지 테스트해야 합니다. 이 설정만으로 시스템 DNS가 가로채지거나 조회가 자동으로 프록시를 통과하지는 않습니다. 클라이언트에서 DNS 아웃바운드 경로를 별도로 설정해야 합니다.

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

UseIPv4는 해당 DNS 모듈이 선택하는 조회 결과에 영향을 줍니다. 운영체제의 IPv6를 끄거나 앱이 다른 확인자를 통해 IPv6 주소를 얻지 못하게 하는 설정은 아닙니다. 네트워크에서 IPv4와 IPv6를 모두 사용할 수 있다면 동작을 이해한 뒤 적절한 정책을 선택하세요. 특정 IPv6 연결만 실패한다면 먼저 시스템 라우팅, 프록시 아웃바운드, 서버 연결 중 어디의 문제인지 확인하세요. 주소 체계를 전역에서 끄면 증상을 일시적으로 피할 수는 있어도 실제 설정 누락을 감출 수 있습니다.

라우팅의 도메인 정책과 DNS 조회 정책은 서로 다른 계층에 있습니다. 전자는 라우팅 판단을 위해 대상 도메인을 언제 조회할지 결정하고, 후자는 DNS 모듈이 어떤 방식으로 조회할지 정합니다. 도메인 목록으로 트래픽을 분기할 때는 먼저 도메인 규칙을 적용하고, 실제로 주소 조건이 필요한 연결만 조회하는 편이 좋습니다. 모든 요청을 미리 조회하면 주소 규칙이 원래 도메인 기준으로 처리하려던 대상에 영향을 줄 수 있습니다. 변경 후에는 웹페이지가 열리는지만 보지 말고 도메인 매칭 결과와 최종 연결 주소도 함께 확인하세요.

암호화 DNS에도 연결 가능한 네트워크 경로가 필요합니다

암호화 DNS는 조회 전송을 보호하지만 DNS 서비스 자체와도 연결할 수 있어야 합니다. DNS 서비스 주소가 도메인이라면 먼저 해당 주소를 조회해야 합니다. 그 연결을 프록시로 보내도록 설정했다면 프록시 서버의 도메인도 아직 작동하지 않는 DNS에 의존할 수 있습니다. 이런 순환 의존성은 클라이언트는 정상적으로 시작되지만 새 도메인 접속이 계속 시간 초과되는 문제로 나타날 수 있습니다. 해결하려면 명확한 초기 조회 경로를 마련하고 프록시 서버 주소가 독립적으로 조회되거나 올바르게 처리되는지 확인하세요.

클라이언트의 ‘프록시를 통해 조회’, ‘원격 DNS’ 같은 옵션은 현재 코어와 생성되는 설정을 기준으로 해석해야 합니다. 이름만 보고 모든 조회가 특정 출구를 이용한다고 단정하지 마세요. 도메인에 따라 확인자를 선택한다면 일치하는 항목이 없을 때 어떤 기본 서버를 쓰는지, 실패 시 폴백하는지, 폴백으로 기존 경로 요구가 달라지는지도 확인하세요. 확인자를 추가한다고 항상 신뢰성이 높아지는 것은 아닙니다. 같은 도메인에 서로 다른 응답이 생길 수도 있습니다.

검증할 때는 일반 도메인 하나를 정하고 시스템 조회 결과를 기록한 뒤 대상 앱에서 새 연결을 만드세요. 터미널 조회는 해당 터미널 도구가 사용하는 경로만 보여 주며, 브라우저는 보안 DNS를 별도로 사용할 수 있습니다. 설정을 바꾼 뒤에는 캐시가 만료될 때까지 기다리거나 영향 범위를 확인한 후 관련 캐시를 비우세요. 테스트할 때마다 서버 노드를 바꾸면 출구와 DNS가 동시에 달라져 어떤 변경이 결과에 영향을 줬는지 알기 어렵습니다.

LAN 장치 이름, 사내 도메인, 로컬 서비스도 확인해야 합니다. 이들은 LAN DNS에서만 응답할 수 있으므로 모두 공개 DNS로 보내면 프린터, 내부 웹페이지, 개발 환경에 접근할 수 없게 됩니다. 실제 내부 네트워크에 속하는 이름은 적절한 조회 경로를 유지하되, 알 수 없는 도메인을 모두 로컬 이름으로 취급하지 마세요. 검색 접미사를 사용하는 환경에서는 짧은 이름과 전체 도메인을 각각 테스트해 클라이언트가 기존 조회 방식을 바꾸지 않았는지 확인하세요.

TUN 모드와 시스템 트래픽 가로채기의 범위

시스템 프록시와 가상 네트워크 어댑터는 서로 다른 문제를 해결합니다

시스템 프록시는 시스템 설정을 따르는 앱에 프록시 진입점을 제공하며, 실제로 사용할지는 앱의 구현에 달려 있습니다. TUN은 가상 네트워크 인터페이스와 시스템 라우팅으로 트래픽을 가로채 시스템 프록시를 사용하지 않는 더 많은 앱도 처리 경로에 넣습니다. 두 기능은 ‘일반 모드’와 ‘가속 모드’의 차이가 아닙니다. 웹에 정상적으로 접속할 수 있다면 다른 앱이나 프로토콜 트래픽을 반드시 가로채야 하는 경우에만 TUN의 권한과 호환성을 검토하세요.

v2rayN의 TUN 기능은 관련 네트워크 스택 구성 요소에 의존할 수 있습니다. 실제 구현은 클라이언트 인터페이스와 생성된 설정을 기준으로 확인하세요. 현재 프록시 아웃바운드에서 Xray를 사용한다고 해서 임의의 TUN 인바운드 필드를 Xray 설정에 그대로 넣을 수 있는 것은 아닙니다. 코어, 트래픽 가로채기 구성 요소, 그래픽 클라이언트는 각각 역할이 다릅니다. 사용하기 전에 현재 클라이언트의 옵션 설명을 읽고 필요한 구성 요소가 준비됐는지 확인한 다음 권한, 가상 네트워크 어댑터 생성, 시스템 라우팅 설치가 성공했는지 살펴보세요.

먼저 단독으로 켠 뒤 충돌을 해결하세요

먼저 일반 프록시가 작동하는지 확인하고, 시스템 네트워크를 가로챌 수 있는 다른 도구를 끈 다음 작업을 저장하고 TUN을 켜는 순서를 권장합니다. 처음 테스트할 때 DNS, 라우팅, 노드를 동시에 바꾸지 마세요. 클라이언트가 권한 상승을 요청하면 스위치를 반복해서 누르지 말고 시스템 안내에 따라 필요한 권한을 부여하세요. 켠 뒤 로그에서 ‘인터페이스 생성 실패’, ‘라우팅 추가 실패’, ‘프록시 연결 실패’를 구분하세요. 서로 다른 계층에서 발생하는 문제라 해결 방법도 다릅니다.

Android 클라이언트는 시스템 VPN 서비스를 통해 트래픽을 가로채므로 데스크톱 가상 네트워크 어댑터의 문제 해결 절차를 그대로 적용할 수 없습니다. 같은 사용자 환경에서 VPN 서비스를 사용하는 다른 앱이 충돌을 일으킬 수도 있습니다. 앱별 프록시를 설정했다면 대상 앱이 가로채기 범위에 포함됐는지도 확인하세요. 시스템의 백그라운드 제한으로 화면을 끈 뒤 연결이 끊길 수 있으므로 먼저 끊기는 시점을 확인하고 필요한 백그라운드 실행 설정만 조정하세요. 간헐적인 연결 끊김을 모두 노드 품질 탓으로 돌리지 마세요.

라우팅 루프와 LAN 접속

TUN으로 트래픽을 가로챈 뒤에는 프록시 서버 연결에 올바른 우회 경로가 필요합니다. 연결이 다시 가상 인터페이스로 들어가면 루프가 발생해 계속 재연결되거나 리소스 사용량이 늘고 인터넷에 전혀 접속하지 못할 수 있습니다. 클라이언트가 필요한 우회를 자동 처리하는 경우가 많지만 사용자 지정 라우팅, 추가 네트워크 도구, 수동 시스템 경로 설정이 이를 방해할 수 있습니다. 이런 증상이 나타나면 먼저 TUN을 끄고 기준 상태를 복구한 다음 프록시 대상과 시스템 라우팅을 확인하세요. 예외 규칙을 계속 추가하며 해결을 시도하지 마세요.

LAN 대상은 별도로 테스트하세요. 먼저 라우터 관리 주소에 접속한 다음 파일 공유, 프린터, 내부 도메인을 확인할 수 있습니다. 사설 네트워크 대역을 주소 기준으로 제외하면 연결 경로는 해결할 수 있지만 내부 이름 조회까지 해결되는 것은 아닙니다. 반대로 DNS가 올바른 주소를 반환해도 시스템 라우팅으로 직접 연결된다는 보장은 없습니다. 여러 네트워크 대역을 사용하거나 기업 VPN에 연결했다면 제외 범위가 상대 네트워크와 겹치지 않는지도 확인하세요. 넓은 대역을 통째로 제외하면 다른 용도의 트래픽에 영향을 줄 수 있습니다.

UDP 사용 가능 여부는 트래픽 가로채기 구성 요소, 코어 설정, 노드 프로토콜, 서버 지원, 대상 네트워크까지 이어지는 전체 경로에 따라 달라지며 TUN 스위치만으로 보장되지 않습니다. 웹 요청이 성공해도 실시간 통신이나 다른 UDP 서비스가 정상이라는 뜻은 아닙니다. 실제 대상 앱으로 테스트하고 특정 네트워크에서만 실패하는지 살펴보세요. TCP는 정상인데 UDP만 실패한다면 시스템 프록시 옵션을 계속 바꾸기보다 프로토콜 지원 여부와 관련 로그부터 확인하세요.

네트워크를 바꾼 뒤에도 다시 테스트해야 합니다. Wi-Fi에서 유선으로 전환하거나 절전 모드에서 복귀하거나 기업 네트워크에 연결하면 기본 게이트웨이, 인터페이스 우선순위, DNS가 달라질 수 있습니다. 클라이언트가 라우팅을 제대로 다시 설정하지 못하면 이전 상태가 연결에 계속 영향을 줍니다. 먼저 트래픽 가로채기를 중지했다가 다시 켜고 인터페이스 상태가 복구되는지 확인하세요. 확인 없이 시스템의 가상 네트워크 어댑터를 전부 삭제하지 마세요. 다른 정상적인 네트워크 도구에 영향을 주고 복구도 어려워질 수 있습니다.

FakeDNS 매핑과 도메인 복원

가상 주소는 매핑을 위한 인덱스이지 대상 서버가 아닙니다

FakeDNS는 조회된 도메인에 관리되는 가상 주소를 반환하고 도메인과 주소의 매핑을 저장합니다. 앱이 이 주소에 연결하면 트래픽 가로채기 경로가 매핑을 바탕으로 도메인을 복원해 이후 라우팅이나 프록시 연결에서 도메인 정보를 사용합니다. 이 주소는 웹사이트의 실제 주소도, 공용 네트워크에서 사용하는 실제 출구도 아닙니다. 앱이 특수 대역의 주소를 받았다고 곧바로 DNS 오류로 판단하지 마세요. 매핑이 올바르게 복원됐는지, 실제 연결이 예상한 아웃바운드에서 만들어지는지 이어서 확인해야 합니다.

FakeDNS는 조회와 이후 연결을 모두 제어할 수 있는 환경에 적합합니다. DNS 조회만 FakeDNS로 들어오고 연결은 클라이언트를 우회하면 가상 주소로 예상대로 접속할 수 없습니다. 반대로 연결만 클라이언트로 들어오고 조회는 다른 확인자가 처리하면 대응하는 매핑이 만들어지지 않습니다. 사용하기 전에 TUN이나 다른 투명 트래픽 가로채기의 기본 동작부터 검증하세요. 명시적 프록시가 이미 도메인을 전달할 수 있다면 이 계층을 추가할 필요가 없을 수도 있습니다. 구성 요소가 늘면 관리해야 할 상태도 많아집니다.

코어 주소 풀, DNS 서비스, 스니핑을 함께 설정하세요

아래는 해당 필드를 지원하는 코어에서 주소 풀을 정의하고 FakeDNS를 DNS 서비스로 사용하는 예시입니다. 일부 설정만 보여 주는 예시이며, 매핑을 복원할 수 있는 인바운드, 올바른 라우팅, DNS 트래픽 가로채기와 함께 사용해야 의미가 있습니다. 해당 필드를 지원하지 않는 네트워크 스택 설정에 그대로 넣지 마세요. 클라이언트가 이미 FakeDNS 설정을 생성했다면 수동 설정과 자동 설정이 동시에 적용되지 않도록 인터페이스 옵션을 우선 사용하세요.

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

예시 주소 풀은 벤치마크용으로 예약된 주소 범위를 사용합니다. 모든 환경에서 다른 용도로 쓰이지 않는다는 뜻은 아닙니다. 일부 기업 네트워크, 테스트 환경, 다른 트래픽 가로채기 도구에서도 사용할 수 있습니다. 활성화 전에 로컬 라우팅과 기존 설정을 확인해 주소가 겹치지 않도록 하세요. 주소 풀 용량은 매핑 리소스를 관리하기 위한 값이며 클수록 좋은 것이 아닙니다. 연결 가능한 노드 수를 뜻하는 것도 아닙니다. 용량은 리소스 사용량과 활성 도메인 규모에 따라 달라지므로 예시 값을 성능 최적화 결과로 간주하지 마세요.

FakeDNS 스니핑 복원을 지원하는 인바운드가 있다면 기존 인바운드 객체에 다음 sniffing 필드를 합칠 수 있습니다. 여기서는 필드 구조만 보여 주며 수신 주소나 포트는 추가하지 않습니다. 트래픽 가로채기 구성 요소가 다른 설정 형식을 사용한다면 해당 구현 방식에 따라야 합니다. 스니핑만 켜서는 DNS 트래픽 가로채기를 대체할 수 없으며 이미 사라진 매핑을 새로 만들 수도 없습니다. 검증할 때는 조회, 가상 주소, 이후 연결을 하나의 연속된 과정으로 관찰하세요.

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

캐시, 재시작, 혼합 조회의 한계

FakeDNS 매핑은 일반적으로 실행 중에만 유지되는 상태입니다. 코어를 재시작해도 앱에는 이전에 받은 가상 주소가 캐시되어 있을 수 있지만 새 프로세스에는 해당 매핑이 없습니다. 이때 일부 앱은 실패하고 다시 열면 복구되는 일이 생길 수 있습니다. 문제를 확인할 때는 영향을 받는 앱의 기존 연결과 새 연결을 먼저 종료하고, 필요하면 관련 DNS 캐시를 정리한 뒤 다시 조회하고 접속하세요. 주소 풀 전체를 바로 바꾸면 오래된 캐시와 새 매핑이 뒤섞여 원인을 파악하기 더 어려워집니다.

브라우저나 앱에 내장된 암호화 조회가 FakeDNS를 우회하면 앱마다 서로 다른 유형의 주소를 받을 수 있습니다. 모든 설정이 실패했다는 뜻은 아니지만 한 앱의 결과만으로 시스템 전체를 판단할 수는 없습니다. 도메인 기준으로 일괄 분기하려면 앱의 조회 설정과 트래픽 가로채기 범위를 확인하세요. 대상 앱이 자체 조회 방식을 사용해야 한다면 도메인을 식별할 다른 경로가 있는지 확인하고, 주소 규칙으로만 처리될 수 있는 범위도 고려해야 합니다.

LAN 서비스에 가상 주소를 무분별하게 반환해서도 안 됩니다. 내부 이름은 LAN DNS의 검색 접미사나 특수 레코드에 의존할 수 있고, 일부 앱은 조회 결과 주소를 직접 비교합니다. 먼저 내부 도메인이 실제 주소로 조회되도록 설정한 뒤 적합한 외부 대상에 FakeDNS를 적용하세요. 실제 주소가 필요한 진단 도구, 주소 기반 접근 제어, 일부 장치 검색 기능은 각각 따로 테스트해야 합니다. 웹페이지 접속 하나로 모든 서비스가 정상이라고 판단하지 마세요.

FakeDNS를 끌 때는 DNS 서비스 선택, 매핑 복원 설정, 관련 라우팅도 함께 되돌린 다음 앱이 실제 주소를 다시 조회하도록 하세요. 주소 풀만 끄고 가상 주소를 반환하는 조회 경로를 남겨 두면 설정이 일부만 비활성화된 상태가 됩니다. 복구 후 일반 도메인이 예상대로 실제 주소를 반환하는지, 기존 라우팅도 계속 작동하는지 확인하세요. FakeDNS를 켰을 때만 문제가 발생한다면 일반 DNS 기준 설정을 보존하고 구간별로 점검하세요. 노드가 사용할 수 없다고 단정하지 마세요.

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

출처별로 분리한 다음 용도에 따라 정리하세요

여러 구독을 하나의 거대한 서버 목록으로 단순히 합치지 마세요. 출처마다 업데이트 주기, 이름 규칙, 사용 가능한 범위가 다를 수 있습니다. 먼저 출처별로 그룹을 분리하고 일상적인 선택에 필요한 항목은 검색이나 필터로 찾으세요. 한 출처의 업데이트에 문제가 생겨도 해당 그룹만 비활성화하거나 다시 가져오면 다른 그룹에 영향을 주지 않습니다. 용도는 그룹 메모에 적을 수 있지만 제공업체의 홍보 문구를 검증된 기능 설명으로 간주하지 마세요.

구독 주소와 서버 공유 링크는 서로 다른 정보입니다. 구독 주소는 여러 항목을 계속 가져오는 데 사용하고, 서버 공유 링크는 보통 서버 하나를 설명합니다. 단일 노드 링크를 구독 업데이트 입력란에 넣으면 파싱에 실패할 수 있고, 구독 내용을 단일 노드로 가져오면 관리 관계가 사라질 수 있습니다. 새 출처를 추가하기 전에 콘텐츠 유형을 확인하고 적절한 메뉴를 선택하세요. 테스트가 끝나면 용도와 최근 확인 결과만 기록하세요. 접속 인증 정보가 포함된 전체 주소를 공개 메모에 저장하지 마세요.

자동 업데이트에는 사용할 수 있는 가져오기 경로가 필요합니다

자동 업데이트가 되려면 클라이언트가 실행 중이고 작업이 수행될 수 있어야 하며, 구독 서비스에 접속할 수 있고 요청에 사용되는 네트워크 경로도 올바라야 합니다. 시스템이 절전 중이거나 클라이언트가 종료된 상태에서도 계속 업데이트된다는 뜻은 아닙니다. 업데이트 주기는 제공업체가 허용하는 요청 빈도와 실제 필요를 고려해 정하세요. 지나치게 자주 새로고침하지 마세요. 일시적으로 요청이 제한되면 수동 클릭을 반복하지 말고 오류 유형을 확인한 뒤 잠시 후 다시 시도하고, 현재 사용할 수 있는 서버 항목은 보존하세요.

업데이트에 프록시가 필요하다면 현재 활성 노드가 이번 업데이트를 통해서만 복구되는 상황이 아닌지 확인하세요. 검증된 예비 출처를 남겨 둘 수 있지만 목록에 있다는 이유만으로 사용할 수 있다고 판단해서는 안 됩니다. 업데이트 서비스가 직접 연결로 접속 가능하다면 먼저 해당 경로를 테스트하세요. 핵심은 순환 의존성을 줄이는 것입니다. 노드 목록 가져오기, 프록시 서버 조회, 프록시 연결이 아직 준비되지 않은 한 단계에 서로 의존해서는 안 됩니다.

업데이트 후에는 성공 메시지만 보지 말고 실제 변경 사항을 확인하세요. 활성 서버가 남아 있는지, 이름이 바뀌었는지, 프로토콜 매개변수가 교체됐는지, 필터 조건 때문에 목록이 크게 줄었는지 살펴보세요. 제공업체가 항목을 삭제해도 클라이언트가 원래 용도에 맞는 대체 항목을 자동으로 선택하지 않을 수 있습니다. 직접 다시 선택하고 새 연결을 만들어야 합니다. 오래 실행 중인 앱은 연결을 새로 만들 때까지 업데이트 전 경로를 계속 사용할 수 있다는 점도 유의하세요.

같은 노드처럼 보여도 중복 항목을 임의로 삭제하지 마세요

구독마다 표시 이름은 같지만 실제로 다른 서버일 수 있고, 이름은 달라도 같은 서비스를 가리킬 수 있습니다. 중복 여부는 메모만 비교하지 말고 프로토콜, 서버 주소, 포트, 전송 설정을 함께 확인하세요. 기술 매개변수가 같더라도 서로 다른 관리 출처에 속한 항목일 수 있습니다. 삭제 후 다음 업데이트 때 다시 나타날지는 구독 관리 방식에 달려 있습니다. 우선 그룹과 필터로 목록을 정리하고, 확인되지 않은 항목을 큰 목록에서 한꺼번에 삭제하지 마세요.

직접 수정한 서버는 원격 구독 항목과 분리하세요. 전송 매개변수를 바꿔야 한다면 허용 여부를 확인한 뒤 수동 항목으로 복사하고 용도를 명확히 표시할 수 있습니다. 원격 출처가 나중에 바뀌어도 수동 복사본은 자동으로 갱신되지 않으므로 직접 다시 확인해야 합니다. 복사본을 보존하는 목적은 올바른 업데이트를 장기간 우회하는 것이 아니라 테스트 변수를 통제하는 데 있습니다. 테스트가 끝나면 더 이상 사용하지 않는 복사본을 정리해 오래된 설정을 잘못 선택하지 않도록 하세요.

데스크톱과 휴대폰에서 같은 출처를 가져와도 필터 규칙, 활성 노드, 라우팅 설정이 자동으로 일치하는 것은 아닙니다. v2rayN, v2rayNG, v2flyNG는 구독 형식과 매개변수 지원에 차이가 있을 수 있으므로 한 기기에서 사용할 수 있다고 다른 기기에서도 완전히 호환되는 것은 아닙니다. 기기 간 문제를 확인할 때는 먼저 프로토콜과 전송 조건을 맞춘 뒤 각각 검증하세요. 인증 정보가 포함된 전체 설정을 보내 화면을 비교하지 마세요. 필요하면 민감한 값을 제거한 필드 이름만 비교하세요.

백업을 내보내기 전에 어떤 데이터가 포함되는지 확인하세요. 서버 설정, 구독 주소, 인증 정보는 민감할 수 있으므로 접근이 제한된 위치에 백업 파일을 보관해야 합니다. 다른 기기에 복원한 뒤에는 로컬 수신 포트, 네트워크 어댑터 권한, 시스템 프록시 상태도 다시 확인하세요. 구독 복사만으로 이런 환경 정보까지 해결되지는 않습니다. 오래된 기기를 정리할 때는 더 이상 필요하지 않은 설정도 삭제해 사용하지 않는 클라이언트 디렉터리에 계정 정보가 남지 않도록 하세요.

사용자 지정 아웃바운드와 설정 범위

아웃바운드 태그는 라우팅이 연결되는 지점입니다

아웃바운드는 코어에서 연결이 나가는 방식을 정의하고, 라우팅은 태그를 이용해 해당 아웃바운드를 선택합니다. 태그는 로컬에서 참조하는 이름일 뿐 프로토콜이나 지역을 자동으로 식별하지 않습니다. 이름을 “direct”로 지정해도 실제 직접 연결이 보장되지 않으며, 동작은 객체의 프로토콜과 설정으로 결정됩니다. 새 아웃바운드를 추가하기 전에 기존 태그를 확인해 이름이 겹치지 않는지, 라우팅이 예상한 객체를 가리키는지 살펴보세요. 태그의 오타는 설정 검사 실패나 예상 경로 연결 실패로 이어질 수 있습니다.

일반적인 클라이언트 설정에는 프록시, 직접 연결, 차단 등의 아웃바운드가 이미 생성되어 있습니다. 특정 도메인만 직접 연결하고 싶다면 같은 기능의 아웃바운드를 새로 만들기보다 라우팅 규칙을 추가하세요. 사용자 지정 아웃바운드는 특정 트래픽을 관리되는 로컬 프록시 서비스로 보내는 경우처럼 연결 방식을 실제로 달리해야 할 때 적합합니다. 이 경우에도 클라이언트가 사용자 지정 필드를 병합할 수 있는지, 노드를 바꿀 때 수동 설정을 덮어쓰는지 먼저 확인하세요.

기본 객체 구조부터 이해하세요

아래 예시는 직접 연결과 차단 아웃바운드의 기본 객체 구조이며 해당 프로토콜을 지원하는 코어에서 사용할 수 있습니다. 프록시 서버를 포함하지 않으며 클라이언트 설정 전체를 대체하지도 않습니다. 기존 설정에 같은 태그가 있으면 다시 추가하지 마세요. 매칭되는 라우팅 규칙이 없는 트래픽은 첫 번째 아웃바운드를 사용할 수 있다는 점도 주의해야 합니다. 예시 배열을 그대로 교체하면 기본 경로가 프록시에서 직접 연결로 바뀔 수 있습니다.

{
  "outbounds": [
    {
      "tag": "direct",
      "protocol": "freedom",
      "settings": {}
    },
    {
      "tag": "block",
      "protocol": "blackhole",
      "settings": {}
    }
  ]
}

차단 아웃바운드는 특정 연결을 명확하게 거부할 때 사용하며 네트워크 문제를 해결하는 기능이 아닙니다. 테스트 중 범위가 지나치게 넓은 도메인이나 주소 목록을 차단 아웃바운드로 보내면 일부 페이지 리소스가 무작위로 누락된 것처럼 보일 수 있습니다. 먼저 대상 하나에 적용한 뒤 범위를 넓히세요. 직접 연결 아웃바운드도 모든 시스템 설정을 우회한다는 보장은 없습니다. 운영체제 라우팅, 방화벽, 하위 네트워크 조건의 영향을 받습니다. 코어가 아웃바운드를 선택했다는 것은 경로 결정이 끝났다는 뜻일 뿐입니다.

다른 로컬 프록시에 연결할 때 자기 자신을 참조하지 않도록 하세요

다른 로컬 프록시를 통해 전달해야 한다면 해당 서비스가 실제로 수신 대기 중인지, 프로토콜, 주소, 포트, 인증 요구 사항이 맞는지 먼저 확인하세요. 수신 주소가 로컬 루프백인지 LAN 주소인지에 따라 접속할 수 있는 대상이 달라집니다. 편의를 위해 수신 범위를 모든 네트워크 인터페이스로 확대하지 마세요. LAN 접속이 꼭 필요하다면 시스템 방화벽과 접근 제어도 함께 검토해 로컬 전용 진입점이 관련 없는 장치에 노출되지 않도록 하세요.

가장 흔한 실수는 사용자 지정 아웃바운드가 현재 클라이언트 자신의 프록시 수신 포트로 다시 연결되는 것입니다. 연결이 클라이언트로 들어온 뒤 같은 아웃바운드를 다시 선택하면 루프가 생깁니다. 포트가 같다고 같은 서비스라는 뜻은 아니므로 수신 프로세스와 전체 처리 경로를 확인하세요. 다단계 프록시를 쓸 때는 각 홉을 그려 어느 단계에서 도메인을 조회하고, 어느 단계에서 UDP를 처리하며, 최종 연결을 누가 만드는지 명확히 하세요. 경로가 길수록 홉마다 검증하는 것이 중요합니다.

프록시 프로토콜마다 도메인, UDP, 인증 처리 방식이 다릅니다. 상위 프록시에서 일반 웹 프록시를 사용할 수 있다고 해서 모든 앱 트래픽도 지원하는 것은 아닙니다. 로컬 상위 프록시가 특정 요청만 받는다면 라우팅 범위를 검증된 용도로 제한하세요. 다른 구성 요소의 아웃바운드 객체를 현재 코어에 그대로 붙여 넣어서도 안 됩니다. 필드 이름이 비슷해도 설정 형식이 호환된다는 뜻은 아닙니다. 코어 이름과 문서의 의미를 확인한 뒤 설정 검사와 시작 로그로 올바르게 적용됐는지 판단하세요.

클라이언트에서 서버를 바꾸거나 구독을 업데이트하거나 라우팅을 수정하면 실행 설정이 다시 생성될 수 있습니다. 이때 임시 파일에 직접 추가한 아웃바운드가 사라질 수 있습니다. 클라이언트가 공식 지원하는 사용자 지정 설정 입력란을 우선 사용하고 객체를 추가하는 방식인지 전체 필드를 교체하는 방식인지 기록하세요. 전체 사용자 지정 설정을 사용하면 활성 서버 선택 같은 그래픽 기능이 일반적인 방식으로 동작하지 않을 수도 있습니다. 설정하기 전에 이 범위를 확인해 인터페이스에서는 전환된 것처럼 보여도 실제로는 고정 설정이 실행되는 일을 방지하세요.

사용자 지정 아웃바운드를 검증할 때는 테스트 도메인 하나만 해당 아웃바운드에 매칭시키고 로그의 태그와 상위 프록시 연결을 확인한 뒤 범위를 단계적으로 넓히세요. 실패하면 대상 규칙이 일치했는지, 상위 프록시가 수신 가능한지, 인증이 맞는지, 도메인을 조회할 수 있는지 순서대로 확인합니다. 여러 계층을 한꺼번에 바꾸지 마세요. 복구할 때는 테스트 라우팅을 되돌리고 더 이상 참조하지 않는 아웃바운드를 제거한 뒤 기본 프록시와 직접 연결 규칙의 순서와 동작이 유지되는지 확인하세요.

설정 검증, 문제 진단, 복구

‘시작할 수 있음’과 ‘예상대로 작동함’을 나누어 확인하세요

설정 검사를 통과해도 구조와 일부 필드가 코어 요구 사항에 맞는다는 뜻일 뿐, 구독 서비스에 접속할 수 있거나 프록시 노드를 사용할 수 있거나 라우팅 결과가 올바르다는 보장은 없습니다. 전체 검증은 클라이언트 시작, 코어 실행, 인바운드 트래픽 가로채기, 라우팅 매칭, 조회 경로, 실제 서비스 접속 순으로 진행해야 합니다. 각 계층에서 확인할 증거가 다르므로 웹페이지 요청 하나의 성공으로 전체를 판단할 수 없습니다. 특히 TUN과 FakeDNS는 시스템 상태와 실행 중 매핑을 함께 다루므로 단계별 확인이 필요합니다.

변경을 시작하기 전에 기준 상태를 기록하세요. 사용 중인 클라이언트와 코어, 활성 서버, 시스템 프록시 상태, TUN 상태, 라우팅 모드, 접속할 수 있는 테스트 대상 하나를 정리합니다. 설정 이름과 동작만 기록하고 서버 주소나 인증 정보는 공개하지 마세요. 이번 변경의 목표를 “지정 도메인을 직접 연결”처럼 명확하게 한 문장으로 적으세요. 목표가 구체적일수록 검증하기 쉽습니다. ‘네트워크 전반 최적화’처럼 범위가 넓으면 변경이 실제로 효과가 있었는지 판단하기 어렵습니다.

증상에 맞춰 가장 짧은 진단 경로를 선택하세요

클라이언트가 시작되지 않으면 DNS를 계속 조정하지 말고 실행 환경, 디렉터리 권한, 설정 파일 읽기 문제부터 해결하세요. 클라이언트는 시작하지만 코어가 종료된다면 최근 수정한 필드와 태그, 포트 충돌을 확인하세요. 코어는 정상적으로 실행되는데 앱이 프록시를 전혀 사용하지 않는다면 시스템 프록시, 앱 설정, 트래픽 가로채기 범위를 점검해야 합니다. 트래픽이 코어에 들어온 뒤에야 라우팅과 아웃바운드를 분석할 수 있습니다. 문제를 올바른 계층에서 다루면 모든 구성 요소를 한 번에 재설치하는 것보다 효과적입니다.

지연 시간 테스트와 실제 연결 테스트도 구분해서 해석하세요. 테스트는 특정 대상을 특정 요청 방식으로 확인할 수 있으므로 모든 프로토콜과 서비스가 정상이라는 뜻은 아닙니다. 테스트가 성공해도 실제로 필요한 대상에 접속해 출구와 라우팅이 예상대로인지 확인해야 합니다. 사이트 하나만 실패하면 프록시 경로 전체가 끊겼다고 판단하기 전에 해당 사이트의 관련 도메인과 연결 유형을 확인하세요. 페이지 본문은 열리는데 이미지나 로그인이 실패한다면 리소스별 라우팅을 점검해야 할 수 있습니다.

로그는 시간과 한 번의 요청을 기준으로 확인하세요. 테스트를 시작한 시각을 기록한 다음 해당 대상, 인바운드, 아웃바운드 태그를 찾습니다. DNS 조회 실패, 연결 거부, 연결 시간 초과, 인증 실패는 각각 다른 원인을 가리킵니다. 연결 거부는 상대방이 명시적으로 거부했거나 포트에서 서비스가 수신 대기 중이지 않다는 뜻인 경우가 많습니다. 시간 초과는 경로, 방화벽, 원격 응답 문제일 수 있습니다. 로그 정보가 부족하면 문제를 진단하는 동안만 상세도를 높이고, 완료 후에는 민감한 대상 정보가 장기간 쌓이지 않도록 원래 수준으로 되돌리세요.

복구도 의존 관계에 따라 진행하세요

이번 변경에 여러 계층이 포함됐다면 새 서비스 연결을 먼저 중단한 뒤 가장 바깥쪽의 트래픽 가로채기나 추가 규칙을 되돌리고 DNS와 아웃바운드 기준 설정을 복원하세요. FakeDNS를 끌 때는 앞서 설명한 대로 매핑 관련 설정과 앱 캐시도 함께 처리해야 합니다. TUN 문제는 먼저 일반 시스템 네트워크를 복구한 다음 클라이언트 프록시를 확인하세요. 잘못된 트래픽 가로채기 상태를 유지한 채 서버를 계속 바꾸지 마세요. 사용 가능 상태를 복구하지 못하고 새로운 변수만 늘어납니다.

복구 후에는 스위치가 꺼진 것만 확인하지 말고 다시 테스트해야 합니다. 클라이언트가 관련 코어를 중지했거나 올바른 설정을 다시 불러왔는지, 시스템 프록시가 실제 수신 중인 주소를 가리키는지, 일반 웹과 LAN 접속이 모두 복구됐는지 확인하세요. 클라이언트를 종료한 뒤에도 프록시 설정이 남아 있다면 시스템 네트워크 설정에서 확인하세요. 오래된 진입점을 가리기 위해 두 번째 클라이언트를 실행하지 마세요. 기준 상태를 다시 사용할 수 있게 된 뒤에야 방금 실패한 설정을 다시 추가하고 변경 범위를 최소화해야 합니다.

추가로 도움을 요청할 때는 클라이언트 이름, 플랫폼, 사용 코어, 최소 재현 절차, 민감 정보를 제거한 오류 요약을 제공하세요. 구독 링크, 인증 필드, 전체 서버 설정, 사설 도메인이 포함된 로그를 그대로 보내지 마세요. 스크린샷을 찍기 전에 주소 표시줄, QR 코드, 클립보드 알림을 확인하세요. 시작하자마자 종료되는 문제는 v2rayN 실행 안 됨 및 비정상 종료 해결을 참고하세요. 시작 문제와 연결 문제를 하나의 원인으로 혼동하지 마세요.

안정적인 설정은 설명하고 검증하고 복구할 수 있어야 합니다. 스위치를 계속 추가하기보다 필요한 구독 그룹, 명확한 라우팅 순서, 현재 네트워크에 맞는 조회 경로를 유지하는 편이 관리하기 쉽습니다. 새 기기에서는 빠른 시작 가이드에 따라 연결을 다시 설정한 뒤 이해한 규칙을 옮기세요. 용어가 궁금하면 개념 빠른 참조를 확인하세요. 기능을 한 번에 하나씩 추가하고 효과와 사용 범위를 확인한 뒤 유지해야 이 가이드를 반복해서 활용할 수 있는 운영 기준으로 삼을 수 있습니다.