V2Ray 고급 설정 가이드

먼저 세 계층 설정 모델을 세우기

빠른 시작 페이지에서는 구독 가져오기, 서버 선택, 시스템 프록시 활성화, 접속 확인이라는 기본 흐름을 완료합니다. 이 가이드는 기본 흐름 이후 필요한 세부 설정을 다루며, 다중 구독 분리, 복잡한 트래픽 분기, DNS 조회 경로, TUN 인계 범위와 사용자 지정 아웃바운드를 포함합니다. 변경하기 전에 현재 설정을 세 계층으로 나누세요. 가장 바깥 계층은 v2rayN, v2rayNG 또는 v2flyNG의 인터페이스 설정이고, 중간 계층은 클라이언트가 생성해 Xray 또는 V2Fly에 전달하는 실행 설정이며, 가장 아래 계층은 운영체제의 프록시, 라우팅 테이블, 가상 네트워크 인터페이스와 이름 해석 동작입니다. 세 계층은 서로 영향을 주지만 의미는 다릅니다.

예를 들어 v2rayN의 ‘시스템 프록시 설정’은 시스템 프록시를 지원하는 앱을 로컬 리스닝 포트로 연결할 뿐, 라우팅 모드와 같은 의미가 아닙니다. ‘중국 본토 우회’는 코어 라우팅 규칙으로, 요청이 코어에 들어온 뒤 direct와 proxy 중 어느 아웃바운드로 갈지 결정합니다. TUN 모드는 운영체제 네트워크 계층에서 더 많은 연결을 인계하므로 앱이 시스템 프록시를 읽지 않아도 가상 네트워크 인터페이스로 캡처될 수 있습니다. 세 기능을 하나의 스위치처럼 취급하면 브라우저는 정상인데 명령줄은 실패하거나, 시스템 프록시를 꺼도 트래픽이 계속 코어를 통과하는 일이 흔히 발생합니다.

조정할 때마다 한 계층만 변경하세요. 먼저 현재 작동하는 설정을 저장하고, 변경 항목을 기록한 뒤 코어를 재시작하고 로그를 확인한 다음 정해진 테스트를 수행합니다. 테스트에는 최소한 도메인 요청 하나, IP를 직접 사용하는 요청 하나, 명확한 direct 대상 하나, 명확한 proxy 대상 하나가 포함되어야 합니다. 한 번에 라우팅, DNS, TUN을 함께 바꾸면 로그는 최종 실패 지점만 보여 주므로 최초의 편차가 어디서 생겼는지 역추적할 수 없습니다.

요청 하나의 실제 경로 이해하기

일반적인 시스템 프록시 환경에서는 앱이 v2rayN이 제공하는 HTTP 또는 SOCKS 인바운드에 먼저 연결합니다. 코어는 요청 대상을 읽고 필요하면 도메인을 해석한 다음 라우팅 규칙에 따라 아웃바운드 태그를 매칭합니다. direct에 매칭되면 코어가 로컬 네트워크에서 직접 연결을 만들고, proxy에 매칭되면 현재 서버에 해당하는 프록시 아웃바운드로 연결을 넘기며, block에 매칭되면 요청을 로컬에서 종료합니다. TUN 환경에서는 운영체제가 IP 패킷을 먼저 가상 네트워크 인터페이스로 보내고, 코어가 연결 대상을 복원한 다음 동일한 라우팅 및 아웃바운드 절차를 진행합니다.

라우팅 매칭은 확인 가능한 정보에 의존합니다. SOCKS 인바운드는 보통 원래 도메인을 전달하므로 코어가 domain 또는 geosite를 직접 매칭할 수 있습니다. 일부 프로그램은 먼저 도메인을 자체 해석한 뒤 대상 IP만 제출하므로, 이때 코어가 보는 것은 IP이고 도메인 규칙은 매칭되지 않을 수 있습니다. 트래픽 스니핑은 일부 연결의 핸드셰이크 정보에서 도메인을 복원할 수 있지만 모든 프로토콜에서 작동하지 않으며 잘못된 DNS 설정의 대체 수단으로 사용해서도 안 됩니다. 규칙이 매칭되지 않을 때는 로그에 기록된 대상이 도메인인지 IP인지 먼저 확인해야 합니다.

DNS 역시 독립적인 모듈이 아닙니다. 라우팅 규칙이 대상 IP 해석을 요구할 수 있고, DNS 조회 자체도 아웃바운드를 선택해야 하며, TUN에서는 시스템 조회가 코어에 가로채일 수 있습니다. 모든 DNS 요청을 하나의 원격 리졸버로 보내면서 그 리졸버의 도메인 해석이 프록시 아웃바운드에 의존하면 시작 의존성이 생길 수 있습니다. 프록시 서버가 아직 연결되지 않았는데 리졸버에도 접근할 수 없는 상황입니다. 해결책은 서버를 계속 바꾸는 것이 아니라 시작 경로에 직접 접근 가능한 부트스트랩 해석 방식을 남기고, 어떤 조회가 direct로 가고 어떤 조회가 proxy로 갈지 명확히 정하는 것입니다.

로그로 계층을 찾고 인터페이스 상태만 믿지 않기

인터페이스에 ‘연결됨’이 표시되는 것은 보통 코어 프로세스가 시작되었다는 뜻일 뿐, 모든 요청이 올바른 아웃바운드를 찾았다는 의미는 아닙니다. 문제를 확인할 때는 먼저 리스닝 포트가 열렸는지 보고, 요청이 해당 인바운드로 들어왔는지 확인한 다음, 라우팅 매칭 결과와 아웃바운드 연결 오류를 차례로 봅니다. 테스트 요청이 로그에 전혀 없다면 문제는 앱 프록시, 시스템 프록시 또는 TUN 인계 계층에 있습니다. 인바운드 기록은 있지만 규칙 결과가 예상과 다르면 대상 식별이나 라우팅 순서가 문제입니다. 예상 아웃바운드까지 매칭되었는데 연결에 실패할 때는 서버 설정, 네트워크 연결성, 시간 설정을 확인합니다.

• 현재 조작 대상이 구독 원본 항목인지, 클라이언트가 생성한 설정인지, 시스템 네트워크 설정인지 확인합니다.
• 변경하기 전에 클라이언트 설정을 내보내거나 주요 옵션을 기록해 알려진 상태로 되돌릴 수 있게 합니다.
• 테스트 중에는 프록시 설정을 덮어쓰는 다른 네트워크 도구를 종료해 포트와 라우팅 테이블이 서로 덮어쓰지 않도록 합니다.
• 동일한 대상 그룹으로 반복 테스트하고, 먼저 라우팅 매칭 변화를 비교한 다음 최종 접속 결과를 비교합니다.

데스크톱의 고급 설정은 구독 그룹, 라우팅 규칙, DNS와 TUN 진입점이 한곳에 모여 있고 로그를 대조하기 쉬운 v2rayN을 우선 사용합니다. Android에서는 v2rayNG를 사용할 수 있으며, V2Fly 코어가 필요할 때는 v2flyNG를 선택합니다. 세 클라이언트의 다운로드 경로와 지원 플랫폼은 클라이언트 다운로드 페이지에서 확인할 수 있습니다. 인터페이스 변경에 따라 항목 이름은 달라질 수 있지만 ‘인바운드—라우팅—DNS—아웃바운드’라는 코어 흐름은 동일합니다. 이후 장은 모두 이 흐름을 기준으로 설명합니다.

소스별로 그룹을 만들고 모든 항목을 한곳에 쌓지 않기

구독 그룹의 첫 번째 역할은 소스를 표시하는 것입니다. 구독을 추가할 때 각 주소에 ‘업무용 설정’, ‘모바일 백업’, ‘테스트 환경’처럼 추적 가능한 고정 메모를 지정하고 ‘구독 1’, ‘새 주소’처럼 출처를 알 수 없는 이름은 피하세요. 업데이트가 끝난 뒤에도 서버 항목은 소속 그룹 관계를 유지해야 합니다. 나중에 같은 이름의 항목, 다른 라우팅 동작, 특정 소스의 장애가 발생해도 문제 범위를 바로 좁힐 수 있습니다.

그룹의 두 번째 역할은 업데이트를 분리하는 것입니다. 구독 업데이트는 보통 원격 콘텐츠를 다시 읽고 해당 그룹의 항목을 추가, 수정 또는 제거합니다. 업데이트 전에 서버 주소, 포트, 전송 매개변수를 수동으로 바꾸었다면 다음 동기화에서 로컬 변경이 덮어써질 수 있습니다. 오래 유지할 사용자 지정 항목은 독립된 로컬 설정으로 복사하고 메모에 출처와 용도를 적으세요. ‘수정 후 더 이상 업데이트하지 않는다’는 암묵적인 약속에 의존하지 마세요. 임시 변경은 원래 값을 기록하고 테스트가 끝나면 복사본을 삭제합니다.

그룹의 세 번째 역할은 일괄 작업 범위를 제어하는 것입니다. 테스트 서버, 선택 항목 내보내기, 일괄 활성화 또는 삭제를 할 때 먼저 현재 그룹을 제한하세요. 특히 다중 구독 환경에서는 같은 메모가 서로 다른 소스에서 올 수 있으므로 표시 이름만 보고 서버 설정을 공유하는지 판단할 수 없습니다. 그룹 이름은 출처를, 항목 메모는 지역·프로토콜·용도를 나타내도록 해 두 정보가 서로 다른 역할을 맡게 하세요. 모든 속성을 지나치게 긴 이름 하나에 넣지 않는 것이 좋습니다.

필터 규칙은 보이는 집합만 줄이는 역할을 합니다.

서버 필터는 항목이 많고 이름 규칙이 안정적인 구독에 적합합니다. 일반적인 조건은 메모 포함 단어, 정규식, 프로토콜 유형 또는 그룹별 필터입니다. 먼저 포함 단어로 간단한 규칙을 만들고 결과를 확인한 뒤 정규식으로 확장하세요. 정규식에서는 대소문자, 공백, 하이픈, 전각 문자의 차이를 명확히 해야 합니다. 예를 들어 메모에 ‘백업’ 또는 ‘테스트’가 포함된 항목을 남기려면 백업|테스트를 사용할 수 있습니다. 제외하려면 클라이언트가 제공하는 제외 조건을 사용하고, 지나치게 복잡한 부정식으로 모든 논리를 흉내 내지 마세요.

필터와 삭제는 의미가 다릅니다. 필터된 항목은 구독 그룹에 계속 저장되지만 현재 화면이나 후보 목록에 표시되지 않을 뿐입니다. 항목을 삭제하면 다음 업데이트 때 다시 나타날 수 있습니다. 특정 유형이 장기간 필요하지 않다면 그룹의 필터 조건에서 제외하는 것이 우선입니다. 특정 프로토콜이나 지역만 잠시 확인하려면 화면 필터를 사용하고 구독 내용을 수정하지 마세요. 필터 결과가 비어 있으면 먼저 규칙을 모두 지워 전체 목록을 복원한 뒤 조건을 하나씩 추가하세요. 구독에 실제 항목이 없는지, 필터 표현식의 범위가 지나치게 넓은지 구분할 수 있습니다.

유지 조건:
(백업|테스트).*(VLESS|Trojan)

제외 조건:
만료|점검|임시

설명:
먼저 용도 단어를 매칭한 다음 프로토콜 단어를 매칭합니다.
제외 조건은 별도로 실행하며 유지 조건과 하나의 복잡한 표현식으로 합치지 않습니다.

예시는 필터 순서를 설명하기 위한 것이며, 실제 매칭 대상은 구독에서 제공하는 서버 메모입니다.

구독 업데이트 시 되돌릴 수 있는 상태 보존하기

업데이트하기 전에 현재 서버가 어느 그룹에 속하는지 확인하고, 현재 작동하는 항목의 메모를 기록합니다. 업데이트 직후 오래된 항목을 일괄 삭제하지 말고 추가·제거·매개변수 변화를 먼저 관찰하세요. 클라이언트가 업데이트 시 원래 항목 보존을 지원한다면 단기 문제 해결을 위해 활성화할 수 있지만, 안정화 후 중복 항목을 정리합니다. 오래된 항목과 새 항목을 동시에 장기간 보존하면 선택이 혼란스러워지고 자동 선택이 더 이상 관리되지 않는 설정을 사용할 수도 있습니다.

구독 주소를 읽지 못하면 네트워크 계층에 따라 확인합니다. 첫째 주소가 완전하고 앞뒤에 공백이 없는지 확인합니다. 둘째 구독 업데이트 요청이 직결, 시스템 프록시 따르기, 현재 코어 통과 중 어떤 방식인지 확인합니다. 셋째 반환 내용이 클라이언트가 인식할 수 있는 구독 형식인지 확인합니다. 로그인 페이지, 오류 메시지 또는 빈 내용이 반환되면 클라이언트에는 ‘해석 실패’만 표시될 수 있습니다. 이때 서버를 바꾸는 것은 보통 도움이 되지 않으므로 먼저 구독 요청 자체를 처리해야 합니다.

구독 업데이트는 성공했지만 새 항목이 없다면 현재 그룹, 필터 조건, 중복 항목 처리, 프로토콜 지원을 차례로 확인합니다. 일부 항목은 메모가 같아 중복으로 처리될 수 있고, 현재 코어가 해당 필드를 인식하지 못해 가져오지 못할 수도 있습니다. v2rayNG는 기본적으로 Xray 설정을 대상으로 하며 v2flyNG는 V2Fly 코어를 대상으로 합니다. 구독에 특정 코어 확장이 포함되어 있다면 알 수 없는 필드를 수동으로 삭제하고 계속 사용하기보다 클라이언트와 코어의 기능을 맞춰야 합니다.

안정적인 서버 선택 절차 만들기

서버 테스트는 테스트 시점, 방법, 대상에서의 성능만 보여 줄 뿐 프로토콜 매개변수 검사를 대신하지 않습니다. 먼저 설정 필드 누락, 주소 해석 불가, 전송 계층 불일치 항목을 제외한 뒤 연결 테스트를 수행합니다. 선택 후에는 실제 앱 요청으로 라우팅과 DNS를 검증하고 클라이언트 테스트 결과만 보지 마세요. 여러 항목이 같은 도메인을 공유하면 DNS 캐시와 연결 재사용 때문에 짧은 테스트 결과가 서로 영향을 줄 수 있으므로, 전환 후 기존 연결이 끝나거나 해당 앱이 재시작될 때까지 기다립니다.

검증된 기준 항목 하나를 보존하는 것이 좋습니다. 라우팅, DNS, TUN 또는 사용자 지정 아웃바운드를 변경한 뒤에는 항상 먼저 기준 항목으로 테스트하세요. 기준 항목도 실패한다면 로컬 설정에 문제가 있을 가능성이 높고, 새 항목만 실패한다면 해당 항목의 프로토콜, 포트, 전송, 보안 계층, 서버 이름을 확인합니다. 이렇게 비교하면 로컬 규칙 문제를 구독 문제로 오인하지 않고, 문제 해결 중 여러 변수를 연속해서 바꾸는 일도 막을 수 있습니다.

구독 가져오기 형식과 데스크톱·Android 진입점은 V2Ray 구독 링크 가져오기 가이드에서 계속 확인할 수 있습니다. 이 장의 핵심은 가져온 뒤의 관리입니다. 출처를 추적할 수 있고, 업데이트를 되돌릴 수 있으며, 필터를 취소할 수 있고, 선택에는 기준이 있어야 합니다. 이 네 가지가 충족되어야 다중 구독과 복잡한 라우팅을 안정적으로 운영할 수 있습니다.

먼저 아웃바운드 태그를 정하고 매칭 조건을 작성하기

라우팅 규칙의 결과는 ‘허용’ 또는 ‘거부’가 아니라 요청을 지정된 아웃바운드로 전달하는 것입니다. 일반적인 태그에는 프록시 아웃바운드 proxy, 직접 연결 direct, 차단 아웃바운드 block이 있습니다. 클라이언트가 생성하는 실제 태그는 다를 수 있으므로 규칙을 복사하기 전에 현재 아웃바운드 이름을 확인해야 합니다. 존재하지 않는 태그를 규칙에서 참조하면 코어가 시작을 거부하거나 해당 규칙이 예상대로 동작하지 않을 수 있습니다.

하나의 규칙은 도메인, IP, 포트, 인바운드 태그, 네트워크 유형 또는 프로토콜 특성으로 매칭할 수 있습니다. 도메인 조건은 특정 사이트와 geosite 분류에 적합하고, IP 조건은 LAN·사설 주소·geoip 분류에 적합하며, 인바운드 태그는 서로 다른 로컬 포트나 TUN 트래픽을 다른 아웃바운드로 보낼 때 적합합니다. 서로 관계없는 조건을 한 규칙에 지나치게 넣지 마세요. 같은 규칙 안의 여러 필드는 보통 동시에 만족해야 하므로 직관보다 범위가 좁아집니다.

규칙 목록은 순서대로 검사하며 첫 번째 매칭 항목에서 검사를 끝냅니다. 따라서 정확한 규칙은 분류 규칙보다 앞에, 분류 규칙은 최종 기본 경로보다 앞에 배치해야 합니다. 예를 들어 geosite:cn에 속하지만 프록시를 사용해야 하는 도메인은 먼저 해당 도메인에 proxy 규칙을 별도로 작성하고, 그다음 geosite:cn을 direct로 보내야 합니다. 순서가 반대면 분류 규칙이 먼저 매칭되어 뒤의 예외는 실행되지 않습니다.

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

다음은 코어 라우팅 구조의 예시입니다. 아웃바운드 태그는 클라이언트가 생성한 설정과 일치해야 합니다.

domainStrategy의 영향 이해하기

AsIs는 라우팅 단계에서 원래 대상을 우선 사용하며, IP 규칙을 위해 도메인을 자동으로 해석하지 않는다는 뜻입니다. 요청에 도메인이 포함되어 있으면 도메인 규칙이 매칭되고, IP 대상만 IP 규칙으로 바로 들어갈 수 있습니다. 동작이 단순해 주로 도메인별 분류를 사용하는 설정에 적합합니다. 단점은 도메인이 어떤 규칙에도 매칭되지 않을 때 앱이 이미 대상을 IP로 해석하지 않는 한 이후 geoip 조건이 처리하지 못한다는 점입니다.

IPIfNonMatch는 먼저 도메인 규칙을 시도하고, 매칭되지 않으면 도메인을 해석한 뒤 IP 규칙을 다시 시도합니다. ‘도메인 분류 우선, IP 지역 분류 보완’ 구조에 적합하며 흔히 균형 잡힌 선택으로 사용됩니다. 라우팅 단계의 해석은 코어 DNS 설정을 사용하므로 DNS 설정이 불완전하면 라우팅 규칙이 작동하지 않는 것처럼 보일 수 있습니다. 로그에 해석 오류가 나타나면 도메인 예외를 계속 추가하지 말고 먼저 DNS를 수정하세요.

IPOnDemand는 IP가 필요한 규칙을 만났을 때 더 일찍 해석을 시작합니다. 복잡한 규칙에서는 조회 횟수가 늘고, 원래 도메인만으로 판단하면 되는 요청도 DNS 결과의 영향을 받을 수 있습니다. IP를 미리 확보해야 한다는 명확한 요구가 없다면 ‘규칙이 매칭되지 않는다’는 문제의 일반적인 해결책으로 사용하지 않는 것이 좋습니다. 전략은 이름만 보고 어느 것이 더 완전한지 판단하지 말고 규칙 구조에 따라 선택해야 합니다.

설명 가능한 계층으로 규칙 구성하기

규칙을 다섯 계층으로 나누는 것이 좋습니다. 첫 번째 계층은 geoip:private와 내부 도메인처럼 내부망과 로컬 리소스를 처리하며 보통 direct로 보냅니다. 두 번째는 분류 결과를 덮어써야 하는 정확한 예외입니다. 세 번째는 인바운드 태그로 브라우저 포트와 개발 도구 포트를 구분하는 등 프로토콜 또는 앱별 규칙입니다. 네 번째는 geosite, geoip 같은 넓은 범위의 분류입니다. 다섯 번째는 최종 기본 경로로, 매칭되지 않은 요청을 proxy와 direct 중 어디로 보낼지 명확히 정합니다.

차단 규칙은 추적 가능하게 유지해야 합니다. 범위가 넓은 분류 목록을 바로 추가하면 앱이 실패했을 때 원격 문제인지 로컬 block 매칭인지 판단하기 어렵습니다. 먼저 명확한 도메인부터 시작하고 로그에 라우팅 결과를 남기세요. UDP, LAN 검색, 시간 동기화 같은 시스템 트래픽은 ‘필요 없어 보인다’는 이유만으로 모두 차단하지 마세요. TUN 모드에서는 이런 요청이 네트워크 상태 판단과 앱 시작에 영향을 줄 수 있습니다.

포트 규칙은 대상 포트와 전송 프로토콜을 함께 고려해야 합니다. 53만 매칭하면 TCP와 UDP DNS가 모두 포함될 수 있고, 네트워크 유형만 매칭한 UDP 규칙에는 다른 실시간 통신도 들어갑니다. DNS만 별도로 처리하려면 포트, 네트워크, 인바운드 소스를 함께 제한하세요. 특정 앱을 지정 아웃바운드로 고정하려면 계속 늘어나는 대상 도메인 목록으로 추측하기보다 독립 인바운드 포트를 설정하거나 클라이언트가 지원하는 프로세스 매칭 기능을 우선 사용합니다.

geosite와 geoip 업데이트 후 변화 처리하기

분류 데이터베이스는 동일한 규칙의 매칭 범위에 영향을 줍니다. 업데이트 후 일부 도메인의 경로가 달라졌다면 먼저 현재 코어가 데이터 파일을 읽는지, 다음으로 분류 이름이 존재하는지, 마지막으로 정확한 도메인이 새로운 집합에 포함되었는지 확인합니다. 같은 규칙을 반복해서 추가해 문제를 덮지 마세요. 첫 매칭 원칙은 규칙을 중복해도 바뀌지 않습니다. 관련 파일의 역할, 교체 방법과 규칙 장애 점검은 geoip.dat 및 geosite.dat 업데이트 방법에서 확인할 수 있습니다.

라우팅 설정을 완료한 뒤 설명이 포함된 규칙 목록을 내보내세요. 최소한 규칙 순서, 각 계층의 목적, 의존하는 아웃바운드 태그와 데이터베이스 분류를 기록합니다. 클라이언트 인터페이스의 사전 설정은 빠른 선택에 적합하지만 사용자 지정 규칙이 늘어나면 실제 생성된 설정을 기준으로 삼아야 합니다. 이렇게 하면 클라이언트 업데이트, 코어 전환, 기기 이전 시 차이가 인터페이스 사전 설정 때문인지 코어 필드 변경 때문인지 판단할 수 있습니다.

시스템 DNS, 코어 DNS, 앱 자체 해석 구분하기

시스템 DNS는 운영체제가 일반 앱에 제공하는 이름 해석 진입점입니다. 코어 DNS는 Xray 또는 V2Fly 설정의 해석 모듈로, 주로 라우팅 판단, 프록시 서버 주소 해석, 인계된 DNS 요청을 처리합니다. 일부 브라우저나 앱은 시스템 설정을 우회해 자체 암호화 DNS를 사용합니다. 세 경로가 동시에 존재할 수 있으므로 ‘DNS를 수정했다’고 할 때 어느 계층을 수정했는지 명확히 해야 합니다.

일반 시스템 프록시 모드에서 앱이 도메인을 SOCKS 또는 HTTP 프록시에 넘기면 코어가 도메인을 보고 자체 설정에 따라 처리할 수 있습니다. 앱이 먼저 시스템 DNS로 IP를 얻은 뒤 프록시에 연결하면 코어에는 IP만 보일 수 있습니다. TUN 모드에서는 시스템 DNS 요청이 가상 네트워크 인터페이스에 캡처될 수 있지만, 앱 자체 암호화 DNS는 일반 HTTPS 요청으로 실행될 수 있습니다. 해석 결과가 다를 때는 먼저 앱 내부의 사용자 지정 해석 기능을 끄고 시스템 기본 경로로 기준을 세운 다음 계층별로 복원합니다.

DNS 설정의 목표는 특정 리졸버의 응답 속도만 높이는 것이 아니라 조회 가능성, 현재 네트워크에 적합한 결과, 결과에 기반한 일관된 라우팅 판단을 보장하는 것입니다. 도메인 규칙이 geosite로 아웃바운드를 결정하는데 앱이 먼저 해석한 뒤 IP만 제출하면 최종적으로 geoip 또는 기본 규칙이 결정하게 됩니다. 두 결과 모두 정상일 수 있지만 설계 의도와 일치해야 합니다.

도메인별로 명확한 DNS 서버 지정하기

코어 DNS는 여러 서버를 설정하고 도메인 분류에 따라 선택할 수 있습니다. 내부 도메인은 내부 영역을 인식하는 리졸버로 보내고, 일반 직결 도메인은 로컬 네트워크에서 접근 가능한 리졸버를 사용할 수 있습니다. 프록시를 통해 접근해야 하는 DNS 서비스는 해당 아웃바운드를 지정하거나 라우팅 규칙이 순환을 만들지 않도록 해야 합니다. 모든 서버를 단순히 나열한 뒤 코어가 ‘최적’ 결과를 자동으로 선택할 것이라고 기대하지 마세요. 동시 조회, 폴백, 예상 IP 처리 방식은 코어와 설정 필드에 따라 다릅니다.

{
  "dns": {
    "hosts": {
      "router.internal": "192.168.1.1"
    },
    "servers": [
      {
        "address": "223.5.5.5",
        "domains": [
          "geosite:cn"
        ],
        "expectIPs": [
          "geoip:cn"
        ]
      },
      {
        "address": "1.1.1.1",
        "domains": [
          "geosite:geolocation-!cn"
        ],
        "skipFallback": true
      },
      "localhost"
    ],
    "queryStrategy": "UseIP"
  }
}

예시는 분류별 조회 구조를 보여 줍니다. 실제 주소와 아웃바운드 경로는 현재 네트워크 조건에 맞춰 설정해야 합니다.

hosts는 소수의 내부 이름을 고정하거나 특정 해석 결과를 덮어쓸 때 적합합니다. 대규모 도메인 목록의 대체 수단이 아니며 자주 바뀌는 외부 주소를 저장해서도 안 됩니다. domains는 특정 DNS 서버가 담당할 도메인 집합을 제한하며, 순서와 우선순위는 코어 규칙과 함께 이해해야 합니다. expectIPs는 반환 주소가 예상 분류에 맞는지 확인하는 데 사용됩니다. 폴백에 도움을 줄 수 있지만 분류 데이터베이스가 오래되었거나 대상이 여러 지역으로 분산되면 조건이 지나치게 엄격해 원래 사용 가능한 결과를 거부할 수 있습니다.

IPv4와 IPv6 조회 전략 선택하기

UseIP는 일반적으로 사용 가능한 IP 유형의 반환을 허용하지만 구체적인 동작은 시스템과 코어 지원에 따라 달라집니다. UseIPv4는 IPv4 결과만 요청하거나 유지하므로 현재 네트워크에 안정적인 IPv6 경로가 없을 때 적합합니다. UseIPv6는 IPv6만 사용하며 로컬, 프록시 서버, 대상 경로 모두 해당 연결성을 갖춰야 합니다. 한 번 IPv6 연결에 실패했다고 모든 IPv6를 영구적으로 끄지 마세요. 실패 지점이 로컬 출구인지 프록시 아웃바운드인지 대상 사이트인지 먼저 판단합니다.

듀얼 스택 환경의 대표적인 문제는 DNS가 IPv6 주소를 반환하지만 현재 아웃바운드가 IPv4 연결만 만들 수 있는 경우입니다. 앱이 IPv6 타임아웃을 기다린 뒤 IPv4로 폴백해 처음 열 때 느려질 수 있습니다. 코어 DNS에서 일시적으로 UseIPv4를 사용해 확인해 보세요. 지연이 사라지면 시스템 IPv6 라우팅과 아웃바운드 지원을 점검하고, 변화가 없다면 병목은 주소 체계 선택에 없습니다. 반대로 IPv4를 강제하면 IPv6만 제공하는 일부 내부 리소스가 작동하지 않으므로 내부 도메인은 별도 서버와 규칙을 사용하는 것이 좋습니다.

DNS 순환과 시작 의존성 피하기

프록시 서버 주소가 도메인이라면 코어가 시작될 때 먼저 해석해야 합니다. 유일한 DNS 서버가 아직 연결되지 않은 프록시 아웃바운드를 통해서만 접근 가능하면 순환 의존성이 생깁니다. 서버 주소를 위해 직접 접근 가능한 부트스트랩 리졸버를 준비하거나, 신뢰할 수 있는 전제에서 정적 매핑을 설정하세요. 정적 매핑은 주소 변경을 직접 관리해야 하므로 통제된 환경에 적합하고 동적 서비스를 단일 IP에 장기간 고정하는 데는 적합하지 않습니다.

DNS 라우팅 규칙에서도 순환이 발생할 수 있습니다. 모든 53번 포트 트래픽을 전용 DNS 아웃바운드로 보내는데 전용 아웃바운드 자체가 동일한 규칙에 잡히는 53번 포트 요청을 다시 만들 수 있습니다. 인바운드 태그, 대상 주소 또는 전용 아웃바운드 태그로 규칙 범위를 좁혀 코어 자체의 상위 조회가 순환에서 빠져나가게 하세요. TUN에서는 가상 네트워크 인터페이스가 보낸 조회가 같은 인바운드로 다시 리디렉션되지 않도록 해야 합니다.

캐시 문제는 먼저 정리하고 재현하는 순서로 점검해야 합니다. 앱 캐시, 시스템 DNS 캐시, 코어 캐시를 차례로 지운 뒤 조회를 한 번만 보냅니다. 캐시를 지우지 않으면 DNS 서버를 바꾼 뒤에도 이전 결과가 사용되어 잘못 판단할 수 있습니다. 설정이 안정된 것을 확인한 뒤 정상 캐시를 복원하세요. 캐시를 완전히 비활성화하면 조회량이 늘고 일시적인 네트워크 변동이 매 연결에 더 직접적으로 영향을 줍니다.

마지막으로 ‘내부 도메인, 명확한 직결 도메인, 명확한 프록시 도메인, 프록시 서버 도메인’ 네 유형을 각각 테스트합니다. 각 조회가 예상 서버로 들어가는지 확인하고 라우팅 로그와 대조해 최종 아웃바운드를 확인하세요. DNS가 정상이라는 기준은 모든 도메인이 하나의 서버에서 응답하는 것이 아니라, 각 이름이 설명 가능한 경로를 따라 연결 가능한 결과를 얻는 것입니다.

TUN이 해결하는 문제 명확히 하기

시스템 프록시는 앱이 운영체제의 프록시 설정을 능동적으로 읽어야 합니다. 브라우저와 일부 데스크톱 프로그램은 보통 지원하지만 일부 명령줄 도구, 게임 런처, 자체 네트워크 스택을 사용하는 프로그램은 무시할 수 있습니다. TUN 모드는 가상 네트워크 인터페이스를 만들고 라우팅을 조정해 더 많은 IP 트래픽을 코어로 보낸 뒤 라우팅 규칙에 따라 direct, proxy, block을 선택합니다. 인계 범위는 넓어지지만 잘못된 서버, 라우팅, DNS 설정을 자동으로 수정하지는 않습니다.

TUN을 켜기 전에 일반 시스템 프록시 모드에서 기준 서버 연결, 도메인 해석, 직결 및 프록시 규칙이 예상대로 작동하는지 확인합니다. 그렇지 않으면 TUN 전환 후 가상 네트워크 인터페이스, 라우팅 테이블, DNS 하이재킹, 권한이라는 변수가 동시에 늘어나 문제 해결 범위가 크게 확대됩니다. 일반 프록시 설정을 하나 저장해 두고 TUN이 실패하면 먼저 TUN을 끄고 시스템 네트워크를 복원한 다음 기본 경로가 여전히 정상인지 확인하세요.

v2rayN은 Windows, macOS, Linux에서 데스크톱 클라이언트를 제공하지만, 각 시스템의 가상 네트워크 인터페이스 생성, 라우팅 변경, 권한 요청 방식은 다릅니다. 인터페이스의 핵심 개념은 같습니다. TUN 인바운드를 선택하고, 스택 유형을 설정하며, 자동 라우팅과 엄격한 라우팅을 결정하고, DNS 인계를 구성한 뒤 충분한 권한으로 코어를 실행해야 합니다. 플랫폼별 설치 경로는 Windows 다운로드, macOS 다운로드, Linux 다운로드에서 확인할 수 있습니다.

네트워크 스택과 자동 라우팅 선택하기

TUN 구현에는 보통 여러 네트워크 스택 옵션이 있습니다. 시스템 스택은 운영체제의 기본 동작에 가까워 호환성 경로가 명확하고, 사용자 공간 스택은 일부 환경에서 크로스 플랫폼 처리에 편리하지만 특정 프로토콜, 조각화, 로컬 네트워크에서 동작이 다를 수 있습니다. 명확한 요구가 없다면 클라이언트가 기본으로 권장하는 항목을 먼저 사용하세요. UDP, LAN 또는 특정 앱에 문제가 생겼을 때만 다른 설정은 그대로 두고 스택만 바꿔 비교하며, MTU·DNS·라우팅 규칙을 동시에 수정하지 마세요.

자동 라우팅은 범위에 해당하는 시스템 트래픽을 가상 네트워크 인터페이스로 보냅니다. 활성화 후 기본 경로, LAN 경로, 프록시 서버 주소의 예외 경로를 확인해야 합니다. 프록시 서버 자체의 연결이 같은 TUN 인바운드로 다시 들어가면 루프가 발생합니다. 클라이언트는 보통 서버 주소와 필요한 시스템 네트워크에 대한 제외 항목을 자동으로 만들지만, 서버가 도메인을 사용하고 해석 결과가 바뀔 때는 로그를 확인해 실제 주소가 잘못 인계되지 않았는지 확인해야 합니다.

엄격한 라우팅은 TUN을 우회하는 경로를 줄이는 기능입니다. 활성화하면 LAN, 가상 머신 네트워크, 컨테이너 네트워크, 기업 네트워크 클라이언트에 영향을 줄 수 있습니다. 먼저 엄격한 라우팅을 끈 상태에서 기본 검증을 마친 뒤 인계 요구에 따라 활성화하세요. 켠 뒤 LAN 리소스만 실패한다면 사설 주소와 해당 대역에 direct 경로를 남기고, 더 앞선 프록시 규칙에 매칭되지 않는지도 확인합니다.

권한, 방화벽, 라우팅 잔여 설정 처리

가상 네트워크 인터페이스 생성과 시스템 라우팅 변경에는 보통 권한 상승이 필요합니다. 클라이언트에는 TUN이 켜졌다고 표시되지만 시스템에 해당 인터페이스가 없다면 먼저 권한 요청이 완료되었는지 확인하고 코어 시작 로그를 봅니다. 스위치를 반복해서 누르지 마세요. 시작 실패로 프로세스나 일부 라우팅이 남을 수 있습니다. 먼저 코어를 중지하고 클라이언트를 종료한 뒤 가상 인터페이스와 관련 프로세스 상태를 확인하고 다시 시작합니다.

방화벽은 프로그램 경로, 네트워크 인터페이스 유형, 네트워크 프로필에 따라 접근을 제어할 수 있습니다. 클라이언트를 업데이트하거나 데스크톱 버전과 클래식 WPF 버전을 전환하면 프로그램 경로가 달라져 기존 규칙이 더 이상 매칭되지 않을 수 있습니다. ‘시스템 프록시는 정상인데 TUN에는 트래픽이 전혀 없음’이라면 코어 프로세스가 새 가상 인터페이스를 통해 통신하도록 허용되었는지 확인하세요. ‘일부 앱은 정상이고 일부는 즉시 실패’라면 앱이 특정 물리 인터페이스에 고정되어 있는지, 현재 스택이 지원하지 않는 네트워크 방식을 사용하는지 확인합니다.

비정상 종료 후 시스템에 DNS 또는 라우팅 설정이 일시적으로 남을 수 있습니다. 먼저 TUN을 정상적으로 끄고 클라이언트를 종료한 다음 시스템 DNS 자동 설정과 기본 경로를 복원합니다. 클라이언트 프로세스가 완전히 종료된 것을 확인한 뒤에만 시스템 네트워크를 재설정하세요. 코어 실행 중 가상 네트워크 인터페이스를 직접 삭제하면 클라이언트가 이미 무효화된 인터페이스를 계속 사용해 로그에 파생 오류가 더 많이 나타납니다.

증상에 따라 TUN 장애 범위 좁히기

활성화 직후 모든 네트워크가 끊기면 먼저 기본 경로, 코어 리스닝 성공 여부, 프록시 서버가 루프에 들어갔는지 확인합니다. 도메인은 실패하지만 IP는 정상이면 DNS 인계와 상위 조회 아웃바운드를 중점적으로 봅니다. 작은 웹 리소스는 정상인데 큰 리소스가 멈추면 다른 설정은 유지한 채 MTU가 너무 높은지 테스트합니다. UDP만 이상하면 서버 프로토콜, TUN 스택, 라우팅 규칙이 UDP를 허용하는지 확인하고 DNS부터 바꾸지 마세요.

TUN을 끈 뒤에도 네트워크가 이상하면 가상 네트워크 인터페이스가 사라졌는지, 시스템 DNS가 복원되었는지, 기본 경로가 물리 네트워크를 가리키는지 확인합니다. 클라이언트 코어 재시작은 운영체제 설정 복원과 같지 않으므로 먼저 클라이언트의 중지 또는 복원 작업을 실행해야 합니다. 복원이 끝나면 클라이언트를 거치지 않는 기본 네트워크 요청으로 시스템 상태를 확인하고, 마지막에 일반 프록시 모드를 다시 활성화합니다.

TUN이 안정된 뒤 프로세스 규칙, 엄격한 라우팅, FakeDNS를 설정합니다. 항목을 하나 추가할 때마다 ‘도메인 요청, IP 요청, direct 대상, proxy 대상, LAN 리소스’ 다섯 그룹을 반복 테스트합니다. TUN의 목적은 인계 범위를 넓히는 것이지 모든 트래픽을 하나의 아웃바운드로 강제하는 것이 아닙니다. 최종 경로는 여전히 라우팅 규칙이 결정하므로 직결 대역, DNS 아웃바운드, 서버 루프 예외를 명확히 해야 합니다.

‘가짜 주소 반환, 실제 도메인 보존’ 과정 이해하기

앱이 도메인 조회를 시작하면 FakeDNS는 실제 대상 IP를 바로 반환하지 않고 전용 주소 풀에서 임시 주소를 할당해 ‘임시 주소—원래 도메인’ 매핑을 저장합니다. 앱은 이어서 이 임시 주소에 연결하고, TUN 인바운드가 연결을 캡처하면 코어가 매핑을 통해 원래 도메인을 복원한 뒤 도메인 라우팅과 실제 원격 연결을 수행합니다. 따라서 앱이 IP 패킷만 제출하더라도 코어는 geosite 또는 정확한 도메인 규칙으로 아웃바운드를 판단할 수 있습니다.

임시 주소는 로컬 매핑 범위에서만 의미가 있으며 LAN이나 실제 외부 네트워크로 전송되어서는 안 됩니다. TUN이 연결을 인계하지 않거나 라우팅 테이블이 물리 네트워크 인터페이스로 보내면 앱은 직접 연결을 시도하다 실패합니다. 따라서 FakeDNS는 DNS 인계 및 TUN 라우팅과 함께 활성화해야 합니다. DNS 설정에 FakeDNS 서버만 추가하고 반환 주소에 해당하는 연결이 코어로 들어오게 하지 않으면 ‘해석은 되지만 모든 연결이 실패’하는 전형적인 현상이 나타납니다.

FakeDNS는 주로 도메인 정보 손실을 해결하며 서버 연결 능력을 높이거나 상위 실제 해석을 대체하지 않습니다. 코어가 도메인을 복원한 뒤에도 아웃바운드 방식에 따라 실제 대상을 해석하거나 도메인을 원격으로 전달해야 합니다. 상위 DNS에 접근할 수 없거나 라우팅 태그가 잘못되었거나 서버가 대상 연결을 지원하지 않으면 FakeDNS로 해결할 수 없습니다.

주소 풀을 계획하고 실제 네트워크와 겹치지 않게 하기

주소 풀은 현재 LAN, 기업 네트워크, 가상 머신 네트워크, 컨테이너 네트워크와 겹치지 않는 전용 예약 범위를 사용해야 합니다. 임시 주소가 실제 내부 대역과 겹치면 내부 리소스 접근이 FakeDNS 매핑으로 잘못 인식되거나 외부 도메인의 임시 연결이 실제 내부망으로 전달될 수 있습니다. 활성화하기 전에 시스템 라우팅 테이블을 확인하고 물리 네트워크, VPN, 가상 머신, 컨테이너가 사용하는 대역을 기록한 뒤 충돌하지 않는 범위를 선택하세요.

주소 풀 크기는 동시에 유지할 수 있는 매핑 수를 결정합니다. 일반적인 데스크톱 사용에서는 범위를 무작정 늘릴 필요가 없으며, 지나치게 큰 범위는 기존 네트워크와 겹칠 가능성을 높입니다. 매핑에는 수명이 있으므로 앱이 캐시한 임시 주소도 유효 기간 안에 계속 인식되어야 합니다. 앱이 DNS를 오래 캐시한 상태에서 코어가 재시작되어 매핑이 사라지면 기존 연결이 잠시 실패할 수 있습니다. 이때 앱 DNS 캐시를 지우고 다시 조회하면 되며, 이전 임시 주소를 hosts에 기록해서는 안 됩니다.

{
  "dns": {
    "servers": [
      {
        "address": "fakedns",
        "domains": [
          "geosite:geolocation-!cn"
        ]
      },
      "localhost"
    ],
    "fakedns": [
      {
        "ipPool": "198.18.0.0/15",
        "poolSize": 65535
      }
    ]
  }
}

예시 주소 대역은 기준 설명을 위한 것입니다. 활성화하기 전에 로컬 시스템과 사용 중인 네트워크가 동일한 범위를 사용하지 않는지 확인해야 합니다.

FakeDNS에 들어갈 도메인 결정하기

모든 조회를 한 번에 FakeDNS로 전환하는 것은 권장하지 않습니다. 내부 도메인, LAN 장치 이름, 로컬 DNS가 반드시 응답해야 하는 영역은 실제 해석을 유지해야 합니다. 도메인 라우팅이 필요하고 TUN에 의해 인계되는 외부 도메인부터 FakeDNS에 넣고, 나머지 조회는 해당 리졸버가 처리하게 하세요. 분류 범위가 명확할수록 문제가 매핑, 실제 해석, 라우팅 규칙 중 어디에서 발생했는지 판단하기 쉽습니다.

일부 앱은 DNS 결과를 비교하거나 직접 연결 UDP 세션을 만들거나 주소를 시스템 외부의 다른 장치로 전달합니다. 이런 흐름은 임시 주소와 맞지 않을 수 있습니다. 일반 TUN에서는 정상인데 FakeDNS 활성화 후 실패하는 앱이 있다면 먼저 해당 도메인에 실제 해석 예외를 설정하고 모든 FakeDNS를 바로 끄지 마세요. 예외가 유효한지 확인한 뒤 해당 앱의 도메인 집합을 확대할 필요가 있는지 판단합니다.

FakeDNS와 트래픽 스니핑은 함께 사용할 수 있지만 역할이 다릅니다. FakeDNS는 조회 단계에서 매핑을 만들며 인계된 DNS 요청에 적합하고, 스니핑은 연결 내용에서 도메인을 복원하며 매핑이 없지만 핸드셰이크에 도메인이 포함된 트래픽에 적합합니다. 둘을 함께 켰다면 로그에서 대상 복원의 출처를 확인하세요. 복원된 도메인이 잘못되거나 규칙이 이상하면 둘 중 하나씩 끄고 테스트해 최종 도메인이 어느 경로에서 얻어졌는지 구분합니다.

매핑 경로에 따라 실패 점검

첫째 앱의 조회가 코어 DNS에 들어가는지 확인합니다. 조회가 인계되지 않아 일반 실제 IP가 반환되면 이후 FakeDNS 매핑이 만들어지지 않습니다. 둘째 반환 주소가 설정된 주소 풀에 속하는지 확인합니다. 셋째 연결을 시작하고 TUN이 해당 임시 주소를 캡처하는지 확인합니다. 넷째 코어가 매핑에서 도메인을 복원할 수 있는지 확인합니다. 다섯째 복원된 도메인이 어떤 라우팅 규칙에 매칭되는지 확인합니다. 다섯 단계를 순서대로 검증하면 중단 지점을 정확히 찾을 수 있습니다.

임시 주소는 반환되지만 연결 로그가 없다면 시스템 라우팅 또는 TUN 인계가 문제입니다. 연결 로그는 있지만 도메인을 복원하지 못하면 코어 재시작으로 매핑이 사라졌는지, 앱이 오래된 주소를 캐시했는지 확인합니다. 도메인이 올바르게 복원되었지만 잘못된 아웃바운드에 매칭되면 라우팅 규칙 순서로 돌아갑니다. 올바른 아웃바운드에 매칭되었는데도 실패한다면 실제 DNS와 아웃바운드 연결을 확인하고 FakeDNS는 더 이상 수정하지 않습니다.

설정을 완료한 뒤 최초 조회, 반복 조회, 코어 재시작 후 오래된 캐시, LAN 이름을 각각 테스트합니다. 최초 및 반복 요청은 매핑 재사용을 확인하고, 재시작 테스트는 앱 캐시 복구 동작을 확인하며, LAN 테스트는 실제 해석 예외를 검증합니다. 안정적인 FakeDNS의 기준은 도메인 분기가 설명 가능하고 내부 리소스에 영향이 없으며 재시작 후 다시 조회하면 복구되는 것이지, 모든 DNS 결과가 임시 주소가 되는 것이 아닙니다.

각 구독의 역할 정의하기

두 번째 구독을 추가하기 전에 어떤 문제를 해결하는지 먼저 정합니다. 업무 환경, 기기 용도, 프로토콜 지원, 백업 관계로 나눌 수 있지만 ‘항목이 더 많아진다’는 이유만으로 소스를 추가하지 마세요. 각 구독에는 고유 메모, 명확한 업데이트 방식, 독립된 필터 조건이 있어야 합니다. 두 소스에서 같은 이름의 항목이 많이 제공되면 이름 앞에 짧은 그룹 표시를 추가해 로그와 현재 서버 열에서 출처를 바로 구분할 수 있게 합니다.

주 구독은 일상적인 선택에 사용하고, 백업 구독은 주 소스 업데이트 실패나 특정 환경에서만 활성화하며, 테스트 구독은 자동 선택에 참여시키지 않습니다. 그룹 메모에 역할을 기록해야 일괄 업데이트와 정리의 근거가 생깁니다. 모든 구독을 계속 활성화해 섞어 표시하면 오래된 항목, 중복 항목, 테스트 설정을 잘못 선택할 가능성이 커지고 특정 매개변수 변화가 어느 소스에서 왔는지도 알 수 없습니다.

구독마다 다른 프로토콜 필드와 코어 확장을 사용할 수 있습니다. 가져오기에 성공했다고 현재 코어가 완전히 실행할 수 있다는 뜻은 아닙니다. Xray와 V2Fly의 기능 차이는 Xray 코어와 V2Fly 코어 차이 해설에서 확인할 수 있습니다. v2rayN은 데스크톱에서 주요 설정 관리를 맡길 수 있고, Android에서는 코어 요구에 따라 v2rayNG 또는 v2flyNG를 사용합니다. 클라이언트 간 이전 시 표준 공유 링크나 지원되는 구독 형식을 이전해야 하며, 한 클라이언트의 전용 설정을 그대로 교환할 수 있다고 가정하지 마세요.

업데이트 순서와 실패 시 복구 계획 세우기

일괄 업데이트는 ‘백업—테스트—주 사용’ 순서로 실행합니다. 먼저 주 사용이 아닌 그룹을 업데이트하면 구독 형식 변화, 필터 규칙 무효화, 중복 처리 이상을 미리 발견할 수 있습니다. 가져오기 구조가 정상인지 확인한 뒤 주 사용 그룹을 업데이트하세요. 업데이트 중에는 현재 연결된 항목을 유지하고 새 목록을 확인한 뒤 전환해 업데이트와 연결 전환이 동시에 일어나지 않게 합니다.

구독 업데이트에 실패했다고 즉시 그룹을 삭제하고 다시 추가하지 마세요. 먼저 반환 오류를 기록하고 요청 경로와 주소가 유효한지 확인한 뒤 단독 업데이트를 시도합니다. 삭제 후 재구성하면 그룹 필터, 업데이트 정책, 로컬 메모리를 잃을 수 있고 기존 항목과 새 항목의 대응 관계도 사라집니다. 꼭 재구성해야 한다면 그룹 설정을 내보내거나 주요 항목을 캡처하고, 새 그룹에는 임시 이름을 사용해 검증한 뒤 기존 그룹을 교체합니다.

업데이트 결과를 네 가지로 점검합니다. 전체 항목 유형이 합리적인지, 현재 항목이 여전히 존재하는지, 필터 후 선택 가능한 항목이 있는지, 프로토콜 필드를 현재 코어가 인식하는지 확인합니다. 구독 내용은 변하므로 고정된 수치에 의존하지 않습니다. 구조를 비교하는 것이 핵심입니다. 업데이트 후 목록이 갑자기 비었다면 먼저 필터를 끄고, 목록은 있지만 모두 시작되지 않는다면 코어 호환성과 공유 필드 변화를 확인합니다.

중복 항목과 로컬 복사본 처리하기

중복 여부를 메모만 보고 판단해서는 안 됩니다. 같은 이름이 다른 주소나 프로토콜을 가리킬 수 있고, 다른 이름이 같은 서버를 가리킬 수도 있습니다. 정리하기 전에 최소한 주소, 포트, 프로토콜, 전송, 보안 설정, 서버 이름을 비교하세요. 클라이언트의 자동 중복 제거가 일부 필드만 다룬다면 기능적으로 같은 항목이 남을 수 있습니다. 반대로 이름만 보고 수동 삭제하면 용도가 다른 설정을 잘못 지울 수 있습니다.

구독 항목을 수정해야 한다면 로컬 복사본으로 만들고 메모에 ‘로컬 테스트’와 출처 그룹 이름을 추가합니다. 복사본은 구독 업데이트에 의해 덮어써지지 않으며 전송 매개변수, 라우팅 정책, 코어 차이를 비교하는 데 사용할 수 있습니다. 테스트가 끝나면 유효한 변경을 관리 가능한 설정 소스에 반영하거나 설명이 명확한 로컬 항목으로 보존하세요. 추적할 수 없는 복사본을 많이 쌓지 마세요. 몇 차례 업데이트 후 원본 설정과 분리됩니다.

로컬 라우팅, DNS, TUN 설정은 보통 클라이언트 수준 설정이므로 모든 서버 항목에 복사하지 않아야 합니다. 서버 연결 매개변수와 로컬 네트워크 정책을 분리하면 구독을 전환해도 라우팅 로직이 초기화되지 않고 문제가 서버인지 로컬 정책인지 판단하기 쉬워집니다. 특정 서버 전용 아웃바운드 경로가 필요할 때만 사용자 지정 설정에 명확한 참조를 만드세요.

이전할 때 설명 가능한 설정만 가져가기

이전 전에 구독 주소, 그룹 메모, 필터 표현식, 현재 서버, 라우팅 규칙, DNS 설정, TUN 옵션을 목록으로 만듭니다. 새 기기에서 먼저 구독을 가져와 기본 연결을 확인한 뒤 필터와 라우팅을 이전하고, 마지막에 DNS·TUN·FakeDNS를 이전합니다. 운영체제가 다른 곳에 생성된 설정 전체를 바로 덮어쓰지 마세요. 인바운드 리스닝 주소, 가상 네트워크 인터페이스, 파일 경로, 권한 요구가 다를 수 있습니다.

이전 후 첫 번째 테스트는 동일한 기준 서버와 동일한 대상 그룹으로 수행합니다. 서버 연결은 정상인데 규칙이 다르면 라우팅 순서와 분류 데이터베이스를 비교하고, 도메인 동작이 다르면 시스템 DNS·코어 DNS·앱 설정을 비교합니다. TUN만 이상하면 새 시스템의 권한, 라우팅, 방화벽을 확인합니다. 계층별 이전은 단계가 더 많지만 각 단계에 명확한 복구 지점이 있습니다.

다중 구독 관리를 완료한 뒤 각 그룹의 역할, 필터 의미, 이전 순서를 기록한 문서형 설정 설명을 보관하는 것이 좋습니다. 서버의 민감한 필드는 저장할 필요 없이 구조만 설명하면 됩니다. 이렇게 하면 클라이언트 인터페이스가 바뀌거나 재설치한 뒤에도 오래된 화면 위치를 기억하지 않고 역할에 따라 복원할 수 있습니다.

최소 아웃바운드 집합부터 시작하기

관리 가능한 설정에는 최소한 주 프록시 아웃바운드, 직접 연결 아웃바운드, 차단 아웃바운드가 있어야 합니다. 주 프록시 아웃바운드는 현재 서버 연결을 담당하고, direct는 코어가 로컬 네트워크로 대상에 연결하게 하며, block은 명확히 필요 없는 요청을 종료합니다. 먼저 세 가지가 작동하는지 확인한 뒤 백업 프록시, 특정 인터페이스 직결, 체인 아웃바운드를 추가하세요. 아웃바운드가 많아질수록 라우팅 태그, DNS 경로, 로그 판단이 복잡해집니다.

각 아웃바운드는 고유하고 안정적인 tag를 사용해야 합니다. 태그는 단순한 인터페이스 이름이 아니라 라우팅 규칙, DNS 조회, 다른 아웃바운드가 연결되는 지점입니다. proxy-main, proxy-backup, direct-work처럼 소문자 영문과 하이픈을 사용하는 것이 좋습니다. 태그를 변경하면 전체 설정 참조를 검색해야 하며, 한 곳이라도 빠뜨리면 코어 시작 실패나 기본 경로 유입이 발생할 수 있습니다.

클라이언트가 현재 서버를 기준으로 자동 생성하는 프록시 아웃바운드는 서버를 전환한 뒤 달라질 수 있습니다. 사용자 지정 규칙이 클라이언트가 고정 유지하는 논리 태그를 참조한다면 전환 후에도 해당 태그가 존재하는지 확인하세요. 수동 아웃바운드를 직접 참조한다면 해당 아웃바운드를 독립적으로 저장해야 합니다. 생성된 설정 전체를 복사해 현재 서버를 고정하지 마세요. 구독 전환과 업데이트가 무효화됩니다.

{
  "outbounds": [
    {
      "tag": "proxy-main",
      "protocol": "vless",
      "settings": {
        "vnext": [
          {
            "address": "server.example",
            "port": 443,
            "users": [
              {
                "id": "00000000-0000-4000-8000-000000000000",
                "encryption": "none"
              }
            ]
          }
        ]
      },
      "streamSettings": {
        "network": "tcp",
        "security": "tls",
        "tlsSettings": {
          "serverName": "server.example"
        }
      }
    },
    {
      "tag": "direct",
      "protocol": "freedom"
    },
    {
      "tag": "block",
      "protocol": "blackhole"
    }
  ]
}

예시의 주소와 식별자는 구조를 보여 주기 위한 것이며, 실제 연결 매개변수는 유효한 설정에서 가져와야 합니다.

direct 아웃바운드의 범위를 명확히 정하기

direct는 트래픽이 코어를 우회한다는 뜻이 아니라, 요청이 코어로 들어온 뒤 freedom 아웃바운드가 로컬 네트워크에서 연결을 만든다는 뜻입니다. 따라서 코어 DNS, 주소 체계 전략, 아웃바운드 바인딩 설정의 영향을 받습니다. LAN, 내부 도메인, 명확한 직결 분류는 보통 direct로 보내지만 라우팅 규칙 순서가 올바른지 확인해야 합니다. TUN이 direct 트래픽을 인계하고 있다면 해당 아웃바운드 연결이 시스템 라우팅에 의해 다시 TUN으로 들어가지 않도록 해야 합니다.

여러 네트워크 인터페이스가 있는 환경에서는 특정 direct 아웃바운드에 송신 인터페이스나 소스 주소를 지정해 업무 네트워크와 일반 네트워크를 분리할 수 있습니다. 설정 전에 인터페이스 이름이 안정적인지 확인하고 대상 대역에 해당 인터페이스로 접근할 수 있는지 검증하세요. 시스템 절전, 네트워크 전환, 인터페이스 재생성 후에는 바인딩 이름이 무효화될 수 있습니다. ‘기본 direct는 정상인데 사용자 지정 direct는 실패’하면 먼저 바인딩을 제거해 기준 상태를 복원한 뒤 인터페이스와 소스 주소를 확인하고 대상 라우팅 규칙은 바꾸지 마세요.

차단 아웃바운드는 명확히 매칭된 트래픽만 받아야 합니다. block 매칭은 보통 로컬에서 즉시 실패하며 원격 타임아웃과 다릅니다. 로그에 요청이 block으로 들어간 것이 보이면 서버를 계속 확인할 필요가 없습니다. 문제 해결을 쉽게 하려면 차단 규칙을 한곳에 모으고 목적을 적어 여러 사전 설정과 사용자 지정 목록에 흩어 놓지 마세요.

프록시 체인은 신중하게 사용하기

체인 아웃바운드는 하나의 프록시 아웃바운드가 다른 아웃바운드를 통해 연결을 만들게 합니다. 명확한 네트워크 토폴로지가 있는 환경에 적합하지만 연결 계층이 한 번 이상 늘어납니다. 각 계층에는 서버 해석, 라우팅, 전송, 오류 처리가 필요합니다. 설정하기 전에 각 아웃바운드를 단독으로 검증하고 참조를 연결하세요. 체인이 실패하면 가장 바깥쪽 연결부터 로그를 확인해 요청이 실제로 어느 계층까지 도달했는지 판단합니다.

아웃바운드 참조는 루프를 피해야 합니다. proxy-a가 proxy-b를 통해 연결되는데 proxy-b도 proxy-a를 통해 연결되면 둘 다 기본 연결을 만들 수 없습니다. 더 알아채기 어려운 루프는 라우팅에서 발생합니다. proxy-b의 서버 주소가 규칙에 의해 다시 proxy-a로 보내지고 proxy-a는 다시 proxy-b에 의존하는 경우입니다. 체인에 포함된 서버 주소에 높은 우선순위 규칙을 설정하고 direct 또는 특정 선행 아웃바운드 중 어디로 보낼지 명확히 하세요.

체인 설정에서는 DNS도 고려해야 합니다. 각 서버 도메인을 어느 계층이 해석하는지, 조회가 어느 아웃바운드를 사용하는지, 해석 결과가 TUN에 의해 인계되는지를 미리 정해야 합니다. 가장 안정적인 방법은 직접 해석 가능한 진입 서버로 첫 계층을 만든 뒤 이후 연결을 이미 구축된 아웃바운드를 통해 보내는 것입니다. 최하위 연결이 최상위 DNS 경로에 의존하게 하지 마세요.

태그로 전체 설정을 연결해 검증하기

사용자 지정 아웃바운드를 완료한 뒤 모든 태그와 참조 대상을 목록으로 만듭니다. 각 라우팅 규칙이 참조하는 아웃바운드는 반드시 존재해야 하고, 각 체인 참조는 독립적으로 구축 가능한 선행 아웃바운드를 가리켜야 하며, 전용 DNS 아웃바운드는 자기 자신에 의존해서는 안 됩니다. TUN 제외 경로는 프록시 서버 연결을 포함해야 합니다. 그다음 한 번도 참조되지 않은 아웃바운드가 있는지 확인합니다. 참조되지 않은 항목이 반드시 오류는 아니지만, 보통 오래된 설정이 남았거나 예상한 규칙이 아직 만들어지지 않았다는 뜻입니다.

• 주 프록시 아웃바운드로 명확한 프록시 도메인을 테스트하고 로그에서 태그를 확인합니다.
• direct로 LAN과 명확한 직결 대상을 테스트하고 TUN 인바운드로 다시 돌아오지 않는지 확인합니다.
• 임시 정확 규칙 하나로 백업 아웃바운드를 테스트한 뒤 테스트가 끝나면 임시 규칙을 삭제합니다.
• 명확한 차단 대상을 발생시키고 로그에 로컬 block 매칭이 표시되는지 확인합니다.
• 코어를 재시작한 뒤 다시 테스트해 기존 연결이나 캐시로 유지되는 잘못된 정상 상태를 배제합니다.

설정을 시작할 수 없으면 먼저 JSON 구조를 검증한 뒤 중복 태그, 알 수 없는 아웃바운드 참조, 프로토콜 필수 필드를 확인합니다. 시작은 되지만 경로가 잘못되었다면 라우팅의 첫 매칭 항목을 확인합니다. 경로는 올바르지만 연결에 실패하면 대상 아웃바운드 자체를 점검합니다. 시작 오류, 라우팅 오류, 연결 오류를 한 번의 변경에서 함께 처리하지 마세요.

이제 구독, 필터, 라우팅, DNS, TUN, FakeDNS, 아웃바운드가 완전한 흐름을 구성합니다. 이후 규칙을 추가할 때는 요청 진입점에서 흐름을 따라 계층별로 판단하고 최종 오류만 보고 전체 설정을 추측하지 마세요. 기본 환경을 다시 만들려면 사용 가이드로 돌아가 빠른 흐름을 따르고, 클라이언트나 데스크톱 버전을 바꾸려면 V2Ray 클라이언트 다운로드 페이지로 이동하세요. 설정을 완료한 뒤 구조 설명과 작동하는 기준 설정을 보존하고, 다음 변경에서는 변수 하나만 바꾸세요.