Clash 프로토콜 및 코어 기술 참고서

02 · TCP FAMILIES

SS, VMess, Trojan, VLESS의 설계상 선택

SS: 간결한 구조와 명확한 암호화 방식

Shadowsocks는 보통 SS라고 줄여 부릅니다. 핵심 방식은 비교적 가벼운 프로토콜 구조로 프록시 트래픽을 전달하고, 사전 공유 비밀번호와 지정한 암호화 방식으로 데이터를 보호하는 것입니다. 최신 설정에서는 현재 코어가 지원하는 AEAD 방식을 사용하고 서버와 클라이언트의 암호화 방식, 비밀번호, 포트를 완전히 일치시켜야 합니다. SS는 필드가 적어 구독 가져오기와 클라이언트 간 마이그레이션이 비교적 간단하며, 로그에 나타난 실패 원인도 포트·비밀번호·암호화 방식·네트워크 도달 가능성을 차례로 확인하며 추적하기 쉽습니다.

필드가 적다고 모든 SS 노드의 성능이 같은 것은 아닙니다. 서버 구현, 암호화 알고리즘의 하드웨어 가속, UDP 릴레이, 플러그인 매개변수와 기본 네트워크가 결과에 영향을 줍니다. 일부 구독에는 추가 운반 계층을 제공하는 plugin과 plugin-opts가 포함됩니다. 현재 코어가 지정된 플러그인을 지원하지 않으면 server, port, cipher, password가 모두 올바르더라도 노드를 사용할 수 없습니다. 리소스가 제한된 라우터에서는 SS가 이해하기 쉬운 출발점인 경우가 많지만, 암호화 비용은 목표 아키텍처에서 테스트해야 하며 데스크톱 프로세서 결과만으로 추정해서는 안 됩니다.

VMess: 다양한 인증, 시간 및 전송 옵션

VMess는 V2Ray 생태계에서 시작했으며, 설정에는 사용자 식별자, alterId, 암호화 옵션, 네트워크 전송과 TLS 등의 필드가 자주 포함됩니다. 과거 설정에서는 다양한 alterId 값이 보이며, 최신 서버 배포는 더 단순한 조합을 사용하는 경우가 많지만 클라이언트는 이전 구독과의 호환성을 위해 파싱 필드를 유지할 수 있습니다. VMess 인증은 시간 상태에 민감하므로 기기 시간이 크게 어긋나면 인증 실패가 발생할 수 있습니다. 문제를 확인할 때 주소와 사용자 식별자뿐 아니라 시스템 시간이 정상적으로 동기화되는지도 확인하세요.

VMess의 실제 복잡성은 여러 전송 방식을 조합할 수 있다는 점에서 비롯됩니다. TCP, WebSocket, HTTP, gRPC는 경로, 리버스 프록시와 서버 설정에 서로 다른 요구 사항이 있습니다. WebSocket 설정에서는 path와 Host를 확인하고, gRPC에서는 service-name을 확인해야 합니다. TLS를 활성화했다면 servername, 인증서 검증과 ALPN도 점검해야 합니다. 구독 변환 도구가 잘 사용되지 않는 전송 필드를 누락하는 경우가 있어 노드 이름과 기본 정보는 정상인데 핸드셰이크만 계속 실패할 수 있습니다. 이런 문제는 프록시 모드를 계속 바꾸기보다 변환 전후의 단일 노드 설정을 필드별로 비교해 해결해야 합니다.

Trojan: TLS 운반과 인증서 매개변수가 핵심

Trojan은 보통 표준 TLS 연결을 통해 데이터를 전달하며, 인증의 핵심은 비밀번호입니다. 설정 자체는 복잡해 보이지 않지만 TLS 관련 필드가 연결 성립 여부를 결정합니다. server는 실제 연결 주소이고 servername 또는 SNI는 TLS 핸드셰이크의 호스트 이름입니다. 두 값은 같을 수도 있고 다를 수도 있습니다. 도메인으로 연결한다면 DNS 해석, 인증서 유효성, 호스트 이름 일치가 모두 충족되어야 합니다. 구독이 도메인을 IP로 바꾸면서 올바른 servername을 유지하지 않으면 TCP에는 도달하지만 TLS 검증이 실패하는 경우가 흔합니다.

일부 사용자는 인증서 오류를 우회하려고 바로 skip-cert-verify를 활성화하지만, 이는 도메인·인증서 체인·시스템 시간 문제를 가릴 수 있습니다. 더 안정적인 순서는 먼저 기기 시간을 확인하고, servername이 인증서 이름과 일치하는지 검사한 다음, 서버 인증서 체인과 네트워크 경로를 확인하는 것입니다. 인증서 검증이 실패한 이유를 명확히 알고 그 위험을 받아들일 때만 검증 정책을 조정해야 합니다. Trojan은 WebSocket이나 gRPC 같은 운반 방식도 사용할 수 있습니다. 문제 해결 순서는 VMess와 비슷하게 TLS를 먼저 확인하고 path, Host 또는 service-name을 점검한 뒤 UDP와 정책 그룹 동작을 확인합니다.

VLESS: 프로토콜 계층 부담을 줄이고 전송 계층에 보안을 의존

VLESS 역시 V2Ray 계열에서 시작했지만 설계상 VMess와 같은 암호화 메커니즘을 프로토콜 계층에서 제공하지 않으며, 일반적으로 TLS 또는 다른 보안 전송에 기밀성과 신원 검증을 의존합니다. 사용자 식별자로 인증하고, uuid, flow, network, tls, servername과 전송 방식에 따른 추가 필드를 흔히 사용합니다. 프로토콜 계층의 처리가 더 직접적이어서 유연한 전송 조합이 필요한 배포에 자주 사용되지만, ‘필드가 가볍다’고 해서 보안 전송을 생략해도 된다는 뜻은 아닙니다.

VLESS 설정의 호환성 문제는 확장 기능에 집중됩니다. flow, Reality, 클라이언트 지문, 전송 세부 사항, UDP 동작에 대한 지원 시점은 코어마다 다릅니다. mihomo는 여러 VLESS 확장을 지원하지만 실제로 사용할 수 있는 필드는 현재 코어 문서와 실행 로그를 기준으로 확인해야 합니다. 구독에 알 수 없는 필드가 있으면 파서가 이를 무시할 수도 있고 노드 전체를 거부할 수도 있습니다. 오류가 발생하지 않고 무시되는 경우에는 노드가 가져와진 것처럼 보여 실행 단계에서 실패하므로 더 발견하기 어렵습니다. 다른 클라이언트로 마이그레이션하기 전에는 핵심 확장 기능이 변환 과정에서 사라지지 않았는지 확인하세요.

proxies:
  - name: "SS baseline"
    type: ss
    server: example.com
    port: 443
    cipher: aes-128-gcm
    password: "your-password"
    udp: true

위 예시는 SS 노드의 최소 구조만 보여 주며 필드 관계를 파악하기 위한 것입니다. 실제 주소, 포트, 비밀번호와 암호화 방식은 서버 설정에서 가져와야 합니다. YAML은 들여쓰기에 민감하므로 목록 항목 아래 필드는 같은 계층을 유지해야 합니다. 비밀번호에 콜론, 샵 또는 기타 특수 문자가 포함되면 따옴표를 사용하세요. 설정 로드 실패와 연결 실패는 서로 다른 문제입니다. 전자는 YAML 문법과 필드 이름을 먼저 확인하고, 후자는 네트워크·인증·서버 상태를 확인해야 합니다.

04 · PERFORMANCE

연결 속도, 리소스 사용량과 모바일 배터리

연결 설정 시간과 지속 처리량은 같은 지표가 아닙니다

웹페이지 로딩 속도는 DNS, TCP 또는 QUIC 핸드셰이크, TLS, 서버 처리와 페이지 리소스 수가 함께 결정합니다. 프로토콜 핸드셰이크가 가벼워도 이 중 일부 시간만 줄일 수 있습니다. DNS가 느리거나 페이지가 여러 도메인에 연결해야 한다면 단일 연결의 장점이 체감 성능으로 이어지지 않을 수 있습니다. 지속 다운로드는 경로 용량, 혼잡 제어와 서버 출구에 더 크게 좌우됩니다. 짧은 연결 테스트는 여러 대상을 반복 방문해 캐시 영향을 줄이고, 지속 전송 테스트는 충분한 시간 동안 진행하며 속도 안정성, 주기적인 0 속도 발생 여부와 네트워크 전환 후 복구를 관찰해야 합니다.

다중화도 신중하게 이해해야 합니다. 여러 논리 연결을 더 적은 수의 하위 연결에 넣으면 반복 핸드셰이크를 줄일 수 있지만, 하위 연결에 혼잡이나 중단이 발생했을 때 영향 범위도 커집니다. TCP의 다중화는 여전히 단일 TCP 연결의 패킷 손실 복구 영향을 받을 수 있고, QUIC의 다중 스트림 설계는 스트림 간 차단을 줄이는 대신 사용자 공간의 상태 관리 비용을 늘립니다. 짧은 요청이 많을 때는 다중화가 효과적일 수 있지만 소수의 장시간 대용량 연결에서는 이득이 뚜렷하지 않을 수 있습니다. 기본적으로 끄거나 켜는 것을 절대적인 결론으로 보지 말고 애플리케이션 유형에 따라 테스트해야 합니다.

CPU, 메모리와 암호화 비용

SS의 리소스 사용량은 암호화 방식, 프로세서 명령어 집합과 동시 연결 수에 따라 달라집니다. 하드웨어 가속을 지원하는 데스크톱 프로세서는 일반적인 AEAD 알고리즘을 효율적으로 처리할 수 있고, 일부 저전력 아키텍처는 다른 알고리즘에 더 적합할 수 있습니다. Trojan, VMess over TLS, VLESS over TLS는 모두 TLS 처리 비용을 부담하며, 실제 비용은 전송 계층에서 WebSocket, gRPC 또는 추가 다중화를 사용하는지에도 영향을 받습니다. Hysteria2와 TUIC은 암호화 외에도 사용자 공간에서 QUIC의 확인 응답, 재전송, 혼잡과 스트림 상태를 관리해야 합니다.

메모리 사용량은 보통 프로토콜 이름 하나만으로 결정되지 않습니다. 연결 수, 규칙 규모, DNS 캐시, TUN 라우팅, 로그 수준과 provider 수가 단일 노드 간 차이보다 더 크게 나타날 수 있습니다. 라우터에서 메모리 압박이 발생하면 먼저 불필요한 규칙 집합을 줄이고, 지나치게 긴 provider 체인을 단축하며, 상세 로그의 지속 기록을 제한한 뒤 프로토콜을 비교하세요. 데스크톱에서는 시작 직후 수치만 기록하지 말고 장시간 실행 후 계속 증가하는지 관찰해야 합니다. 비정상적인 증가가 발생하면 설정 구조와 재현 절차를 보존하는 것이 특정 프로토콜이 ‘메모리를 더 많이 사용한다’고 단정하는 것보다 원인 파악에 유용합니다.

모바일 배터리 소모는 깨우기 빈도가 좌우합니다

휴대전화 배터리 사용량은 암호화 계산뿐 아니라 무선 모듈과 CPU가 깨어나는 빈도에 더 크게 좌우됩니다. 잦은 노드 상태 점검, 짧은 DNS 캐시, 지속적인 로그 기록, 백그라운드 속도 측정과 과도하게 적극적인 연결 유지는 깨우기 횟수를 늘립니다. 매번 처리량이 작더라도 장시간 누적되면 대기 시간이 크게 줄어듭니다. QUIC 기반 노드는 NAT 매핑을 유지하기 위해 연결 유지 패킷을 보낼 수 있고, TUN 모드는 더 많은 시스템 트래픽을 처리해야 합니다. 기기에 백그라운드 애플리케이션이 많다면 이러한 요인이 겹칩니다.

최적화는 프로토콜을 바꾸기 전에 전역 동작부터 조정하는 순서가 적절합니다. 장애 발견에 필요한 합리적인 간격으로 상태 점검 주기를 설정하고 여러 provider가 동시에 고빈도로 탐색하지 않게 하세요. 실제 사용하는 정책 그룹만 남기고, 디버깅이 끝나면 일반 로그 수준으로 되돌리며, 모든 트래픽을 인계받을 필요가 없으면 시스템 프록시를 우선 사용하세요. LAN 연결 스위치도 실제 요구 사항에 맞는지 확인해야 합니다. 이러한 조정을 마친 뒤 같은 시간대에 TCP와 QUIC 노드를 비교하세요. 테스트 중에는 화면 밝기, 애플리케이션 활동과 네트워크 유형을 비슷하게 유지해야 시스템 스케줄링 차이가 프로토콜 차이를 가리지 않습니다.

재현 가능한 테스트 기록 만들기

테스트 표에는 최소한 기기, 운영체제, 클라이언트, 코어, 네트워크 유형, 인계 방식, DNS 모드, 노드 프로토콜과 테스트 시간을 기록해야 합니다. 한 번에 하나의 변수만 바꾸세요. 예를 들어 규칙 모드와 시스템 프록시를 고정하고 SS와 Hysteria2 노드만 교체한 뒤, 다음 라운드에서 노드를 고정하고 시스템 프록시와 TUN을 비교합니다. 매 라운드 성공률과 오류 유형도 함께 기록해야 합니다. 연결 5회 중 2회가 시간 초과라면 성공했을 때 속도가 아무리 높아도 자동 선택 그룹의 유일한 노드로는 적합하지 않습니다.

모바일 배터리는 최소 한 번의 평소 사용 주기 전체를 관찰하고, 시스템 배터리 화면에서 클라이언트의 전면 및 백그라운드 활동을 확인해야 합니다. 몇 분간의 짧은 실행만으로는 대기 상태의 연결 유지 비용을 판단할 수 없습니다. 배터리 소모가 비정상적이면 먼저 모든 능동 상태 점검을 중지하고 상세 로그를 끈 뒤 하나씩 복원해 깨우기의 원인을 찾을 수 있습니다. 백그라운드 실행과 절전 정책에 대한 추가 단계는 Clash 모바일 배터리 소모가 빠를 때 해결 방법을 참고하세요.

06 · SUBSCRIPTIONS

구독 형식, 설정 호환성과 필드 보존

노드 링크, 노드 목록과 전체 설정

‘구독’은 서로 다른 세 가지 콘텐츠를 가리킬 수 있습니다. 첫 번째는 ss, vmess, trojan, vless 링크처럼 여러 프로토콜 링크로 구성된 노드 목록이며, 클라이언트나 변환 서비스가 링크를 Clash 노드로 파싱합니다. 두 번째는 이미 변환된 proxies 목록으로, 노드만 포함하고 전체 규칙과 DNS는 포함하지 않습니다. 세 번째는 노드 외에 proxy-groups, rules, rule-providers, dns, tun 등을 포함하는 완전한 Clash 또는 mihomo 설정입니다. 가져오기 전에 유형을 판단하면 전체 설정을 노드 provider로 잘못 처리하거나 구독 업데이트로 로컬 규칙을 덮어쓰는 일을 피할 수 있습니다.

노드 링크는 도구 간 전달에 적합하지만 모든 확장 매개변수가 통일된 방식으로 표현되는 것은 아닙니다. VLESS의 flow와 Reality 필드, Hysteria2의 대역폭·난독화 매개변수, TUIC의 인증·혼잡 제어 옵션은 링크 규격, 생성기 또는 변환기에 따라 누락될 수 있습니다. 전체 YAML은 더 많은 필드를 표현할 수 있지만 대상 코어에 대한 의존성도 명확합니다. 여러 mihomo 클라이언트 사이에서 복잡한 설정을 옮겨야 한다면 공유 링크로 반복 변환하는 것보다 YAML을 보존하는 편이 안정적입니다.

proxy-providers는 출처를 관리하며 프로토콜 변환과는 다릅니다

proxy-providers를 사용하면 mihomo가 파일 또는 URL에서 노드 집합을 불러오고 interval에 따라 업데이트할 수 있습니다. 노드 출처와 기본 설정을 분리한 뒤 여러 정책 그룹이 같은 provider를 참조하게 만들 때 적합합니다. provider의 health-check는 테스트 주소에 주기적으로 접속해 노드 사용 가능 여부를 판단하지만, 점검 빈도는 네트워크 요청과 모바일 배터리 소모에 영향을 줍니다. provider가 읽는 콘텐츠는 대상 코어가 파싱할 수 있어야 하며, 원격 응답이 호환되지 않는 형식이라면 provider에 넣는 것만으로 임의의 프로토콜 변환이 자동으로 이루어지지 않습니다.

proxy-providers:
  primary:
    type: http
    url: "https://example.com/subscription.yaml"
    path: ./providers/primary.yaml
    interval: 21600
    health-check:
      enable: true
      interval: 1800
      url: "https://www.example.com/"

예시에 사용한 도메인은 구조를 보여 주기 위한 것입니다. url은 실제 구독 주소로 바꾸고 접근 자격 증명이 포함된 링크를 공개적으로 공유하지 마세요. path는 코어 작업 디렉터리의 캐시 파일을 가리키고, interval은 업데이트 주기입니다. health-check의 interval은 상태 점검 주기로 두 값의 의미가 다릅니다. 테스트 주소는 안정적이고 응답이 작으며 실제 네트워크 대상과 비교 가능한 것이 좋습니다. 여러 provider의 점검 주기를 짧게 설정하면 클라이언트가 백그라운드 연결을 계속 생성하므로 모바일에서는 특히 빈도를 조절해야 합니다.

변환 과정에서 확장 필드가 가장 쉽게 손실됩니다

구독 변환은 보통 원본 형식 파싱, 필드 매핑, 대상 YAML 생성의 세 단계로 진행됩니다. 기존 SS, VMess, Trojan의 일반적인 필드 매핑은 비교적 안정적이지만 플러그인, gRPC, Reality, 클라이언트 지문, Hysteria2, TUIC 확장 항목은 변환기 기능의 제약을 더 쉽게 받습니다. 변환 후에는 각 프로토콜에서 최소 한 개의 노드를 추출해 server, port, uuid 또는 password, network, tls, servername, alpn, flow, udp 등 핵심 필드를 비교하세요. 노드 수만 비교해서는 안 됩니다. 개수가 같아도 필드가 누락될 수 있습니다.

노드 이름도 관리에 영향을 줄 수 있습니다. 변환기가 중복 제거를 위해 노드 이름을 바꾸면 proxy-groups에서 이전 이름을 직접 사용한 설정은 로드 시 프록시를 찾지 못하는 오류가 발생합니다. providers로 노드 집합을 참조하면 이름 의존성을 줄일 수 있지만 규칙 대상과 정책 그룹 이름은 여전히 존재해야 합니다. 전체 설정을 마이그레이션할 때는 먼저 모든 규칙이 최종적으로 가리키는 정책 그룹을 확인하고, 다음으로 정책 그룹이 참조하는 노드나 provider를 확인해 rules에서 proxy-groups, proxies로 이어지는 참조 체계를 점검하세요.

YAML 문법이 올바르더라도 의미 오류가 발생할 수 있습니다

YAML 검사는 들여쓰기, 중복 구조와 유형 문제를 발견할 수 있지만 원격 주소, 비밀번호, SNI 또는 규칙 대상이 올바른지는 확인하지 못합니다. 흔한 의미 오류로는 일부 파서가 거부하는 문자열 형식의 포트, 일관되지 않은 불리언 값, 중복된 정책 그룹 이름, 존재하지 않는 그룹을 가리키는 규칙, 쓰기 권한이 없는 provider 경로, 서버가 지원하지 않는 UDP를 활성화한 노드가 있습니다. 먼저 코어 설정 검사를 실행한 뒤 시작하고, 첫 번째 provider 업데이트, DNS 초기화와 노드 핸드셰이크 로그를 관찰하세요.

서비스 제공자가 전체 구독을 관리하는 경우 로컬 수정은 다음 업데이트에서 덮어쓰일 수 있습니다. 장기간 유지할 규칙은 원격 캐시 파일을 직접 편집하지 말고 클라이언트가 지원하는 재정의·병합 또는 로컬 설정 계층에 배치해야 합니다. 클라이언트마다 재정의 기능의 명칭과 지원 범위가 다르므로 마이그레이션 전에 로컬 규칙을 내보내야 합니다. Clash Plus 같은 클라이언트가 설정 관리를 간소화할 수는 있지만 원격 구독, 생성된 실행 설정, 로컬 재정의라는 세 계층은 여전히 구분해야 하며 문제를 해결할 때 실제로 적용된 파일이 무엇인지 확인해야 합니다.

08 · MIGRATION

프로토콜 테스트, 설정 마이그레이션과 장애 추적

마이그레이션 전에 복구 가능한 최소 설정 만들기

기존 클라이언트에서 Clash Plus, Clash Verge Rev, FlClash 또는 다른 mihomo 클라이언트로 옮길 때는 기존 클라이언트에서 작동하는 설정을 먼저 보존하고 즉시 삭제하지 마세요. 새 클라이언트에는 노드 하나 또는 provider 하나만 가져와 DIRECT, 단일 프록시, MATCH로 구성된 최소 규칙을 만들고 코어 시작, DNS와 시스템 프록시가 정상인지 확인합니다. 기준선이 통과된 뒤 전체 정책 그룹, 규칙 집합과 TUN을 추가하세요. 이렇게 하면 클라이언트 설치 문제, 코어 호환성 문제와 복잡한 설정 문제를 분리할 수 있습니다.

원본 Clash 설정을 mihomo로 가져오는 경우 대부분의 기본 필드는 계속 사용할 수 있지만 DNS와 TUN의 기본 동작은 확인해야 합니다. 반대로 마이그레이션할 때는 VLESS, Hysteria2, TUIC 등 원본이 지원하지 않는 노드와 Meta 확장 규칙을 삭제해야 합니다. 정책 그룹 참조도 함께 업데이트하지 않으면 존재하지 않는 대상을 가리켜 설정이 실패합니다. 일괄 수정은 항상 먼저 파일을 복사하고 코어 검사 명령으로 문법을 확인한 다음 실행 중인 설정을 교체해야 합니다.

단계별로 로그 읽기

시작 단계의 로그는 ‘설정을 로드할 수 있는가’에 답합니다. YAML 파싱, 알 수 없는 필드, provider 파일, 수신 포트와 TUN 권한을 중점적으로 확인하세요. 업데이트 단계의 로그는 ‘원격 콘텐츠를 가져와 파싱할 수 있는가’에 답하며 구독 요청, 반환 형식, 캐시 경로와 노드 수를 확인합니다. 연결 단계의 로그는 ‘대상 트래픽이 규칙에 적중하고 핸드셰이크를 완료하는가’에 답하며 규칙 대상, 노드 이름, DNS, 시간 초과, TLS와 인증 정보를 확인합니다. 서로 다른 단계를 섞으면 구독 업데이트 성공이 노드 핸드셰이크 성공을 의미한다고 판단하는 것처럼 오류가 발생합니다.

일반적인 dial tcp timeout은 정해진 시간 안에 TCP 연결이 완료되지 않았다는 뜻이며 주소에 도달할 수 없거나 포트가 차단되었거나 DNS 결과가 비정상적이거나 서버가 수신 대기하지 않는 경우 발생할 수 있습니다. connection refused는 대상이 명확히 연결을 거부했다는 뜻이므로 포트와 서비스 상태를 먼저 확인하세요. TLS 오류는 시스템 시간, servername과 인증서를 확인해야 하며 authentication failed는 비밀번호, UUID 또는 인증 문자열을 가리킵니다. QUIC 노드가 계속 시간 초과를 일으키면 먼저 네트워크를 바꿔 UDP 경로를 확인한 뒤 프로토콜 매개변수를 점검하세요. 더 많은 로그 문구와 확인 순서는 Clash 실행 로그 읽는 법에서 확인할 수 있습니다.

포트, 시스템 프록시와 TUN을 계층별로 확인

mixed-port는 HTTP와 SOCKS 진입점을 동시에 제공하는 데 자주 사용됩니다. 시스템 프록시를 켠 뒤 운영체제는 클라이언트가 실제로 수신 대기하는 주소와 포트를 가리켜야 합니다. 포트를 다른 프로그램이 사용 중이면 코어가 시작되지 않을 수 있으며, 인터페이스의 스위치가 켜져 있다고 수신 대기가 성공했다는 뜻은 아닙니다. 먼저 다른 프록시 도구를 끄고 로그의 수신 대기 오류를 확인하세요. LAN 공유에는 allow-lan, 방화벽과 올바른 수신 주소도 필요하며, 다른 기기에 내 컴퓨터의 로컬 주소만 입력해서는 안 됩니다.

TUN 모드는 더 낮은 계층에서 트래픽을 인계받으므로 시스템 권한, 가상 네트워크 카드 또는 관련 네트워크 확장이 필요합니다. 활성화한 뒤 네트워크가 되지 않으면 먼저 TUN을 끄고 시스템 프록시 기준선으로 돌아가세요. 시스템 프록시가 정상이라면 노드·구독·기본 DNS는 대체로 사용할 수 있으므로 TUN 권한, 라우팅 또는 DNS 가로채기 문제가 더 유력합니다. 그런 다음 TUN을 다시 활성화해 자동 라우팅, 인터페이스 선택, 사설 주소 제외와 DNS 모드를 차례로 확인하세요. TUN 장애가 발생했을 때 프로토콜 노드까지 동시에 바꾸면 유효한 비교 기준을 잃게 됩니다.

프로토콜 교체는 단일 변수 순서로 진행

VMess에서 VLESS로 전환하거나 Trojan에서 Hysteria2로 전환할 때는 대상 서버, 클라이언트, 규칙, DNS와 인계 방식을 최대한 동일하게 유지해야 합니다. 먼저 새 노드를 수동 선택 그룹에서 단독으로 연결할 수 있는지 확인한 뒤 자동 측정 또는 폴백 그룹에 추가하세요. 웹 탐색, 지속 다운로드, UDP 애플리케이션과 네트워크 전환 복구 네 가지 동작을 테스트하고 오류를 기록합니다. 새 프로토콜이 특정 업무에서만 더 나은 성능을 보인다면 전체 기본값을 한 번에 교체하지 말고 전용 정책 그룹을 구성하세요.

복잡한 프로토콜의 튜닝은 계층별로 진행해야 합니다. 첫 번째 라운드에서는 구독 기본값을 사용하고, 두 번째 라운드에서는 전송 관련 옵션만 조정하며, 세 번째 라운드에서 다중화·대역폭·혼잡 제어를 검토하고, 마지막으로 TUN과 DNS를 처리합니다. 매 라운드마다 이전 단계로 돌아갈 수 있어야 합니다. 조정 후 성능이 떨어지면 설정을 계속 추가하지 말고 가장 최근 변경 하나를 되돌리세요. 복구 가능성은 운영 설정의 중요한 속성으로, 코어 업데이트·클라이언트 전환·네트워크 변경 때 명확한 대안을 제공합니다.

mode: rule
mixed-port: 7890
allow-lan: false
log-level: info

rules:
  - DOMAIN-SUFFIX,example.com,DIRECT
  - GEOIP,LAN,DIRECT
  - MATCH,PROXY

이 예시는 문제 해결에 사용하는 기본 구조를 보여 줍니다. 규칙 모드, 혼합 포트, LAN 스위치, 일반 로그 수준과 세 개의 규칙으로 구성되어 있습니다. 실제 설정에는 PROXY라는 이름의 정책 그룹 또는 프록시도 정의해야 합니다. 규칙은 순서대로 매칭되므로 명확한 도메인은 더 일반적인 GEOIP와 MATCH보다 앞에 배치해야 합니다. 로그에 대상이 DIRECT에 적중했다고 표시되면 프록시 프로토콜 핸드셰이크를 계속 조사할 것이 아니라 먼저 규칙 대상을 수정해야 합니다.

최종 선택 기록 작성

테스트를 마친 뒤 각 기본 노드에 프로토콜, 전송 방식, TLS 호스트 이름, 적합한 네트워크, UDP 지원 여부, 해당 provider와 폴백 노드를 기록하세요. 비밀번호 같은 민감한 정보는 저장하지 말고 문제 추적에 필요한 구조 정보만 남기면 됩니다. 모바일에서는 TUN 활성화 여부, 상태 점검 주기와 백그라운드 제한을 추가로 기록하고, 라우터에서는 코어 아키텍처, 서비스 시작 방식과 규칙 집합 출처를 기록하세요. 다음 클라이언트 또는 코어 업데이트 후 같은 기록을 기준으로 다시 테스트하면 감으로 다시 선택하는 것보다 신뢰할 수 있습니다.

최종 설정이 모든 프로토콜을 포함할 필요는 없습니다. 안정적인 TCP 노드 한두 개, 검증된 QUIC 노드 하나를 유지하고 명확한 정책 그룹으로 구성하면 대부분의 데스크톱과 모바일 환경에 대응할 수 있습니다. 노드가 너무 많으면 상태 점검, 이름 관리와 장애 추적 비용이 늘어납니다. 프로토콜 매뉴얼의 목적은 모든 기술을 동시에 활성화하라는 것이 아니라 각 방식이 해결하는 문제, 필요한 조건과 실패 시 돌아갈 경로를 이해하도록 돕는 것입니다.