Clash 프로토콜 및 커널 기술 참고

프로토콜·전송·커널·규칙을 먼저 분리해서 보기

클라이언트의 한 노드에는 여러 계층의 매개변수가 포함됩니다

Clash 클라이언트에서 노드 이름을 볼 때 이름 끝의 SS, Trojan 또는 VLESS를 전체 기술 정보로 착각하기 쉽습니다. 실제로 사용할 수 있는 연결에는 최소한 프로토콜 식별 계층, 암호화 또는 인증 방식, 하위 전송 방식, 선택적 TLS, 도메인과 포트, 그리고 클라이언트 커널이 해당 필드를 해석하는 방식이 포함됩니다. VLESS로 표시된 두 노드라도 각각 TCP와 WebSocket을 사용할 수 있고, 서로 다른 TLS 기능을 활성화할 수도 있습니다. 따라서 핸드셰이크 횟수, 데이터 캡슐화, 리소스 사용량이 달라집니다. 반대로 프로토콜 이름이 다른 두 노드가 안정적인 TCP와 비슷한 서버 경로를 사용한다면, 일상적인 웹 페이지 로딩 체감은 이름만큼 크게 다르지 않을 수 있습니다.

따라서 선택할 때는 단순히 “어떤 프로토콜이 가장 빠른가?”라고 물어서는 안 됩니다. 더 정확한 질문은 다음과 같습니다. 현재 클라이언트 커널이 설정을 완전히 인식할 수 있는가? 현재 네트워크에는 안정적인 전송과 UDP 기반의 빠른 복구 중 무엇이 더 적합한가? 기기가 장시간 백그라운드에서 실행되는가? 서버가 해당 프로토콜을 올바르게 구현했는가? 이런 변수를 먼저 나눠 봐야 구독 파싱 실패, DNS 이상 또는 잘못된 규칙 선택을 프로토콜 자체의 문제로 오인하지 않을 수 있습니다.

네 가지 계층 순서로 판단하기

첫 번째는 커널 기능을 확인하는 단계입니다. 원본 Clash가 지원하는 프로토콜과 최신 mihomo의 지원 범위는 완전히 같지 않습니다. Hysteria2, TUIC 및 일부 VLESS 확장 기능은 대개 최신 Meta 계열 커널이 필요합니다. 클라이언트 화면에 특정 필드가 보인다고 해서 실제로 실행 중인 커널이 반드시 처리할 수 있다는 뜻은 아닙니다. 두 번째는 설정 형식을 확인하는 단계입니다. 구독 변환 과정에서 UDP, TLS, SNI, ALPN 또는 전송 경로 필드가 누락될 수 있습니다. 이 경우 프로토콜 이름은 맞아 보여도 핵심 매개변수는 이미 달라진 상태입니다. 세 번째는 네트워크 조건을 판단하는 단계입니다. 패킷 손실이 적은 고정 네트워크에서는 연결 수립과 서버 응답이 중요하고, 변동이 큰 모바일 네트워크에서는 복구 능력과 세션 마이그레이션이 더 중요합니다. 네 번째로 기기 비용, 즉 상시 메모리 사용량, CPU 깨우기, 백그라운드 연결 유지와 배터리를 확인합니다.

이 순서로 보면 흔한 현상을 쉽게 설명할 수 있습니다. 예를 들어 Hysteria2 노드가 지원 클라이언트에서는 정상 연결되지만 구버전 Clash로 가져온 뒤 알 수 없는 유형 오류가 발생한다면 이는 커널 기능 문제입니다. Trojan 노드를 수동으로 추가하면 작동하지만 특정 범용 구독으로 가져온 뒤 작동하지 않는다면 먼저 필드가 온전히 보존됐는지 비교해야 합니다. 같은 노드가 Wi-Fi에서는 안정적이지만 셀룰러 네트워크로 전환할 때 끊긴다면 그때 전송 방식과 세션 복구를 분석하는 것이 적절합니다.

속도 테스트만으로는 일부 문제만 확인할 수 있습니다

한 번의 속도 측정에는 회선 용량, 서버 부하, 테스트 대상, 로컬 네트워크가 모두 반영되므로 특정 프로토콜의 설계가 더 우수하다고 단정할 수 없습니다. 비교할 때는 최소한 같은 기기, 같은 네트워크, 비슷한 시간대, 같은 서버 지역, 같은 테스트 대상을 유지해야 합니다. 또한 최초 연결, 연속 요청, 대용량 파일 전송, 네트워크 전환 후 복구를 각각 관찰하세요. 최초 연결이 빠르면 핸드셰이크 경로가 짧을 가능성이 있고, 지속적인 처리량이 안정적이면 혼잡 제어와 회선의 궁합이 좋다는 뜻입니다. 네트워크 전환 후 복구가 빠르면 모바일 환경에 적합한 세션 및 전송 구현일 수 있습니다. 이런 지표를 하나의 총점으로 압축할 필요는 없습니다.

대부분의 사용자에게는 활발히 유지 관리되고 mihomo 또는 Meta 호환 기능이 내장된 그래픽 클라이언트를 사용하는 것이 합리적인 출발점입니다. 이 사이트의 다운로드 페이지에서는 각 플랫폼에 Clash Plus를 우선 추천하며, Clash Verge Rev, FlClash, Clash Nyanpasu, Clash Meta for Android 등의 선택지도 함께 소개합니다. 클라이언트를 정한 뒤에는 구독에서 제공하는 프로토콜 유형과 실제 네트워크 조건에 따라 다음 판단을 진행하세요. 특정 프로토콜 이름을 좇아 설정을 자주 옮길 필요는 없습니다.

프로토콜 6종의 배경과 설계상의 선택

Shadowsocks: 간결한 구조와 성숙한 구현

Shadowsocks는 보통 SS라고 부르며, 비교적 간결한 암호화 프록시 구조로 TCP와 UDP 트래픽을 전달하는 데 초점을 둡니다. 핵심 설정은 서버 주소, 포트, 암호화 방식, 비밀번호로 비교적 단순합니다. 프로토콜 구조가 명확하고 오랜 기간 구현되어 왔기 때문에 많은 클라이언트와 구독 형식이 SS를 인식합니다. 플랫폼을 옮길 때 필드 차이로 문제가 생기는 경우도 대체로 적습니다. 최신 설정에서는 현재 커널이 지원하는 AEAD 암호화 방식을 사용해야 합니다. 구독에 커널이 더 이상 허용하지 않는 이전 방식이 포함되어 있다면 클라이언트가 자동으로 바꾸지 않고 로드 단계에서 바로 거부할 수 있습니다.

SS의 장점은 캡슐화 오버헤드를 이해하기 쉽고 클라이언트 구현이 전반적으로 성숙했으며, 복잡도가 낮은 환경에서 리소스 비용을 관리하기 쉽다는 점입니다. 한계는 확장 기능이 구체적인 구현과 플러그인 조합에 좌우된다는 것입니다. 추가 전송 플러그인을 사용하면 실제 연결 구조는 기본 SS와 달라집니다. 문제를 재현하려면 주소, 포트, 비밀번호만 복사할 것이 아니라 플러그인 이름, 플러그인 매개변수, 전송 경로를 함께 기록해야 합니다.

VMess: 통합된 인증과 전송 옵션

VMess는 사용자 식별, 시간 검증, 여러 전송 방식을 하나의 프로토콜 체계에서 조합해야 하는 배경에서 등장했습니다. 일반적인 설정에는 UUID, alterId 또는 호환 필드, 전송 네트워크, TLS, 서버 이름, 경로 등이 포함됩니다. 한때 Clash 설정과 범용 구독에 널리 사용됐기 때문에 대부분의 Clash 계열 커널은 비교적 성숙한 파싱 기능을 갖추고 있습니다. 다만 VMess는 유연한 만큼 설정 변수도 많습니다. TCP, WebSocket, HTTP 계열 전송은 핸드셰이크와 캡슐화 방식이 서로 다르므로 성능을 비교할 때 전송 조합을 명시해야 합니다.

VMess가 기기 시간에 민감하다는 인식은 인증 및 시간 관련 메커니즘에서 비롯됐습니다. 최신 시스템은 대개 시간을 자동으로 동기화하지만 기기 시간이 크게 어긋났다면 문제 해결 목록에서 시스템 시간과 시간대를 확인해야 합니다. 모든 연결 실패의 기본 원인은 아니지만, 매개변수가 완전히 일치하고 네트워크에도 연결되는데 인증만 실패할 때 확인할 가치가 있습니다. 설정을 옮길 때는 이전 필드가 새 커널에서 무시되거나 변환되는지도 살펴보세요. 호환성 경고를 네트워크 오류로 오인하지 않도록 해야 합니다.

Trojan: TLS 연결을 중심으로 구성

Trojan의 일반적인 형태는 TLS 연결과 비밀번호 인증을 중심으로 하며, 설정에는 보통 서버 이름, 인증서 검증 상태, 선택적인 ALPN 정보가 필요합니다. 사용자 입장에서는 복잡한 전송 조합보다 필드를 확인하기 쉽습니다. 주소와 포트는 연결 대상을 정하고, 비밀번호는 인증을 담당하며, SNI 또는 servername은 TLS 핸드셰이크에 사용됩니다. 주소를 IP로 바꾸면서 올바른 서버 이름을 유지하지 않으면 TLS 검증이 실패할 수 있습니다. 인증서 검증을 끄면 테스트가 계속될 수 있지만 기존의 신원 확인 범위가 달라지므로 장기적인 해결책으로 사용해서는 안 됩니다.

Trojan은 안정적인 TCP 네트워크에서 대체로 균형 잡힌 성능을 보이며, 로그를 통해 연결 과정을 단계별로 확인하기 쉽습니다. 흔한 실패 원인으로는 도메인 해석 오류, 시스템 시간 이상, 서버 이름 불일치, 인증서 체인 문제, 비밀번호 오류가 있습니다. 이런 문제는 실제 프로토콜 데이터가 전송되기 전에 발생하므로, 문제 해결 시 먼저 TLS와 인증 오류를 확인하고 곧바로 프록시 모드나 라우팅 규칙을 바꾸지는 마세요.

VLESS: 간결한 프로토콜 코어, 조합 계층에 맡긴 기능

VLESS는 프로토콜 코어를 가볍게 유지하고 UUID로 신원을 식별하는 경우가 많으며, 다양한 전송 및 보안 계층을 조합해 기능을 확장합니다. 이름만으로는 TLS 사용 여부를 알 수 없고, TCP·WebSocket·gRPC 계열 전송이나 다른 확장을 사용하는지도 알 수 없습니다. 따라서 VLESS는 “라벨보다 전체 설정을 확인해야 하는” 대표적인 유형입니다. 최신 Meta와 mihomo 커널은 일반적으로 원본 Clash보다 VLESS 기능을 더 폭넓게 지원하지만, 구체적인 필드는 구현 발전에 따라 달라질 수 있어 구형 클라이언트는 기본 구조만 인식할 수 있습니다.

VLESS는 최신 커널 확장이 필요하고 서버와 클라이언트의 기능이 명확히 맞는 설정에 적합합니다. 주요 위험은 기본 프로토콜이 이해하기 어렵다는 데 있지 않고, 구독 변환 과정에서 확장 필드가 잘려 나가는 데 있습니다. 노드가 여전히 VLESS로 표시되더라도 flow, servername, client-fingerprint 또는 전송 매개변수가 누락될 수 있습니다. 이 경우 노드 이름과 주소만 비교하는 것은 의미가 없으며, 원본 공유 내용과 클라이언트가 최종 생성한 설정을 직접 대조해야 합니다.

Hysteria2와 TUIC: QUIC 기반의 최신 전송 방식

Hysteria2와 TUIC는 모두 QUIC와 UDP의 전송 기능을 적극 활용하지만 같은 프로토콜이 아니며 설정을 서로 바꿔 쓸 수도 없습니다. 두 프로토콜이 공통으로 해결하려는 문제는 지터, 패킷 손실, 대역폭 변화가 있는 네트워크에서 기존의 단일 TCP 경로가 재전송과 헤드 오브 라인 블로킹으로 대기 시간을 키울 수 있다는 점입니다. QUIC는 사용자 공간에서 더 유연한 혼잡 제어, 스트림 관리, 연결 복구를 구현할 수 있습니다. Hysteria2 설정은 보통 인증, TLS, 대역폭 또는 혼잡 관련 옵션을 중심으로 구성되고, TUIC 설정에는 UUID, 비밀번호, 혼잡 제어, UDP 릴레이 관련 옵션이 자주 포함됩니다.

이 두 프로토콜의 이점은 UDP 경로 품질에 달려 있습니다. 로컬 네트워크, 라우터 또는 서버 진입점의 UDP 지원이 불안정하면 “복구가 빠른 연결”이 아니라 “연결 자체가 실패하거나 주기적으로 흔들리는 연결”이 될 수 있습니다. 또한 비교적 최신 커널 구현이 필요하므로 Clash라는 이름이 붙은 모든 클라이언트가 지원한다고 가정해서는 안 됩니다. 선택하기 전에 클라이언트가 실제로 mihomo를 사용하거나 해당 Meta 기능을 갖췄는지 확인한 뒤, 소량 트래픽 접속, 지속 전송, 네트워크 전환이라는 세 가지 테스트로 판단하세요. 한 번의 최고 속도만 봐서는 안 됩니다.

연결 속도, 처리량, 리소스 사용량

최초 연결 속도는 핸드셰이크 체인이 좌우합니다

사용자가 체감하는 “웹 페이지가 얼마나 빨리 열리는가”는 대개 DNS, TCP 또는 QUIC 연결 수립, TLS 핸드셰이크, 프로토콜 인증, 첫 요청 응답이 함께 결정합니다. SS 기본 연결은 프로토콜 계층이 간결하지만 노드 앞에 플러그인이나 추가 전송이 있으면 핸드셰이크 체인이 늘어납니다. Trojan은 일반적으로 TCP와 TLS를 완료한 뒤 프로토콜 인증을 진행합니다. VMess와 VLESS의 실제 핸드셰이크는 선택한 전송 및 보안 계층에 따라 달라집니다. Hysteria2와 TUIC가 QUIC를 기반으로 작동하면 암호화와 전송 핸드셰이크를 통합할 수 있지만, 최초 접속은 여전히 DNS와 UDP 경로 수립의 영향을 받습니다.

따라서 “UDP 프로토콜은 항상 연결이 빠르다”거나 “캡슐화가 적으면 항상 빠르다”고 단순화할 수 없습니다. 서버와의 거리가 가깝고 패킷 손실이 적은 네트워크에서는 프로토콜 간 핸드셰이크 차이가 전체 로딩 시간에서 작은 부분만 차지할 수 있습니다. 왕복 지연 시간이 높으면 직렬 핸드셰이크가 한 번 추가될 때마다 차이가 더 커집니다. 이미 세션 재사용이 이뤄지고 있다면 최초 핸드셰이크 차이는 다시 줄어듭니다. 테스트할 때는 콜드 스타트 직후의 첫 요청과 클라이언트를 계속 실행한 상태의 연속 요청을 나눠 기록해 세션 재사용 효과를 프로토콜의 고정적인 장점으로 오인하지 않도록 하세요.

처리량은 혼잡 제어와 회선 용량에 좌우됩니다

지속적인 다운로드나 동영상 전송은 혼잡 제어, 서버 출구 대역폭, 로컬 접속 회선, 중간 구간 품질에 더 크게 의존합니다. TCP 계열 연결은 운영체제나 런타임의 혼잡 제어를 사용하므로 안정적인 회선에서는 예측 가능한 처리량을 보이는 경우가 많습니다. 하지만 패킷 손실이 발생하면 단일 TCP 연결은 재전송과 혼잡 윈도 축소로 큰 변동을 겪을 수 있습니다. QUIC 계열 프로토콜은 사용자 공간에서 혼잡 제어와 여러 스트림을 관리해 지터가 있는 네트워크에 다른 전략을 적용할 수 있지만, 설정이 부적절하면 전송 과속, 대기열 증가, 리소스 사용량 상승이 발생할 수 있습니다.

Hysteria2 설정의 대역폭 관련 값을 크게 입력한다고 항상 좋은 것은 아닙니다. 통신사가 표시하는 최고 속도나 한 번의 속도 측정 결과가 아니라 지속 가능한 회선 용량을 반영해야 합니다. 과대 설정은 대기열 적체와 패킷 손실을 일으킬 수 있고, 과소 설정은 사용 가능한 처리량을 제한합니다. TUIC의 혼잡 제어 선택도 클라이언트와 서버가 지원한다는 전제에서 결정해야 합니다. 서버 제공자가 명확한 설명을 하지 않았다면 사용자가 임의로 ‘범용 최적값’을 적용하기보다 구독 제공자가 지정한 매개변수를 유지하는 편이 일반적으로 더 안정적입니다.

CPU와 메모리는 프로토콜 이름만으로 순위를 매길 수 없습니다

프로토콜 자체는 암호화, 캡슐화, 재전송, 상태 유지에 영향을 주지만 클라이언트 전체 리소스에는 규칙 데이터베이스, DNS 캐시, 연결 추적, TUN 가상 네트워크 카드, 트래픽 통계, UI 프로세스도 포함됩니다. 그래픽 클라이언트의 메모리 사용량이 커널 프로세스보다 훨씬 높을 수 있지만, 이것이 프로토콜 처리 자체가 같은 수준의 리소스를 사용한다는 뜻은 아닙니다. 프로토콜 비용을 비교하려면 동일한 클라이언트와 규칙 설정, 비슷한 트래픽 조건에서 커널 프로세스를 관찰해야 하며, 가벼운 명령줄 커널과 완전한 데스크톱 클라이언트를 직접 비교해서는 안 됩니다.

하드웨어와 런타임 최적화가 잘 된 AEAD 방식을 사용하는 SS는 대체로 CPU 비용이 안정적입니다. Trojan의 TLS 구현도 성숙한 암호화 라이브러리를 활용할 수 있습니다. VMess와 VLESS의 비용은 전송 계층에 따라 달라지며 WebSocket, TLS, 추가 캡슐화가 처리량을 늘릴 수 있습니다. Hysteria2와 TUIC는 높은 처리량, 패킷 손실 복구, 다수의 동시 스트림에서 사용자 공간 전송 상태를 더 많이 유지해야 하므로 불안정한 네트워크에서 처리량이 좋아지는 대신 CPU 깨우기가 늘어날 수 있습니다. 저전력 기기와 라우터에서는 단순히 “연결 가능” 여부만 확인하지 말고 지속 부하 테스트를 먼저 진행해야 합니다.

동시 연결과 상태 확인은 리소스 차이를 키웁니다

Clash 설정에는 자동 선택, 장애 조치, 로드 밸런싱 전략 그룹이 자주 포함됩니다. 전략 그룹이 많은 노드를 대상으로 고빈도 상태 확인을 실행하면 매번 DNS, 핸드셰이크, 소량 트래픽 요청이 발생합니다. 노드 수가 많고 간격이 짧을수록 백그라운드 깨우기도 잦아집니다. 이때 늘어난 배터리 소모, 트래픽, 연결 수는 특정 프로토콜이 본질적으로 과도한 리소스를 사용하는 것이 아니라 전략 설정에서 비롯될 수 있습니다. 노드를 선택할 때는 상태 확인 범위를 실제 후보로 제한하고, 안정적인 소량 응답 테스트 URL과 적절한 간격을 사용하세요.

마찬가지로 TUN 모드는 더 넓은 시스템 트래픽을 인계하므로 브라우저, 시스템 서비스, 백그라운드 앱이 모두 커널을 통해 연결을 만들 수 있습니다. 시스템 프록시 모드는 대개 적용 범위가 더 좁습니다. 두 프로토콜을 비교하면서 TUN 상태까지 함께 바꾸면 결과의 원인을 구분할 수 없습니다. 프록시 모드, DNS 설정, 규칙 세트, 전략 그룹을 고정하고 같은 서버 조건에서 프로토콜 노드만 교체한 뒤 충분한 사용 주기 동안 관찰하세요.

모바일 배터리, 백그라운드 실행, 네트워크 전환

배터리 소모는 깨우기 횟수와 전송 지속 시간에서 발생합니다

모바일 프록시의 배터리 사용량은 특정 프로토콜 이름 하나로 결정되지 않습니다. 무선 칩이 저전력 상태에서 깨어나는 과정, CPU의 암호화 및 캡슐화 처리, VPN 서비스 유지, 앱의 백그라운드 동기화, DNS 조회, 상태 확인이 모두 배터리를 소모합니다. 짧은 시간에 더 빠르게 전송하면 무선 모듈이 저전력 상태로 더 빨리 돌아갈 수 있지만, 빈번한 소량 요청, 지속적인 하트비트, 반복적인 재연결은 기기를 장시간 활성 상태로 유지합니다. 배터리 소모를 판단할 때는 몇 분 동안의 온도 변화가 아니라 몇 시간 또는 하루의 일반적인 사용 주기를 관찰해야 합니다.

SS와 기본 Trojan은 안정적인 네트워크에서 대체로 복잡도가 낮은 연결을 유지하기 쉽습니다. VMess와 VLESS의 배터리 사용량은 전송 조합의 영향을 받습니다. 예를 들어 특정 연결을 계속 유지하거나 TLS를 자주 다시 수립하면 깨우기가 늘어납니다. Hysteria2와 TUIC는 지터가 있는 회선에서 전송을 빠르게 복구할 수 있지만, 사용자 공간 QUIC, UDP 연결 유지, 혼잡 처리를 위해 계산 리소스도 필요합니다. 모바일 네트워크 자체가 안정적이라면 QUIC 방식이 반드시 배터리를 크게 절약하는 것은 아닙니다. 반대로 네트워크가 자주 바뀌고 기존 연결이 반복해서 시간 초과를 겪는다면 빠른 복구가 불필요한 대기와 재연결 시간을 줄일 수 있습니다.

Android VPN 서비스와 배터리 절전 정책

Android 클라이언트는 보통 시스템 VPN 인터페이스를 통해 트래픽을 인계합니다. 시스템은 배터리 최적화, 백그라운드 제한, 제조사별 프로세스 관리, 대기 정책에 따라 앱을 일시 중지할 수 있습니다. 그 결과 일정 시간 화면을 잠근 뒤 연결이 끊기거나 알림이 사라지고, 화면을 다시 켜면 재연결될 수 있습니다. 이런 현상이 발생하면 먼저 클라이언트가 계속 실행되도록 허용됐는지, VPN이 여전히 활성 상태인지, 시스템이 필요한 백그라운드 활동을 허용하는지 확인하세요. 이는 프로토콜 인증 실패와 다릅니다. 잠금 해제 후 클라이언트가 다시 시작되어 빠르게 복구된다면 시스템 백그라운드 정책을 우선 점검해야 합니다.

Clash Plus, Clash Meta for Android, FlClash, Surfboard는 UI와 커널 기능이 서로 다르므로 같은 구독을 가져와도 DNS, 앱별 프록시, 백그라운드 기본값이 달라질 수 있습니다. 클라이언트 간 배터리 사용량을 비교할 때는 프록시 모드, 규칙, 상태 확인, 적용 앱 범위를 통일해야 합니다. 실제로 필요한 앱만 VPN을 통과시키면 불필요한 트래픽을 줄일 수 있지만, 앱별 설정이 잘못되면 일부 앱이 우회되거나 연결되지 않을 수 있으므로 변경 후 항목별로 확인해야 합니다.

iOS 시스템 네트워크 확장의 범위

iOS 클라이언트는 시스템이 제공하는 네트워크 확장 기능으로 작동하며 백그라운드 수명 주기는 시스템이 통합 관리합니다. Clash Plus는 App Store에서 받을 수 있고, 관련 진입점과 공식 사이트 clashplus.io는 다운로드 페이지의 iOS 영역에 정리되어 있습니다. 시스템이 Wi-Fi와 셀룰러 네트워크를 전환하면 하위 주소, 기본 라우팅, NAT 상태가 모두 바뀌므로 기존 TCP 세션은 대개 다시 수립해야 합니다. 연결 마이그레이션이나 복구를 지원하는 QUIC 구현은 중단 시간을 줄일 수 있지만 최종 결과는 클라이언트, 서버, 네트워크의 UDP 지원 여부에 달려 있습니다.

네트워크를 전환한 뒤 모든 프로토콜을 사용할 수 없다면 노드가 고장 났다고 바로 판단하지 말고 시스템 VPN 상태와 DNS를 먼저 확인하세요. Hysteria2 또는 TUIC만 실패하고 TCP 계열 프로토콜은 계속 연결된다면 새 네트워크의 UDP 연결 가능 여부를 중점적으로 살펴야 합니다. 반대로 QUIC 계열 프로토콜은 정상적으로 복구되는데 특정 TCP 연결만 오래 대기한다면 노드를 바꾸거나 연결을 다시 시작해 기존 세션을 정리할 수 있습니다. 클라이언트를 재설치할 필요는 없습니다.

모바일 네트워크의 NAT와 UDP 연결 유지

모바일 네트워크는 주소 변환을 사용하는 경우가 많으며 UDP 매핑의 유휴 유지 시간이 TCP보다 짧을 수 있습니다. 사용 가능한 세션을 유지하기 위해 클라이언트나 프로토콜 구현이 연결 유지 트래픽을 보낼 수 있습니다. 연결 유지가 너무 적으면 유휴 후 첫 요청에서 경로를 다시 수립해야 하고, 너무 잦으면 무선 깨우기와 배터리 소모가 늘어납니다. 사용자가 간격을 임의로 매우 짧게 설정해서는 안 됩니다. 구독이나 서버에서 명확히 요구하지 않는다면 클라이언트 기본값을 우선 사용하고, “화면을 잠근 채 유휴 상태로 둔 뒤 첫 접속이 성공하는가”로 조정 필요성을 판단하세요.

네트워크 전환 테스트는 세 단계로 진행하세요. 먼저 Wi-Fi에서 연결을 수립하고 여러 대상을 방문합니다. 다음으로 Wi-Fi를 끄고 셀룰러 네트워크가 연결될 때까지 기다린 뒤 현재 노드가 자동으로 복구되는지 관찰합니다. 마지막으로 기기를 일정 시간 잠근 뒤 다시 접속합니다. 실패가 네트워크 전환, 잠금 해제, 최초 DNS 조회 중 언제 발생했는지 기록하세요. 이렇게 단계별로 기록하면 “모바일에서 불안정하다”는 표현보다 진단 가치가 높고, 프로토콜 복구 문제와 시스템 백그라운드 및 DNS 문제도 구분할 수 있습니다.

원본 Clash, Meta, mihomo의 관계

커널은 설정을 실제로 해석하고 트래픽을 전달하는 구성 요소입니다

Clash 클라이언트는 보통 그래픽 인터페이스, 설정 관리, 프록시 커널로 구성됩니다. UI는 구독 가져오기, 노드 선택, 로그 표시, 시스템 프록시 제어를 담당하고, 커널은 YAML 파싱, 연결 수립, 규칙 실행, DNS 처리, 트래픽 전달을 담당합니다. 클라이언트 이름과 커널 이름이 항상 같지는 않으므로 프로토콜 지원 여부를 판단할 때 앱 아이콘만 봐서는 안 됩니다. 클라이언트의 정보, 설정 또는 로그에서 실제 커널을 확인하고 커널 전환을 지원하는지도 살펴보세요.

원본 Clash는 규칙 매칭, 전략 그룹, 설정 구조, 제어 인터페이스의 기본 모델을 만들었으며 많은 설정 항목이 생태계의 공통 문법이 되었습니다. SS, VMess, Trojan 등 일반적인 유형을 지원하지만 이후 등장한 프로토콜과 확장 기능의 범위는 제한적입니다. 이전 설정이 계속 작동한다고 해서 모든 최신 노드를 처리하기에 적합하다는 뜻은 아닙니다. 구독에 Hysteria2, TUIC 또는 최신 VLESS 확장이 포함되어 있으면 원본 커널이 알 수 없는 유형을 보고하거나 필드를 무시하거나 해당 프록시를 시작하지 못할 수 있습니다.

Clash.Meta는 프로토콜 및 네트워크 기능을 확장합니다

Clash.Meta는 기존 설정 및 규칙 체계를 바탕으로 프로토콜, DNS, TUN, 규칙 제공자, 전송 기능을 확장했습니다. 목표 중 하나는 Clash 설정 방식을 최대한 유지하면서 새로운 프로토콜을 같은 전략 그룹과 규칙 엔진에 포함하는 것입니다. 따라서 하나의 설정에서 SS, Trojan, VLESS, Hysteria2, TUIC를 함께 사용하고 자동 선택이나 수동 전략 그룹으로 운용할 수 있습니다. 다만 호환성이 완전히 동일한 것은 아닙니다. 일부 Meta 전용 필드는 원본 Clash에서 실패할 수 있지만, 원본 설정은 Meta 계열 커널에서 더 쉽게 로드되는 경우가 많습니다.

“Meta가 특정 프로토콜을 지원한다”는 말이 모든 시기의 Meta 빌드가 모든 필드를 지원한다는 뜻은 아닙니다. 프로토콜 구현, 필드 이름, 기본 동작은 계속 발전하며 클라이언트에 포함된 커널의 업데이트 주기도 서로 다릅니다. 이 사이트에서는 고정 버전 번호만으로 지원 여부를 판단하지 않습니다. 실제로는 클라이언트의 커널 정보와 설정 로드 로그를 확인해야 합니다. 서비스 제공자가 특정 기능을 요구한다면 유지 관리가 계속되고 커널 업데이트가 가능한 클라이언트를 선택하세요.

mihomo는 현재 Meta 계열 커널의 이름입니다

mihomo는 Meta 계열의 기능을 이어받아 발전시킨 커널입니다. 많은 최신 그래픽 클라이언트가 mihomo를 핵심 구성 요소로 사용하므로 Hysteria2, TUIC, 최신 VLESS 확장, 더욱 완전한 DNS와 TUN 설정을 인식할 수 있습니다. 자료에서 Clash.Meta와 mihomo를 보더라도 완전히 분리된 두 설정 생태계로 이해해서는 안 됩니다. 같은 확장 경로가 시기와 구현에 따라 서로 다른 이름으로 불린다고 이해하는 편이 적절합니다. 구체적인 호환성은 현재 커널의 실제 파싱 결과를 기준으로 판단해야 합니다.

Clash Plus는 이 사이트에서 모든 플랫폼에 우선 추천하는 선택지이며, Clash Verge Rev, FlClash, Clash Nyanpasu 등은 운영체제와 UI 선호에 따라 선택할 수 있습니다. Linux 서버, 라우터, 직접 설정을 관리해야 하는 사용자는 mihomo 커널을 바로 사용할 수 있습니다. 일반적인 데스크톱 및 모바일 사용자는 시스템 프록시, TUN 권한, 구독 업데이트, 로그 확인을 UI에서 처리할 수 있는 그래픽 클라이언트가 더 적합한 경우가 많습니다. 전체 플랫폼 진입점은 다운로드 페이지의 mihomo 커널 영역에서 확인하세요.

설정 호환성은 문법 호환성과 동작 호환성으로 나뉩니다

문법 호환성은 커널이 필드를 읽고 시작할 수 있다는 뜻이고, 동작 호환성은 규칙, DNS, 전략 그룹, 프로토콜 연결이 예상대로 작동한다는 뜻입니다. 오래된 설정이 mihomo에서 성공적으로 로드됐다는 사실만으로는 기본 문법을 받아들였다는 것만 알 수 있으며, DNS 결과, 규칙 제공자 새로 고침, TUN 라우팅이 원래 클라이언트와 완전히 같다는 뜻은 아닙니다. 마이그레이션 후에는 설정 로드, 노드 연결, 규칙 적중, DNS 조회, 시스템 앱 트래픽을 확인해야 하며 UI에 “연결됨”이라고 표시되는지만 봐서는 안 됩니다.

역방향 마이그레이션은 위험이 더 큽니다. mihomo 설정에 최신 프록시 유형, 규칙 문법, DNS 옵션이 포함되어 있으면 원본 Clash가 이를 인식하지 못할 수 있습니다. 오류 필드를 무작정 삭제하는 것도 안전한 방법이 아닙니다. 삭제한 필드가 TLS 신원 확인, UDP 릴레이, 라우팅 동작을 담당할 수 있기 때문입니다. 원본 설정을 보존하고 대상 커널에 맞는 호환 사본을 만든 뒤, 지원되지 않는 노드와 기능을 하나씩 교체하는 방법이 더 적절합니다.

구독 형식과 설정 호환성

원시 YAML과 공유 구독은 서로 다른 문제를 해결합니다

Clash 원시 YAML은 프록시 노드, 전략 그룹, 규칙, DNS, TUN, 규칙 제공자를 한 번에 표현할 수 있어 정보가 완전하며 호환 커널에 바로 로드하기 적합합니다. 범용 공유 구독은 보통 링크 목록이나 인코딩된 텍스트로 단일 노드를 표현하며, 프로토콜 연결 매개변수 전달에 초점을 둡니다. Clash의 전략과 규칙까지 포함하지 않을 수 있습니다. 구독 변환기는 노드를 Clash 설정으로 변환하지만, 변환 과정에서 각 프로토콜과 확장 필드를 이해해야 합니다. 변환기의 기능이 뒤처져 있으면 최종 YAML을 파싱할 수는 있어도 올바른 연결을 수립하지 못할 수 있습니다.

구독 가져오기가 성공했다는 것은 클라이언트가 입력을 받아들였다는 뜻일 뿐 모든 노드가 완전하다는 뜻은 아닙니다. 최소한 전통적인 프로토콜 하나와 최신 프로토콜 하나를 표본으로 확인하고 최종 노드 유형, 포트, TLS, servername, 네트워크 유형, 경로, UDP, 프로토콜 전용 필드를 살펴보세요. 특히 VLESS, Hysteria2, TUIC는 필드가 누락되어도 UI에 뚜렷하게 표시되지 않을 수 있습니다. 클라이언트가 현재 설정을 볼 수 있다면 원본 설정과 구간별로 비교하세요. 노드 상세만 확인할 수 있다면 핵심 필드를 기록하고 로그로 검증해야 합니다.

URI 형식은 단일 노드에 적합하지만 표현력에는 한계가 있습니다

SS, VMess, Trojan, VLESS 등 대표적인 프로토콜에는 대응하는 공유 URI 또는 인코딩 형식이 있지만, 소프트웨어마다 쿼리 매개변수, 이름 인코딩, 확장 필드 처리 방식이 다를 수 있습니다. 링크 끝의 노드 이름은 표시용일 뿐 인증에는 사용되지 않습니다. 연결을 바꾸는 것은 쿼리 매개변수의 type, security, sni, path 등입니다. 링크를 복사할 때 메신저가 특수 문자를 잘라내거나 중간 시스템이 다시 인코딩하면 클라이언트가 잘못된 경로 또는 서버 이름을 받을 수 있습니다.

Hysteria2와 TUIC의 공유 형식도 생태계의 도구에 따라 필드 이름이 다를 수 있습니다. “한 클라이언트에서는 가져와지지만 다른 클라이언트에서는 인식되지 않는” 경우에는 먼저 대상 클라이언트가 해당 URI 방식을 지원하는지 확인한 뒤 원시 YAML 사용을 고려하세요. 인증 구조, 전송 방식, 필수 필드가 서로 다르므로 링크 접두사만 다른 프로토콜 이름으로 바꾸어서는 안 됩니다.

설정 변환에서 가장 쉽게 누락되는 필드

TLS 관련 필드가 첫 번째 핵심 그룹입니다. servername, SNI, 인증서 검증, ALPN, 클라이언트 지문 계열 옵션이 여기에 포함됩니다. 전송 관련 필드는 두 번째 그룹으로 WebSocket 경로와 요청 헤더, gRPC 서비스 이름, UDP 릴레이, QUIC 혼잡 제어 옵션이 있습니다. 세 번째는 프로토콜 전용 필드로 SS 암호화 방식, VLESS flow, TUIC UUID와 비밀번호 조합, Hysteria2 인증 및 대역폭 매개변수 등이 해당합니다. 네 번째는 전략 그룹 이름, 규칙 대상, DNS 모드 같은 Clash 동작 필드입니다.

변환 과정에서 전략 그룹 참조도 잘못될 수 있습니다. 규칙 끝에 지정한 전략 이름은 proxy-groups의 이름과 정확히 일치해야 하고, 전략 그룹이 참조하는 노드 이름은 proxies의 이름과 일치해야 합니다. 변환기가 이름을 중복 제거하거나 접미사를 붙이거나 문자를 바꾸면 규칙이 존재하지 않는 전략을 가리킬 수 있습니다. 커널은 보통 로드 단계에서 오류를 보고하지만 일부 도구는 자동으로 바꾸므로 원래 설정과 동작이 달라질 수 있습니다.

mixed-port: 7890
mode: rule

proxies:
  - name: "예시 Trojan"
    type: trojan
    server: example.com
    port: 443
    password: "your-password"
    sni: example.com
    udp: true

proxy-groups:
  - name: "수동 선택"
    type: select
    proxies:
      - "예시 Trojan"
      - DIRECT

rules:
  - DOMAIN-SUFFIX,example.org,수동 선택
  - MATCH,DIRECT

위의 짧은 설정은 필드 간 참조 관계를 보여줍니다. 노드 이름을 전략 그룹이 참조하고, 규칙이 다시 전략 그룹을 참조합니다. 예시 주소와 인증 값은 구조 설명에만 사용됩니다. 실제 설정에는 DNS, 규칙 제공자, 더 많은 프록시 유형이 포함될 수 있습니다. 수동으로 수정할 때는 공백 들여쓰기를 사용하고 탭을 섞지 마세요. 문자열에 콜론, 해시 기호 또는 특수 문자가 포함되면 따옴표를 사용해 YAML이 다른 유형으로 해석하지 않도록 해야 합니다.

구독 업데이트에는 되돌릴 수 있는 경로가 필요합니다

클라이언트가 구독을 업데이트하면 원격 내용에 따라 노드 이름, 전략 그룹, 프로토콜 필드가 바뀔 수 있습니다. 기존 이름에 의존하는 로컬 오버라이드 기능은 업데이트 후 작동하지 않을 수 있습니다. 수정하기 전에 현재 작동하는 설정을 저장하고, 어떤 내용이 구독에서 왔고 어떤 내용이 로컬 오버라이드로 생성됐는지 구분해 두세요. 구독이 완전한 Clash YAML을 제공한다면 전략과 노드를 같은 출처로 유지하는 것이 좋습니다. 노드 목록만 제공하는 경우에는 클라이언트 템플릿으로 안정적인 로컬 전략 그룹을 구성하세요.

업데이트 후 모든 노드가 작동하지 않는다면 먼저 구독을 정상적으로 가져왔는지, 파일이 비어 있지 않은지, YAML을 파싱할 수 있는지 비교한 뒤 노드 매개변수의 변화를 확인하세요. 최신 프로토콜만 실패한다면 클라이언트 업그레이드나 전환 후 커널이 바뀌었는지 먼저 점검해야 합니다. 노드는 연결되지만 규칙 동작이 달라졌다면 인증 매개변수를 계속 살피지 말고 전략 그룹과 규칙 이름을 확인하세요. 최초 가져오기와 관련한 자세한 내용은 Clash 초보자를 위한 자주 묻는 질문 10가지와 자주 묻는 질문 페이지를 참고하세요.

기기와 네트워크 환경별 프로토콜 선택

고정 회선과 일상적인 데스크톱 사용

패킷 손실이 적고 지연 시간이 안정적인 고정 네트워크에서는 SS, Trojan, VMess, VLESS 모두 안정적인 경험을 제공할 수 있습니다. 이때 프로토콜 차이는 서버 부하, 회선 거리, DNS 품질보다 작은 경우가 많습니다. 필드가 완전하고 커널 지원이 성숙하며 서버가 안정적으로 관리되는 노드를 우선 선택하세요. SS는 구조가 간결한 설정에 적합하고, Trojan은 TLS 매개변수가 명확한 연결에 적합합니다. VMess는 이미 성숙한 구독을 사용하는 환경에, VLESS는 클라이언트와 서버가 모두 최신 구현을 사용하고 관련 확장이 필요한 설정에 적합합니다.

데스크톱에서 TUN, 규칙 데이터베이스, 많은 전략 그룹을 장시간 실행한다면 프로토콜 선택보다 리소스 관리가 더 중요할 수 있습니다. 관계없는 노드의 상태 확인을 줄이고, 규칙 세트 규모를 적절히 유지하며, 중복 DNS 조회를 피하는 것이 프로토콜을 바꾸는 것보다 안정성 개선에 더 효과적인 경우가 많습니다. Windows와 macOS 사용자는 Clash Plus부터 시작한 뒤 UI 요구에 따라 Clash Verge Rev, FlClash, Clash Nyanpasu를 고려할 수 있습니다. 유지 관리가 중단된 Clash for Windows 또는 ClashX Meta에서 마이그레이션한다면 클라이언트 마이그레이션 및 설정 호환성 가이드를 참고하세요.

모바일 네트워크, 통근, 빈번한 접속 지점 전환

모바일 네트워크의 핵심 변수는 지터, 짧은 패킷 손실, 주소 변경, 백그라운드 제한입니다. UDP 경로가 안정적이라면 QUIC 방식이 전송 복구를 더 유연하게 처리할 수 있으므로 Hysteria2 또는 TUIC를 비교 후보로 삼을 만합니다. 일부 접속 네트워크에서 UDP 지원이 불안정하다면 Trojan, SS 또는 TCP 기반 VMess·VLESS가 더 예측 가능한 결과를 낼 수 있습니다. 가장 안정적인 구성은 하나의 프로토콜만 남기는 것이 아니라 같은 전략 그룹에 신뢰할 수 있는 TCP 계열 노드와 검증된 QUIC 계열 노드를 함께 준비하고, 네트워크 전환 후 실제 결과에 따라 선택하는 것입니다.

모바일에서는 자동 테스트 빈도도 관리해야 합니다. 짧은 간격으로 모든 노드를 탐색하면 배터리와 데이터 사용량이 늘어나고, 네트워크가 막 전환된 시점에 많은 실패 연결이 발생할 수 있습니다. 자주 쓰는 후보를 작은 범위로 제한하고 테스트 간격을 늘리며 수동 선택 전략을 유지할 수 있습니다. 앱이 지속적인 백그라운드 통신을 필요로 한다면 먼저 시스템이 VPN 서비스 실행을 허용하는지 확인한 뒤 프로토콜 복구 능력을 판단하세요.

패킷 손실이 많거나 대역폭 변동이 큰 네트워크

웹 페이지가 간헐적으로 멈추고 지속 다운로드 속도가 주기적으로 떨어지며 로컬 직접 연결 테스트에서도 지터가 나타난다면 접속 회선이 원인일 수 있습니다. Hysteria2와 TUIC의 사용자 공간 혼잡 제어 및 QUIC 멀티플렉싱은 이런 환경에서 더 유리할 수 있지만, UDP 연결이 가능하고 서버 매개변수가 적절해야 합니다. 최소 10분 이상 지속 전송 테스트를 진행하면서 짧은 요청의 응답도 함께 관찰하세요. 속도 측정 시작 몇 초 동안의 최고 속도만 봐서는 안 됩니다.

QUIC 계열 노드가 계속 시간 초과를 일으킨다면 먼저 UDP를 지원한다고 알려진 다른 네트워크로 비교하세요. 다른 네트워크에서 정상이라면 원래 네트워크 경로를 계속 점검해야 합니다. 모든 네트워크에서 실패한다면 서버, 인증, TLS 또는 클라이언트 커널 문제일 가능성이 더 큽니다. 대역폭 매개변수를 무작정 높이거나 연결 유지 간격을 줄이지 마세요. 이런 조정은 대기열과 배터리 소모를 악화시킬 수 있습니다. 패킷 손실이 많은 환경에서 TCP 계열 노드가 느리지만 안정적이라면 대체 경로로 사용할 수 있습니다.

저전력 기기, 라우터, Linux 서버

리소스가 제한된 기기에서는 지속적인 CPU 사용량, 메모리, 동시 연결 상태를 최우선으로 확인해야 합니다. 기본 SS나 간결한 Trojan 설정은 비용을 추정하기 쉬운 편이지만 실제 결과는 암호화 라이브러리와 하드웨어에 따라 달라집니다. Hysteria2와 TUIC는 높은 처리량과 복구 성능에 이점이 있을 수 있지만 사용자 공간 처리량도 더 많이 요구할 수 있습니다. 배포 전에 대상 기기에서 지속 부하, 유휴 메모리, 온도 테스트를 진행하고 시스템이 UDP 버퍼를 안정적으로 처리할 수 있는지 확인하세요.

mihomo를 직접 실행하는 Linux 사용자는 설정 파일, 서비스 시작, 권한, 로그를 직접 관리해야 합니다. 설정은 먼저 포그라운드에서 검증한 뒤 시스템 서비스에 넘겨야 합니다. 라우터에서는 투명 프록시, DNS 하이재킹, LAN 주소, 방화벽 규칙도 고려해야 합니다. 이 때문에 “노드는 연결됐지만 단말 기기에서 접속할 수 없는” 현상이 흔히 발생합니다. 이런 경우 커널의 외부 연결과 LAN 전달을 나누어 검증하고 모든 실패를 프로토콜 탓으로 돌리지 마세요.

최대 설정 호환성이 필요한 마이그레이션 환경

기존 클라이언트에서 옮길 때 원래 설정에 SS, VMess, Trojan이 주로 포함되어 있다면 Clash 설정 가져오기를 지원하는 최신 mihomo 클라이언트를 선택하는 것이 대체로 순조롭습니다. 먼저 설정을 복사하고, 기존 클라이언트의 시스템 프록시나 TUN을 끈 뒤 새 클라이언트에서 가져오고, 파싱 로그를 확인하고, 노드를 선택하고, 규칙을 검증한 다음 마지막으로 시작 시 자동 실행을 설정하세요. 두 클라이언트가 동시에 시스템 프록시나 가상 네트워크 카드를 인계하지 않도록 해야 합니다. 그렇지 않으면 포트 충돌, 라우팅 덮어쓰기, 순환 전달이 발생할 수 있습니다.

원래 설정에 VLESS, Hysteria2, TUIC 또는 Meta 전용 DNS 필드가 포함되어 있다면 mihomo를 명확히 사용하는 클라이언트를 선택해야 합니다. 원본 Clash에 맞게 설정을 낮추려면 기능을 삭제하거나 교체해야 하는 경우가 많으므로 파일 확장자만 바꾸는 방식으로는 충분하지 않습니다. 마이그레이션의 목표는 UI에 표시되는 노드 수를 같게 만드는 것이 아니라 핵심 프로토콜, 전략 그룹, 규칙, DNS 동작을 일치시키는 것입니다.

검증, 마이그레이션, 문제 진단 절차

첫 번째 단계: 커널이 설정을 완전히 로드할 수 있는지 확인

가져온 직후 TUN을 바로 켜거나 모든 시스템 트래픽을 클라이언트로 보내지 마세요. 설정 로드 결과와 로그를 확인해 알 수 없는 프록시 유형, 필드 유형 오류, 존재하지 않는 전략 그룹 참조, YAML 파싱 실패가 없는지 확인합니다. 최신 프로토콜에서 unsupported, unknown proxy type과 같은 메시지가 나타나면 클라이언트의 실제 커널을 먼저 확인하세요. YAML 오류는 들여쓰기, 콜론, 목록 기호, 따옴표를 점검합니다. 전략 그룹 오류가 발생하면 노드 이름과 그룹 이름이 완전히 일치하는지 확인하세요.

클라이언트에 “가져오기 실패”만 표시되고 자세한 정보가 없다면 같은 계열의 다른 클라이언트나 mihomo를 포그라운드에서 실행해 설정을 로드하면 오류 위치를 더 명확히 확인할 수 있습니다. 한 번에 여러 필드를 삭제하지 마세요. 명확한 오류 하나만 수정하고 다시 로드해야 어떤 변경이 효과가 있었는지 알 수 있습니다. 설정이 로드된 다음 노드 연결 단계로 넘어가세요.

두 번째 단계: DNS, 네트워크 연결 가능 여부, 프로토콜 핸드셰이크 분리

연결에 실패하면 먼저 서버 도메인을 해석할 수 있는지, 대상 포트에 연결할 수 있는지, 실패가 TLS·인증·데이터 전달 중 어느 단계에서 발생했는지 판단하세요. 로그의 timeout은 대개 어느 단계에서 대기 시간이 초과됐다는 뜻이지만, 이것만으로 서버 오프라인, UDP 연결 불가, DNS 오류 중 무엇인지 확정할 수는 없습니다. certificate, servername, handshake와 같은 정보는 TLS 단계에 가깝고, authentication, invalid user 또는 비밀번호 관련 정보는 인증을 가리킵니다. unknown field와 unsupported는 여전히 설정 및 커널 단계의 문제입니다.

노드 매개변수는 바꾸지 않고 네트워크만 전환해 비교할 수 있습니다. Wi-Fi와 모바일 네트워크 모두에서 실패하면 설정과 서버를 우선 확인하고, 특정 네트워크에서만 실패하면 해당 네트워크의 DNS, UDP, 라우팅을 계속 점검하세요. Hysteria2와 TUIC는 실패하지만 Trojan과 SS가 작동한다면 UDP 경로를 확인해야 합니다. 모든 노드가 사용 가능으로 표시되는데 브라우저가 접속하지 못한다면 시스템 프록시, TUN, 규칙, DNS 문제로 범위를 좁혀야 하며 프로토콜을 계속 바꿔서는 안 됩니다.

세 번째 단계: 전략 그룹과 규칙이 실제 대상 노드를 선택했는지 확인

Clash 규칙은 위에서 아래로 매칭되고, 매칭되면 규칙이 지정한 전략 그룹을 사용합니다. 전략 그룹은 수동 선택, 자동 테스트, 장애 조치, 로드 밸런싱 상태일 수 있습니다. UI에서 특정 노드를 클릭했다고 해서 현재 요청이 반드시 그 노드를 통과하는 것은 아닙니다. 요청이 다른 전략 그룹에 매칭되거나 DIRECT 규칙으로 직접 연결될 수도 있습니다. 연결 상세 또는 규칙 로그를 확인해 대상 도메인이 어떤 규칙에 매칭됐는지, 어떤 전략 그룹에 들어갔는지, 최종적으로 어떤 노드를 사용했는지 확인하세요.

문제를 진단할 때는 대상 노드와 DIRECT만 포함하는 작은 수동 전략 그룹을 임시로 만들고 소수의 테스트 규칙에서 이를 참조할 수 있습니다. 이렇게 하면 자동 선택과 복잡한 규칙을 배제할 수 있습니다. 검증이 끝나면 원래 설정으로 복구하세요. 규칙 오류를 가리기 위해 모든 트래픽을 장기간 글로벌 모드로 바꾸지 마세요. 기존 분기 범위를 잃게 되고 특정 규칙이 왜 매칭되지 않았는지도 알 수 없게 됩니다.

네 번째 단계: 최소 변수 원칙으로 프로토콜 비교

SS와 Trojan, VLESS와 Hysteria2 등을 비교할 때는 서버 지역, 테스트 대상, 클라이언트, 프록시 모드, DNS, 테스트 시간을 최대한 동일하게 유지해야 합니다. 설정 로드, 최초 연결, 연속 요청, 지속 처리량, 유휴 후 복구, 네트워크 전환을 순서대로 관찰하세요. 매 라운드마다 노드만 바꾸고 클라이언트와 규칙을 동시에 바꾸지 마세요. “어느 단계에서 실패했는가”를 기록하는 것이 총 지연 시간 하나를 기록하는 것보다 가치가 큽니다.

두 노드가 서로 다른 서버에서 제공된다면 테스트 결과는 노드 선택에만 사용할 수 있으며 프로토콜 설계의 우열을 증명하지는 못합니다. 서버 CPU, 출구 회선, 라우팅, 부하가 결과를 좌우할 수 있습니다. 프로토콜 설명은 차이를 이해하기 위한 틀을 제공할 뿐이며, 최종 선택은 자신의 기기와 네트워크에서 직접 검증해야 합니다.

다섯 번째 단계: 마이그레이션 시 되돌리기와 단계별 인계를 유지

기존 클라이언트에서 Clash Plus, Clash Verge Rev, FlClash 또는 다른 mihomo 클라이언트로 전환할 때는 먼저 기존 설정을 내보내거나 복사하고 현재 시스템 프록시 포트, TUN 상태, DNS 모드, 자주 쓰는 전략을 기록하세요. 기존 클라이언트를 종료하고 시스템 프록시와 가상 네트워크 카드가 해제됐는지 확인한 뒤 새 클라이언트를 시작합니다. 가져온 후에는 단일 노드를 먼저 테스트하고 전략과 규칙을 검증한 다음 TUN, LAN 공유, 시작 시 자동 실행 같은 시스템 기능을 마지막에 켜세요.

마이그레이션 후 포트가 이미 사용 중이라면 보통 기존 프로세스가 여전히 실행 중이거나 새 설정과 기존 설정이 같은 수신 포트를 사용하고 있다는 뜻입니다. 앱은 접속되지만 시스템 서비스가 접속되지 않는다면 시스템 프록시와 TUN의 적용 범위를 비교하세요. 도메인은 실패하지만 직접 주소는 접속된다면 DNS를 중점적으로 확인해야 합니다. 최신 프로토콜만 사용할 수 없다면 규칙을 계속 수정하지 말고 새 클라이언트가 예상한 커널을 실제로 활성화했는지 확인하세요.

재사용 가능한 문제 해결 기록 형식

유효한 장애 기록에는 최소한 운영체제, 클라이언트 이름, 실제 커널, 프록시 모드, 노드 프로토콜, 전송 유형, 문제 발생 시간, 네트워크 유형, 로그 단계, 이미 진행한 비교 테스트가 포함되어야 합니다. 인증 정보는 그대로 공개해서는 안 됩니다. “사용할 수 없음”을 “설정은 로드되며 Trojan 노드가 TLS 핸드셰이크 단계에서 servername 불일치를 보고하고, 같은 네트워크에서 SS 노드는 연결됨”처럼 작성하면 해결 경로가 훨씬 명확해집니다.

설정을 장기적으로 관리할 때는 한 번에 한 종류의 설정만 바꾸고, 변경 후 기본 회귀 테스트를 완료하세요. 구독 업데이트, 자주 쓰는 노드 연결, 규칙 매칭, DNS 해석, 시스템 절전 후 복구를 확인해야 합니다. GeoIP와 GeoSite 규칙 데이터베이스 업데이트 및 오류 점검은 Clash GeoIP 및 GeoSite 데이터 업데이트 가이드를 참고하세요. LAN 공유 문제는 혼합 포트와 LAN 공유 프록시 안내에서 계속 확인할 수 있습니다.

위 절차를 완료하면 프로토콜 선택은 대체로 설명 가능한 결론으로 좁혀집니다. 안정적인 고정 네트워크에서는 설정이 성숙하고 커널이 완전히 지원하는 노드를 사용하고, 모바일 또는 지터가 큰 네트워크에서는 UDP 연결이 가능할 때 Hysteria2와 TUIC를 테스트합니다. 리소스가 제한된 기기에서는 동시 연결, 상태 확인, 전송 비용을 우선 관리하고, 최신 VLESS 확장과 QUIC 계열 프로토콜에는 mihomo 커널을 선택하세요. 그래도 판단하기 어렵다면 빠른 시작 가이드에서 기본 검증을 먼저 완료한 뒤 자주 묻는 질문에서 현상별로 계속 확인하세요.