V2Ray 설정 고급 가이드

되돌릴 수 있는 설정 모델부터 만들기

클라이언트 설정, 코어 설정과 시스템 네트워크 구분하기

고급 설정의 첫 단계는 규칙을 늘리는 것이 아니라 각 설정을 어느 계층이 담당하는지 명확히 하는 것입니다. v2rayN, v2rayNG와 v2flyNG는 구독 관리, 서버 선택, 코어 실행 및 시스템 네트워크 설정을 담당하는 그래픽 클라이언트입니다. Xray 또는 V2Fly 코어는 프로토콜 연결, DNS 조회, 라우팅 매칭과 인바운드·아웃바운드 처리를 담당합니다. 운영체제는 기본 라우팅, 시스템 프록시, 가상 네트워크 어댑터와 애플리케이션 자체의 네트워크 권한을 관리합니다. 세 계층이 동시에 작동할 때 화면에 “연결됨”이 표시되어도 클라이언트와 코어 프로세스가 시작되었다는 뜻일 뿐, 도메인 해석, 라우팅 매칭과 시스템 트래픽 인계까지 올바르다는 의미는 아닙니다.

문제 해결 시 데이터 흐름을 따라 확인하세요. 애플리케이션이 먼저 도메인이나 대상 주소를 생성하고, 운영체제가 트래픽을 로컬 프록시 또는 가상 네트워크 어댑터로 보낼지 결정한 뒤, 코어가 DNS와 라우팅 규칙을 적용하고 마지막으로 직접 연결, 프록시 또는 차단 아웃바운드를 선택합니다. 브라우저는 되지만 명령줄 도구가 되지 않는다면 시스템 프록시 상속 방식을 중점적으로 확인하세요. 도메인은 되지 않지만 주소로는 접속된다면 DNS를 확인해야 합니다. 특정 웹사이트만 문제가 있다면 규칙 순서, 프로토콜 지원과 대상 사이트의 주소 체계를 확인하세요. 계층별로 판단하면 클라이언트를 무작정 재설치하는 정보량이 낮은 작업을 피할 수 있습니다.

기준 설정과 변경 기록 만들기

조정을 시작하기 전에 연결이 확인된 기준 설정을 보관하세요. 기준 설정에는 사용 가능한 구독 하나, 현재 서버 하나, 기본 DNS, 기본 라우팅과 시스템 프록시 모드만 포함하고 TUN, FakeDNS 또는 복잡한 사용자 지정 아웃바운드는 활성화하지 않습니다. 이후 클라이언트 유형, 현재 설정 파일, 선택한 서버, 시스템 프록시 상태와 테스트 애플리케이션을 기록하세요. 데스크톱 v2rayN에서는 용도별 설정을 별도 구성으로 저장하는 방식이 적합합니다. Android에서는 현재 선택한 설정, 앱별 프록시 상태와 배터리 정책을 기록하여 시스템 백그라운드 제한을 코어 장애로 오판하지 않도록 하세요.

변경할 때마다 하나의 주제만 다루세요. 예를 들어 먼저 구독 필터링을 완료하고 테스트한 다음 라우팅 규칙을 추가합니다. 라우팅이 안정된 후 DNS를 조정하고, 마지막으로 TUN과 FakeDNS가 필요한지 평가하세요. DNS, 라우팅과 가상 네트워크 어댑터를 한꺼번에 바꾸면 실패 원인을 알 수 없습니다. 변경 기록에는 복잡한 도구가 필요하지 않으며 “변경 전, 변경 항목, 예상 결과, 실제 결과, 되돌리기 작업”을 담은 표 하나면 충분합니다. 규칙이 많을수록 되돌리기 능력이 중요합니다. 구독 업데이트, 네트워크 전환과 시스템 업그레이드가 이전에 드러나지 않았던 경계 상황을 노출할 수 있기 때문입니다.

반복 가능한 검증 작업 정의하기

검증 작업은 고정해야 결과를 비교할 수 있습니다. 기본 점검에는 클라이언트 로그에 지속적인 재시도가 없는지, 테스트 도메인이 해석되는지, 브라우저와 브라우저가 아닌 앱 하나가 모두 연결되는지, 클라이언트를 종료한 뒤 시스템 프록시 또는 가상 네트워크 어댑터 상태가 올바르게 복원되는지가 포함되어야 합니다. 라우팅은 직접 연결 규칙, 프록시 규칙과 차단 규칙에 명확히 해당하는 대상 세 개를 선택해 검증하고, 자주 쓰는 웹페이지 하나만 테스트해서는 안 됩니다. DNS는 조회 결과와 최종 연결 경로를 함께 관찰하여 브라우저 캐시를 설정 성공으로 오해하지 않도록 하세요.

Windows에서는 Get-NetIPInterface로 인터페이스 우선순위를 확인하고, macOS에서는 scutil --dns로 시스템 리졸버를 확인하며, Linux에서는 ip route로 라우팅 테이블을 점검할 수 있습니다. 명령 출력은 시스템 상태를 확인하는 용도일 뿐 클라이언트 내부 규칙이 반드시 매칭되었다는 뜻은 아닙니다. Android에서는 클라이언트 로그, 네트워크 전환과 앱별 테스트를 함께 확인하는 방식이 적합합니다. 적절한 클라이언트를 아직 설치하지 않았다면 먼저 클라이언트 페이지에서 플랫폼에 맞는 항목을 선택하세요. 데스크톱 설정에는 v2rayN을 우선 권장하며 Android에서는 코어 요구 사항에 따라 v2rayNG 또는 v2flyNG를 선택할 수 있습니다.

구독 그룹과 서버 필터링

그룹은 관리 문제를 해결하고, 라우팅은 트래픽 문제를 해결합니다

구독 그룹은 라우팅 분기로 오해하기 쉽습니다. 그룹은 서버를 정리하고 선택 범위를 좁히며 업데이트 범위를 지정할 뿐, 특정 웹사이트가 어느 아웃바운드로 나갈지는 결정하지 않습니다. 실제 트래픽 경로를 제어하는 것은 라우팅 규칙과 아웃바운드 태그입니다. 구독은 출처별로 저장하고, 용도나 기능별 뷰를 만든 다음, 라우팅 규칙이 안정적인 아웃바운드를 참조하도록 구성하는 것이 좋습니다. 구독 이름, 서버 이름과 아웃바운드 태그를 같은 계층으로 취급하지 마세요. 구독 업데이트로 이름이 바뀌면 이름에 의존하는 필터와 규칙이 동시에 작동하지 않을 수 있습니다.

“출처 그룹”과 “작업 그룹”이라는 두 가지 기준을 유지하는 것이 좋습니다. 출처 그룹은 구독 주소에 대응하여 독립적인 업데이트, 일시 중지와 삭제를 쉽게 합니다. 작업 그룹은 프로토콜, 전송 방식, 지역 표기 또는 수동 용도에 따라 필터링합니다. v2rayN 서버 목록에서는 메모, 구독 소속과 필터 표현식을 활용해 범위를 좁히는 방식이 적합합니다. v2rayNG와 v2flyNG의 모바일 화면에서는 그룹 수를 적게 유지하여 작은 화면에서 지나치게 복잡한 필터 조건을 관리하지 않도록 하세요. 그룹 이름은 안정적이고 읽기 쉬워야 하며 단기 상태를 이름에 넣지 마세요.

관리하기 쉬운 필터 조건 설계하기

서버 필터링은 대개 메모 텍스트를 기준으로 하므로 정확성은 이름 지정 품질에 달려 있습니다. “포함 조건 우선, 제외 조건 보완” 전략을 권장합니다. 먼저 명확한 프로토콜이나 용도를 제한한 다음 테스트 항목, 만료 항목과 불필요한 전송 유형을 제외하세요. 필터 표현식은 가능한 한 짧게 유지하고 구독 업데이트 후 결과를 표본 점검하세요. 상위 제공자가 이름 형식을 바꾸면 서버를 하나씩 수동으로 수정하지 말고 필터 조건을 업데이트해야 합니다. 다음 업데이트에서 로컬 수정이 덮어써질 수 있기 때문입니다. 중요한 서버에 로컬 메모를 추가할 때는 업데이트 후에도 해당 필드가 보존되는지 확인하세요.

정규 표현식은 이름 규칙이 안정적일 때 적합하며, 모호한 텍스트를 추측하는 데는 적합하지 않습니다. 다음 예시는 이름에 “VLESS” 또는 “REALITY”가 포함되면서 “테스트”와 “만료”는 제외합니다. 클라이언트마다 필터 입력란의 정규식 지원 여부가 다를 수 있으므로 먼저 소수의 항목으로 결과를 확인한 뒤 전체 목록에 적용하세요. 일반 텍스트 검색만 지원한다면 여러 개의 단순한 뷰로 나누고, 하나의 키워드에 모든 논리를 담으려 하지 마세요.

^(?=.*(?:VLESS|REALITY))(?!.*(?:테스트|만료)).*$

필터 결과가 비어 있으면 먼저 제외 조건을 제거한 뒤 표현식을 조금씩 추가하세요. 결과가 너무 많다면 대소문자, 전각 기호와 상위 제공자의 이름 형식이 일치하는지 확인하세요. 필터는 서버 연결 가능 여부를 검증하지 않으며 실제 연결 테스트를 대신할 수도 없습니다. 지연 시간은 특정 시점의 왕복 네트워크 상태만 보여 주므로 처리량, 안정성과 프로토콜 호환성을 완전히 나타내지 못합니다. 서버를 선택할 때는 한 번의 정렬 결과만 보지 말고 로그의 핸드셰이크 결과, 지속적인 접속 상태와 네트워크 전환 후 복구 여부를 함께 판단하세요.

업데이트, 삭제와 중복 항목 처리

구독은 출처별로 하나씩 업데이트하세요. 먼저 한 구독을 업데이트하고 서버 수, 이름과 현재 선택 항목이 바뀌었는지 확인한 뒤 다음 출처로 넘어갑니다. 모든 구독을 동시에 업데이트하면 중복 항목이나 이상한 이름이 빠르게 퍼져 출처를 찾기 어려워집니다. 구독을 삭제하기 전에는 현재 사용하는 서버와 사용자 지정 라우팅이 해당 출처에 의존하지 않는지 확인하세요. 일부 클라이언트는 구독에서 생성된 이전 서버를 보존하고, 일부는 업데이트 때 덮어씁니다. 작업 전에 화면에서 업데이트 정책을 확인하고 필요하다면 먼저 클라이언트 설정을 내보내세요.

중복 서버는 표시 이름만으로 판단할 수 없습니다. 두 항목의 이름은 같아도 주소, 포트와 프로토콜 매개변수가 다를 수 있고, 반대로 매개변수는 같지만 서로 다른 구독에서 제공될 수도 있습니다. 프로토콜 유형, 서버 주소, 포트, 전송 계층과 보안 매개변수를 비교한 뒤 보존 여부를 결정하는 것이 안전합니다. 여러 출처가 장기간 동일한 항목을 제공한다면 출처가 더 안정적이고 이름 형식이 더 일관된 항목 하나를 남기고 나머지는 사용 중지 그룹으로 옮기세요. 즉시 삭제하지 않으면 업데이트에 문제가 생겼을 때 되돌릴 수 있습니다.

자동 선택 기능에도 명확한 범위가 필요합니다. 후보 집합 안에서 수동 전환을 줄일 수 있지만, 후보 집합은 먼저 필터링해야 하며 테스트 방식도 실제 사용 환경과 비슷해야 합니다. 프로토콜 기능과 네트워크 경로가 서로 다른 서버를 하나의 자동 그룹에 모두 넣으면 연결 동작이 자주 바뀌어 DNS 캐시, 장기 연결과 문제 해결을 방해할 수 있습니다. 안정성이 우선인 경우에는 일정 기간 서버를 고정하고 로그와 앱 동작을 관찰하세요. 후보 항목의 호환성을 확인한 뒤에만 자동 정책을 활성화하는 것이 좋습니다.

라우팅 규칙의 매칭 순서와 실전 구성

위에서 아래로 진행되는 첫 매칭 이해하기

V2Ray 라우팅의 핵심은 규칙 수가 아니라 매칭 순서입니다. 대부분의 설정은 목록을 위에서 아래로 확인하며, 연결이 조건에 맞는 첫 규칙과 매칭되면 이후 규칙은 검사하지 않습니다. 구체적인 규칙은 일반 규칙보다 앞에 두고, 차단 규칙은 명확하고 안정적인 대상을 대상으로 하며, 마지막에 기본 경로를 설정해야 합니다. 범위가 넓은 도메인, 주소 또는 포트 규칙을 위에 배치하면 뒤의 세부 규칙은 문법이 올바르더라도 적용되지 않습니다.

관리하기 쉬운 순서는 보통 로컬 네트워크 주소와 로컬 서비스를 먼저 처리하고, 명확한 차단 항목을 그다음에 둔 뒤, 지정 경로가 필요한 도메인이나 주소 집합, 자주 직접 연결할 집합을 차례로 처리하고 마지막에 기본 아웃바운드를 배치하는 방식입니다. 규칙 하나 안의 조건 조합과 여러 규칙 사이의 선후 관계를 구분해야 합니다. 하나의 규칙에 여러 필드를 입력하면 코어는 일반적으로 해당 조건을 모두 만족해야 하는 것으로 처리하며, 같은 필드 안의 여러 값은 어느 하나가 매칭되면 됩니다. 설정하기 전에 의도를 자연어로 먼저 작성한 뒤 규칙으로 옮기세요.

도메인, 주소와 프로세스 조건의 경계

도메인 규칙은 코어가 대상 도메인을 확보할 수 있을 때만 적용됩니다. 앱이 먼저 자체적으로 해석한 뒤 주소에 직접 연결하면 코어에는 대상 주소만 보일 수 있으며, 이 경우 주소 규칙, DNS 스니핑 또는 TUN이 필요합니다. 주소 규칙은 비교적 안정적이지만 대형 서비스의 주소 범위는 바뀌므로 수동 관리 비용이 높습니다. GeoSite은 도메인 분류별 매칭에, GeoIP는 주소 귀속 지역별 매칭에 적합합니다. 두 데이터는 최신 상태로 유지해야 하며 자세한 업데이트 방법은 GeoIP 및 GeoSite 데이터베이스 업데이트 가이드를 참고하세요.

프로세스 조건은 운영체제와 클라이언트 구현에 의존하므로 유일한 기준으로 사용해서는 안 됩니다. 설치 방식, 보조 프로세스나 앱 업데이트에 따라 프로세스 이름이 바뀔 수 있고, 같은 앱도 시스템 서비스를 통해 네트워크 요청을 보낼 수 있습니다. 데스크톱에서는 프로세스 규칙을 세밀한 분기의 보조 수단으로 사용할 수 있지만, 기본적으로 도메인 또는 주소 규칙도 준비해야 합니다. Android의 앱별 프록시는 시스템 계층에서 어떤 앱을 가상 네트워크로 보낼지 선택합니다. 이는 코어 라우팅과 연속된 두 단계의 판단으로, 전자는 진입 여부를 결정하고 후자는 진입한 트래픽이 어느 아웃바운드로 나갈지 결정합니다.

{
  "routing": {
    "domainStrategy": "IPIfNonMatch",
    "rules": [
      {
        "type": "field",
        "ip": [
          "geoip:private"
        ],
        "outboundTag": "direct"
      },
      {
        "type": "field",
        "domain": [
          "domain:telemetry.example.invalid"
        ],
        "outboundTag": "block"
      },
      {
        "type": "field",
        "domain": [
          "geosite:cn"
        ],
        "outboundTag": "direct"
      },
      {
        "type": "field",
        "network": "tcp,udp",
        "outboundTag": "proxy"
      }
    ]
  }
}

예시의 IPIfNonMatch는 먼저 도메인 규칙을 판단하고, 도메인이 매칭되지 않을 때 주소를 해석하여 주소 규칙에 사용하는 설정입니다. 주소 규칙의 적용 범위를 넓힐 수 있지만 코어 DNS가 결정 과정에 참여하므로 DNS 장에서 설명하는 서버와 조회 정책을 함께 설계해야 합니다. 항상 주소 기준으로 판단하도록 설정하면 도메인 요청에서 더 많은 해석이 발생하고, 전혀 해석하지 않으면 도메인 정보만 있는 연결이 주소 집합과 매칭되지 않습니다. 모든 네트워크에 적용되는 고정값은 없으며 GeoIP 의존 여부, 앱이 도메인을 제공하는지와 DNS 경로에 따라 선택해야 합니다.

페이지 결과를 추측하지 말고 로그로 규칙 검증하기

규칙 검증에서는 대상, 매칭 조건과 최종 아웃바운드 세 가지 정보를 확인해야 합니다. 먼저 브라우저 DNS와 연결 캐시를 정리하고 연결을 재사용하는 테스트 페이지를 닫은 다음 새 요청을 보내세요. 로그에서 대상이 이미 주소로 표시된다면 앱의 해석이나 스니핑을 확인해야 합니다. 대상 도메인은 올바르지만 잘못된 아웃바운드와 매칭된다면 규칙 순서와 도메인 표기를 확인하세요. 아웃바운드는 올바르지만 연결에 실패한다면 프로토콜 매개변수, 서버 상태와 네트워크 경로를 확인하고 라우팅을 계속 수정하지 마세요.

도메인 표기에도 분명한 차이가 있습니다. 전체 도메인은 하나의 호스트 이름에만 매칭되고, 도메인 접미사는 하위 도메인까지 포함하며, 키워드 매칭은 범위가 가장 넓어 오탐이 발생하기 쉽습니다. 전체 도메인이나 잘 관리되는 도메인 집합을 우선 사용하고, 대상 이름이 안정적이며 열거할 수 없을 때만 키워드를 사용하세요. 포트 규칙에는 프로토콜을 명시해야 합니다. 같은 포트에서 TCP와 UDP가 동시에 사용될 수 있기 때문입니다. UDP를 차단할 때는 앱이 TCP로 자동 전환할 수 있다는 점도 고려해야 합니다. 겉으로 계속 접속된다고 해서 차단 규칙이 적용되지 않은 것은 아닙니다.

라우팅을 수정한 뒤에는 로컬 네트워크 서비스, 명확한 직접 연결 대상, 명확한 프록시 대상, 차단 대상과 미매칭 대상을 순서대로 테스트하세요. 로컬 네트워크 접속 이상은 대개 사설 주소 규칙의 위치가 잘못된 경우입니다. 모든 대상이 같은 경로로 나가면 기본 규칙이 너무 앞에 배치되었을 가능성이 있습니다. 도메인만 실패한다면 DNS와 라우팅이 순환을 이루었을 수 있습니다. 연결되지만 웹페이지가 열리지 않는다면 12가지 문제 해결 체크리스트에 따라 로컬 설정, 노드, 라우팅과 해석의 네 계층을 계속 점검하세요.

DNS 설정 최적화와 해석 경로

조회가 어디에서 시작되는지 먼저 그리기

DNS 문제를 찾기 어려운 이유는 시스템 리졸버, 브라우저 보안 DNS, 클라이언트 코어 DNS와 원격 해석이 동시에 존재하기 때문입니다. 앱은 도메인을 시스템에 맡길 수도 있고 암호화된 조회를 직접 보낼 수도 있습니다. 시스템 프록시 모드에서도 일부 앱은 시스템 DNS를 직접 사용합니다. TUN 모드는 더 넓은 범위의 조회를 인계할 수 있지만 하드코딩된 리졸버나 특수 프로토콜이 남아 있을 수 있습니다. 설정 전에는 테스트 앱이 어느 경로를 사용하는지 확인한 뒤 코어가 인계할지 결정해야 하며, 클라이언트에 DNS 주소가 입력되어 있다는 이유만으로 모든 조회가 그곳을 거친다고 가정해서는 안 됩니다.

해석 경로에는 적어도 세 가지 결정이 포함됩니다. 조회를 어느 서버에 맡길지, 조회 트래픽을 어느 아웃바운드로 보낼지, 반환 결과를 라우팅에 사용할지 단순 연결에만 사용할지입니다. DNS 서버 주소 자체가 프록시를 거쳐야 하고 프록시 연결은 같은 DNS에 의존한다면 시작 순환이 발생합니다. 기본 연결에 직접 접근 가능한 리졸버를 남겨 두거나, 이미 해석 가능한 고정 도메인과 독립 경로를 사용해 서버 주소를 구성하세요. 캐시, 동시성이나 주소 체계 우선순위를 논하기 전에 먼저 시작 경로가 완결되는지 확인해야 합니다.

도메인 범위에 따라 리졸버 선택하기

도메인마다 다른 DNS 서버를 사용할 수 있지만 분기 기준은 명확해야 합니다. 내부 도메인과 로컬 네트워크 장치는 검색 도메인, 사설 영역과 로컬 주소에 의존할 수 있으므로 보통 시스템 또는 로컬 네트워크 리졸버에 맡깁니다. 공용 도메인은 코어에 설정한 리졸버로 보낼 수 있습니다. 특정 아웃바운드와 일치해야 하는 도메인은 같은 경로로 조회하여 해석 결과와 연결 출구가 어긋나지 않도록 하세요. 모든 조회를 여러 서버에 동시에 보내 가장 먼저 응답한 결과를 받는 방식은 결과 출처를 불안정하게 만들고 문제 해결을 어렵게 합니다.

설정의 hosts는 로컬 테스트 서비스나 고정 별칭이 필요한 내부 리소스처럼 소수의 안정적인 매핑을 저장하는 데 적합합니다. 대규모 도메인 규칙 데이터베이스가 아니며 일반 해석을 대체해서도 안 됩니다. 매핑이 자주 바뀌면 정적 항목은 쉽게 만료됩니다. 하나의 도메인에 IPv4와 IPv6 레코드가 모두 있다면 시스템 네트워크에 해당 주소 체계로 연결할 수 있는 경로가 있는지 확인하세요. 특정 반환 유형만 비활성화하면 표면적인 장애를 피할 수 있지만 시스템 라우팅이나 상위 네트워크 설정 문제를 가릴 수 있습니다.

{
  "dns": {
    "hosts": {
      "router.home.arpa": "192.168.1.1"
    },
    "servers": [
      {
        "address": "localhost",
        "domains": [
          "domain:router.home.arpa",
          "domain:service.example.invalid"
        ]
      },
      "1.1.1.1"
    ],
    "queryStrategy": "UseIP"
  }
}

예시는 필드 관계를 설명하기 위한 것입니다. 로컬 도메인은 우선 로컬 리졸버에 맡기고 나머지 조회는 다음 서버를 사용합니다. 실제 배포에서는 현재 네트워크에서 접근 가능하고 용도가 명확한 리졸버를 선택하세요. queryStrategy는 반환할 주소 체계의 범위를 제어하고, UseIP는 사용 가능한 주소를 조회하도록 합니다. IPv4 또는 IPv6만 조회할지는 실제 네트워크 성능을 기준으로 결정해야 합니다. 클라이언트가 생성하는 설정은 다른 필드 형식을 사용할 수 있습니다. 그래픽 인터페이스에서 이미 DNS 모드를 제공한다면 중복 설정을 함께 가져오지 마세요. 나중에 생성된 필드가 앞선 설정을 덮어쓸 수 있습니다.

캐시, 브라우저와 오염 여부 판단

DNS를 바꾼 직후 같은 페이지에 다시 접속해도 이전 캐시를 사용하는 경우가 많습니다. 캐시는 브라우저, 시스템 서비스, 코어와 대상 앱에 각각 존재할 수 있습니다. 검증할 때는 새 연결을 만들고 이전에 조회하지 않은 테스트 도메인을 사용하거나 시스템 방식으로 DNS 캐시를 갱신하세요. 브라우저에서 독립 보안 DNS를 활성화했다면 잠시 끄거나 명확히 설정하여 테스트 경로가 클라이언트 설계와 일치하도록 해야 합니다. 그렇지 않으면 브라우저는 정상이고 다른 앱은 실패한다는 사실만으로 두 앱이 서로 다른 해석 경로를 사용한다는 것밖에 알 수 없습니다.

이상 결과를 판단할 때는 한 가지 명령의 출력만 보지 말고 “시스템 조회 결과, 코어 조회 결과, 최종 연결 주소”를 비교하세요. 시스템 조회는 정상인데 코어가 실패하면 코어 DNS의 아웃바운드와 라우팅을 확인해야 합니다. 코어 조회는 정상인데 앱이 여전히 실패한다면 앱이 프록시를 우회하거나 이전 연결을 재사용하는지 확인하세요. 주소 결과는 올바르지만 연결 시간이 초과되면 문제는 이미 DNS 계층을 벗어난 것이므로 라우팅, 프로토콜과 서버를 확인해야 합니다. 해석 시간이 가끔 늘어나는 것만으로 서버를 바꿀 필요는 없습니다. 먼저 네트워크 전환, 첫 핸드셰이크 또는 캐시 미적중 때문인지 관찰하세요.

DNS와 라우팅은 함께 검증해야 합니다. IPIfNonMatch 같은 정책을 사용하면 라우팅 판단이 해석을 직접 유발할 수 있으며 DNS 조회 자체도 라우팅 시스템으로 들어갑니다. DNS 서버의 도메인이 다시 해석 결과에 의존하는 규칙과 매칭되면 재귀가 발생할 수 있습니다. 리졸버에 명확한 아웃바운드를 지정하고, 기본 서버 주소가 직접 접근 가능한 경로를 갖게 하며, 관련 규칙을 일반 규칙보다 앞에 배치하면 순환 위험을 낮출 수 있습니다. 설정이 안정된 뒤 도메인별 리졸버 규칙을 세분화하세요.

TUN 모드 활성화 순서와 범위

TUN과 시스템 프록시는 처리하는 대상이 다릅니다

시스템 프록시는 운영체제의 프록시 설정을 따르는 앱에 프록시 주소를 제공하므로 설정이 간단하고 되돌리기 쉽지만, 시스템 프록시를 무시하는 프로그램과 일부 UDP 트래픽은 처리하지 못합니다. TUN 모드는 가상 네트워크 인터페이스를 만들어 더 넓은 범위의 IP 트래픽을 클라이언트로 보낸 뒤 코어가 DNS, 라우팅과 아웃바운드를 선택하도록 합니다. 이는 “더 강력한 스위치”가 아니라 시스템 데이터 경로를 바꾸는 네트워크 모드이므로 라우팅 테이블, DNS 인계, 인터페이스 우선순위와 로컬 네트워크 접근을 추가로 처리해야 합니다.

TUN 활성화 여부는 앱의 요구 사항에 따라 결정해야 합니다. 브라우저, 일반적인 데스크톱 소프트웨어와 개발 도구가 시스템 프록시를 올바르게 사용한다면 설정을 복잡하게 만들기 위해 전환할 필요가 없습니다. 프록시 설정을 읽지 않는 앱, UDP 요청이나 통합 트래픽 분기가 필요할 때 TUN을 검토하세요. Android 클라이언트는 보통 시스템 가상 네트워크 기능으로 트래픽을 인계하며 앱별 선택을 함께 사용할 수 있습니다. 데스크톱에서는 인터페이스를 만들고 라우팅을 기록하기 위해 시스템 권한이 필요할 수 있습니다. 플랫폼마다 권한 동작은 다르지만 검증 방식은 같습니다. 인터페이스 생성, 기본 경로 변경, DNS가 예상 경로로 들어가는지와 클라이언트 종료 후 네트워크가 복구되는지를 확인하세요.

최소 설정으로 활성화하기

활성화하기 전에 가상 네트워크 어댑터를 만들거나 기본 라우팅을 수정하거나 DNS를 인계하는 다른 네트워크 도구를 종료하여 두 라우팅 체계가 경쟁하지 않도록 하세요. 검증된 서버 하나만 남기고 최소한의 라우팅 집합을 사용하며 FakeDNS는 활성화하지 말고 시스템 방화벽도 동시에 조정하지 마세요. TUN을 시작한 뒤에는 먼저 클라이언트 로그에서 인터페이스가 성공적으로 생성되었는지 확인하고, 로컬 게이트웨이, 일반 도메인과 명확히 프록시로 보낼 대상을 테스트하세요. 첫 단계부터 로컬 게이트웨이에 접근할 수 없다면 원격 프로토콜 매개변수가 아니라 사설 주소 직접 연결과 라우팅 제외를 먼저 확인해야 합니다.

Windows에서는 PowerShell로 인터페이스와 라우팅 우선순위를 확인할 수 있고, macOS에서는 현재 기본 라우팅과 DNS 리졸버를 점검할 수 있으며, Linux에서는 라우팅 테이블, 정책 라우팅과 DNS 서비스 상태를 함께 확인해야 합니다. 다음 명령은 시스템 설정을 변경하지 않고 상태만 읽습니다. 출력에는 클라이언트가 생성한 가상 인터페이스가 나타나야 하지만 인터페이스 이름은 클라이언트와 시스템에 따라 정해지므로 고정된 이름으로 자동 판단을 작성해서는 안 됩니다.

# Windows PowerShell
Get-NetIPInterface | Sort-Object InterfaceMetric

# macOS
route -n get default
scutil --dns

# Linux
ip address
ip route
ip rule

로컬 네트워크, 루프백과 라우팅 순환 처리

TUN에서 가장 흔한 장애는 인계하면 안 되는 트래픽을 다시 가상 인터페이스로 보내는 것입니다. 프록시 서버 자체의 연결은 TUN 라우팅에서 제외해야 합니다. 그렇지 않으면 코어가 아웃바운드를 만들 때 시스템이 다시 인바운드로 보내 순환이 발생합니다. 로컬 네트워크 대역, 루프백 주소, 로컬 서비스와 필요한 시스템 네트워크 탐색도 요구 사항에 따라 직접 연결해야 합니다. 사설 주소 규칙은 보통 기본이지만 기업 네트워크는 더 복잡한 내부 대역과 도메인을 사용할 수 있으므로 실제 라우팅 테이블에 맞춰 추가해야 하며 일반 목록 하나에만 의존해서는 안 됩니다.

활성화 후 클라이언트에는 연결 정상으로 표시되지만 모든 앱이 시간 초과된다면 먼저 서버 주소가 TUN에 다시 포착되는지 확인하세요. 인터넷은 되지만 로컬 네트워크 장치에 접근할 수 없다면 사설 주소 직접 연결과 로컬 인터페이스 라우팅을 확인합니다. UDP 앱만 이상하다면 코어 아웃바운드가 해당 트래픽을 지원하는지, 라우팅이 UDP를 허용하는지와 시스템 방화벽이 가상 인터페이스를 차단하는지 확인하세요. TUN을 중지한 뒤에도 인터넷이 되지 않으면 클라이언트가 정상 종료되어 시스템 DNS, 기본 라우팅과 시스템 프록시를 복구했는지 확인해야 합니다.

모바일 네트워크와 무선 네트워크를 전환하면 하위 인터페이스, 주소와 DNS가 바뀝니다. TUN 클라이언트는 현재 네트워크에 다시 바인딩해야 하므로 잠깐의 중단은 경로 재구성 과정일 수 있습니다. 계속 실패한다면 연결을 다시 시작하고 이전 인터페이스를 여전히 참조하는지 확인하세요. 노트북이 절전 모드에서 복귀할 때도 같은 문제가 발생할 수 있습니다. 문제 해결 시 “처음 시작할 때, 네트워크 전환 후, 절전 복귀 후 또는 장시간 실행 후” 어느 단계에서 발생했는지 기록하면 단순히 “연결할 수 없음”이라고 설명하는 것보다 훨씬 유용합니다.

성능과 MTU 판단

TUN은 사용자 공간 처리를 한 단계 추가하지만 성능 문제를 곧바로 가상 네트워크 어댑터 탓으로 돌릴 수는 없습니다. 같은 서버, 같은 네트워크와 같은 라우팅 규칙에서 시스템 프록시와 TUN의 성능을 먼저 비교한 뒤 CPU 사용량, 로그 재시도와 특정 사이트 동작을 관찰하세요. 작은 요청은 정상인데 큰 페이지나 파일 전송이 멈춘다면 MTU 또는 경로 분할과 관련되었을 수 있습니다. 모든 요청이 고르게 느려진다면 DNS, 서버 경로와 프로토콜 핸드셰이크를 먼저 확인해야 합니다. 비교 테스트 없이 MTU, 동시성과 버퍼를 동시에 바꾸지 마세요.

MTU는 클라이언트 기본값에서 시작해야 합니다. “큰 패킷은 이상하고 작은 패킷은 정상”인 현상이 안정적으로 재현되고 서버와 네트워크를 바꿔도 계속될 때만 값을 조금씩 낮추며 테스트하세요. 값을 바꾼 뒤에는 새로 연결하여 이전 연결이 계속 재사용되지 않도록 해야 합니다. 가상 네트워크 어댑터의 원리, 플랫폼별 조작과 충돌 사례는 V2Ray TUN 모드 상세 가이드에서 확인할 수 있습니다. 이 장의 핵심은 TUN을 전체 설정 체계에 포함해 다루는 것이며, 독립적인 스위치로 취급하지 않는 것입니다.

FakeDNS 작동 방식과 적용 조건

FakeDNS는 도메인 정보 손실을 해결합니다

일부 앱은 먼저 로컬에서 도메인을 해석한 뒤 대상 주소로 연결합니다. 코어가 트래픽을 받을 때 주소만 보게 되므로 도메인 라우팅 규칙을 직접 매칭할 수 없습니다. FakeDNS는 도메인에 전용 주소 풀의 임시 주소를 반환하고 도메인과 주소의 매핑을 기록합니다. 연결이 코어에 도달하면 매핑에서 원래 도메인을 복원한 뒤 도메인 라우팅을 적용합니다. 핵심 가치는 더 빠른 공용 DNS를 제공하는 것이 아니라 라우팅에 필요한 도메인 정보를 보존하는 데 있습니다.

FakeDNS는 보통 TUN 또는 DNS를 인계할 수 있는 인바운드와 함께 사용합니다. 앱의 DNS 조회가 코어로 들어오지 않으면 전용 주소를 받지 못해 매핑을 만들 수 없습니다. 조회는 코어로 들어오지만 이후 연결이 TUN을 우회하면 시스템이 전용 주소에 직접 접근하려다 실패합니다. 따라서 DNS 조회 경로와 연결 경로를 모두 인계해야 합니다. 활성화하기 전에 일반 TUN과 실제 DNS가 정상적으로 작동하는지 먼저 확인하세요. 그렇지 않으면 FakeDNS를 추가하는 것만으로 변수가 늘어납니다.

주소 풀, 매핑과 폴백

전용 주소 풀은 실제 로컬 네트워크, 기업 네트워크 또는 다른 가상 네트워크가 사용하는 대역과 겹치면 안 됩니다. 겹치면 시스템이 실제 내부 서비스를 FakeDNS로 잘못 보내거나 임시 주소를 잘못된 인터페이스로 보낼 수 있습니다. 주소 풀의 용량은 동시에 보존할 수 있는 매핑 수를 결정하지만 무작정 늘릴 필요는 없습니다. 용량 부족은 보통 이전 매핑이 회수되는 형태로 나타나며 장기 연결과 캐시를 사용하는 앱에서 불일치가 발생할 수 있습니다. 합리적인 캐시 주기를 유지하고 클라이언트 재시작이나 네트워크 전환 후 테스트 연결을 새로 만드는 것이 우선입니다.

모든 트래픽이 FakeDNS에 적합한 것은 아닙니다. 로컬 네트워크 장치 검색, 내부 도메인, 시스템 검색 도메인이 필요한 서비스와 실제 주소를 기준으로 판단하는 앱은 실제 해석을 유지하거나 우회하도록 해야 합니다. 전용 주소를 올바르게 처리하지 못하는 앱은 앱별 제외를 사용하거나 해당 도메인을 일반 DNS로 보내세요. 호환성 문제를 단순히 서버 장애로 판단하지 마세요. FakeDNS를 끄면 같은 서버가 즉시 복구되고 일반 TUN은 계속 정상이라면 도메인 매핑, 스니핑과 주소 풀 충돌을 확인해야 합니다.

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

이 부분은 일반적인 필드 관계를 보여 주며 실제 클라이언트에서는 화면이 해당 설정을 생성할 수 있습니다. 198.18.0.0/15는 벤치마크 네트워크에 자주 사용되며 전용 매핑 풀로 적합하지만 로컬 환경에서 이미 사용 중이지 않은지 확인해야 합니다. 설정 후 풀의 주소에 외부 네트워크로 직접 접근해서는 안 됩니다. 이 주소는 로컬 코어 매핑 안에서만 의미가 있습니다. 로그에 해당 주소로 요청이 도착했지만 도메인이 복원되지 않는다면 DNS 조회와 연결이 같은 매핑 컨텍스트를 사용하지 않았거나 매핑이 만료된 것입니다.

스니핑, 라우팅과 실제 DNS의 협력

스니핑은 일부 TCP, TLS 또는 HTTP 트래픽에서 도메인을 복원할 수 있고 FakeDNS는 제어된 DNS 매핑에서 도메인을 복원합니다. 둘은 비슷한 문제를 해결하지만 정보의 출처가 다릅니다. 스니핑은 트래픽에 식별 가능한 정보가 있어야 하므로 모든 프로토콜에 적용되지 않으며, FakeDNS는 조회와 연결이 모두 코어를 거쳐야 합니다. 클라이언트 기본 정책에 따라 함께 사용할 수 있지만 라우팅이 최종적으로 어느 대상을 사용하는지는 명확히 해야 합니다. 로그의 대상 도메인이 앱 요청과 다르다면 대상 덮어쓰기 정책을 확인하여 잘못된 스니핑 결과가 원래 대상을 대체하지 않도록 하세요.

FakeDNS는 임시 주소를 반환하지만 실제 DNS가 완전히 필요 없어지는 것은 아닙니다. 코어가 최종적으로 대상 서버에 연결할 때 실제 주소를 가져와야 할 수 있고, 라우팅 규칙에서 GeoIP를 사용할 때도 실제 해석 결과가 필요할 수 있습니다. 따라서 설정에는 보통 FakeDNS와 일반 리졸버가 함께 존재하며 단계별로 서로 다른 역할을 맡습니다. 일반 리졸버의 아웃바운드 설정이 잘못되면 도메인 복원은 성공했지만 최종 연결만 실패하는 현상이 발생합니다. 로그에서 매핑 매칭과 실제 주소 해석을 구분해 확인해야 합니다.

활성화 후 검증은 네 단계로 나누세요. 먼저 앱이 전용 주소를 받았는지 확인하고, 그 연결이 TUN으로 들어가는지 확인한 다음, 코어 로그에서 원래 도메인이 복원되는지 확인합니다. 마지막으로 도메인 라우팅이 예상 아웃바운드와 매칭되어 실제 연결이 완료되는지 확인하세요. 첫 단계만 확인해서는 설정이 완료되었다고 할 수 없습니다. 브라우저는 되지만 특정 앱이 실패한다면 해당 앱이 주소를 캐시하거나 독립 DNS를 사용하거나 가상 네트워크를 우회하는지 확인하세요. 오래된 매핑의 영향을 피하려면 앱을 완전히 종료하고 연결 상태를 정리한 뒤 다시 테스트해야 합니다.

되돌릴 때는 FakeDNS 서버, 주소 풀과 대상 덮어쓰기 설정을 함께 끄고 일반 DNS를 복원해야 합니다. 하나만 끄면 전용 주소 캐시가 남아 시스템이 잠시 유효하지 않은 대상에 계속 접근할 수 있습니다. 되돌린 뒤 클라이언트와 테스트 앱을 재시작하고 해석 결과가 실제 주소로 복원되었는지 확인하세요. FakeDNS는 명확한 도메인 라우팅 요구가 있고 일반 스니핑만으로 부족한 경우에 적합하며 모든 설정의 기본 전제로 사용해서는 안 됩니다.

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

구독을 외부 설정 출처로 취급하기

다중 구독 관리의 핵심은 목록에 서버를 더 많이 넣는 것이 아니라 외부 설정의 변화를 통제하는 것입니다. 각 구독은 이름, 프로토콜 매개변수, 항목 수와 사용 범위를 바꿀 수 있으므로 독립적인 이름, 업데이트 주기와 사용 중지 상태를 지정해야 합니다. 구독 주소는 클라이언트의 구독 관리에만 저장하고 라우팅 메모, 스크립트 출력이나 공유 스크린샷에 복사하지 마세요. 여러 기기에서 사용해야 한다면 각 기기에 따로 가져온 뒤 기기 용도에 맞는 로컬 그룹을 구성하세요. 데스크톱과 모바일이 완전히 같은 서버 집합을 필요로 한다고 가정하지 마세요.

각 출처에 용도, 적용 클라이언트, 마지막으로 성공한 업데이트 시각과 이상 발생 시 처리 방법을 기록하는 것이 좋습니다. 여기서 업데이트 시각은 로컬 관리용이며 서버 이름에 넣을 필요가 없습니다. 장기간 사용하지 않는 구독은 자동 업데이트를 먼저 중지하고 의존 항목이 없는지 확인한 뒤 삭제하세요. 바로 삭제하면 현재 서버가 함께 제거되거나 그룹 구성이 흐트러질 수 있습니다. v2rayN은 큰 목록 화면에서 차이를 확인할 수 있어 데스크톱 다중 구독 관리 센터로 적합합니다. v2rayNG와 v2flyNG에서는 모바일에서 실제로 필요한 출처만 유지하여 백그라운드 업데이트와 수동 선택 부담을 줄이세요.

시간을 분산한 업데이트와 변경 검토

여러 구독을 같은 시각에 일괄 업데이트하지 마세요. 위험이 낮은 출처부터 업데이트하고 추가, 삭제, 이름 변경과 프로토콜 변화를 확인한 뒤 다음 출처로 진행합니다. 업데이트 후 현재 서버가 교체되었다면 같은 출처의 확인된 항목을 먼저 선택해 테스트하세요. 항목이 대량으로 사라졌다면 즉시 다시 업데이트하거나 목록을 비우지 말고 현재 상태를 보존한 채 클라이언트 로그를 확인해야 합니다. 반복 작업으로 되돌리기에 필요한 정보가 덮어써질 수 있습니다. 자동 업데이트 주기도 지나치게 짧게 설정하지 마세요. 네트워크 전환이나 출처의 일시적 이상이 있을 때 목록이 반복해서 바뀔 수 있습니다.

변경 검토에서는 최소한 네 가지를 확인해야 합니다. 항목 수가 비정상적으로 급증하거나 감소하지 않았는지, 표시 이름이 여전히 필터 규칙에 인식되는지, 현재 선택한 서버가 보존되었는지, 프로토콜과 전송 매개변수가 바뀌었는지 확인하세요. 이름 변경은 구성에만 영향을 주지만 매개변수 변경은 연결에 영향을 줄 수 있습니다. 어떤 출처가 다른 프로토콜 기능을 사용하기 시작했다면 표시 이름만 수정하지 말고 작업 그룹을 조정하세요. 구독 형식 인식과 변환 범위는 V2Ray 구독 형식 완벽 해설을 참고하여 공유 링크, 인코딩 목록과 기본 설정을 같은 구조로 취급하지 않도록 하세요.

중복 제거, 우선순위와 장애 격리

중복 제거는 이름만 보지 말고 연결 식별 정보를 기준으로 해야 합니다. 프로토콜, 주소, 포트, 사용자 식별자, 전송 방식과 보안 매개변수를 비교하세요. 서로 다른 구독에서 제공되는 완전히 동일한 항목도 출처 측면의 가치가 있습니다. 한 출처가 업데이트에 실패해도 다른 출처가 계속 유지할 수 있기 때문입니다. 중복 항목은 낮은 우선순위 그룹으로 옮겨 평소 목록이 복잡해지는 것을 막으면서 되돌리기 능력을 보존할 수 있습니다. 클라이언트가 복잡한 뷰를 지원하지 않는다면 최소한 구독 이름에서 출처를 명확히 구분하세요.

우선순위는 안정성을 높이는 방향으로 정해야 합니다. 고정 용도의 앱에는 지속적으로 검증된 서버를 사용하고 임시 테스트 항목과 섞지 마세요. 테스트 출처는 별도 그룹에 두고 기본 선택 항목이 되지 않도록 해야 합니다. 다중 구독 자동 선택은 호환되는 후보 집합 안에서만 사용하세요. 프로토콜, 전송과 네트워크 경로 차이가 큰 항목은 하나의 빠른 전환 그룹에 넣지 않는 것이 좋습니다. 연결 변화가 DNS, 라우팅이나 앱 문제로 오인될 수 있기 때문입니다.

장애를 격리할 때는 먼저 자동 업데이트와 자동 선택을 중지하고 확인된 서버 하나를 고정한 뒤 출처를 하나씩 확인하세요. 모든 출처가 실패하면 로컬 네트워크, 시스템 인계 또는 공통 설정에 문제가 있을 가능성이 높습니다. 하나의 출처만 실패한다면 해당 출처의 해석, 매개변수 변경과 항목 상태를 집중적으로 확인하세요. 같은 출처가 v2rayN에서는 정상이고 Android 클라이언트에서는 이상하다면 코어 계열, 전송 지원, 시스템 네트워크 권한과 모바일 네트워크 제한을 비교해야 합니다. 데스크톱 설정 전체를 그대로 복사하지 마세요.

백업 범위와 복구 순서

백업에는 구독 정의, 수동 서버, 사용자 지정 라우팅, DNS, 아웃바운드와 클라이언트 환경설정을 포함해야 하지만 복구할 때 한 번에 전부 가져오지는 마세요. 먼저 구독과 서버 하나를 복원하여 기본 연결을 확인하고, 그다음 라우팅과 DNS를 복원한 뒤 마지막으로 TUN, FakeDNS와 사용자 지정 아웃바운드를 복원하세요. 클라이언트 간에 이전할 때는 공통 연결 매개변수와 규칙 의도를 우선 옮기고, 한 클라이언트의 내보내기 화면에 있는 모든 전용 필드를 다른 클라이언트가 인식한다고 가정하지 마세요.

백업 파일은 민감한 설정이므로 통제된 위치에만 보관하고 공개해서는 안 됩니다. 문제를 보여 줄 때는 구독 주소, 서버 주소, 사용자 식별자와 인증 필드를 삭제하고 구조와 관련된 일부만 남기세요. 로그에도 대상 도메인과 연결 정보가 포함될 수 있으므로 문제 해결 자료를 제출하기 전에 확인해야 합니다. 복구가 끝나면 새로운 변경 기록을 작성하여 이전 백업과 현재 구독 상태가 섞이지 않도록 하세요.

다중 구독 관리는 최종적으로 세 가지 결과를 달성해야 합니다. 어느 한 출처에 문제가 생겨도 전체 설정에 영향을 주지 않아야 하고, 업데이트 후 변경 사항을 빠르게 확인할 수 있어야 하며, 출처를 삭제하거나 중지해도 라우팅과 아웃바운드가 망가지지 않아야 합니다. 이를 위해서는 안정적인 이름, 계층형 그룹, 시간을 분산한 업데이트와 명확한 되돌리기가 필요하며 자동화 스위치를 더 늘리는 것만으로는 해결되지 않습니다. 출처가 많을수록 암묵적인 동작은 줄여야 합니다.

사용자 지정 아웃바운드, 체인 경로와 통합 문제 해결

안정적인 태그로 라우팅과 아웃바운드 연결하기

사용자 지정 아웃바운드는 라우팅 규칙이 실행되는 대상입니다. 일반적인 기본 아웃바운드는 프록시, 직접 연결과 차단이며 복잡한 설정에서는 지정 서버, DNS 전용 경로 또는 체인형 프런트 경로를 추가할 수도 있습니다. 각 아웃바운드에는 proxy, direct, block과 dns-out처럼 안정적이고 의미가 분명한 태그를 사용해야 합니다. 라우팅 규칙이 참조하는 것은 화면의 임시 표시 이름이 아니라 태그입니다. 태그를 바꾸기 전에는 모든 라우팅, DNS와 체인 관계를 확인하여 설정 문법은 올바르지만 참조 대상이 존재하지 않는 상황을 피하세요.

아웃바운드 수는 최소한으로 유지해야 합니다. 두 아웃바운드가 이름만 다르고 실제 프로토콜과 경로가 완전히 같다면 하나로 합치고 라우팅 규칙으로 대상을 구분하세요. 연결 매개변수, 프런트 경로, 주소 체계 또는 네트워크 정책이 실제로 다를 때만 독립 아웃바운드를 만드세요. 비슷한 아웃바운드가 많으면 로그를 읽기 어려워지고 구독 업데이트 후 만료된 서버를 가리킬 위험도 커집니다. 그래픽 클라이언트가 자동으로 생성하는 기본 프록시 아웃바운드는 현재 서버에 따라 바뀔 수 있으므로 사용자 지정 규칙이 교체될 수 있는 내부 태그가 아니라 안정적인 진입점을 참조하는지 확인하세요.

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

예시는 직접 연결과 차단 아웃바운드의 기본 구조를 보여 줍니다. 실제 클라이언트는 보통 프록시 아웃바운드를 자동으로 생성하므로 수동 조각이 클라이언트가 관리하는 서버 설정을 덮어써서는 안 됩니다. freedom 아웃바운드의 도메인 정책은 직접 연결 시 대상을 해석하는 방식을 결정하므로 전역 DNS와 시스템 주소 체계가 일치해야 합니다. blackhole은 매칭된 트래픽을 명확히 거부하는 데 사용합니다. 차단 후 앱에 시간 초과나 연결 실패가 표시되는 것은 예상된 결과입니다. 규칙 적용 여부는 앱의 안내 문구가 아니라 아웃바운드 태그로 판단하세요.

체인 경로의 사전 조건

체인 아웃바운드는 연결이 먼저 프런트 아웃바운드를 거친 다음 후속 아웃바운드를 연결하도록 합니다. 경로 요구가 명확한 상황에 적합하지만 핸드셰이크 단계, 장애 지점과 로그 복잡성이 늘어납니다. 설정 전에는 프런트 서버와 최종 서버를 각각 단독으로 사용할 수 있는지 확인하고 어느 구간이 DNS 해석을 담당하는지 명확히 하세요. 프런트 연결 자체가 최종 경로에 의존하면 순환이 발생합니다. 두 단계에서 서로 다른 방식으로 도메인을 해석하면 최종 대상 주소가 예상과 달라질 수도 있습니다.

체인 경로는 안정성을 높이는 만능 방법이 아닙니다. 한 단계를 추가할 때마다 연결 설정, 시간 초과와 매개변수 일치가 한 번씩 더 필요합니다. 먼저 단일 아웃바운드로 앱, 라우팅과 DNS를 검증한 뒤 프런트 경로를 추가하세요. 테스트할 때는 첫 번째 구간의 핸드셰이크 성공 여부, 두 번째 구간의 시작 여부와 최종 대상 연결 여부를 각각 기록해야 합니다. 로그에 “연결 실패”만 표시되면 최종 서버 탓으로 돌리지 말고 가장 앞선 구간부터 확인하세요.

모든 후보 항목이 동일한 프로토콜 기능과 네트워크 동작으로 검증된 경우가 아니라면 동적 자동 선택을 체인 프런트로 사용하지 마세요. 프런트 경로가 자주 바뀌면 장기 연결이 끊기고 DNS와 출구의 관계도 바뀝니다. 더 안정적인 방식은 프런트 아웃바운드를 고정하고 일정 기간 관찰한 뒤 자동 정책을 평가하는 것입니다. 체인 설정에 문제가 생겼을 때 첫 번째 되돌리기 작업은 체인 관계를 취소하고 단일 아웃바운드로 복원하는 것이며, 라우팅 예외를 계속 추가하는 것이 아닙니다.

DNS 전용 아웃바운드와 트래픽 격리

DNS 전용 아웃바운드를 만들면 조회 경로를 명확히 할 수 있지만 부트스트랩 순환을 피해야 합니다. 전용 아웃바운드에 필요한 서버 주소는 기본 네트워크로 해석하거나 직접 접근할 수 있어야 하며, 라우팅 규칙도 DNS 트래픽이 해당 DNS가 있어야 연결되는 프록시로 다시 돌아가지 않도록 해야 합니다. 설정 후 로그에서 DNS 조회와 일반 연결을 구분하여 DNS 트래픽이 dns-out을 사용하는지, 업무 트래픽은 기존 라우팅에 따라 선택되는지 확인하세요.

특정 프로토콜이나 포트를 독립 아웃바운드로 보내는 데도 트래픽 격리를 사용할 수 있지만 조건을 안정적으로 식별할 수 있어야 합니다. 포트는 앱과 같지 않고 프로세스 이름도 모든 연결을 나타내지 않습니다. 대상 도메인, 주소 집합과 명확한 네트워크 유형을 우선 사용하세요. 여러 조건을 조합해야 한다면 테스트 규칙에는 조건 하나만 먼저 작성하고 매칭을 확인한 뒤 제한을 추가하세요. 처음부터 복잡한 조건을 모두 넣으면 매칭되지 않을 때 어느 필드가 맞지 않는지 판단하기 어렵습니다.

통합 문제 해결 순서

복잡한 설정에서 장애가 발생하면 다음과 같이 통합된 되돌리기를 수행하세요. 자동 서버 선택을 끄고 확인된 서버 하나를 고정합니다. 체인 아웃바운드를 취소하고 FakeDNS를 끄며 일반 DNS를 유지합니다. TUN에서 시스템 프록시로 되돌리고, 라우팅은 사설 주소 직접 연결과 기본 프록시만 남기는 상태로 복원하세요. 이 상태에서도 실패한다면 문제는 서버 매개변수, 로컬 네트워크 또는 클라이언트 시작 계층에 있을 가능성이 큽니다. 기준 설정이 복구되면 원래 순서대로 항목을 하나씩 다시 추가하고 장애가 나타난 첫 단계에 집중하세요.

로그는 시간 순서대로 읽으세요. 먼저 설정 로드와 문법 오류를 확인하고, 인바운드가 연결을 받았는지 확인한 다음, DNS가 결과를 반환했는지, 라우팅이 어느 태그와 매칭되었는지, 해당 아웃바운드가 핸드셰이크를 시작했는지를 확인합니다. 오류가 발생한 단계와 그 직접적인 의존 항목만 점검하세요. 아웃바운드 핸드셰이크가 성공했는데 페이지 내용이 이상하다면 앱 프로토콜, 주소 체계 또는 대상 서비스를 확인하고 구독 그룹으로 돌아가 수정하지 마세요. 로그 수준은 일시적으로 높일 수 있지만 원인을 확인한 뒤에는 정상 수준으로 되돌려 불필요한 기록이 장기간 쌓이지 않도록 해야 합니다.

문제 해결 자료에는 클라이언트 이름, 운영체제, 시스템 프록시와 TUN 중 무엇을 사용하는지, 문제 발생 전 단일 변경 사항, 주요 로그 단계와 되돌리기 결과가 포함되어야 합니다. 전체 구독이나 전체 설정을 그대로 제출하지 마세요. 많은 스크린샷보다 대조 실험이 효과적입니다. 같은 서버가 기준 설정에서 정상인지, 같은 설정이 다른 네트워크에서도 정상인지, 새로 추가한 모듈을 끄면 복구되는지를 확인하세요. 이 세 가지 결과만으로도 범위를 로컬 시스템, 코어 설정 또는 서버 경로로 좁힐 수 있습니다.

설정을 완료한 후에는 구독 출처, 작업 그룹, 라우팅 순서, DNS 경로, TUN 제외 항목, FakeDNS 주소 풀과 사용자 지정 아웃바운드 의존성을 정리한 구조 설명을 저장하세요. 이후 클라이언트, 코어 데이터 또는 구독을 업데이트할 때 이 설명에 따라 항목별로 재확인합니다. 클라이언트 선택을 다시 정리해야 한다면 v2rayN, v2rayNG, v2flyNG 비교를 참고하세요. 기본 작업은 여전히 빠른 시작을 기준으로 하며, 이 페이지는 장기 유지 관리와 시스템 문제 해결에 사용합니다.