V2Ray 고급 설정: 구독, 라우팅, DNS 및 TUN

02 / 구독 정리

구독 그룹 및 서버 필터

구독은 서버를 일괄 제공하지만 서버 수가 늘어나면 선택 비용과 오작동 가능성도 함께 커집니다. 효과적인 정리 방법은 모든 노드를 긴 목록 하나에 넣는 것이 아니라 먼저 출처별로 그룹을 나눈 다음 용도에 따라 필터링하는 것입니다. v2rayN에서는 기본 그룹, 외부 구독 및 직접 구축한 노드를 분리해 관리하는 것이 좋습니다. v2rayNG와 v2flyNG에서는 구독 설정과 메모 필드로 출처를 구분할 수 있습니다. 그룹의 경계는 안정적으로 유지하고 노드 메모는 바뀌더라도 출처·용도·관리 책임을 한데 섞지 마세요.

각 구독에는 ‘일상용 구독’, ‘테스트 경로’, ‘직접 구축한 서버’처럼 식별 가능한 이름을 사용하세요. 이름에는 출처만 표시하고 현재 노드 상태는 넣지 않는 것이 좋습니다. 상태는 시간이 지나면 바뀌기 때문입니다. 수동으로 추가한 서버는 별도로 보관하고 자동 업데이트되는 구독 그룹으로 옮기지 마세요. 업데이트 후 구독에 덮어쓰기되었는지 판단하기 어려워집니다. 더 이상 사용하지 않는 구독은 먼저 자동 업데이트를 중지하고 일정 기간 지켜본 뒤 그룹을 삭제하세요. 바로 비우면 기존 메모와 선택 기록도 함께 사라집니다.

필터는 어떤 문제를 해결해야 하나요?

서버 필터는 긴 목록에서 후보 범위를 줄이는 데 적합합니다. 흔히 사용하는 기준은 메모 키워드, 프로토콜 유형, 전송 방식 및 구독 출처입니다. 필터 조건은 먼저 설명 가능해야 합니다. 키워드 하나를 입력했을 때 왜 해당 서버가 일치하는지 메모에서 알 수 있어야 합니다. 복잡한 정규식은 유연하지만 구독의 이름 형식이 조금만 바뀌어도 누락될 수 있습니다. 안정적인 방법은 같은 구독의 메모 형식을 통일하고 지역, 용도 또는 경로 유형을 키워드로 사용하는 것입니다.

필터링과 라우팅은 서로 다른 기능입니다. 필터링은 화면에 표시하거나 일괄 테스트할 서버를 정하고, 라우팅은 연결 후 특정 요청이 어느 아웃바운드로 갈지 결정합니다. 서버 필터로 트래픽 분할을 대신하지 말고, 노드가 숨겨졌다고 해서 구성에서 완전히 삭제된 것으로 생각하지도 마세요. 일부 클라이언트의 필터는 목록 표시만 바꾸며 활성 노드는 계속 작동할 수 있습니다. 일괄 삭제하기 전에 현재 선택 항목과 그룹 범위를 확인하세요.

키워드와 정규식의 사용 범위

간단한 키워드는 메모의 ‘업무’, ‘직접 구축’ 또는 프로토콜명으로 필터링하는 일상적인 선택에 적합합니다. 여러 대체 단어를 표현하려면 정규식의 선택 연산자를 사용할 수 있고, 테스트 노드를 제외하려면 부정 조건을 사용할 수 있지만 먼저 작은 범위에서 검증해야 합니다. 클라이언트마다 필터 메뉴와 정규식 기능이 다를 수 있으므로 표현식을 복사하기 전에 메모, 주소 또는 전체 표시 이름 중 어디에 적용되는지 확인하세요. 아래 표현식은 특정 노드 수나 속도 데이터에 의존하지 않는 일반적인 방법만 보여줍니다.

업무|직접 구축
^(?!.*테스트).*
(VLESS|VMess|Trojan)

첫 번째 줄은 메모에 ‘업무’ 또는 ‘직접 구축’이 포함된 항목을 찾고, 두 번째 줄은 ‘테스트’가 포함된 이름을 제외하며, 세 번째 줄은 표시 이름에 포함된 프로토콜 단어로 필터링합니다. 구독마다 이름 지정 방식이 다르다면 먼저 실제 메모를 확인한 뒤 수정하세요. 필터 결과가 비어 있으면 먼저 경계 기호와 제외 조건을 제거해 기본 키워드가 일치하는지 확인하고 제약을 단계적으로 추가하세요. 처음부터 지나치게 긴 표현식을 만들면 어느 부분에서 일치가 끊겼는지 판단하기 어렵습니다.

업데이트, 중복 제거 및 만료 항목 처리

구독 업데이트는 먼저 하나의 그룹에서 실행하는 것이 좋습니다. 업데이트 후 항목이 정상적으로 해석되는지 확인한 다음 활성 노드로 전환하세요. 같은 서버가 메모만 달리해 중복될 수도 있고, 매개변수가 달라 주소만 같을 수도 있습니다. 중복을 제거할 때는 도메인과 포트만 보지 말고 사용자 식별자, 프로토콜, 전송 방식, TLS 및 경로 등 핵심 매개변수도 비교해야 합니다. 완전히 동일한 항목에는 자동 중복 제거가 적합하지만 매개변수에 차이가 있다면 유지한 뒤 이름을 다시 정하는 편이 안전합니다.

만료 항목은 일시적인 연결 불가, 매개변수 오류 및 구독 철회의 세 가지로 나눌 수 있습니다. 한 번 연결에 실패했다고 장기 만료로 판단하지 말고 먼저 로컬 네트워크를 바꾸거나 경로가 복구될 때까지 기다리세요. 프로토콜 해석 오류가 계속되면 현재 클라이언트가 인식하지 못하는 필드를 구독에서 사용하는지 확인합니다. 업데이트 후 구독에서 사라진 항목은 일반적으로 제공자가 철회한 것이므로 자동 그룹에 수동으로 다시 복사하지 않는 것이 좋습니다. 속도 측정은 현재 네트워크 조건에서 응답을 비교하는 용도일 뿐 영구적인 정렬 기준이 아닙니다.

세 클라이언트의 그룹 관리 포인트

v2rayN은 데스크톱 목록 공간이 넓어 여러 구독 관리, 일괄 업데이트 및 세밀한 필터링에 적합하며 데스크톱 플랫폼의 우선 선택지입니다. v2rayNG는 터치 기반 목록을 사용하므로 동시에 활성화하는 구독 수를 줄이고 이름을 짧게 쓰되 명확한 접두사를 유지하는 것이 좋습니다. v2flyNG의 관리 방식은 Android 사용 습관과 비슷하지만 코어 계열이 다르므로 같은 구독을 가져온 뒤에도 프로토콜과 전송 매개변수가 모두 인식되었는지 확인해야 합니다. 재설치하거나 플랫폼을 바꿀 때는 다운로드 페이지에서 운영체제에 맞는 클라이언트를 선택하세요.

정리를 마친 뒤에는 복구 가능성도 확인해야 합니다. 현재 활성 구독과 서버를 기억하고, 한 그룹만 수동으로 업데이트해 직접 구축한 노드가 바뀌지 않는지 확인한 다음 클라이언트를 재시작해 선택 상태가 유지되는지 테스트하세요. 업데이트 후 활성 항목이 바뀌었다면 자동 선택이 켜져 있는지 또는 현재 항목이 구독으로 교체되었는지 확인합니다. 구독 주소는 지속적으로 접근할 수 있는 인증 정보이므로 공개 스크린샷, 로그 또는 공유 규칙 파일에 기록하지 마세요. 문제 해결 시에는 구독 해석 결과와 오류 유형만 설명하면 됩니다.

04 / 이름 해석

DNS 설정 최적화와 분할 해석

DNS 설정은 도메인이 주소를 얻는 방식을 결정하고 도메인 규칙과 IP 규칙 사이의 연결에도 영향을 줍니다. 시스템 DNS, 클라이언트 내장 DNS, 브라우저의 암호화 DNS 및 애플리케이션 자체 해석이 동시에 존재할 수 있습니다. 조회가 예상한 경로를 거치지 않으면 ‘라우팅은 맞지만 여전히 잘못된 아웃바운드로 연결되는’ 현상이 발생합니다. 최적화하기 전에 조회 출처를 확인하세요. 시스템 프록시는 일반적으로 모든 DNS를 자동으로 연결하지 않으며, TUN 모드가 시스템 조회를 클라이언트로 통합하기에는 더 적합하지만 브라우저나 애플리케이션이 직접 시작하는 암호화 조회도 처리해야 합니다.

DNS 분할의 기본 목표는 서로 다른 도메인이 적절한 해석 서버를 사용하게 하고, 조회 자체도 올바른 아웃바운드를 통해 전송되게 하는 것입니다. 도메인 분류, 조회 서버 및 라우팅 아웃바운드는 서로 독립적인 세 가지 결정입니다. 특정 도메인을 특정 DNS 서버에 할당했다고 해서 업무 연결도 반드시 같은 아웃바운드를 사용하는 것은 아닙니다. 이에 맞는 라우팅 규칙이 필요합니다. 반대로 업무 라우팅만 작성하고 해석 경로를 처리하지 않으면 애플리케이션이 부적절한 주소를 먼저 받아 잘못된 IP 규칙을 실행할 수 있습니다.

서버 순서와 일치 범위

코어 DNS에는 여러 서버를 설정할 수 있으며 각 서버에 도메인 일치 목록을 추가할 수 있습니다. 전용 일치 항목은 일반 서버보다 앞에 배치해야 합니다. 내부 도메인은 LAN DNS로 보내고, 지정한 외부 도메인은 암호화 조회를 사용하며, 나머지는 기본 서버로 보낼 수 있습니다. 클라이언트가 skipFallback과 같은 제어 항목을 지원한다면 이미 일치한 도메인이 대체 서버로 계속 조회되지 않게 할 수 있습니다. 다만 전용 서버가 안정적인지 확인한 뒤 사용해야 합니다. 그렇지 않으면 일치한 도메인에 사용 가능한 결과가 없어도 대체 응답을 자동으로 얻지 못합니다.

{
  "dns": {
    "queryStrategy": "UseIP",
    "servers": [
      {
        "address": "192.168.1.1",
        "domains": [
          "full:intranet.example",
          "domain:office.example"
        ],
        "skipFallback": true
      },
      {
        "address": "https://dns.example/dns-query",
        "domains": [
          "domain:service.example"
        ]
      },
      "localhost"
    ]
  }
}

예시에서는 내부 도메인을 LAN 해석 서버로 보내고, 지정한 서비스는 예시 암호화 조회 주소로 보내며, 나머지는 로컬 해석을 사용합니다. 실제 구성에서는 암호화 조회 도메인 자체도 해석되어 연결을 만들어야 하므로, 부트스트랩 해석이 아직 사용할 수 없는 동일한 암호화 채널에 의존해서는 안 됩니다. 시스템 또는 기본 DNS로 조회 서버 도메인을 먼저 해석하거나 클라이언트가 지원하는 부트스트랩 기능을 사용하세요. 로그에 조회 서버 도메인 해석 실패가 계속 표시되면 먼저 이 의존 관계를 해결해야 합니다.

조회 정책과 주소 체계

queryStrategy는 어떤 유형의 주소를 반환할지 제어합니다. UseIP는 사용 가능한 주소 체계를 활용하고, UseIPv4는 IPv4만 요청하며, UseIPv6는 IPv6만 요청합니다. 선택 기준은 로컬 네트워크와 아웃바운드 경로가 해당 주소 체계를 완전히 지원하는지 여부입니다. 시스템이 IPv6 주소를 받았지만 프록시 경로에서 IPv6 연결을 만들 수 없으면 애플리케이션이 실패를 기다린 뒤 폴백하여 첫 접속이 눈에 띄게 느려질 수 있습니다. 이때는 IPv4 정책을 임시로 사용해 확인할 수 있지만, 장기적으로는 로컬 네트워크, 노드 아웃바운드 및 라우팅 규칙이 IPv6를 처리하는지 점검해야 합니다.

모든 해석 문제를 고정된 주소 체계로 덮어서는 안 됩니다. 일부 서비스는 주소 체계에 따라 서로 다른 접속 경로를 제공하며, LAN 내부 서비스도 특정 주소 체계에서만 작동할 수 있습니다. 변경 후 내부 도메인, 일반적인 공용 도메인 및 순수 IP 연결을 각각 테스트해 다른 경로가 손상되지 않았는지 확인하세요. 하나의 애플리케이션만 이상하다면 독립 DNS나 연결 최적화 기능을 사용하는지 확인해야 합니다. 해당 조회가 클라이언트로 들어오지 않았을 수 있기 때문입니다.

DNS와 라우팅의 연동 방식

DNS 조회 자체도 네트워크 요청이므로 직접 연결할지 프록시로 보낼지 라우팅이 결정해야 합니다. 암호화 DNS가 일반 TCP 또는 HTTPS 연결을 사용한다면 서버 도메인이나 IP를 기준으로 아웃바운드를 지정할 수 있습니다. 조회를 프록시로 보낼 때는 해석이 시작되기 전에 프록시 아웃바운드가 연결 가능한 서버 주소를 확보했는지 확인하세요. 구독 노드가 서버 주소로 도메인을 사용하는 경우 시작 단계의 해석 의존성을 특히 주의해야 합니다. 가장 안정적인 시작 경로는 기본 DNS로 노드 서버 도메인을 먼저 해석한 뒤, 연결된 프록시가 이후 전용 조회를 처리하게 하는 것입니다.

라우팅에서 IPIfNonMatch를 사용하면 도메인 규칙이 적중하지 않을 때 DNS 해석을 실행한 다음 IP 규칙을 적용합니다. 이때 DNS 서버가 반환하는 주소가 라우팅 결과에 직접 영향을 줍니다. 하나의 도메인에 여러 주소가 있으면 캐시 결과가 바뀔 때 트래픽이 서로 다른 규칙에 적중할 수 있습니다. 안정적인 도메인 규칙을 우선 사용하고, IP 규칙은 지역 집합·사설 주소 및 주소 기준 판단이 꼭 필요한 대상에만 사용하세요. 모든 도메인의 주소를 수동으로 관리하는 방식은 피하는 것이 좋습니다.

캐시, 누출 경로 및 확인 방법

DNS를 확인할 때는 먼저 브라우저의 독립 해석 옵션을 끄거나 테스트 범위에 명시적으로 포함하세요. 클라이언트를 다시 연결한 뒤 시스템과 브라우저의 관련 캐시를 정리하고 새로운 조회를 한 번 실행합니다. 로그에는 도메인, 선택된 DNS 서버, 반환 주소 및 이후 업무 연결의 라우팅 결과가 표시되어야 합니다. 웹페이지 기반 검사 도구만으로는 모든 시스템 조회 경로를 확인할 수 없습니다. 해당 도구가 보는 것은 현재 브라우저뿐이며 터미널, 백그라운드 서비스 및 다른 애플리케이션은 관찰하지 못하기 때문입니다.

일반 시스템 프록시에서 DNS가 여전히 로컬 네트워크를 통해 처리된다면 이는 연결 범위의 차이이지 반드시 구성 오류는 아닙니다. 더 많은 애플리케이션을 통합하려면 TUN을 활성화하고 DNS에 명확한 인바운드와 라우팅을 설정하세요. TUN을 켠 뒤 해석 루프가 발생하면 DNS 요청이 다시 TUN으로 들어가는지, 조회 서버에 필요한 직접 연결 또는 프록시 예외가 있는지, FakeDNS가 실제 해석 규칙과 겹치지 않는지 확인합니다. 전체 분할 해석 사례는 V2Ray DNS 분할 해석 설정 자세히 보기에서 확인할 수 있습니다.

06 / 도메인 매핑

FakeDNS의 작동 방식과 적용 범위

FakeDNS는 도메인에 주소 풀에서 임시 주소를 반환하고 코어 내부에 도메인과 해당 주소의 매핑을 저장합니다. 애플리케이션이 이 임시 주소로 연결하면 코어가 매핑을 통해 원래 도메인을 복원한 뒤 라우팅과 실제 연결을 수행합니다. 주로 해결하는 문제는 일부 애플리케이션이 먼저 자체 DNS 조회를 실행한 다음 IP 연결만 TUN에 넘겨 코어가 원래 도메인을 잃고 도메인 규칙이 적중하지 못하는 상황입니다. FakeDNS는 이후 연결 단계까지 도메인 정보를 보존해 분할 라우팅 판단을 안정적으로 만듭니다.

FakeDNS는 일반 DNS 서버의 대체품이 아니며 모든 해석을 자동으로 개선하지도 않습니다. 코어가 도메인을 복원한 뒤 실제 연결을 만들 때는 여전히 구성에 따라 해석을 완료하거나 해당 아웃바운드에 맡겨야 합니다. 라우팅, 실제 DNS 또는 아웃바운드 구성이 잘못되면 FakeDNS가 문제를 더 알아보기 어렵게 만들 뿐입니다. 따라서 TUN 기본 경로와 일반 DNS가 안정된 뒤 활성화하고, 어떤 조회가 FakeDNS로 들어가며 어떤 내부 도메인이 실제 주소를 반환해야 하는지 명확히 정해야 합니다.

주소 풀과 매핑 용량

FakeDNS 구성에는 주소 풀과 매핑 용량이 포함됩니다. 주소 풀은 전용 예약 범위를 사용해야 하며 LAN, 기업 네트워크, 컨테이너 네트워크 또는 기존 가상 인터페이스와 겹치면 안 됩니다. 겹치면 시스템이 임시 주소를 실제 네트워크로 보내거나 실제 내부 주소를 FakeDNS로 잘못 전달할 수 있습니다. 용량은 동시에 저장할 수 있는 도메인 매핑 수를 결정합니다. 용량이 부족하면 오래된 매핑이 제거되고 애플리케이션이 이전 주소를 계속 보유할 때 도메인을 복원하지 못할 수 있습니다. 일상적인 사용에서는 클라이언트 기본값을 유지하고, 동시 도메인이 많으며 로그에 매핑 제거가 표시될 때만 조정하세요.

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

198.18.0.0/15는 일반적인 벤치마크용 예약 주소 범위이며 많은 구현에서 가상 매핑에 사용합니다. 사용하기 전에 로컬 네트워크와 다른 도구가 이 범위를 사용하지 않는지 확인하세요. 구성 조각은 코어 내부의 FakeDNS 객체만 나타냅니다. 조회가 실제로 이 객체에 들어가려면 해당 DNS 설정, 인바운드 스니핑 및 TUN 연결이 추가로 필요합니다. 객체만 단독으로 추가해도 시스템 조회 경로가 자동으로 바뀌지는 않습니다.

스니핑과 대상 덮어쓰기

인바운드 스니핑은 연결에서 도메인이나 프로토콜 정보를 식별하는 기능입니다. FakeDNS와 함께 사용할 때 일반적인 대상 덮어쓰기 범위에는 HTTP, TLS 및 FakeDNS 매핑이 포함됩니다. 대상 덮어쓰기를 켤지는 클라이언트 템플릿에 따라 결정해야 합니다. 복원된 도메인으로 라우팅할 수 있지만 일부 특수 연결의 대상 처리가 바뀔 수도 있습니다. 먼저 클라이언트가 제공하는 표준 FakeDNS 모드를 사용해 생성된 구성을 확인한 뒤 사용자 지정하세요. 모든 프로토콜 식별 옵션을 한꺼번에 켜지 마세요.

{
  "inbounds": [
    {
      "tag": "tun-in",
      "protocol": "tun",
      "sniffing": {
        "enabled": true,
        "destOverride": [
          "http",
          "tls",
          "fakedns"
        ],
        "routeOnly": true
      }
    }
  ]
}

routeOnly는 식별 결과를 주로 라우팅 판단에 사용하고 최종 연결 대상을 직접 바꾸지는 않는다는 뜻입니다. 대상 변경의 영향을 줄이고 싶은 환경에 적합합니다. 구체적인 필드를 현재 코어와 클라이언트 구성 방식이 지원하는지는 클라이언트가 생성한 결과를 기준으로 확인해야 합니다. 구성 로드 시 알 수 없는 필드 오류가 발생하면 사용자 지정 조각을 먼저 되돌리고 화면의 FakeDNS 옵션을 사용한 뒤 코어 계열과 구성 형식이 일치하는지 확인하세요.

FakeDNS에 맡기지 않는 것이 좋은 대상

LAN 도메인, 기업 내부 도메인, 인쇄 및 검색 서비스는 일반적으로 실제 주소가 필요하므로 FakeDNS를 우회해 내부 DNS로 보내야 합니다. 로컬 주소 판단, 인증서 바인딩 또는 특수한 해석 결과에 의존하는 애플리케이션도 가상 매핑에 적합하지 않을 수 있습니다. 제외 규칙은 최대한 구체적으로 작성하세요. 명확한 내부 도메인과 예약 접미사를 먼저 제외한 뒤 추가 문제가 있는지 관찰합니다. 광범위한 도메인을 통째로 제외하면 FakeDNS가 도메인을 보존한다는 의미가 사라집니다.

일부 애플리케이션은 DNS 반환 주소를 검증하거나 시스템 해석을 우회하거나 자체 암호화 조회를 사용합니다. 앞의 두 경우에는 FakeDNS가 적용되지 않을 수 있고, 마지막 경우에는 조회가 일반 HTTPS 연결로 TUN에 들어올 수 있습니다. 이때 코어는 연결 특성으로 도메인 복원을 시도할 수 있을 뿐입니다. 로그에 FakeDNS 조회가 보이지 않는다면 주소 풀을 반복해서 바꾸지 말고 애플리케이션의 조회가 클라이언트로 들어오는지 먼저 확인하세요.

일반적인 장애 판단 순서

활성화 후 전혀 해석되지 않는다면 먼저 DNS가 조회를 FakeDNS로 보내는지 확인합니다. 임시 주소는 반환되지만 연결에 실패한다면 TUN이 해당 주소 범위를 연결하는지와 인바운드가 도메인을 복원할 수 있는지 점검합니다. 내부 서비스만 실패한다면 내부 도메인 제외 규칙과 LAN DNS를 확인하고, 일정 시간 사용한 뒤 간헐적으로 실패한다면 매핑 용량, 애플리케이션 캐시 및 절전 모드 복구를 확인하세요. 증상마다 원인이 되는 계층이 다르므로 DNS 서버 교체만으로 모든 문제를 해결할 수는 없습니다.

확인할 때 조회가 예약 주소를 반환하는지 관찰한 뒤 코어 로그에서 같은 주소가 원래 도메인으로 매핑되는지와 최종 아웃바운드를 확인할 수 있습니다. 임시 주소는 실제 서버를 나타내지 않으므로 시스템 도구로 임시 주소에 직접 연결해 서버 도달 가능성을 판단하지 마세요. FakeDNS를 끈 뒤에는 애플리케이션과 시스템의 관련 DNS 캐시를 정리해 이미 무효화된 임시 주소로 계속 연결하지 않도록 합니다.

실제 DNS 분할과 함께 사용하기

성숙한 구성에서는 FakeDNS와 실제 DNS를 함께 사용합니다. 일반 공용 도메인은 먼저 임시 주소를 반환해 도메인을 보존하고, 내부 도메인은 LAN DNS에 직접 조회해 실제 주소를 얻으며, 노드 서버 도메인은 기본 DNS로 시작 단계에서 해석하고, 일부 지정 서비스만 전용 암호화 조회를 사용합니다. 각 도메인 그룹에는 명확한 우선순위를 부여해 같은 대상이 내부 DNS와 FakeDNS에 동시에 일치하지 않도록 하세요. 변경 후에는 공용 웹페이지, 내부 서비스, 노드 재연결 및 시스템 절전 복구를 각각 테스트해 수명 주기가 바뀌어도 매핑을 다시 만들 수 있는지 확인합니다.

08 / 아웃바운드 구성

사용자 지정 아웃바운드, 체인 포워딩 및 체계적인 문제 해결

아웃바운드는 라우팅 결정의 최종 목적지입니다. 일반적인 아웃바운드에는 프록시 노드, 직접 연결, 차단 및 로컬 또는 업스트림 SOCKS 서비스로의 전달이 있습니다. 사용자 지정 아웃바운드는 특정 업무를 독립된 출구로 보내거나 로컬의 기존 서비스를 재사용하거나 명확한 테스트 경로를 만들 때 유용합니다. 핵심은 태그가 고유하고 프로토콜 매개변수가 완전하며 의존 관계에 순환이 없는 것입니다. 라우팅은 태그로만 아웃바운드를 참조하므로 이름을 바꾼 뒤에는 모든 규칙도 함께 업데이트해야 합니다.

그래픽 클라이언트는 일반적으로 현재 노드에 따라 주요 프록시 아웃바운드를 생성하고 직접 연결 및 차단 아웃바운드도 추가합니다. 수동으로 확장할 때는 클라이언트의 병합 방식을 확인하지 않은 상태에서 이러한 기본 객체를 덮어쓰지 마세요. 더 안전한 방법은 클라이언트가 제공하는 사용자 지정 구성, 사전 구성 또는 템플릿 메뉴를 사용해 고유 태그를 새로 만들고 구체적인 규칙 하나로 테스트하는 것입니다. 실행 중인 파일을 직접 수정하면 노드 전환이나 재시작 후 사라질 수 있고 화면 상태와 실제 구성이 달라질 수도 있습니다.

로컬 SOCKS 업스트림 추가

{
  "outbounds": [
    {
      "tag": "local-socks",
      "protocol": "socks",
      "settings": {
        "servers": [
          {
            "address": "127.0.0.1",
            "port": 1081
          }
        ]
      }
    }
  ]
}

예시는 local-socks라는 아웃바운드를 만들고 연결을 로컬 1081 포트의 SOCKS 서비스로 전달합니다. 사용하기 전에 해당 포트가 실제로 수신 중인지 확인하고, 업스트림 트래픽이 같은 TUN에 다시 포착되어 자기 자신으로 돌아가지 않도록 주의하세요. 업스트림에 인증이 필요하다면 클라이언트가 지원하는 구성 구조에 실제 자격 증명을 추가하고 로컬에만 보관합니다. 테스트할 때는 먼저 명확한 도메인 하나를 이 아웃바운드로 지정하고 전체 트래픽을 바로 전환하지 마세요.

{
  "routing": {
    "rules": [
      {
        "type": "field",
        "domain": [
          "domain:service.example"
        ],
        "outboundTag": "local-socks"
      }
    ]
  }
}

규칙의 태그는 아웃바운드 태그와 철자까지 완전히 같아야 합니다. 구성 로드에 실패하면 먼저 JSON 구조, 중복 쉼표 및 필드 위치를 확인하고, 로드는 성공했지만 업스트림으로 가지 않으면 규칙 순서와 도메인 적중 여부를 확인합니다. 적중은 되었지만 연결에 실패할 때 로컬 포트, 업스트림 인증 및 순환 라우팅을 점검하세요. 계층별 점검이 노드를 계속 바꾸는 것보다 빠릅니다.

체인 포워딩의 위험 관리

체인 포워딩은 하나의 아웃바운드가 다른 아웃바운드를 통해 연결을 만들도록 합니다. 명확한 네트워크 토폴로지가 있는 환경에는 적합하지만 해석 의존성, 연결 계층 및 장애 지점이 늘어납니다. 시작하기 전에 경로를 그려 보세요. 애플리케이션이 어느 인바운드로 들어오는지, 라우팅이 어느 업무 아웃바운드를 선택하는지, 해당 아웃바운드가 어느 선행 아웃바운드를 통해 연결하는지, 노드 서버 도메인을 누가 해석하는지 적습니다. 경로의 어느 한 지점이라도 앞선 진입점으로 되돌아가면 순환이 발생할 수 있습니다.

체인 구조를 모호한 전역 규칙으로 구현해서는 안 됩니다. 선행 아웃바운드와 업무 아웃바운드에 명확한 태그를 사용하고 업스트림 서버 주소에는 필요한 직접 연결 또는 지정 라우팅을 추가하세요. 체인을 거치지 않는 기본 연결도 하나 남겨 복구에 사용합니다. 시간 초과가 발생하면 먼저 각 단계를 따로 확인한 뒤 조합 테스트를 진행하세요. 단독으로는 작동하지만 조합에서 실패한다면 DNS 시작 의존성, UDP 지원 및 TUN이 업스트림 연결을 다시 포착하는지 중점적으로 확인합니다.

직접 연결 및 차단 아웃바운드

직접 연결 아웃바운드는 LAN, 내부 서비스 및 프록시가 필요 없는 대상에 사용합니다. 차단 아웃바운드는 연결을 명확히 거부할 때 사용합니다. 차단 규칙은 구체적으로 작성하고 포괄적인 프록시 규칙보다 앞에 배치하세요. 넓은 범위의 분류를 직접 사용하면 로그인, 결제, 업데이트 또는 삽입 리소스에 영향을 줄 수 있으므로 추가 후 페이지의 기본 도메인과 리소스 도메인을 확인해야 합니다. 특정 애플리케이션만 프록시를 사용하지 않게 하려면 프로세스 규칙이나 인바운드 격리를 우선 사용하세요. 클라이언트와 코어가 안정적인 프로세스 식별을 지원하지 않을 때만 설명 가능한 도메인 및 IP 조건을 사용합니다.

직접 연결이라고 해서 모든 클라이언트 처리를 우회하는 것은 아닙니다. 트래픽이 먼저 TUN으로 들어온 뒤 코어가 직접 연결 아웃바운드를 선택할 수도 있고, 시스템 라우팅 계층에서 바로 TUN을 우회할 수도 있습니다. 두 방식은 로그, DNS 및 로컬 서비스 호환성에 서로 다른 영향을 줍니다. 기록과 통합 라우팅이 필요하다면 트래픽을 코어로 들여보낸 뒤 직접 연결할 수 있고, LAN 검색이나 장치 접근처럼 로컬 네트워크에 민감한 트래픽은 일반적으로 시스템 라우팅 계층에서 우회하면서 사설 주소 직접 연결 규칙도 유지하는 편이 적합합니다.

로그로 문제 해결 매트릭스 만들기

고급 설정 문제 해결에서는 네 가지 질문에 답해야 합니다. 트래픽이 클라이언트로 들어오는가, 도메인을 누가 해석하는가, 어떤 라우팅 규칙이 적중했는가, 최종 아웃바운드가 연결을 설정했는가입니다. 로그 수준은 문제 해결 중에만 높이고 완료 후에는 일반 수준으로 되돌려 많은 기록 때문에 검색이 어려워지지 않게 하세요. 로그에 대상 요청이 없으면 시스템 프록시, 애플리케이션 프록시 또는 TUN을 확인합니다. 요청은 있지만 도메인이 없으면 DNS 연결과 스니핑을 확인하고, 라우팅 태그가 잘못되었으면 규칙 순서를 조정합니다. 아웃바운드 연결에 실패하면 해당 서버와 업스트림을 점검하세요.

장기간 유지할 수 있는 구성 만들기

유지 관리가 쉬운 구성은 노드 이름, 임시 주소 및 화면 정렬에 대한 의존성을 최대한 줄여야 합니다. 라우팅은 안정적인 아웃바운드 태그를 참조하고 DNS는 명확한 도메인 그룹을 사용하며 구독은 출처의 경계를 유지해야 합니다. TUN과 FakeDNS는 필요할 때만 활성화하세요. 각 사용자 지정 객체에 용도를 적고 정상적으로 작동하는 기본 구성도 보존합니다. 장애가 발생하면 최근에 추가한 객체부터 비활성화해 기준 상태가 복구되는지 확인한 뒤 문제를 규칙 하나 또는 아웃바운드 하나로 좁혀 가세요.

구성을 완료한 뒤 네 차례 검수하세요. 클라이언트를 재시작해 구성을 불러올 수 있는지 확인하고, 노드를 전환해 라우팅이 이전 노드에 의존하지 않는지 확인합니다. 구독을 업데이트해 사용자 지정 그룹과 태그가 덮어써지지 않았는지 확인하고, 시스템을 재시작해 TUN·DNS·시스템 프록시가 올바르게 연결되고 복구되는지 확인하세요. 웹페이지 한 번 접속한 것만으로는 완료로 볼 수 없습니다. 내부 네트워크를 사용한다면 LAN 서비스, 내부 도메인 및 시스템 절전 복구도 추가로 확인합니다.

문제를 계속 찾지 못한다면 먼저 빠른 시작 기본 흐름으로 돌아가 최소 연결을 확인한 뒤 도움말 센터에서 설치 설정과 문제 해결 항목을 확인하세요. 시스템 프록시, DNS 또는 속도 차이가 관련된 경우 사이트의 기술 노트에 있는 계층별 사례를 함께 참고할 수 있습니다.