프록시 프로토콜과 코어 참고 자료

코어 계열과 설정의 한계

클라이언트, 코어, 설정 파일

GUI 클라이언트는 서비스를 설치하고 설정을 가져오며, 정책 그룹을 표시하고 시스템 권한을 요청합니다. 코어는 규칙을 해석하고 아웃바운드 연결을 설정하며 DNS와 데이터 전달을 처리합니다. 화면에 스위치가 있다고 해서 현재 실행 중인 코어가 관련 기능을 모두 지원한다는 뜻은 아닙니다. 프로토콜 사용 가능 여부를 판단하려면 클라이언트 안내, 코어 식별 정보, 설정 로드 결과를 함께 확인해야 합니다. 앱 이름만 비교하면 화면 기능과 네트워크 기능을 혼동하기 쉽습니다.

오리지널 Clash는 규칙, 프록시, 정책 그룹 등의 설정 구조를 정립했고 많은 클라이언트가 이 필드를 이어받았습니다. Meta 포크는 이 체계를 바탕으로 프로토콜과 네트워크 기능을 확장했고, 이후 mihomo라는 이름으로 계속 개발되고 있습니다. 자료에서 Clash Meta와 mihomo는 서로 완전히 독립되어 호환되지 않는 두 설정 환경이 아니라 같은 발전 계열을 가리키는 경우가 많습니다. 이름이 바뀌었다고 해서 모든 기존 설정을 그대로 옮길 수 있는 것은 아니므로, 필드별로 확인해야 합니다.

호환성은 필드 이름이 비슷하다고 보장되지 않습니다

오리지널 설정의 기본 규칙과 일부 프록시 유형은 대체로 쉽게 옮길 수 있지만, Meta에서 확장된 프로토콜, DNS 옵션, 전송 설정을 오리지널 버전이 인식한다고 단정해서는 안 됩니다. 구형 클라이언트는 오래된 mihomo 코어를 포함할 수도 있으므로, “mihomo 기반”이라는 점은 첫 번째 확인 조건일 뿐입니다. 알 수 없는 프록시 유형, 암호화 방식, 지원되지 않는 전송 매개변수가 나오면 노드 비밀번호를 계속 바꾸기보다 실제 코어의 지원 범위를 먼저 확인하세요.

호환성은 구문을 받아들이는지와 동작이 일치하는지, 두 단계로 나뉩니다. 설정이 로드되었다는 것은 파서가 내용을 받아들였다는 뜻일 뿐입니다. 클라이언트가 특정 필드를 덮어쓰면 최종 동작은 달라질 수 있습니다. 예를 들어 구독에 DNS가 설정되어 있어도 클라이언트가 전역 DNS 설정으로 덮어쓸 수 있고, 파일에서 TUN을 꺼도 화면의 별도 설정으로 활성화할 수 있습니다. 두 기기를 비교할 때는 내려받은 원본 파일만 대조하지 말고 최종 적용 설정과 로그를 확인하세요.

업그레이드와 마이그레이션 검증 순서

마이그레이션할 때는 원본 설정을 복사해 보관하고, 작동이 확인된 설정 하나만 가져오세요. 먼저 설정이 로드되는지 확인한 다음 수동 정책 그룹을 선택해 연결을 검증하고, 마지막으로 규칙 세트, 자동 선택, DNS, TUN을 하나씩 복원합니다. 이렇게 하면 프로토콜 미지원, 설정 참조 누락, 시스템 라우팅 문제를 구분할 수 있습니다. 여러 단계의 설정 덮어쓰기와 원격 리소스를 한꺼번에 가져오면 어느 하나가 실패해도 “클라이언트가 작동하지 않는다”는 결과만 남아 원인을 찾기 어렵습니다.

클라이언트와 코어는 패키징 및 실행 환경에도 영향을 받습니다. 실행 파일을 임의로 앱 디렉터리에 교체하면 시작 매개변수, 권한 서비스, 프로세스 관리 방식이 손상될 수 있습니다. 클라이언트에서 지원하는 업데이트 경로를 우선 사용하세요. 코어를 직접 관리해야 한다면 설정 경로, 작업 디렉터리, 로그 위치를 먼저 파악해야 합니다. 서버에서 코어를 단독으로 실행하는 방식과 데스크톱에서 GUI 클라이언트를 사용하는 방식은 관리 방법이 다르므로 절차를 그대로 바꿔 적용할 수 없습니다.

Clash Plus, Clash Verge Rev, FlClash 중에서 고를 때는 먼저 운영체제 지원과 설정 관리 방식을 살펴보고, 현재 빌드가 필요한 프로토콜을 지원하는지 확인하세요. 아카이브된 Clash for Windows와 ClashX Meta는 기존 설정의 출처를 확인할 때 참고할 수 있지만, 오래된 튜토리얼에서 사용한다는 이유만으로 새 기기의 기본 선택지로 삼을 필요는 없습니다. 오픈소스 라이선스도 구분해야 합니다. mihomo 코어는 GPL-3.0 라이선스를 사용하지만, 주변 앱까지 모두 같은 라이선스를 사용하는 것은 아닙니다.

SS와 VMess: 암호화와 캡슐화

가벼운 구조의 Shadowsocks

Shadowsocks는 흔히 SS라고 줄여 부릅니다. 미리 정한 키와 암호화 방식을 사용해 프록시 트래픽을 전달하며, 기본 형태에서는 TLS를 별도로 덧씌우지 않습니다. 연결 경로가 비교적 단순하고 배포 및 클라이언트 지원도 폭넓습니다. 여기서 “가볍다”는 말은 프로토콜 구조를 뜻하며, 모든 SS 노드가 다른 프로토콜보다 빠르다는 의미는 아닙니다. 서버 회선이 혼잡하거나 기기의 암호화 성능이 낮다면 작은 프로토콜 헤더만으로 병목을 없앨 수 없습니다.

SS를 설정할 때 암호화 방식은 서버 설정과 정확히 일치해야 합니다. 기존 AEAD 방식과 Shadowsocks 2022 계열은 이름 하나만 바꿔 서로 전환할 수 없으며, 후자는 키 형식과 길이에 명확한 요구 사항이 있습니다. 서버에서 제공한 키는 완전한 설정의 일부로 보관해야 합니다. 특정 인코딩의 키를 요구하는 필드에 일반 비밀번호를 임의로 넣어서는 안 됩니다. 인증에 실패하면 로컬 보안 설정을 낮추기보다 암호화 방식, 키, 포트를 먼저 대조하세요.

SS의 TCP와 UDP 전달은 각각 확인해야 합니다. 웹페이지가 열린다고 해서 실시간 음성이나 다른 UDP 앱도 해당 노드를 통해 통신할 수 있다는 뜻은 아닙니다. 서버, 방화벽, 클라이언트 아웃바운드 설정 모두 UDP에 영향을 줄 수 있습니다. 플러그인을 사용하는 설정이라면 클라이언트와 코어가 해당 플러그인 및 옵션을 지원하는지 확인해야 합니다. 플러그인을 적용한 SS는 기본 SS와 연결 조건이 다르므로 테스트할 때 플러그인의 핸드셰이크와 캡슐화 오버헤드를 따로 고려하세요.

VMess의 인증 및 전송 조합

VMess는 V2Ray 프로토콜 계열에서 비롯되었으며, 사용자 식별, 세션 인증, 데이터 전송을 프로토콜 내부에서 구성합니다. 최신 설정에서는 서버가 지원하는 AEAD 방식을 사용해야 합니다. 과거 자료에 나오는 이전 인증 옵션을 그대로 적용하지 마세요. 사용자 ID, 암호화 설정, 시스템 시간이 연결에 영향을 줄 수 있습니다. 특히 기기 시간이 크게 어긋나 있다면 먼저 바로잡으세요. 인증 오류를 모두 네트워크 품질 문제로 돌려서는 안 됩니다. 반복 측정으로 잘못된 ID를 고칠 수는 없습니다.

VMess는 여러 전송 방식을 조합할 수 있습니다. TCP에서 직접 실행하는 설정과 바깥 계층에 WebSocket 또는 다른 지원 전송을 사용하는 설정은 핸드셰이크 경로와 중간 인프라 요구 사항이 다릅니다. WebSocket을 사용할 때 경로, 요청 호스트 이름, TLS 서버 이름은 각각 다른 역할을 합니다. 특정 설정에서 값이 우연히 같더라도 같은 필드로 취급해서는 안 됩니다. 그중 하나라도 빠지면 포트 연결은 되지만 프록시 요청이 실패할 수 있습니다.

사용 조건과 비교 방법

유지 관리가 잘되고 설정이 명확한 SS 서버를 이미 사용 중이라면, 프로토콜 이름이 오래되었다는 이유만으로 바꿀 필요는 없습니다. 현재 서비스가 VMess를 사용하고 특정 전송 방식에 의존한다면 클라이언트와 서버의 매개변수를 계속 일치시키는 것이 우선입니다. 선택할 때 확인해야 할 것은 안정적인 연결 여부, UDP 필요 충족 여부, 설정 유지 관리의 용이성입니다. 프로토콜 이름을 단순히 오래된 것부터 최신 순으로 성능 등급처럼 나열할 수는 없습니다.

두 프로토콜을 비교할 때는 가능한 한 같은 기기, 비슷한 위치의 서버, 동일한 앱 요청을 사용하세요. 한 번에 프로토콜이나 전송 방식 중 하나만 바꾸고 최초 연결, 연속 웹 탐색, 장시간 연결 결과를 각각 기록합니다. 두 설정이 서로 다른 회선에서 제공된다면 테스트 결과는 대개 전체 경로의 차이를 보여줄 뿐 SS나 VMess 자체의 차이라고 할 수 없습니다. 특히 한 번의 웹 속도 측정 화면만으로 프로토콜 효율을 판단하지 마세요.

오래된 구독을 마이그레이션할 때는 클라이언트가 비슷한 이름을 서로 다른 레이블로 표시할 수 있다는 점에도 유의하세요. 노드 메모의 “고속”, “전용 회선” 같은 문구가 아니라 최종 설정의 프록시 유형과 매개변수를 기준으로 판단해야 합니다. 특정 프록시만 실패하면 수동으로 선택한 뒤 로그를 확인하세요. 정책 그룹이 다른 프록시로 자동 전환했다면 웹페이지가 열려도 원래 프록시가 복구되었다는 뜻은 아닙니다.

Trojan과 VLESS: TLS와 사용자 인증

Trojan의 TLS 기반 보안

Trojan은 TLS를 보안 전송의 기반으로 삼고, 암호화된 연결 안에서 프록시 요청과 인증 정보를 전달합니다. 클라이언트에는 일반적으로 서버 주소, 포트, 비밀번호, 올바른 서버 이름이 필요합니다. TLS는 전송을 보호하고 상대 서버의 신원을 확인하며, Trojan 비밀번호는 서비스 이용 권한을 확인합니다. 두 기능은 서로 대체할 수 없습니다. 따라서 비밀번호가 맞더라도 인증서 검증에 실패하면 연결이 올바르게 설정된 것이 아닙니다.

서버 이름은 TLS 핸드셰이크의 이름 협상과 인증서 검증에 사용됩니다. 연결 주소는 도메인 이름일 수도 있고 IP 주소일 수도 있지만, 인증서에 포함된 이름은 설정에서 기대하는 이름과 일치해야 합니다. 도메인 DNS 결과가 바뀌었다고 인증서 이름을 임의로 변경해도 되는 것은 아닙니다. 로그에 인증서 만료, 이름 불일치, 신뢰 체인 오류가 표시되면 시스템 시간, 서버 인증서, 설정을 확인하세요. 인증서 검증 건너뛰기를 일상적인 해결책으로 삼지 마세요.

Trojan은 전송 조합과 구현 확장 방식이 다양합니다. 두 노드가 모두 Trojan으로 표시된다고 해서 필드가 완전히 동일하다고 가정할 수 없습니다. 기본 TLS 연결과 추가 전송으로 캡슐화한 연결은 경로, 호스트 이름, 중간 서비스 요구 사항이 다를 수 있습니다. 설정을 가져온 뒤 핸드셰이크는 완료되지만 요청이 전달되지 않는다면 서버가 사용하는 전송 유형과 구독 변환 과정에서 관련 옵션이 유지되었는지 확인하세요.

VLESS는 보안을 외부 계층에 맡깁니다

VLESS는 간결한 사용자 인증과 요청 캡슐화를 지향하며, 그 자체로 독립적인 암호화 전송과 동등한 보호를 제공하지 않습니다. 일반적으로 TLS나 REALITY 같은 방식과 함께 사용합니다. 여기서 “간결하다”는 전송 보안을 무시해도 된다는 뜻이 아닙니다. 클라이언트의 사용자 ID는 인증 요소 중 하나일 뿐이며, 외부 보안 방식, 전송 네트워크, 서버 설정도 모두 일치해야 합니다. 한 설정의 사용자 ID를 다른 노드에 붙여 넣는 것만으로는 보통 연결할 수 없습니다.

REALITY와 일반 TLS 설정은 검증 조건이 다르며 공개 키, 짧은 ID, 서버 이름 등의 매개변수가 필요합니다. 이러한 값은 서비스 제공자가 안내해야 하며 도메인이나 사용자 ID로 추론할 수 없습니다. 일부 VLESS 설정은 특정 흐름 제어 방식을 사용합니다. 흐름 제어 필드는 외부 보안 및 전송 조합에 따라 달라집니다. 모든 전송 방식에 같은 값을 넣어도 되는 것은 아니며, 무작정 추가하면 서버와 클라이언트가 서로 다르게 해석할 수 있습니다.

추가 핸드셰이크 이해하기

TLS는 보통 연결을 설정하는 과정에서 추가 통신과 연산을 발생시키지만, TLS를 사용하는 프로토콜이 모든 환경에서 더 느리다는 뜻은 아닙니다. 연결 재사용, 세션 재개, 서버 처리 성능, 요청 횟수에 따라 실제 체감은 달라집니다. 반대로 캡슐화 계층이 적어도 첫 페이지가 더 빨리 열리는 것은 아닙니다. DNS 조회, 앱 자체 연결, 원격 서버의 응답 시간이 더 큰 비중을 차지할 수 있습니다. 설정 필드 개수보다 전체 요청 경로를 기준으로 지연 시간을 살펴보세요.

일상적인 사용에서는 서버 측 Trojan 설정이 명확하게 관리되고 기기에 정상적인 인증서 신뢰 환경이 마련되어 있다면 TLS 오류 유형을 기준으로 문제를 찾기 쉽습니다. 기존 VLESS 서비스를 사용한다면 현재 코어가 보안 방식과 전송 매개변수를 지원하는지 확인하세요. 두 프로토콜 사이에 환경과 무관한 고정 우선순위는 없습니다. 이름이 가볍거나 최신인지보다 안정적인 배포, 명확한 매개변수 출처, 지속적으로 업데이트되는 클라이언트가 더 중요합니다.

데스크톱에서는 되지만 모바일에서는 안 된다면 휴대전화 성능 탓으로 돌리기 전에 최종 설정을 비교하세요. 모바일 구독 변환 과정에서 보안 확장 옵션이 누락되거나 시스템 시간, 인증서 환경이 다를 수 있습니다. 먼저 양쪽에서 지원되는 동일한 설정을 사용하고 자동 전환을 꺼서 간섭을 줄인 뒤, 실제로 같은 프록시를 선택했는지 확인하세요. 그런 다음 DNS 조회, 핸드셰이크, 인증, 요청 전달 순으로 점검해야 프로토콜과 플랫폼 차이를 구분할 수 있습니다.

Hysteria2와 TUIC: QUIC 전송

UDP와 QUIC을 사용하는 이유

Hysteria2와 TUIC는 모두 UDP 기반 QUIC으로 프록시 전송을 구현하지만 서로 다른 프로토콜이므로 인증 필드를 공유해 그대로 바꿔 쓸 수 없습니다. QUIC은 신뢰성 있는 전송, 혼잡 제어, 보안 핸드셰이크 등의 기능을 사용자 공간에서 구현해 하나의 연결로 여러 스트림을 전달할 수 있습니다. 전송 계층의 순서 보장 때문에 서로 다른 스트림 간에 생기는 일부 차단을 줄일 수 있지만, 각 스트림 안에서는 여전히 패킷 손실과 데이터 순서를 처리해야 합니다.

이 구조는 왕복 지연 시간이 길거나 패킷 손실이 있는 일부 경로에서 이점을 줄 수 있지만, 네트워크가 UDP를 안정적으로 전달해야 합니다. 경로에서 UDP를 제한하거나 매핑 유지가 불안정하거나 해당 트래픽에 엄격한 속도 제한이 적용되면 연결이 실패하거나 TCP보다 불안정해질 수 있습니다. 따라서 QUIC을 쓴다고 무조건 더 빠르다고 볼 수 없습니다. 먼저 기본 연결 가능 여부를 확인하고 장시간 전송 중 손실 복구와 공정한 대역폭 분배를 살펴보세요.

Hysteria2의 대역폭과 혼잡 제어

Hysteria2는 네트워크 상태가 좋지 않은 환경에서 전송 효율을 높이는 데 중점을 둡니다. 설정에는 대역폭 힌트, 인증, TLS, 선택적 난독화가 포함될 수 있습니다. 대역폭 값은 속도를 높이는 스위치도, 노드 구매 상품에 표시된 속도도 아닙니다. 로컬 업로드와 다운로드 속도, 실제 경로 성능을 함께 고려해야 합니다. 지나치게 높게 설정하면 버퍼가 쌓이고 패킷이 손실되며 같은 네트워크의 다른 앱에 영향을 줄 수 있습니다. 서버가 클라이언트의 전송 정책을 제한할 수도 있습니다.

대역폭 매개변수를 입력하기 전에 현재 구현의 단위와 기본 동작을 확인하세요. 화면에 입력한 값이 코어 필드로 변환되는 방식은 인터페이스마다 다를 수 있습니다. 먼저 서비스 제공자가 안내한 적정 설정을 사용하고 필요할 때만 통제된 방식으로 조정하세요. 난독화 비밀번호와 인증 비밀번호는 역할이 다르므로 혼용할 수 없습니다. 난독화를 활성화하면 서버에도 이에 맞는 설정이 필요합니다. Hysteria와 Hysteria2는 서로 다른 세대의 프로토콜이므로 이름이 비슷해도 설정을 그대로 재사용할 수 없습니다.

TUIC의 세션과 전달 설정

TUIC 역시 QUIC 기반이며, 일반적인 설정에는 사용자 ID, 비밀번호, TLS 이름, 애플리케이션 계층 프로토콜 협상이 포함됩니다. 혼잡 제어, UDP 전달 모드, 연결 유지 설정은 리소스 사용과 호환성에 영향을 주지만 서버가 지원해야 합니다. 특히 다른 코어 설정의 필드를 mihomo에 그대로 복사하지 마세요. 같은 개념도 구현에 따라 이름, 기본값, 지원 범위가 다를 수 있으므로 대상 형식에 맞게 변환해야 합니다.

모바일 네트워크와 연결 마이그레이션

QUIC에는 연결 마이그레이션을 지원하는 메커니즘이 있지만, Wi-Fi와 셀룰러 네트워크 간에 프록시 연결이 끊김 없이 이어지는지는 클라이언트 구현, 서버 설정, 운영체제에 달려 있습니다. 프로토콜 기능이 앱 사용 경험을 보장하는 것은 아닙니다. 네트워크 전환 후 잠시 끊기면 핸드셰이크가 다시 진행되는지, 이전 연결이 종료되는지, 앱이 재시도하는지 확인하세요. 연결 연속성이 중요한 작업이라면 한 번의 다운로드 테스트보다 실제 네트워크 전환 테스트가 더 중요합니다.

또한 외부 계층이 UDP라고 해서 그 안의 모든 트래픽이 비신뢰 전송으로 바뀌는 것은 아닙니다. 브라우저의 신뢰성 있는 바이트 스트림은 여전히 데이터 전체를 전달해야 합니다. 프록시가 업무용 UDP를 전달할 때는 다른 방식으로 구성될 수 있습니다. 문제를 진단할 때 외부 전송과 내부 트래픽을 구분하세요. 외부 UDP가 통하지 않으면 전체 QUIC 연결에 영향을 주지만, 특정 트래픽만 통하지 않는다면 서버 권한, 대상 제한, 규칙 선택이 원인일 수 있습니다.

모바일에서 장시간 사용할 예정이라면 대기 상태, 백그라운드, 신호가 약한 환경도 테스트하세요. 잦은 연결 유지 신호는 매핑을 유지할 수 있지만 기기를 깨우고 무선 통신을 활성 상태로 유지해 배터리 소모를 늘릴 수도 있습니다. 연결을 너무 빨리 끊으면 재연결이 잦아집니다. 모든 기기에 맞는 고정 매개변수 조합은 없습니다. 검증된 TCP 계열 아웃바운드를 비교 대상으로 남겨 두면 네트워크가 바뀔 때 문제가 UDP 경로에 집중되는지 빠르게 판단할 수 있습니다.

연결 속도, 리소스, 모바일 배터리

속도는 단계별로 나눠 살펴보세요

“빠르다”는 말에는 최소한 DNS 조회, 최초 연결 설정, 요청 응답, 지속 처리량이라는 네 가지 지표가 포함됩니다. 클라이언트의 지연 시간 테스트는 보통 정해진 방식으로 한 번 측정한 결과이며 모든 웹사이트의 로딩 시간을 뜻하지 않습니다. 작은 파일 탐색은 왕복 지연 시간과 핸드셰이크의 영향을 더 많이 받고, 장시간 다운로드는 대역폭, 손실 복구, 혼잡 상태에 더 크게 좌우됩니다. 두 프록시가 서로 다른 지표에서 강점을 보일 수 있으므로 숫자 하나만으로 모든 용도를 결정하지 마세요.

리소스 사용량도 프로토콜 이름만으로 고정되지 않습니다. 암호화 구현, 하드웨어 명령어 지원, 동시 연결 수, 패킷 크기, 로그 수준에 따라 CPU 부하가 달라집니다. 짧은 연결이 많으면 핸드셰이크와 상태 관리에 시간이 쓰이고, 대용량 데이터를 계속 전송하면 암호화, 메모리 복사, 네트워크 스택 오버헤드가 더 두드러집니다. 같은 프로토콜도 PC와 저전력 휴대전화에서 다르게 동작할 수 있으며, 이는 프로토콜 설계뿐 아니라 기기와 구현의 차이에서 비롯됩니다.

배터리는 어디에서 소모될까요?

모바일 배터리 소모는 CPU와 무선 네트워크 상태의 영향을 함께 받습니다. 신호가 약하거나 기기가 자주 깨어나고, 하트비트가 잦거나, 연결을 반복해서 다시 설정하거나, 여러 앱이 백그라운드에서 요청을 보내면 무선 통신이 활성 상태로 유지될 수 있습니다. 프록시 트래픽이 많지 않아도 작은 패킷을 장시간 자주 보내면 소모량이 눈에 띌 수 있습니다. 반대로 CPU를 순간적으로 더 많이 사용하더라도 전송 시간이 줄면 전체 에너지 소비는 더 적을 수 있습니다. 따라서 “CPU 사용량이 낮다”는 이유만으로 배터리 효율이 좋다고 단정할 수 없습니다.

TUN, DNS, 규칙 세트, 정책 그룹의 상태 확인도 클라이언트 전체의 비용에 포함됩니다. 수십 개 프록시를 대상으로 자동 속도 측정을 자주 실행하면 연결 유지 부담이 프로토콜에 더해집니다. 모바일에서는 불필요한 측정 주기와 백그라운드 작업을 줄인 뒤 프로토콜을 비교하는 편이 낫습니다. 문제를 진단할 때는 잠시 로그 상세도를 높이고, 재현 후 일상적인 수준으로 되돌리세요. 대량 로그 기록과 화면 갱신을 프로토콜 자체의 고정 오버헤드로 계산하지 않도록 합니다.

재현 가능한 비교 테스트 만들기

테스트에서는 기기, 위치, 네트워크 연결, 대상 사이트, 사용 작업을 고정하고 가능한 한 비슷한 시간대에 두 설정을 번갈아 확인하세요. 먼저 작은 요청을 보내고, 연속 전송을 테스트한 다음 실제 앱을 관찰합니다. 한 번에 하나의 변수만 바꾸세요. 예를 들어 프로토콜만 바꾸거나 DNS 방식만 바꿉니다. 프로토콜을 비교하면서 TUN을 켜고 규칙 세트를 바꾸고 시스템 절전 모드까지 조정하면 체감이 나아져도 무엇이 효과를 냈는지 알 수 없습니다.

배터리 비교에서는 화면 밝기, 신호 강도, 백그라운드 앱 상태도 비슷하게 유지하고 실제 사용 시간도 충분히 확보하세요. 앱 설치 직후 첫 실행, 시스템 인덱싱, 한꺼번에 진행되는 동기화가 단기적인 변동을 일으킬 수 있습니다. 시스템 배터리 통계는 추세를 파악하는 데 도움이 되지만 프로토콜별 절대 에너지 소비량을 직접 산출해 주지는 않습니다. 앱이 백그라운드에 있을 때 시스템이 연결을 반복해서 종료한다면 프로토콜의 연결 유지 설정을 바꾸기 전에 백그라운드 권한과 절전 제한부터 확인하세요.

자동 선택은 서비스 품질 평가가 아닙니다

자동 속도 측정 정책 그룹은 보통 특정 측정 대상과 규칙을 기준으로 프록시를 선택합니다. 측정 대상에 연결된다고 해서 실제 서비스 사이트도 사용할 수 있는 것은 아닙니다. 전환 주기가 너무 짧으면 비슷한 결과에도 선택이 계속 바뀌어 장시간 연결을 방해하고 테스트 요청도 늘어날 수 있습니다. 문제를 진단하는 동안에는 수동 선택으로 바꾸고 연결의 실제 동작을 확인하세요. 안정화한 뒤 자동 정책을 다시 사용하되 적절한 허용 오차와 간격을 설정해 이득 없는 전환을 줄이세요.

웹 탐색은 정상인데 동영상이 끊긴다면 대상 연결에 실제로 어떤 아웃바운드가 선택되었는지 확인한 뒤 지속 처리량 부족, 서버 제한, 앱 캐시 문제를 구분하세요. 다운로드는 빠른데 페이지가 느리게 열린다면 DNS 조회와 짧은 연결의 핸드셰이크를 살펴보세요. 네트워크 전환 때만 실패한다면 연결 재설정과 시스템 라우팅 복구를 확인하세요. 증상별로 나눠야 프로토콜 비교의 목적이 분명해집니다. 프로토콜 이름만 계속 바꾸면 실제 병목을 놓치기 쉽습니다.

최초 연결을 관찰하는 순서는 노드 선택, 지연 시간 측정, 프록시 적용 여부 확인에서 함께 살펴볼 수 있습니다. 결론은 실제 테스트 조건 안에서만 내려야 합니다. 현재 기기와 네트워크에서 잘 맞는 프로토콜이라고 해서 모든 플랫폼에서 똑같은 장점이 있는 것은 아닙니다. 장기간 사용을 위한 더 신뢰할 만한 기준은 결과를 안정적으로 재현할 수 있는지, 유지 관리하기 쉬운지, 앱의 요구 사항을 충족하는지입니다.

구독 형식과 설정 호환성

구독은 가져오는 경로이지 통일된 형식이 아닙니다

구독 링크는 원격 콘텐츠를 가져오는 주소일 뿐입니다. 응답에는 전체 YAML 설정, 노드 링크 모음, 특정 클라이언트 전용 데이터 형식이 들어 있을 수 있습니다. 브라우저에서 링크가 열린다고 해서 그 콘텐츠가 mihomo에 적합하다는 뜻은 아닙니다. 로그인 페이지, 만료 안내 또는 다른 구조가 반환되면 클라이언트에서 파싱 오류가 발생할 수 있습니다. 확인할 때는 콘텐츠 유형과 오류 요약을 살펴보고, 인증 정보가 포함된 링크 전체를 공개적으로 공유하지 마세요.

전체 설정에는 보통 프록시, 정책 그룹, 규칙이 포함되며 원격 규칙 세트나 프록시 제공자를 참조하기도 합니다. 노드 모음에는 주로 아웃바운드 연결 정보가 담기며 트래픽을 어떻게 분기해야 하는지는 포함되지 않을 수 있습니다. 가져온 뒤 노드는 보이는데 예상한 정책 그룹이 없다면 노드가 사라진 것이 아니라 구독 유형이 다른 것일 수 있습니다. proxy-providers를 사용할 때는 기본 설정에서 제공자를 올바르게 참조해야 합니다. 원격 콘텐츠를 가져오는 데 성공했어도 정책 그룹이 그 안의 프록시를 사용하고 있다는 뜻은 아닙니다.

변환 과정에서 프로토콜 의미가 손실될 수 있습니다

파일 확장자를 YAML로 바꾸는 것만으로 서로 다른 생태계의 설정을 변환할 수는 없습니다. 사용자 인증, 전송 경로, TLS 이름, 흐름 제어, 프로토콜 확장을 항목별로 매핑해야 하며 대상 코어도 해당 기능을 지원해야 합니다. 기본 프로토콜만 인식하는 변환 도구는 서버 주소를 남겨 두면서 추가 필드를 버릴 수 있고, 그 결과 “노드는 있지만 연결할 수 없는” 상태가 됩니다. 새 프로토콜이나 복잡한 전송 조합일수록 원본 설정과 변환 결과를 꼼꼼히 대조해야 합니다.

전체 설정과 일부 덮어쓰기 설정의 적용 순서도 중요합니다. 구독을 업데이트하면 원격 파일이 교체될 수 있으므로 캐시 내용을 직접 편집해도 변경 사항이 오래 유지되지 않습니다. 규칙을 추가해야 한다면 클라이언트에서 제공하는 덮어쓰기 또는 병합 기능을 우선 사용하고, 구독 업데이트 뒤에도 적용되는지 확인하세요. 전역 덮어쓰기, 개별 설정 덮어쓰기, 코어 기본값이 함께 존재한다면 최종 적용 순서를 파악해야 업데이트 때마다 다른 설정으로 테스트하는 일을 막을 수 있습니다.

먼저 구조를 검증한 다음 자동 업데이트를 켜세요

처음 가져온 뒤에는 설정 이름과 출처를 확인하고, 프록시 유형, 정책 그룹 참조, 규칙이 온전히 포함되어 있는지 살펴보세요. 프록시 하나를 수동 선택해 연결을 검증한 다음 업데이트 간격과 자동 선택을 설정합니다. 업데이트가 실패하면 주소 조회, 요청 연결, 응답 콘텐츠, 설정 파싱의 네 단계로 나눠 점검하세요. 기존 설정이 연결된다면 먼저 보관하세요. 다시 가져오려고 유일하게 작동하는 설정과 진단 단서를 삭제하지 마세요.

업데이트 경로가 현재 프록시에 의존할 수도 있습니다. 예를 들어 원격 제공자가 특정 정책을 통해 연결되고, 해당 정책은 아직 업데이트되지 않은 프록시 모음에 의존한다면 시작 시 의존성 문제가 생길 수 있습니다. 리소스를 처음 불러올 때 사용할 수 있는 아웃바운드와 캐시 사용 가능 여부를 확인하세요. 화면의 업데이트 버튼이 계속 돌아간다는 이유만으로 코어 오류라고 판단하지 마세요. 실패한 대상이 기본 구독인지, 프록시 제공자인지, 규칙 제공자인지에 따라 해결 방법이 다릅니다.

아래 예시는 기본 실행 옵션만 보여줍니다. 유효한 아웃바운드, 정책 그룹, 규칙이 이미 포함된 설정에 병합할 수 있습니다. 완성된 구독이 아니며 원격 프록시를 만들지도 않습니다. 문제를 진단할 때 실행 모드와 로그 수준을 명확하게 설정하면 화면 설정과 파일 내용 사이의 혼란을 줄일 수 있습니다. 클라이언트가 해당 필드를 덮어쓰는 경우에는 최종 적용 설정을 기준으로 해야 합니다.

mode: rule
log-level: info
allow-lan: false
ipv6: false

여러 설정 관리와 복구

여러 설정을 사용하면 출처나 테스트 방식을 나눠 관리할 수 있지만 한 번에 명확한 설정 하나만 활성화해야 합니다. 정책 그룹에서 마지막으로 선택한 프록시를 클라이언트가 저장할 수 있으므로 설정을 바꿔도 예상한 프록시로 자동 복귀한다고 가정하지 마세요. 테스트할 때마다 현재 설정, 모드, 선택된 아웃바운드를 다시 확인해야 합니다. 프로토콜을 마이그레이션할 때는 모든 노드를 한곳에 섞기보다 용도를 알아볼 수 있는 이름을 설정에 붙여야 비교하고 복구하기 쉽습니다.

업데이트가 성공한 뒤에도 동작을 확인해야 합니다. 새 규칙이 앱의 아웃바운드를 바꾸거나, 노드 이름이 바뀌어 기존 정책 선택이 무효가 되거나, 원격 리소스 참조가 달라질 수 있습니다. 복구 가능한 사본을 보관하고 클라이언트에서 이전 설정으로 되돌릴 수 있는지 알아두세요. 파일, 링크, 업데이트의 관계는 Profile과 여러 설정 관리를 참고하세요. 자주 발생하는 업데이트 오류는 FAQ에서 더 확인할 수 있습니다.

DNS, TUN, 트래픽 진입 경로

프로토콜 아웃바운드가 있다고 앱 트래픽이 유입된 것은 아닙니다

프록시 프로토콜은 클라이언트에서 서버까지 데이터를 어떻게 전송할지 결정하고, 시스템 프록시와 TUN은 앱 트래픽이 클라이언트로 들어오는 방식을 결정합니다. 서로 다른 계층의 문제입니다. 시스템 프록시는 보통 앱이 운영체제의 프록시 설정을 따라야 하며, 일부 앱은 이를 무시합니다. TUN은 가상 네트워크 인터페이스와 라우팅으로 더 넓은 범위의 트래픽을 처리합니다. 앱이 직접 연결되는 이유는 노드 프로토콜이 지원되지 않아서가 아니라 트래픽이 코어를 통과하지 않기 때문일 수도 있습니다.

마찬가지로 TUN을 켰다고 모든 트래픽이 원격 프록시를 사용하게 되는 것은 아닙니다. 코어에 들어온 뒤에도 규칙을 거치며 직접 연결 규칙에 해당하는 요청은 직접 나갑니다. 확인할 때는 진입 경로, 규칙, 아웃바운드를 나눠 살펴보세요. 먼저 연결 기록을 찾고, 적용된 규칙과 정책 그룹을 확인한 뒤, 실제 프록시를 확인합니다. 연결 기록에 대상 앱이 전혀 나타나지 않는다면 원격 프로토콜의 인증 매개변수가 아니라 트래픽 진입 경로와 권한부터 해결해야 합니다.

Fake-IP와 실제 주소 조회

Fake-IP 모드는 도메인에 가상 주소를 반환하고 도메인과 연결 간 매핑을 유지해, 코어가 나중에 트래픽을 처리할 때 대상 이름을 확인할 수 있도록 합니다. 원격 프록시 서버가 아니며 아웃바운드 정책을 자동으로 바꾸지도 않습니다. redir-host는 실제 조회 주소를 반환하는 방식에 가깝습니다. 두 방식은 도메인 인식, 캐시, 앱 호환성에 미치는 영향이 다릅니다. 이름만 보고 정하기보다 앱 동작과 현재 규칙 요구 사항을 고려해 선택하세요.

일부 기기의 기기 검색, 로컬 네트워크 서비스, 특정 앱은 실제 DNS 조회 결과에 의존할 수 있습니다. 이런 경우 fake-ip-filter를 사용해 필요한 항목만 제외할 수 있습니다. 모든 도메인을 제외하면 필터가 Fake-IP를 사용하는 목적 자체가 달라지므로 주의하세요. 모드를 바꾸면 시스템, 브라우저, 앱에 이전 캐시가 남아 있을 수 있습니다. 상황에 따라 관련 캐시를 지우거나 앱을 다시 시작해 이전 결과와 새 결과가 섞여 오판하지 않도록 하세요.

DNS 조회 경로와 시작 시 의존성

프록시 서버에 연결할 때도 DNS가 필요할 수 있습니다. 서버 주소를 조회하려면 아직 연결되지 않은 프록시를 먼저 거쳐야 하는 경우 시작 시 의존성 문제가 발생합니다. 암호화된 DNS 업스트림의 호스트 이름, 프록시 노드 도메인, 일반 서비스 도메인은 서로 다른 설정 항목에서 조회될 수도 있습니다. 문제를 진단할 때는 어느 계층의 도메인 조회가 실패했는지 확인한 뒤 해당 조회 경로를 살펴보세요. 모든 DNS 문제를 하나의 공통 스위치 탓으로 돌려서는 안 됩니다.

IPv6도 별도로 확인해야 합니다. 시스템은 IPv6를 우선 사용할 수 있지만 프록시 진입 경로, 규칙, 원격 서버 지원이 완전하지 않으면 일부 사이트가 지연되거나 IPv4로 전환될 수 있습니다. 특정 IPv6 설정을 꺼서 문제 범위를 좁힐 수는 있지만 모든 환경에서 영구적인 해결책은 아닙니다. 시스템 주소, 라우팅, DNS 응답, 프록시 서버 지원이 서로 일치하는지 확인해 실제 사용하는 주소 계열을 테스트해야 합니다.

규칙 순서와 플랫폼별 차이

규칙은 보통 위에서 아래로 매칭되며 먼저 일치한 항목이 이후 정책을 결정합니다. 노드를 테스트할 때 요청이 앞쪽의 직접 연결 규칙에 걸리지 않았는지 확인하세요. 프로세스 규칙, 도메인 규칙, 주소 규칙은 필요한 정보가 서로 다르고 플랫폼에서 제공하는 프로세스 정보도 제한적일 수 있습니다. 도메인이 아직 인식되지 않았거나 조회 경로가 바뀌었거나 연결이 캐시된 경우 관찰 결과가 예상과 다를 수 있습니다. 규칙 두 개의 순서만 바꾸면 문제가 해결된다고 단정하지 마세요.

데스크톱에서 TUN을 활성화하려면 서비스 권한, 가상 네트워크 어댑터, 라우팅이 필요할 수 있습니다. 모바일은 보통 시스템 VPN 권한이 필요하며 백그라운드 관리의 영향을 받습니다. 여러 네트워크 도구가 동시에 실행되면 시스템 프록시, DNS, 기본 경로를 두고 충돌할 수 있습니다. 테스트할 때는 트래픽을 가로채는 도구를 하나만 남기고 기존 설정을 기록한 다음 하나씩 복원하세요. Windows 스토어 앱의 특정 루프백 문제는 UWP 루프백 예외 안내를 참고하세요.

이러한 진입 경로와 DNS 요인은 프로토콜을 바꾼 뒤 문제가 해결된 것처럼 보이는 이유를 설명할 수 있습니다. 변경 과정에서 연결이 다시 설정되거나 캐시가 갱신되거나 네트워크 스택이 재시작되었을 뿐, 프로토콜 자체가 DNS를 고친 것은 아닐 수 있습니다. 신뢰할 만한 결론을 내리려면 프로토콜은 그대로 두고 관련 설정만 따로 다시 불러와 같은 변화가 재현되는지 확인하세요. 계층을 분리해야 노드, 규칙, DNS, 시스템 권한 중 무엇을 수정할지 판단할 수 있습니다.

사용 환경별 선택과 단계별 문제 해결

제약 조건에 따라 후보를 좁히세요

데스크톱에서 일상적으로 웹을 탐색할 때는 매개변수가 완전하고 서버가 안정적이며 관리하기 쉬운 아웃바운드를 우선 선택하세요. 사용할 수 있는 SS, VMess, Trojan 서비스가 이미 있다면 프로토콜 이름이 최신이라는 이유만으로 옮길 필요는 없습니다. 특정 VLESS 보안 조합이 필요하다면 현재 코어와 구독 변환 경로가 이를 지원하는지 먼저 확인하세요. GUI 클라이언트는 Clash Plus부터 살펴보고, 운영체제 지원, 설정 관리, 실제 기능 요구 사항을 기준으로 다운로드 페이지에 나열된 다른 클라이언트와 비교할 수 있습니다.

모바일로 이동 중 사용할 때는 네트워크 전환, 백그라운드 동작, 배터리를 함께 고려해야 합니다. 평소 사용하는 Wi-Fi와 셀룰러 네트워크에서 안정적으로 연결되는 설정을 먼저 선택한 뒤 대기 상태와 재연결을 살펴보세요. 현재 네트워크에서 UDP가 불안정하다면 Hysteria2나 TUIC를 유일한 후보로 삼지 않는 편이 좋습니다. 지연 시간이 길고 패킷 손실이 뚜렷하면서 UDP가 안정적이라면 비교 대상에 추가할 수 있습니다. 결론은 짧은 실험실식 속도 측정이 아니라 평소 이동 경로에서 실제 앱을 사용한 결과를 바탕으로 내려야 합니다.

대용량 파일 전송은 지속 처리량, 서버 제한, 네트워크 공유를 고려해야 합니다. 실시간 음성은 지터, 패킷 손실, 업무용 UDP 사용 가능 여부가 더 중요합니다. 서버나 라우터에서는 프로세서 아키텍처, 메모리, 로그 보관, 자동 시작도 고려해야 하므로 mihomo 코어를 직접 관리하는 방식이 적합한 경우가 많습니다. 데스크톱 GUI 클라이언트의 편의 기능이 독립 코어에도 있다고 가정할 수 없습니다. 배포 전에 누가 설정을 생성하고 서비스를 복구할지 정해야 합니다.

연결 단계별로 문제 범위 좁히기

첫 번째 단계에서는 설정이 로드되었는지 확인합니다. 알 수 없는 필드, 잘못된 프록시 유형, 존재하지 않는 정책 그룹 참조는 먼저 설정 구조를 수정해야 합니다. 이 단계에서는 아직 네트워크 연결이 시작되지 않았습니다. 두 번째 단계에서는 서버 주소가 조회되는지, 대상 포트가 해당 전송 방식으로 연결 가능한지 확인합니다. TCP 포트 연결에 성공해도 UDP 사용 가능 여부, TLS, 프로토콜 인증, 실제 프록시 요청 성공을 증명하지는 않습니다. 계속 다음 단계로 검증해야 합니다.

세 번째 단계에서는 보안 핸드셰이크와 인증을 점검합니다. 인증서 오류는 시간, 이름, 신뢰 체인을 확인하고 인증 오류는 비밀번호, 사용자 ID, 키 형식, 프로토콜 세대를 확인하세요. 네 번째 단계에서는 실제 트래픽 전달을 살펴봅니다. 요청에 적용된 규칙, 정책 그룹, 최종 아웃바운드를 확인하고 모든 대상에서 실패하는지 특정 대상에서만 실패하는지 구분하세요. 일부 트래픽만 비정상이라면 DNS, 주소 계열, 서버 권한, 대상 앱 특성을 살펴보세요. 모든 설정을 처음부터 바꾸지는 마세요.

최소 재현 환경과 복구 경로를 유지하세요

문제를 진단하는 동안 복구 가능한 설정 하나, 수동 정책 하나, 명확한 대상 하나만 사용하고 자동 선택과 복잡한 설정 덮어쓰기는 잠시 줄이세요. 변경 사항과 결과를 매번 기록해 실패하면 이전 상태로 되돌릴 수 있도록 합니다. 디버그 로그는 문제 발생 단계를 파악하는 데 도움이 되지만 공유하기 전에 구독 주소, 인증 정보, 민감한 대상 정보를 삭제해야 합니다. 공개된 문제 설명에는 클라이언트 이름, 코어 식별 정보, 운영체제, 프로토콜 유형, 오류 범주를 남기면 초기 진단에 대개 충분합니다.

두 프로토콜이 같은 시점에 모두 나빠졌다면 로컬 네트워크, 서버 상태, 공통 의존 요소를 먼저 확인하세요. 한 프로토콜만 실패한다면 해당 프로토콜에 특유한 전송 및 인증 요구 사항을 비교합니다. 같은 설정이 다른 기기에서 정상 작동하면 먼저 이 기기의 시간, 인증서, 권한, 최종 설정 덮어쓰기를 점검하세요. 네트워크를 바꾼 뒤 복구되었다면 원래 경로의 조건을 집중적으로 살펴보세요. 이런 교차 검증이 구독을 계속 새로고침하는 것보다 원인을 명확히 파악하는 데 도움이 됩니다.

설정을 조정한 뒤에는 웹페이지 하나만 확인하지 마세요. 일상적으로 사용하는 앱, 업무용 UDP, 절전 후 복구, 네트워크 전환을 다시 테스트하고 시스템 프록시나 TUN을 끈 뒤에도 시스템 네트워크가 예상대로 복구되는지 확인하세요. 마지막으로 적절한 로그 수준, 업데이트 간격, 자동 정책을 복원하고 임시 테스트 설정을 정리합니다. 장기적인 관리의 목표는 매개변수를 최대한 많이 유지하는 것이 아니라 각 설정의 용도를 설명하고 문제가 생겼을 때 어느 계층부터 확인할지 아는 것입니다.