v2rayN
고급 설정 가이드

구독 그룹과 서버 필터

구독 그룹은 구독 출처를 구분하고, 서버 필터는 목록을 걸러냅니다. 둘 다 서버 연결 품질을 자동으로 높이거나 라우팅을 대신하지는 않습니다. 먼저 구독 주소 하나를 알아보기 쉬운 이름의 그룹에 추가하고, 업데이트 후 서버가 표시되는지 확인한 다음 필터 조건을 설정하세요. 그룹 생성, 주소 변경, 정규식 적용을 한꺼번에 하면 목록이 비었을 때 어느 단계에서 문제가 생겼는지 판단하기 어렵습니다.

그룹을 만들고 업데이트 경로 지정하기

v2rayN의 구독 그룹 설정에서 새 그룹을 추가하고 알아보기 쉬운 설명과 구독 주소를 입력한 뒤 저장하고 기본 창으로 돌아갑니다. 해당 그룹을 선택한 다음 구독 업데이트를 실행하세요. 제공업체가 안내한 경로와 쿼리 매개변수를 포함해 주소 전체를 그대로 입력합니다. 메신저에서 복사할 때 따옴표, 줄바꿈, 문장 끝 마침표가 붙지 않도록 주의하세요. 구독 주소에는 보통 접근 정보가 포함되므로 전체 주소를 스크린샷이나 로그, 공개 게시물에 올리지 마세요.

업데이트 방식의 ‘프록시 사용’과 ‘프록시 사용 안 함’은 구독 내용을 가져올 때 요청이 어떤 경로를 이용할지만 정합니다. 업데이트된 모든 서버의 라우팅을 지정하는 설정은 아닙니다. 현재 프록시가 연결되지 않은 상태에서 프록시를 거쳐 업데이트하도록 강제하면 순환 의존성이 생길 수 있습니다. 새 설정을 받아야 연결할 수 있는데, 설정을 받으려면 먼저 연결해야 하는 상황입니다. 우선 접속 가능한 경로로 업데이트한 뒤 가져오기에 성공하면 이후 업데이트 방식을 조정하세요.

저장 후에는 세 가지를 확인하세요. 그룹 이름이 맞는지, 구독 주소가 온전한지, 업데이트 로그에 유효한 내용이 파싱되었다고 표시되는지 확인합니다. 요청이 성공했는데 목록이 바뀌지 않았더라도 클라이언트 문제라고 단정할 수는 없습니다. 원격 서버가 같은 내용을 반환했거나 로그인 페이지 또는 안내 문구를 반환했을 수 있습니다. 요청 완료 메시지만 보지 말고 파싱 결과와 대상 그룹도 확인하세요. 필요하면 필터를 잠시 끄고 다시 확인합니다.

간단한 키워드부터 정규식 작성하기

‘서버 필터(정규식)’는 보통 서버 설명을 기준으로 일치 항목을 찾습니다. 가져오기와 목록 표시에 각각 어떻게 적용되는지는 현재 화면의 안내를 확인하세요. 실제로 존재하는 이름 일부를 먼저 입력해 테스트한 뒤 조건을 확장합니다. 처음부터 복잡한 제외 패턴을 작성하지 마세요. 정규식에서 세로줄은 ‘또는’, 괄호는 그룹화, 대괄호는 문자 집합을 뜻하며 일반 텍스트를 이어 쓰는 기호가 아닙니다.

홍콩|일본
^(홍콩|일본)
홍콩.*전용선
\[예비\]

위 네 줄은 각각 별도의 예시이므로 한 입력란에 함께 붙여 넣지 마세요. 첫 번째는 설명에 키워드 중 하나라도 포함된 항목을 찾고, 두 번째는 설명이 지정된 키워드로 시작하는 항목을 찾습니다. 세 번째는 두 문자열이 순서대로 포함된 항목을 찾고, 네 번째는 대괄호가 있는 문자열을 찾습니다. 제공업체가 이름에 다른 약어를 사용하면 결과가 없을 수 있습니다. 실제 서버 설명을 기준으로 필터를 설정하세요. 지역 이름을 모든 구독에 통하는 공통 규칙으로 간주하면 안 됩니다.

입력 오류가 나면 먼저 정규식을 지우고 저장한 뒤 서버가 다시 표시되는지 확인하세요. 그런 다음 조건을 한 부분씩 되살립니다. 마침표, 괄호, 더하기 기호를 찾으려면 해당 문자가 특별한 의미를 갖는다는 점에 유의하세요. 예를 들어 문자 그대로의 마침표는 보통 \.로 작성합니다. 클라이언트 빌드에 따라 정규식 구현이 다를 수 있으며, 특히 전방·후방 탐색, 인라인 옵션, 복잡한 그룹에서 차이가 생길 수 있습니다. 다른 환경으로 옮기기 어려운 고급 문법보다 짧고 이해하기 쉬운 표현식을 사용하세요.

필터 오류와 업데이트 실패 구분하기

필터를 적용한 뒤 서버가 보이지 않으면 ‘전체’ 또는 해당 출처 그룹으로 돌아가 검색란을 비운 다음 그룹 필터를 확인하세요. 기본 창의 검색과 구독 설정의 필터가 함께 적용될 수 있으므로 한 곳만 바꿔서는 목록이 복구되지 않을 수 있습니다. 원인이 필터인지 확인한 다음 유지할 조건을 결정하세요. 목록을 복구하려고 그룹 전체를 반복해서 삭제하지 마세요. 설명, 업데이트 방식, 기타 관리 설정까지 함께 사라질 수 있습니다.

업데이트에 실패하면 주소 유효성, 요청 경로, 응답 내용, 파싱 형식 순서로 확인합니다. 같은 주소를 한 네트워크 경로에서는 가져올 수 있지만 다른 경로에서는 실패한다면 연결과 DNS를 먼저 점검하세요. 구독 내용 대신 웹페이지가 반환되면 주소의 용도와 인증 상태를 확인합니다. 이미 가져온 서버를 사용할 수 있다면 기존 설정을 유지하고, 업데이트 실패가 전체 연결 불가로 번지지 않도록 하세요.

라우팅 규칙 실전

라우팅의 핵심은 순서에 따른 규칙 매칭입니다. 코어가 연결 대상과 사용 가능한 메타데이터를 확인하고, 일치하는 규칙을 찾으면 아웃바운드를 선택합니다. 일반적으로 구체적인 규칙을 포괄적인 규칙보다 앞에 둡니다. 설정 전에 현재 활성화된 라우팅 프리셋과 클라이언트가 시작할 때 코어 설정을 다시 생성하는지 확인하세요. 임시 생성 파일만 수정하면 서버를 바꾸거나 코어를 재시작할 때 덮어써질 수 있으므로 영구 설정으로 간주하면 안 됩니다.

아웃바운드 태그를 먼저 확인한 뒤 조건 작성하기

아래 예시는 Xray의 routing 객체 형식으로 광고 도메인 차단, 사설 주소 직접 연결, 지정된 도메인 목록 직접 연결을 보여줍니다. 완전한 설정에 direct와 block이라는 아웃바운드가 이미 정의되어 있다고 가정합니다. 클라이언트가 실제로 다른 태그를 생성한다면 해당 태그도 함께 바꿔야 합니다. 태그는 정확히 일치해야 하는 참조값이며, 의미를 자동으로 인식하는 예약된 중국어 이름이 아닙니다. 이 객체를 규칙 배열만 받는 입력란에 그대로 붙여 넣지 마세요.

{
  "routing": {
    "domainStrategy": "IPIfNonMatch",
    "rules": [
      {
        "type": "field",
        "domain": ["geosite:category-ads-all"],
        "outboundTag": "block"
      },
      {
        "type": "field",
        "ip": ["geoip:private"],
        "outboundTag": "direct"
      },
      {
        "type": "field",
        "domain": ["geosite:cn"],
        "outboundTag": "direct"
      }
    ]
  }
}

한 규칙에 서로 다른 유형의 조건을 넣으면 보통 모든 조건을 만족해야 합니다. 반면 같은 배열의 여러 후보 항목은 그중 하나가 일치하면 됩니다. 예를 들어 domain과 port를 함께 쓰면 특정 도메인이면서 포트 조건도 충족해야 한다는 뜻이지, 둘 중 하나만 맞으면 된다는 의미가 아닙니다. 도메인이나 특정 주소 대역 중 하나에 해당하면 적용하려는 경우 규칙을 두 개로 나누세요. 분리한 뒤에는 앞쪽의 포괄적인 조건이 연결을 먼저 가져가지 않는지 순서도 확인합니다.

어떤 규칙에도 일치하지 않는 트래픽을 어떻게 처리하는지는 코어의 기본 동작과 클라이언트가 생성한 전체 설정에 따라 달라집니다. 위 조각만으로 최종적으로 프록시를 거친다고 단정할 수 없습니다. Xray는 보통 규칙에 일치하지 않는 트래픽을 첫 번째 아웃바운드로 처리하지만, GUI 클라이언트가 기본 처리 규칙을 추가할 수도 있습니다. 최종 설정의 아웃바운드 순서와 마지막 규칙을 확인한 뒤 기본 경로를 명시할지 결정하세요. 설정을 검토할 때는 새로 추가한 몇 줄뿐 아니라 처음과 끝도 확인해야 합니다.

도메인, IP, 규칙 데이터베이스의 관계 이해하기

geosite는 도메인 분류이고 geoip는 주소 분류입니다. 코어가 해당 데이터 파일을 읽을 수 있고 파일 안에 분류 이름이 있어야 사용할 수 있습니다. 파일이 있다고 해서 모든 출처에 동일한 분류가 들어 있는 것은 아니며, 그럴듯한 이름을 입력한다고 분류가 자동으로 생기는 것도 아닙니다. 분류를 불러오지 못하면 데이터 파일의 출처와 저장 위치, 코어 로그를 먼저 확인하세요. 규칙 데이터 오류를 해결하려고 서버를 계속 바꾸지 마세요.

domainStrategy는 라우팅 매칭을 위해 도메인의 IP 정보를 조회할지 결정합니다. AsIs는 IP 규칙만을 위해 도메인을 능동적으로 조회하지 않습니다. IPIfNonMatch는 도메인 규칙에 일치하지 않을 때 조회를 시도하고, IPOnDemand는 IP가 필요한 매칭 과정에서 조회할 수 있습니다. 이 옵션은 조회 시점과 처리 비용을 바꾸지만, 연결에 사용할 DNS 서버를 직접 지정하지는 않습니다.

앱이 IP 주소만 프록시에 전달하면 코어에 원래 도메인 이름이 없어 도메인 규칙의 매칭 근거가 부족할 수 있습니다. 일부 트래픽은 스니핑으로 도메인을 확인할 수 있지만, 암호화된 연결 정보를 모두 복원하거나 모든 프로토콜을 식별할 수 있는 것은 아닙니다. 같은 웹사이트가 앱마다 다른 경로로 연결된다면 먼저 인바운드에 도메인과 IP 중 무엇이 전달되는지 살펴보고 스니핑과 DNS 경로를 확인하세요. 처음부터 직접 연결이나 프록시 범위를 전부 넓히지는 마세요.

이해하기 쉬운 사례로 규칙 검증하기

검증할 때는 규칙에 명시한 도메인 하나, 사설 주소 대상 하나, 규칙에 일치하지 않는 대상 하나를 골라 각각 새 연결을 만드세요. 로그에서 대상과 아웃바운드 태그를 확인해 예상한 순서로 규칙에 일치하는지 살펴봅니다. 브라우저가 기존 연결을 재사용할 수 있으므로 규칙을 바꾼 뒤 새로 고침만 해서는 경로가 바뀌지 않을 수 있습니다. 관련 연결을 끊거나 테스트 앱을 재시작한 뒤 비교하세요. 규칙 로드 성공과 실제 요청 성공은 별개이므로 둘 다 확인해야 합니다.

특정 규칙이 다른 규칙을 예상치 않게 덮어쓰면 가장 포괄적인 조건을 잠시 빼고 최소한의 규칙만 남겨 검증하세요. 특히 클라이언트 생성 규칙과 사용자 지정 규칙이 함께 있으면 포트, 네트워크 유형, 프로세스 규칙도 판단에 영향을 줄 수 있습니다. 데이터 파일 업데이트와 분류 형식은 geoip.dat 및 geosite.dat 라우팅 데이터베이스 안내에서 확인하세요. 업데이트 전후에 같은 테스트 사례로 다시 검증합니다.

DNS 설정 최적화

DNS 설정에서는 세 가지를 먼저 확인하세요. 누가 조회를 보내는지, 조회가 어디로 전달되는지, 결과를 누가 사용하는지입니다. 시스템 리졸버, 브라우저 보안 DNS, 클라이언트 내장 DNS, 라우팅 판단을 위한 코어의 조회가 동시에 존재할 수 있습니다. 클라이언트에 서버 주소 하나를 입력해도 모든 앱이 그 경로를 이용한다고 보장할 수는 없습니다. 최적화의 목표는 경로를 일관되게 유지하고 결과를 사용할 수 있게 하며 문제 원인을 파악하기 쉽게 만드는 것입니다. 설정 가능한 항목을 전부 켜는 것이 목표는 아닙니다.

DNS 서버와 조회 아웃바운드 구분하기

아래는 서버 목록과 조회 유형을 설명하기 위한 Xray dns 객체 예시입니다. queryStrategy는 내장 DNS 조회에 필요한 주소 유형을 제어하며 시스템 전체의 IPv6를 끄는 설정이 아닙니다. 예시의 암호화 DNS 엔드포인트도 테스트할 수 있는 선택지 중 하나입니다. 현재 네트워크에서 접속할 수 있는지 확인한 뒤 사용할지 결정하세요. 이 조각에는 DNS 트래픽 라우팅 설정이 없으므로 요청이 반드시 프록시를 거친다고 추론할 수 없습니다.

{
  "dns": {
    "servers": [
      "https://1.1.1.1/dns-query"
    ],
    "queryStrategy": "UseIP"
  }
}

DNS 서버 주소 지정과 조회 출구 지정은 별개의 설정입니다. 일부 코어에서는 암호화 DNS 요청이 내부 라우팅에 참여하지만, 다른 유형의 서버는 로컬 연결을 직접 사용할 수 있습니다. 클라이언트 화면에 직접 연결 DNS, 원격 DNS, 별도 아웃바운드 같은 항목이 있을 수도 있습니다. 이런 이름은 클라이언트가 기능을 감싼 방식이므로 다른 코어의 설정 필드와 기계적으로 대응시키면 안 됩니다. 먼저 사용하는 코어를 확인하고 관련 문서에 따라 최종 설정을 해석하세요.

도메인 형식의 암호화 DNS 엔드포인트를 사용하면 부트스트랩 조회도 필요합니다. DNS 서비스에 연결하기 전에 시스템이 해당 서비스의 주소를 알아야 하기 때문입니다. 부트스트랩 조회가 아직 연결되지 않은 프록시에 의존하면 순환 의존성이 발생할 수 있습니다. 고정 서비스 주소, 명확한 부트스트랩 경로, 클라이언트가 제공하는 시작 단계 조회 기능으로 해결할 수 있습니다. 목적이 불분명한 서버를 여러 개 추가하기보다는 이해하기 쉬운 방법 하나를 선택하세요.

연결 경로에 맞춰 DNS 전략 설정하기

직접 연결할 대상은 현재 네트워크에서 도달할 수 있는 주소를 받아야 하며, 프록시 대상의 조회 방식도 프록시 연결 동작과 맞아야 합니다. 일부 프로토콜은 도메인을 서버에 전달하므로 로컬 DNS가 규칙 판단에만 사용될 수 있습니다. 다른 경로는 로컬에서 먼저 주소를 조회한 뒤 연결합니다. 라우팅 판단에 사용한 결과와 실제 연결에 사용한 결과가 다르면 예상한 분기와 실제 접속이 달라질 수 있으므로 도메인 유지 방식도 함께 확인해야 합니다.

IPv6 문제가 발생하면 먼저 네트워크에서 사용할 수 있는 IPv6 경로가 있는지 확인한 뒤 주소 선호도를 정하세요. DNS 응답에 AAAA 레코드가 있다는 것 자체는 오류가 아닙니다. 앱이 도달할 수 없는 주소를 선택했을 때 대기하거나 다른 주소로 전환하는 문제가 나타날 수 있습니다. IPv4만 조회하도록 잠시 바꾸는 것은 비교 테스트로 쓸 수 있지만 모든 네트워크에 영구 적용할 해결책은 아닙니다. 프록시 서버, 직접 연결 경로, TUN에서 IPv6를 일관되게 처리하는지도 확인하세요.

브라우저에서 자체 보안 DNS를 사용하면 시스템의 일반 DNS 설정을 우회할 수 있습니다. 앱이 이미 설정된 암호화 연결을 통해 조회하면 일반 DNS 포트 트래픽으로 보이지 않을 수도 있습니다. 문제를 해결할 때는 먼저 이 설정들을 기록한 다음 조회 경로를 잠시 통일하세요. 클라이언트 경로가 정상인지 확인한 뒤 앱 설정을 하나씩 복구하면서 차이를 비교합니다. 시스템 네트워크 설정을 한꺼번에 초기화하지 마세요. 접속이 복구되더라도 실제 원인을 파악하기 어려워집니다.

‘조회 성공·연결 성공·라우팅 정상’ 순서로 검증하기

먼저 로그에서 조회가 예상한 리졸버에 도달했는지 확인하고, 사용 가능한 주소가 반환되는지 살핀 다음 연결이 지정한 아웃바운드를 이용하는지 검증하세요. 명령줄에서 확인한 시스템 조회 결과는 시스템 계층만 보여주며 브라우저 내부 조회나 코어 내부 DNS까지 나타내지는 않습니다. 진단 기록에는 테스트 앱, 대상 도메인, 프록시 모드, 테스트 시각을 적어 서로 다른 경로의 결과를 혼동하지 않도록 합니다.

DNS를 변경해도 이전 캐시나 연결 풀이 기존 결과를 계속 사용할 수 있습니다. 먼저 테스트 앱을 종료하고 관련 캐시를 지우세요. 필요하면 클라이언트 코어를 재시작한 다음 같은 대상으로 다시 테스트합니다. 특정 도메인만 실패하면 도메인 규칙과 DNS 응답을 먼저 확인하세요. 모든 도메인이 실패하지만 IP 연결은 된다면 리졸버에 접속할 수 있는지와 부트스트랩 경로를 점검합니다. 일반 연결이 안정되지 않은 상태에서 FakeDNS를 추가하지 마세요.

TUN 모드

TUN은 가상 네트워크 인터페이스를 통해 시스템 라우팅이 전달한 IP 트래픽을 받아 클라이언트와 연결된 구성 요소에서 처리합니다. 앱이 프록시 설정을 따르는 데 의존하는 시스템 프록시와 달리 TUN은 네트워크 계층에 더 가까운 곳에서 동작합니다. 하지만 특정 연결을 실제로 처리하는지는 라우팅, 제외 조건, 주소 계열, 실행 권한에 따라 달라집니다. ‘Tun 활성화’ 스위치가 켜져도 기능 활성화를 시도한다는 뜻일 뿐 모든 트래픽이 예상대로 처리된다는 보장은 없습니다.

일반 연결을 먼저 확인한 다음 처리 범위 넓히기

활성화하기 전에 TUN을 끄고 일반 시스템 프록시로 정상 접속을 한 번 확인해 선택한 서버와 기본 프로토콜 설정이 작동하는지 살펴보세요. 그런 다음 라우팅 프리셋, 시스템 DNS, 다른 네트워크 도구의 상태를 기록합니다. 데스크톱 클라이언트는 TUN에 별도 구성 요소나 다른 설정 구조를 사용할 수 있습니다. 기본 연결이 Xray를 사용한다고 해서 Xray의 라우팅 필드를 다른 TUN 구성 요소의 설정에 그대로 입력하면 안 됩니다. 클라이언트 인터페이스에서 지원하는 필드부터 확인하세요.

처음 활성화할 때는 시스템 안내에 따라 필요한 권한을 허용하고 가상 인터페이스와 라우팅 설치가 끝날 때까지 기다린 다음 테스트 앱을 실행하세요. 스위치를 빠르게 연속해서 켰다 끄지 마세요. 시작 실패 직후 다시 켜면 이전 프로세스나 인터페이스 상태가 판단을 방해할 수 있습니다. 재시도하기 전에 시작 로그에서 권한 부족, 인터페이스 생성 실패, 주소 충돌 여부를 확인하세요. 드라이버나 시스템 서비스가 관련된 경우 창을 닫아도 백그라운드 구성 요소가 중지되지 않을 수 있습니다.

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

시스템 트래픽을 처리할 때 클라이언트에서 프록시 서버로 연결하는 외부 연결은 네트워크에 정상적으로 도달해야 하며, 자체 처리 규칙에 다시 들어가 무한 반복되면 안 됩니다. 클라이언트가 보통 서버 주소 우회, 프로세스 제외, 인터페이스 바인딩 등을 처리하지만 사용자 지정 라우팅이나 다중 프록시가 이런 보호를 깨뜨릴 수 있습니다. TUN을 켠 뒤 모든 연결이 갑자기 멈추면 노드 설정이 정말 바뀌었는지 보기 전에 외부 연결이 루프에 빠졌는지 확인하세요.

로컬 네트워크 서비스는 따로 확인해야 합니다. 프린터, 라우터 관리 페이지, 로컬 개발 서버는 사설 주소를 사용할 수도 있고 로컬 네트워크 이름을 조회해 주소를 얻을 수도 있습니다. 사설 주소를 직접 연결하도록 설정하는 것만으로는 로컬 이름 검색 문제가 해결되지 않을 수 있습니다. 관련 조회, 브로드캐스트, 멀티캐스트가 현재 구현에서 처리되는지도 확인하세요. 로컬 장치 하나에 접속하려고 모든 대역을 포괄적으로 제외하지 말고 필요한 범위만 설정합니다.

‘LAN 연결 허용’과 TUN은 같은 기능이 아닙니다. 전자는 보통 프록시 수신 주소와 다른 기기에서 이 기기의 포트에 접속할 수 있는지에 영향을 주고, 후자는 이 기기의 트래픽 처리에 영향을 줍니다. 다른 기기에서 이 기기의 프록시를 사용할 필요가 없다면 수신 범위를 넓힐 이유가 없습니다. 필요하다면 방화벽, 인증 옵션, 신뢰할 수 있는 네트워크 범위도 확인해 불필요한 네트워크 인터페이스에 프록시 포트가 노출되지 않도록 하세요.

UDP가 정상적으로 작동하려면 앱 트래픽이 처리 범위에 포함되고, 클라이언트 구성 요소와 선택한 프로토콜, 서버 경로가 모두 UDP를 지원해야 합니다. 실시간 통신이 실패했다고 해서 DNS만 원인이라고 단정할 수는 없습니다. UDP 전달, 대상 포트, 경로 제한 때문일 수도 있습니다. 먼저 일반 웹페이지 접속으로 기본 연결을 확인한 뒤 실제 사용할 앱으로 UDP를 검증하세요. TCP만 테스트한 결과를 전체 연결의 검증으로 간주하지 마세요.

충돌을 파악하고 계층별로 복구하기

다른 VPN, 가상 머신 네트워크, 컨테이너 네트워크, 기업용 네트워크 도구가 동시에 라우팅이나 DNS를 설정할 수 있습니다. 문제를 확인할 때는 다른 네트워크 처리 기능부터 중지하고 한 번에 하나의 도구만 사용하세요. 소프트웨어를 바로 삭제할 필요는 없습니다. 특정 인터페이스를 켜거나 끌 때 문제가 나타나는지 살펴보고 인터페이스와 네트워크 대역의 관계를 기록하세요. 절전 모드에서 깨어나거나 무선 네트워크를 바꾸거나 유선 네트워크에 연결한 뒤 문제가 생기면 출구 인터페이스가 올바르게 다시 선택되는지도 확인해야 합니다.

복구할 때는 먼저 TUN을 끄고 백그라운드 구성 요소가 종료됐는지 확인한 뒤 시스템 프록시, DNS, 기본 라우팅이 예상 상태로 돌아왔는지 살펴봅니다. 일반 네트워크에 여전히 문제가 있으면 기록해 둔 원래 값에 따라 시스템 네트워크 설정을 복구하세요. 네트워크 전체 초기화를 첫 단계로 삼지 마세요. macOS 권한 문제는 설치 허용 및 네트워크 권한 설정을 참고하세요. Android 백그라운드 연결 중단은 앱 절전 정책을 별도로 확인해야 합니다.

FakeDNS

FakeDNS는 실제 조회 결과 대신 합성 주소를 반환하고 ‘합성 주소와 도메인’의 대응 관계를 저장합니다. 앱이 합성 주소로 연결하면 코어가 저장된 대응 관계에서 도메인을 찾아 라우팅하거나 프록시 처리에 사용합니다. FakeDNS의 장점은 도메인 정보의 연관성을 유지하고 일부 사전 조회 단계를 줄이는 데 있습니다. 공용 네트워크에서 바로 접속할 수 있는 실제 서버 주소를 제공하는 기능은 아닙니다. 이 점을 알아야 트래픽 처리에서 빠져나온 뒤 연결이 즉시 실패하는 이유를 이해할 수 있습니다.

DNS와 연결이 같은 경로에서 처리되는지 먼저 확인하기

FakeDNS를 사용하려면 합성 응답을 만드는 구성 요소와 이후 연결을 받는 구성 요소가 대응 관계를 공유해야 합니다. DNS는 한 구성 요소가 처리하는데 연결은 대응 관계를 모르는 다른 구성 요소에 전달되면 접속할 수 없는 합성 주소만 남습니다. 데스크톱 클라이언트는 모드에 따라 서로 다른 코어를 사용할 수 있으므로 전환 전에 실제 구현을 확인하세요. 두 곳의 설정 이름이 모두 FakeDNS라고 해서 설정 형식과 대응 관계의 수명까지 같다고 간주하면 안 됩니다.

아래 예시는 Xray 관련 필드를 보여줍니다. 주소 풀을 만들고 내장 DNS에서 FakeDNS를 사용하도록 설정하며 지정한 인바운드에서 해당 스니핑 덮어쓰기를 활성화합니다. 세 부분은 완전한 설정의 같은 이름을 가진 각 계층에 따로 병합해야 합니다. 인바운드 객체의 조각으로 인바운드 전체를 대체해서는 안 됩니다. 수신 주소, 포트, 프로토콜 등 기존 필드가 필요하기 때문입니다. 관련 설정 경로가 모두 연결되어야 각 필드가 함께 작동합니다.

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

해당 인바운드의 스니핑 설정 예시:

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

ipPool은 합성 주소 풀을 지정하고 poolSize는 대응 관계의 용량을 제한합니다. 예시 주소 대역은 테스트용이므로 일반 공용 대상으로 직접 연결하는 데 사용하지 마세요. 설정 전에 가상 머신, 테스트 네트워크, 기업 내부 네트워크에서 같은 대역을 사용 중인지 확인합니다. 충돌이 있다면 사용 중인 코어가 지원하는 범위에 따라 다른 대역을 계획하고 트래픽 처리 라우팅도 함께 확인해야 합니다. 주소 풀 문자열만 바꾸고 끝내면 안 됩니다.

캐시, 대응 관계 손실, 앱 호환성 처리하기

대응 관계는 보통 실행 중인 코어 상태에 저장됩니다. 코어를 재시작하면 앱에는 이전 합성 주소가 캐시되어 있지만 새 인스턴스는 그 주소가 어떤 도메인에 해당하는지 모를 수 있습니다. 재시작 직후 일부 앱이 실패했다가 캐시를 지운 뒤 복구되는 현상이 나타날 수 있습니다. FakeDNS를 켜거나 끌 때는 시스템 DNS 캐시, 브라우저 캐시, 기존 연결도 고려하세요. 규칙 오류로 오해하지 않도록 관련 테스트 앱을 순서대로 재시작합니다.

일부 앱은 주소 유형을 직접 확인하거나 조회 결과를 저장하고, 해당 주소를 다른 프로세스에 전달합니다. 이런 과정에서 합성 주소가 호환성 문제를 일으킬 수 있습니다. 로컬 네트워크 이름, 기기 검색, IP를 직접 사용하는 일부 서비스도 모두 FakeDNS에 포함하기에 적합하지 않을 수 있습니다. 특정 앱만 문제가 생기면 실제 DNS 조회를 기준으로 비교한 뒤 도메인이나 앱을 제외할지 검토하세요. 제외 조건의 위치와 형식은 실제 DNS 구성 요소에 맞춰야 합니다.

규칙에서 합성 주소 대역을 시스템 네트워크로 직접 제외하면 도메인 이름을 복원하기 전에 연결이 처리 경로를 벗어날 수 있습니다. 반대로 합성 주소에 ‘프록시’ 규칙을 추가하는 것만으로 해결되지 않을 수도 있습니다. 코어가 규칙을 검사하기 전에 원래 도메인으로 복원했을 수 있기 때문입니다. 현재 구현에서 복원과 규칙 매칭 중 어느 과정이 먼저인지 로그의 최종 대상을 확인한 뒤 규칙을 조정하세요. 실제 주소의 분기 설정을 합성 주소에 그대로 적용하면 안 됩니다.

설정을 켜고 끄며 효과와 한계를 비교하기

비교할 때는 서버, 라우팅 프리셋, 테스트 앱을 그대로 둔 채 FakeDNS만 전환하세요. 먼저 대상 도메인이 합성 주소를 받는지 확인한 뒤 이후 연결에서 도메인으로 복원되는지, 최종 아웃바운드가 규칙에 맞는지 살펴봅니다. 합성 주소가 보이지 않으면 앱이 해당 DNS를 우회했을 수 있습니다. 합성 주소는 보이지만 연결되지 않으면 DNS 서버를 계속 바꾸기보다 트래픽 처리 범위, 대응 관계, 인바운드의 복원 기능을 확인하세요.

끄기 전에 앱이 새 연결을 만들지 않도록 중지한 다음 관련 기능을 끄고 오래된 캐시를 정리하세요. 마지막으로 실제 DNS 조회를 복구해 테스트합니다. FakeDNS는 모든 설정에 필요한 기능이 아닙니다. 일반 DNS와 라우팅으로 충분하다면 현재 설정을 유지해도 됩니다. 도메인 연관 정보가 꼭 필요하고 전체 처리 경로를 관리할 수 있을 때만 도입하세요. 원인을 파악하기 어려운 문제가 생기면 실제 DNS로 되돌리는 것이 가장 유용한 첫 비교 테스트가 될 수 있습니다.

다중 구독 관리

다중 구독 관리의 핵심은 모든 출처를 하나의 목록에 넣는 것이 아니라 출처, 업데이트 경로, 사용 목적의 관계를 유지하는 데 있습니다. 출처별로 그룹을 만들고 설명에 용도를 기록하는 것이 좋습니다. 업무용, 가정용, 테스트용 이름을 따로 정할 수 있지만 비밀번호, 계정, 전체 구독 주소를 그룹 이름에 넣지 마세요. 한참 뒤에도 설정을 쉽게 이해할 수 있도록 그룹 설명을 작성하세요. 가져온 당일에만 알아볼 수 있는 이름은 피합니다.

출처 기록과 업데이트 주기 관리하기

각 그룹에는 최소한 출처 용도, 업데이트 방식, 필터 조건을 기록하세요. 기록은 본인 기기에 저장하면 됩니다. 자동 업데이트 주기는 실제 필요와 제공업체의 제한에 맞추세요. 목록을 ‘최신처럼’ 보이게 하려고 자주 요청하지 마세요. 요청 횟수를 늘려도 구독 내용이 자동으로 개선되지는 않으며, 반복 요청으로 속도 제한이 걸릴 수도 있습니다. 업데이트에 실패하면 이전에 사용하던 설정을 유지한 채 해당 그룹부터 조사하고 모든 출처를 동시에 바꾸지 마세요.

처음 정리할 때는 그룹별로 하나씩 업데이트해 각 출처에서 내용을 가져와 파싱할 수 있는지 확인한 다음 일괄 업데이트를 고려하세요. 그러면 어떤 주소가 만료됐는지, 어느 그룹의 요청 경로를 바꿔야 하는지 파악할 수 있습니다. 일괄 작업에서 일부만 실패하면 전체 DNS나 프록시 모드를 바로 바꾸지 말고 실패한 그룹의 응답과 인증 상태를 먼저 확인하세요. 전체 설정을 바꾸면 정상 작동하던 그룹에도 영향을 주어 문제 범위가 커질 수 있습니다.

같은 출처에서 여러 형식의 주소를 제공할 수 있으므로 주소 모양만 보고 내용이 같은지 판단할 수 없습니다. 클라이언트와 호환되는 주소를 선택하고 필요한 매개변수를 유지하세요. 웹 관리 페이지 주소와 구독 주소를 혼동하지 마세요. 주소에 로그인이 필요하거나 만료됐다면 클라이언트에서 재시도해도 인증 문제가 해결되지 않습니다. 이 경우 클라이언트에서 경로를 추측해 조합하지 말고 제공업체의 정식 관리 화면에서 유효한 주소를 다시 받으세요.

중복 이름, 중복 설정, 현재 선택 항목 구분하기

서버 설명만으로 서버를 고유하게 식별할 수는 없습니다. 서로 다른 출처의 서버가 같은 설명을 사용할 수 있고, 같은 서버도 설명이 바뀌면 새 항목처럼 보일 수 있습니다. 중복 여부를 판단할 때는 이름만 보고 삭제하지 말고 실제 프로토콜, 주소, 포트, 인증 매개변수를 기기에서 비교하세요. 클라이언트마다 중복 판정 기준이 다를 수 있으므로 실행 전에 적용 범위를 확인하고, 필요하면 현재 설정을 내보내 실수로 삭제했을 때 복구할 방법을 마련합니다.

구독을 업데이트하면 서버 객체가 교체되거나 정렬과 설명이 바뀔 수 있습니다. 현재 선택 항목을 유지할지는 클라이언트가 새 설정과 기존 설정을 어떻게 연결하는지에 따라 달라지므로 항상 유지된다고 가정하지 마세요. 대규모 업데이트가 끝나면 먼저 현재 그룹과 선택한 서버를 확인한 뒤 사용을 재개합니다. 기존 항목이 원격 목록에서 제거되었다면 실제 사용 가능한 항목을 다시 선택하세요. 목록에서 같은 위치에 있다는 이유만으로 연결 대상이 그대로라고 판단하지 마세요.

구독에 포함된 항목은 보통 제공업체가 관리하므로 필드를 직접 수정하면 다음 업데이트에서 변경 내용이 덮어써질 수 있습니다. 오랫동안 유지해야 하는 사용자 지정 설정은 용도가 분명한 별도의 수동 그룹에 넣고 변경 이유를 기록하세요. 같은 서버를 여러 그룹에 복사해 두고 용도를 적지 않으면 문제 해결 중 잘못된 항목을 수정하기 쉽습니다. 설명을 복잡하게 쓰는 것보다 설정 출처를 확인하는 일이 더 중요합니다.

이전, 백업, 개인정보 보호

다른 기기로 옮기기 전에 클라이언트 설정, 구독 출처, 개별 서버 설정 중 무엇을 이전할지 확인하세요. 내보내기 방법에 따라 포함되는 정보가 다르며 QR 코드나 공유 링크에도 연결 인증 정보가 포함될 수 있습니다. 신뢰할 수 있는 경로로만 전송하고 작업이 끝나면 불필요한 임시 사본을 삭제하세요. 공개적으로 도움을 요청할 때는 전체 내보내기 파일 대신 민감 정보를 제거한 설정 설명을 사용하세요. 로그의 구독 경로와 쿼리 매개변수도 함께 정리해야 합니다.

데스크톱 v2rayN과 Android의 v2rayNG, v2flyNG는 호환되는 구독 내용을 가져올 수 있지만 GUI의 그룹 설정, 라우팅 프리셋, 앱 적용 범위까지 함께 이전되지는 않을 수 있습니다. 특히 사용자 지정 라우팅과 DNS는 새 기기의 코어에 맞춰 다시 설정하고 검증해야 합니다. 설치 파일은 클라이언트 설치 파일 페이지에서 확인하세요. 이전 기기의 파일 이름만 보고 새 기기에 맞는 아키텍처를 판단하지 마세요.

Android 백그라운드 연결 끊김은 다중 구독 충돌이 아니라 절전 제한 때문일 수도 있습니다. 먼저 앱을 화면에 띄운 상태에서 정상 연결되는지 확인한 다음 VPN 권한, 앱별 적용 범위, 백그라운드 제한을 살펴보세요. 자세한 내용은 v2rayNG 앱별 프록시와 배터리 최적화 예외 설정을 참고하세요. 장기간 관리할 때는 사용 불가가 확인된 출처를 주기적으로 정리하고 필요한 기록만 남겨 실제 수요에 맞는 목록을 유지합니다.

사용자 지정 아웃바운드

사용자 지정 아웃바운드는 클라이언트의 일반 화면에서 설정할 수 없는 연결 경로를 구성할 때 사용합니다. 예를 들어 특정 대상을 로컬의 다른 프록시 수신 포트로 전달할 수 있습니다. 아웃바운드 프로토콜, 태그 참조, 수신 가능 여부, 루프 방지까지 고려해야 하므로 규칙 하나를 추가하는 일만은 아닙니다. 설정을 편집하기 전에 ‘앱이 어떤 인바운드로 들어오는지, 규칙이 어떤 태그를 선택하는지, 해당 태그가 어디로 연결되는지’를 먼저 정리하세요. 일반 프록시 경로를 이해하기 전에는 사용자 지정 전달 계층을 여러 개 겹치지 않는 것이 좋습니다.

로컬 SOCKS 아웃바운드로 최소 예시 구성하기

아래는 직접 연결, 차단, 로컬 SOCKS 서비스 연결을 나타내는 Xray 형식의 아웃바운드 객체 세 개입니다. 완전한 설정의 outbounds 배열에 병합해야 합니다. 기존 배열을 무작정 대체하면 현재 서버 아웃바운드가 삭제되거나 기본 순서가 바뀔 수 있습니다. 로컬 주소는 연결 대상만 나타내며 포트는 실제 서비스가 사용하는 값과 일치해야 합니다. 해당 주소에 수신 서비스가 없으면 설정을 불러올 수 있어도 전달은 되지 않습니다.

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

이 예시에는 인증 설정이 없으므로 대상 서비스가 해당 연결을 허용하도록 설정된 경우에만 사용할 수 있습니다. 실제 서비스에 인증이 필요하면 해당 코어가 지원하는 사용자 필드를 사용하고 실제 인증 정보는 로컬에만 저장하세요. 설정을 간단히 하려고 수신 범위를 넓히거나 기존 인증을 끄지 마세요. 루프백 주소는 코어가 실행되는 동일한 네트워크 환경을 가리킵니다. 코어가 컨테이너나 격리된 환경에서 실행되면 호스트의 서비스를 가리키지 않을 수 있습니다.

아웃바운드를 준비한 다음 테스트용으로 가장 구체적인 규칙 하나를 추가하세요. 아래 예시는 태그 참조를 설명하기 위해 예약된 예시 도메인을 사용하며 실제 서비스가 제공되는 도메인일 필요는 없습니다. 실제로 검증할 때는 직접 확인할 대상 도메인으로 바꾸고 규칙 순서도 적절히 유지하세요. outboundTag는 아웃바운드의 tag와 정확히 일치해야 합니다. 대소문자, 하이픈, 철자를 임의로 바꾸면 안 됩니다.

{
  "type": "field",
  "domain": ["full:example.com"],
  "outboundTag": "local-socks"
}

전달과 프록시 체이닝 구분하기

업무 연결을 로컬 SOCKS 서비스로 전달한다는 것은 그 서비스가 이후 연결을 처리한다는 뜻이지, 모든 프록시 서버가 지정한 순서로 이미 연결되었다는 의미는 아닙니다. 실제 프록시 체이닝에는 외부 연결의 다이얼 방식, 도메인 조회 위치, 각 단계의 인증을 명확히 설정해야 합니다. 코어마다 체이닝 필드가 다르므로 sing-box 필드 이름을 Xray 설정에 그대로 옮기지 마세요. 이름이 비슷하다고 동작도 같을 것이라 추정하면 안 됩니다.

가장 위험한 실수는 두 프록시가 서로를 가리키게 만드는 것입니다. 클라이언트 A가 요청을 B에 전달하고 B의 업스트림이 다시 A를 가리키거나, TUN이 로컬 프록시의 외부 연결을 원래 인바운드로 되돌릴 수 있습니다. 문제를 조사할 때는 최종 출구에서 거꾸로 추적해 각 홉이 다음 홉에 도달하는지, 명확한 종착점이 있는지 확인하세요. 먼저 TUN을 끄고 단일 앱의 프록시에서 사용자 지정 아웃바운드를 검증한 다음 시스템 전체의 트래픽 처리를 단계적으로 복구하면 문제 범위를 크게 좁힐 수 있습니다.

아웃바운드가 여러 개면 DNS와 UDP 처리 차이도 커집니다. 로컬 SOCKS 서비스가 TCP를 처리하더라도 필요한 UDP 전달까지 지원한다는 뜻은 아닙니다. 도메인을 첫 번째 단계에서 조회할지 다음 단계에 맡길지도 규칙과 접속 가능성에 영향을 줍니다. 테스트할 때는 도메인 대상, IP 대상, 실제 앱 프로토콜을 각각 확인하세요. ‘포트에 연결할 수 있다’는 것만으로 전체 경로 검증이 끝난 것은 아닙니다.

설정 저장, 점검, 복구

우선 클라이언트가 제공하는 사용자 지정 설정, 아웃바운드, 라우팅 편집 기능을 사용하세요. 어떤 입력란은 전체 설정을 받고 다른 입력란은 객체 조각만 받으므로 붙여 넣기 전에 화면 안내와 기존 구조를 확인해야 합니다. JSON 객체, 배열, 문자열 형식이 올바르게 유지되어야 하며 주석이나 후행 쉼표를 추가하면 안 됩니다. 태그 중복, 존재하지 않는 태그 참조, 객체 필드에 배열을 넣는 실수는 시작 실패나 알아채기 어려운 설정 덮어쓰기를 일으킬 수 있습니다.

저장한 뒤 먼저 코어가 설정을 정상적으로 불러오는지 확인하고 새 연결을 만들어 로그의 아웃바운드 태그가 대상 수신 서비스와 일치하는지 살펴보세요. 설정 로드에 실패하면 서버를 바꾸거나 구독을 업데이트하지 말고 수정 전 설정부터 복구합니다. 로드는 성공했지만 연결이 거부되면 로컬 서비스 실행 여부, 수신 주소, 포트가 일치하는지 확인하세요. 연결은 성립하지만 이후에 실패하면 다음 홉의 프로토콜, 인증, 주소 조회를 차례로 점검합니다.

유지 관리가 가능한 설정을 만들었다면 용도, 의존 서비스, 수신 포트, 복구 절차를 기록해 다음에 실행할 때 업스트림 서비스를 먼저 시작해야 한다는 점을 놓치지 않도록 하세요. 코어와 클라이언트의 관계는 Project V, V2Fly, Xray 생태계 안내에서 더 살펴볼 수 있습니다. 여러 주제에 걸친 문제가 있다면 자주 묻는 질문에서 증상별로 찾아보세요. 일반 시스템 프록시가 작동하는 기본 설정을 항상 보관하고, 사용자 지정 아웃바운드에 문제가 생기면 먼저 가장 단순한 경로로 되돌리세요.