프로토콜·코어 기술 가이드

1. 프로토콜 선택의 네 가지 기준

프로토콜, 전송 방식, 코어, 인터페이스는 서로 다른 계층입니다

클라이언트에 표시되는 노드 이름은 대개 제공자가 정합니다. 이름에 '고속', '전용선'이라고 적혀 있어도 기술 사양을 대신하지는 않습니다. 실제 연결에는 최소 네 계층이 관여합니다. 프로토콜은 클라이언트와 서버의 인증 및 전달 방식을 정하고, 전송 방식은 TCP·UDP 등으로 데이터를 전달합니다. 코어는 프로토콜을 구현하고 설정을 해석해 규칙을 적용하며, 그래픽 인터페이스는 구독 관리와 시스템 프록시, 로그 접근 기능을 제공합니다. 같은 인터페이스라도 코어가 바뀌면 인식하는 노드 유형이 달라질 수 있습니다. 같은 프로토콜이라도 서버와 회선이 다르면 사용 경험이 크게 달라질 수 있습니다.

따라서 선택의 첫 단계는 프로토콜 이름의 신구를 비교하는 것이 아니라 양쪽이 제대로 통신할 수 있는지 확인하는 것입니다. 서버에서 사용하는 프로토콜과 인증 정보, 전송 방식, 보안 설정이 클라이언트 설정과 일치해야 합니다. 노드 유형이 VLESS를 지원한다고 해서 모든 VLESS 조합을 지원하는 것은 아닙니다. 인터페이스에 특정 이름이 표시되어도 실행 중인 코어가 해당 설정을 전부 이해한다고 볼 수 없습니다. 앱 이름만 보고 판단하기보다 클라이언트의 코어 정보와 실제 설정을 확인하는 편이 정확합니다.

연결 시간과 지속 전송 속도를 구분해 살펴보세요

웹페이지를 열 때는 도메인 조회, 서버 연결, 인증, 대상 사이트 연결, 첫 바이트 수신까지 여러 단계가 필요합니다. 첫 접속이 느리다면 어느 단계에서든 지연이 발생했을 수 있습니다. 대용량 파일 다운로드는 지속적인 전송 성능, 혼잡 제어, 서버의 외부 회선, 대상 사이트의 속도 제한에 더 큰 영향을 받습니다. 첫 바이트를 빠르게 받더라도 전송 속도를 오래 유지하지 못하는 노드가 있는가 하면, 연결 준비 시간은 조금 더 걸려도 다운로드가 안정적인 노드도 있습니다. 두 결과는 서로 모순되지 않으며, 하나의 지연 시간만으로 모두 설명할 수도 없습니다.

모바일 네트워크에서는 네트워크 전환과 무선 모듈의 절전 동작도 고려해야 합니다. Wi-Fi에서 셀룰러 네트워크로 전환하면 로컬 주소와 외부 IP, 경로 품질까지 달라질 수 있습니다. 일부 연결은 다시 수립해야 합니다. 전송 구현에 따라 경로 변경을 시도할 수도 있지만, 실제 결과는 코어와 서버, 중간 네트워크가 함께 지원하는지에 달려 있습니다. 프로토콜에 특정 기능이 있다는 것은 설계상 그 기능을 제공한다는 뜻일 뿐, 모든 배포 환경에서 활성화되어 있거나 앱의 세션이 반드시 유지된다는 뜻은 아닙니다.

조건을 충족하지 않는 선택지부터 제외하세요

실제 선택은 제외하는 방식으로 진행할 수 있습니다. UDP 외부 연결이 안정적으로 허용되지 않는 네트워크라면 QUIC 기반 프로토콜을 유일한 연결 수단으로 삼지 마세요. 기기의 코어가 특정 보안 조합을 지원하지 않는다면 생소한 필드를 지워 억지로 가져오지 마세요. 서버가 한 가지 프로토콜만 제공한다면 클라이언트에서 다른 프로토콜로 바꿀 수도 없습니다. 사용할 수 있는 조합을 추린 뒤에는 같은 시간대, 같은 기기, 같은 대상 조건에서 성능을 비교하세요. 이렇게 얻은 결과는 현재 환경에 대한 판단이지, 조건을 무시한 프로토콜 순위가 아닙니다.

2. SS와 VMess의 설계 차이

SS: 비교적 단순한 프로토콜 구조와 명확한 암호화 설정

Shadowsocks는 보통 SS로 줄여 부르며, 처음에는 가볍게 암호화된 프록시 연결을 제공하도록 설계됐습니다. 설정의 핵심은 비교적 단순합니다. 서버 주소, 포트, 암호화 방식, 비밀번호가 필요합니다. 클라이언트는 로컬 앱의 요청을 프로토콜 데이터로 변환하고, 서버는 대상 서버와 연결합니다. 널리 쓰이는 기존 AEAD 방식은 암호화와 메시지 인증을 결합해 데이터 변조 여부를 확인할 수 있습니다. 여기서 암호화 '방식'은 속도를 위해 임의로 바꿔도 되는 옵션이 아닙니다. 양쪽의 방식이나 인증 정보가 일치하지 않으면 연결을 제대로 수립할 수 없습니다.

SS에는 이후 여러 프로토콜 사양과 확장 기능이 추가됐으며, 키 요구 사항이 다른 최신 방식도 있습니다. 모두 SS라고 해서 이전 설정의 비밀번호 문자열을 다른 방식에 그대로 옮겨 쓸 수 있는 것은 아닙니다. 일반 비밀번호를 받는 방식도 있고, 특정 길이와 인코딩을 요구하는 키를 사용해야 하는 방식도 있습니다. 클라이언트에서 플러그인 확장을 지원하더라도 다른 클라이언트에는 같은 플러그인 구현이 없을 수 있습니다. 가져오기는 성공하지만 핸드셰이크가 계속 실패한다면 로컬 혼합 포트를 반복해서 바꾸기보다 암호화 방식, 키 형식, 플러그인 설정부터 확인하세요.

SS의 기본 구조는 비교적 단순하지만 실제 자원 부담은 암호화 방식, CPU 명령어 지원, 구현 품질, 트래픽 규모에 따라 달라집니다. TCP와 UDP 전달 기능도 양쪽에서 각각 지원해야 합니다. 노드가 UDP를 지원해도 모든 앱의 UDP 요청이 해당 노드를 통과하는 것은 아닙니다. 시스템 프록시는 보통 프록시 설정을 따르는 프로그램에만 적용되며, 다른 트래픽은 TUN이나 앱 자체의 SOCKS 설정이 필요할 수 있습니다. 음성 통화나 게임 연결을 점검할 때는 트래픽이 프록시로 들어오는 경로와 노드에서 나가는 경로를 모두 확인하세요.

VMess: 인증 구조를 갖춘 프록시 프로토콜

VMess는 V2Ray 생태계에서 비롯된 프로토콜로, 사용자 인증과 요청 캡슐화를 지원하며 다양한 전송 방식과 함께 사용할 수 있습니다. 흔히 UUID, 암호화 옵션, 전송 유형, TLS 설정이 포함됩니다. 이 항목들은 서로 다른 계층에 속합니다. UUID는 인증에 사용하고, 전송 설정은 연결을 전달하는 방식을 지정하며, TLS는 해당 연결을 안전하게 감쌉니다. 계층을 구분하면 같은 VMess라도 한 노드는 TCP로 바로 연결되고 다른 노드는 WebSocket 경로와 요청 호스트 정보까지 필요한 이유를 이해할 수 있습니다.

VMess 인증은 시간과 관련이 있어 기기의 시계가 크게 어긋나면 연결에 문제가 생길 수 있습니다. 기기의 시간 동기화가 정상적으로 켜져 있는지 확인하고 서버 로그도 살펴보세요. 과거 설정에는 alterId 같은 필드가 있을 수 있습니다. 최신 배포 방식과 예전 방식은 다르므로 숫자를 임의로 늘리거나 줄여 호환성을 추측하지 마세요. 현재 코어에 맞춰 제공자가 안내한 설정을 우선 사용하고, 이전 구독을 옮길 때는 인증 모드를 별도로 확인하세요. 오래된 필드를 범용 최적화 옵션으로 취급해서는 안 됩니다.

오래된 노드도 여전히 쓸모가 있을 수 있습니다

SS와 VMess는 오랫동안 널리 배포되어 호환 범위가 넓습니다. 기존 기기에서 계속 사용하는 이유도 여기에 있습니다. 선택할 때는 등장 시점만 따지기보다 서버가 관리되고 있는지, 암호화 설정이 적절한지, 회선이 안정적인지 확인하세요. 이미 필요한 기능을 제공하는 노드가 있다면 특정 전송 호환 문제 해결이나 설정 통일 등 분명한 목적이 있을 때 다른 프로토콜로 옮기면 됩니다. 유형 이름만 바꿔서는 회선 용량이 늘지 않으며, 잘못 변환하면 플러그인이나 전송 설정을 잃을 수 있습니다.

두 프로토콜의 속도에는 정해진 우열이 없습니다. 비교할 때는 서버 위치, 외부 회선, 대상 사이트를 가능한 한 동일하게 맞추세요. 제공업체가 서로 다르면 실제로는 서버와 네트워크를 비교하는 경우가 많습니다. 모든 프로토콜에서 속도가 느리다면 인터넷 속도 저하를 단계별로 점검하는 방법을 참고하세요. 로컬 연결 경로와 노드 부하, 회선 품질을 나눠 살펴보면 공통 문제를 특정 프로토콜의 단점으로 오해하지 않을 수 있습니다.

3. Trojan과 VLESS의 보안 계층

Trojan: 올바른 TLS 연결이 중요합니다

Trojan은 TLS 연결 안에서 프록시 데이터를 전달하고 비밀번호로 인증하도록 설계됐습니다. 검증된 TLS 보안 기능을 활용하므로 클라이언트에서 서버 주소와 포트, 비밀번호뿐 아니라 서버의 신원도 올바르게 확인해야 합니다. 인증서 유효 기간과 도메인 일치 여부, 인증서 체인의 완전성이 연결에 영향을 줄 수 있습니다. 비밀번호가 맞아도 인증서 문제는 해결되지 않습니다. 반대로 TLS 핸드셰이크가 성공했다고 프록시 인증까지 끝난 것도 아닙니다. 로그를 확인해 실패한 단계를 구분하세요.

혼동하기 쉬운 값이 두 가지 있습니다. 연결 주소는 네트워크 요청을 보낼 곳을 정하고, SNI는 해당 TLS 핸드셰이크에서 서버에 기대하는 호스트명을 알립니다. 배포 방식에 따라 두 값이 같을 수도, 다를 수도 있습니다. IP 주소로 연결한다고 해서 인증서 확인 대상까지 해당 IP로 임의 변경해서는 안 됩니다. 서버가 안내한 도메인 설정을 사용하세요. 클라이언트의 sni 필드나 이에 해당하는 인터페이스 항목은 신원 확인과 라우팅 설정의 일부이지, 유명 웹사이트 도메인을 아무거나 입력해 연결을 개선하는 옵션이 아닙니다.

인증서 검증에 실패하면 먼저 기기 시간, 인증서 도메인, 서버의 인증서 체인을 확인하세요. 검증을 장기간 건너뛰면 클라이언트가 서버 신원을 확인하는 기능이 약해지므로 일반적인 호환성 설정으로 사용해서는 안 됩니다. 서버가 사설 인증 체계를 사용한다면 클라이언트가 지원하는 방식으로 신뢰 관계를 명확히 설정하세요. 모든 검증 오류를 무시해서는 안 됩니다. 문제 해결을 위해 검증 옵션을 일시적으로 변경하더라도 영향을 이해하고, 원인을 확인한 뒤 배포 요건에 맞는 보안 설정으로 되돌리세요.

VLESS: 간결한 인증 구조가 독립적인 암호화를 뜻하지는 않습니다

VLESS 역시 V2Ray 관련 생태계에서 비롯됐으며, 간결한 신원 인증과 프록시 요청 표현에 중점을 둡니다. 자체 암호화 기능이 있는 프로토콜과 달리 VLESS만으로는 전송 내용을 완전히 보호할 수 없으므로 적절한 보안 계층을 함께 사용해야 합니다. 클라이언트에서 type: vless를 확인하는 것은 시작일 뿐입니다. TLS나 REALITY 등의 보안 설정, 전송 방식, 서버가 요구하는 flow도 확인해야 합니다. 보안 필드를 삭제하면 설정을 사용할 수 없거나 원래의 보안 전제를 벗어날 수 있습니다.

REALITY는 관련 프록시와 함께 사용할 수 있는 보안 메커니즘이지, 어떤 노드든 VLESS로 바꾸는 변환 스위치가 아닙니다. 공개 키, 짧은 ID, 서버 이름을 설정할 때는 서버 배포 내용과 일치해야 합니다. 공개 키를 클라이언트에서 임의로 만들거나 짧은 ID를 노드 이름으로 사용할 수 없습니다. flow는 양쪽과 해당 전송 조합이 지원할 때만 사용할 수 있습니다. 설정 예시에 필드가 있다고 해서 다른 VLESS 노드에도 그대로 복사해야 하는 것은 아닙니다.

추가 전송 계층의 이점과 비용을 함께 고려하세요

WebSocket, HTTP 계열 전송 방식 등의 캡슐화는 기존 배포 구조에 맞추기 위해 사용되기도 합니다. 무료로 성능을 높여 주는 계층은 아닙니다. 캡슐화가 추가되면 헤더와 핸드셰이크, 중간 프록시 제약이 늘어날 수 있지만 기존 인프라를 활용해 연결 가능성을 높일 수도 있습니다. 선택할 때는 실제로 어떤 문제를 해결하는지 확인하세요. 직접 연결이 이미 안정적이라면 추가 캡슐화가 이점을 주지 않을 수 있습니다. 서버가 특정 경로로만 서비스를 제공한다면 경로와 호스트명, 관련 설정을 모두 유지해야 합니다. 계층을 줄이겠다고 임의로 삭제하지 마세요.

이 두 프로토콜은 TLS 배포 조건이 명확하고 해당 생태계의 기능이 필요한 환경에 적합합니다. 일반 클라이언트 사용자는 제공자가 mihomo 지원을 명시한 설정을 가져온 뒤, 코어 로그에서 모든 필드가 인식됐는지 확인하는 것이 안전합니다. 설정의 역할을 이해하면 문제를 찾는 데 도움이 되지만, 노드를 반드시 직접 다시 구성해야 하는 것은 아닙니다. 원래 설정을 복사해 두는 편이 기억에 의존해 다시 입력하는 것보다 안전합니다.

4. Hysteria2와 TUIC에 필요한 UDP 환경

공통 기반: QUIC는 일반 UDP 전달과 다릅니다

Hysteria2와 TUIC는 모두 QUIC를 사용해 프록시 데이터를 전송합니다. QUIC는 UDP 기반으로 보안 핸드셰이크, 신뢰성 있는 스트림, 혼잡 제어 등의 기능을 통합합니다. 'UDP로 바꾸면 재전송이 사라진다'고 이해해서는 안 됩니다. 신뢰성 있는 데이터에는 여전히 확인과 복구가 필요하지만, 관련 처리가 QUIC 구현에 포함됩니다. 여러 스트림을 사용하면 기존 TCP 연결 하나에서 발생하는 일부 상호 차단을 줄일 수 있습니다. 그러나 각 스트림 내부의 데이터 순서와 공통 경로의 혼잡, 서버 처리 능력은 여전히 성능을 제한합니다.

이 프로토콜을 사용하려면 클라이언트에서 서버까지 UDP 경로가 먼저 열려 있어야 합니다. 네트워크에서 도메인 조회용 UDP가 허용된다고 해서 임의의 대상 포트로 QUIC 세션을 계속 유지할 수 있는 것은 아닙니다. 게스트 네트워크, 방화벽, 통신사 네트워크, 서버 보안 그룹이 연결에 영향을 줄 수 있습니다. TCP 노드는 연결되지만 두 종류의 QUIC 노드가 모두 시간 초과된다면 인증 비밀번호를 바꾸기보다 외부 UDP 연결, 서버 리스닝, 포트 매핑부터 확인하세요. NAT 매핑의 유지 시간도 장시간 유휴 상태 후 연결 복구에 영향을 줍니다.

Hysteria2: 복잡한 네트워크에 대응하는 전송 제어

Hysteria2는 지연 시간이 길거나 패킷 손실이 있는 복잡한 네트워크 환경을 고려해 설계됐습니다. QUIC로 프록시 데이터를 전달하고 혼잡 제어와 대역폭 설정 기능을 제공합니다. 설정에는 인증 정보와 TLS 이름이 포함되며, 배포 방식에 따라 난독화나 대역폭 필드가 추가될 수 있습니다. 1세대 Hysteria와 Hysteria2는 이름만 바뀐 동일한 와이어 프로토콜이 아니므로 유형 필드만 바꿔 서로 통신할 수 있다고 기대해서는 안 됩니다. 구독 변환기는 올바른 세대를 인식하고 현재 코어에 필요한 설정을 유지해야 합니다.

대역폭 설정은 특히 잘못 사용하기 쉽습니다. 인터페이스에 표시할 희망 속도가 아니라 전송 동작을 결정하는 데 관여할 수 있는 값입니다. 실제 회선보다 훨씬 높은 업로드·다운로드 값을 넣으면 대기열과 패킷 손실이 늘고 다른 앱과 경쟁할 수 있습니다. 너무 낮게 설정하면 전송 속도가 제한될 수 있습니다. 해당 배포에서 사용하는 혼잡 제어 방식에 맞춰 값을 이해하고 안정적인 회선에서 측정한 결과를 기준으로 삼으세요. 서버도 협상이나 정책으로 실제 동작을 제한할 수 있으므로 클라이언트에 더 큰 숫자를 입력해도 서버의 외부 회선 용량이 늘어나지는 않습니다.

TUIC: 다중 스트림과 혼잡 제어도 양쪽 설정이 맞아야 합니다

TUIC도 QUIC에서 프록시 연결을 구현하며, 스트림 다중화와 UDP 전달 등의 기능을 지원합니다. 흔히 UUID와 비밀번호, 서버 이름, 혼잡 제어 옵션이 설정에 포함됩니다. 프로토콜 세대나 구현체에 따라 호환 범위가 다르므로 TUIC라는 이름만 같다고 서로 통신할 수 있다고 단정하지 마세요. 클라이언트에서 서버가 요구하는 프로토콜 세대와 인증 방식을 사용하고, 혼잡 제어 이름도 현재 코어가 지원하는지 확인해야 합니다. 알 수 없는 옵션이 무시될 수도, 오류를 일으킬 수도 있으므로 실제 로드 로그를 확인하세요.

일부 구현은 연결 재수립 대기 시간을 줄이기 위해 초기 데이터 전송이나 세션 복구를 지원합니다. 하지만 첫 연결과 복구 연결, 만료된 세션의 처리 경로는 서로 다르므로 복구 조건에서의 이점을 모든 요청에 적용할 수는 없습니다. 초기 데이터에는 재전송 공격 위험과 서버 정책도 관련되므로 활성화 여부는 구현 문서를 따르세요. 일반 사용자는 제공자가 안내한 기본 설정을 유지하고 반복 접속을 테스트하는 편이 핸드셰이크 시간을 무조건 줄이는 것보다 유용합니다.

실제 사용 환경에서 UDP 경로가 양호하다면 Hysteria2나 TUIC를 선택지로 고려할 수 있지만, 검증하지 않은 환경의 유일한 연결 수단으로 삼는 것은 피하세요. 안정적인 TCP 계열 노드를 하나 남겨 두면 프로토콜 문제와 네트워크 제한을 구분하는 데 도움이 됩니다. 모바일 네트워크를 전환할 때 연결이 항상 유지되는 것도 아닙니다. 연결 ID와 경로 변경 기능, 서버 정책, 클라이언트의 실행 상태가 함께 작용하므로 전환 후 실제 복구 여부를 기준으로 판단하세요.

5. 연결 속도, 자원 사용량, 모바일 배터리

속도 측정값 하나 대신 단계별로 테스트하세요

노드 측정 기능은 보통 특정 주소에 요청을 보내고 한 번의 응답에 걸린 시간을 표시합니다. 클라이언트마다 측정 대상, 연결 재사용 방식, 시간 초과 기준이 다를 수 있어 화면에 표시되는 두 값을 바로 비교하기 어렵습니다. 측정 요청이 성공했다는 것은 해당 시점에 특정 경로의 테스트가 완료됐다는 뜻일 뿐, 동영상이나 코드 저장소, 실시간 통화에서도 같은 성능을 보장하지는 않습니다. 대상 사이트의 위치와 DNS 응답, 연결 정책에 따라 실제 서비스 경로가 달라질 수도 있습니다.

테스트는 세 가지로 나누세요. 짧은 연결은 페이지 첫 바이트와 실패 횟수를 확인하고, 지속 다운로드는 전송 속도가 유지되는지 살펴보며, 실시간 서비스는 지터와 재연결, 백그라운드 복구를 확인합니다. 각 테스트는 가장 좋은 결과 하나만 남기지 말고 여러 번 반복해야 합니다. 비교할 때는 기기와 네트워크, 서버 지역, 대상 주소를 가능한 한 동일하게 맞추고 다른 대용량 작업을 일시 중지하세요. 연결 재사용 여부도 기록해야 합니다. 서버를 동일하게 맞출 수 없다면 순수한 프로토콜 구현이 아니라 노드 전체를 비교한 결과임을 분명히 하세요.

CPU, 메모리, 연결 수는 서로 영향을 줍니다

암호화와 데이터 복사, 프로토콜 캡슐화, 혼잡 제어에는 모두 CPU 시간이 필요합니다. 하드웨어 가속 지원 여부와 코어 빌드 방식, 시스템 네트워크 스택에 따라 비용이 달라지므로 같은 프로토콜이라도 기기 두 대에서 결과가 다를 수 있습니다. 메모리 사용량은 규칙 세트 크기와 DNS 캐시, 연결 수, 로그 버퍼의 영향을 받습니다. 클라이언트의 자원 사용량이 높다고 해서 곧바로 노드 프로토콜 탓으로 돌리지 마세요. 먼저 규칙 제공자가 과도하게 로드됐는지, 다운로드가 많이 병렬 실행되는지, 인터페이스에서 연결 목록을 계속 갱신하는지 확인하세요.

연결 재사용은 일부 연결 수립 과정을 줄일 수 있지만, 자원과 장애 범위를 공유하게 만들기도 합니다. 여러 요청이 하나의 연결을 공유하면 혼잡이 발생했을 때 여러 서비스가 동시에 영향을 받을 수 있습니다. 반대로 연결을 재사용하지 않으면 핸드셰이크와 연결 수가 늘어날 수 있습니다. 특히 프로토콜에 이미 다중 스트림 기능이 있다면 재사용을 중첩한다고 반드시 더 좋아지는 것은 아닙니다. 구체적인 이점을 설명할 수 있고 코어와 서버가 지원하는지 확인되지 않는 한 기본 설정을 유지하세요. 지연 시간을 줄여 줄 것처럼 보이는 옵션을 전부 켜지 마세요.

배터리는 순간 사용량보다 하루 동안의 동작을 살펴보세요

모바일 배터리는 암호화 연산뿐 아니라 무선 모듈이 깨어나는 횟수와 활성 상태가 유지되는 시간에도 영향을 받습니다. 잦은 상태 확인, 지나치게 짧은 연결 유지 간격, 반복적인 재연결 실패, 백그라운드 구독 갱신, 상세 로그는 배터리 소모를 늘릴 수 있습니다. 다운로드 중 CPU 사용량이 낮은 프로토콜이라고 해서 대기 중에도 전력을 덜 쓰는 것은 아닙니다. 해당 네트워크에서 UDP 매핑 유지 시간이 짧아 클라이언트가 세션을 계속 유지하거나 다시 수립한다면 하루 전체 배터리 소모는 오히려 커질 수 있습니다. 실제 사용과 대기 상태를 나눠 확인하세요.

TUN을 켜면 라우팅 조건에 맞는 더 많은 트래픽이 코어로 전달될 수 있습니다. 따라서 배터리 소모 차이는 프로토콜 효율이 아니라 처리 범위가 넓어진 결과일 수도 있습니다. 시스템 프록시는 시스템 설정을 따르는 앱만 처리하므로 두 모드의 작업량이 같다고 볼 수 없습니다. 배터리를 비교할 때는 처리 모드와 규칙, 백그라운드 앱을 동일하게 유지하고 비슷한 사용 시간대에 측정하세요. 운영체제가 클라이언트의 백그라운드 실행을 제한하는지도 확인해야 합니다. 시스템이 앱을 중단해 전력 사용량이 줄었다면 연결이 끊겼을 수 있으므로 최적화에 성공했다고 볼 수 없습니다.

6가지 프로토콜에 고정된 '배터리 절약 등급'이나 '속도 별점'을 붙이는 것은 권장하지 않습니다. 이런 표시는 하드웨어와 회선, 설정의 차이를 가립니다. 더 유용한 결론은 조건을 명시하는 것입니다. 현재 휴대폰과 네트워크, 고정된 트래픽 처리 모드에서 어떤 노드가 필요한 작업을 수행하고 백그라운드에서도 안정적인지 확인하세요. 한 번에 변수 하나만 바꾸면 성능이 나빠졌을 때 이전 상태로 되돌리기 쉽습니다. 코어와 프로토콜, DNS 설정을 동시에 바꾸지 마세요.

6. 원본 Clash, Meta, mihomo의 관계

코어의 발전과 설정 계보

원본 Clash는 규칙 기반 분기, 프록시 그룹, 설정 파일, 제어 인터페이스 등 널리 쓰이는 사용 방식을 확립했습니다. Clash.Meta는 관련 코드와 설정 체계를 바탕으로 프로토콜과 기능을 확장했고, 이후 mihomo라는 이름으로 발전을 이어 갔습니다. 오래된 문서에서 'Meta 코어'와 'mihomo'는 같은 후속 발전 흐름의 서로 다른 시기를 가리키는 경우가 많지만, 모든 시점의 기능이 완전히 동일하다는 뜻은 아닙니다. 호환성을 판단할 때는 과거의 이름만 보지 말고 실제로 실행 중인 구현과 구체적인 필드를 확인해야 합니다.

원본 설정의 여러 기본 개념은 mihomo에서도 확인할 수 있습니다. 예를 들어 proxies, proxy-groups, rules가 있습니다. 사용 방식이 이어지기는 하지만 양방향 호환을 보장하는 것은 아닙니다. 원본 Clash에서 지원하지 않는 최신 프로토콜이나 규칙 유형, DNS 옵션이 포함된 설정은 파일이 YAML 형식이라고 해서 원본 Clash가 자동으로 이해하지 못합니다. 이름보다 이전과 이후 중 어느 방향으로 옮기는지가 중요합니다. 기본 설정을 확장 구현으로 옮기는 일과 확장 설정을 구형 구현으로 되돌리는 일은 서로 다른 작업입니다.

클라이언트는 관리 계층이며 코어와 같은 말이 아닙니다

Clash Plus, Clash Verge Rev, FlClash, Clash Nyanpasu 등의 클라이언트는 서로 다른 인터페이스와 통합 기능을 제공합니다. 다운로드 페이지에서는 구독 관리와 일반 설정을 그래픽 인터페이스에서 시작하기 쉽도록 Clash Plus를 우선 소개합니다. 그 밖의 클라이언트는 플랫폼과 기능에 따라 선택하세요. 시스템 프록시와 서비스 모드, TUN 권한, 설정 덮어쓰기는 클라이언트와 코어가 함께 처리하는 경우가 많습니다. 인터페이스에 고급 필드가 보이지 않아도 코어가 지원하지 않는다고 단정할 수 없으며, 인터페이스에 버튼이 있어도 필요한 시스템 권한이 확보됐다는 뜻은 아닙니다.

클라이언트마다 자체 실행 설정을 생성할 수도 있습니다. 사용자가 가져온 것은 구독 원본이지만 코어를 시작할 때는 포트 추가와 규칙 병합, 덮어쓰기를 적용한 파일을 사용할 수 있습니다. 문제를 해결하려면 어느 파일을 보고 있는지 먼저 확인해야 합니다. 생성된 파일을 직접 편집하면 설정을 바꾸거나 재시작할 때 수정 사항이 덮어써질 수 있습니다. 구독 원본을 편집해도 이후 갱신 과정에서 변경 사항이 사라질 수 있습니다. 클라이언트가 제공하는 지속 가능한 덮어쓰기 기능을 우선 사용하고, 실제 실행 설정에 변경 내용이 반영됐는지 확인하세요.

마이그레이션과 권한 확인은 분리해서 진행

마이그레이션 전에 기존 설정과 프록시 그룹 선택, 덮어쓰기 설정을 보관한 뒤 새 클라이언트에서 복사본을 가져오세요. 복잡한 덮어쓰기를 먼저 끄고 기본 설정으로 프로토콜이 인식되는지, 프록시 그룹 참조가 유효한지, 규칙 제공자를 가져올 수 있는지 확인합니다. 기본 연결이 확인되면 DNS와 TUN, 사용자 규칙을 하나씩 복구하세요. 이렇게 하면 여러 계층이 동시에 바뀐 설정에서 원인을 찾지 않고, 문제가 어느 단계에서 생겼는지 확인할 수 있습니다.

기본 프록시는 작동하지만 TUN이 작동하지 않는다면 프로토콜을 바꾸지 말고 권한과 드라이버, 라우팅, 시스템 서비스를 점검하세요. 시스템 프록시를 켠 뒤 터미널에서만 접속되지 않는다면 브라우저와 터미널을 따로 점검하는 방법을 참고하세요. 이런 문제는 로컬 트래픽 진입점이나 앱 계층에서 발생하며, 서버가 SS를 사용하는지 Trojan을 사용하는지와는 대개 별개의 문제입니다.

7. 구독 형식과 설정 호환성

같은 '구독' 메뉴도 서로 다른 데이터를 받을 수 있습니다

구독은 콘텐츠를 전달하는 방식이지, 하나의 파일 규격이 아닙니다. 링크에서 완성된 Clash YAML이나 노드만 모은 목록, 인코딩된 공유 링크 모음, 웹 오류 메시지가 반환될 수 있습니다. 완성된 설정에는 보통 프록시 그룹과 규칙, DNS 설정이 포함됩니다. 노드 목록에는 서버 항목만 있어 클라이언트나 템플릿에서 나머지를 보완해야 합니다. 따라서 링크가 열린다고 해서 실행 가능한 설정이 반환된 것은 아닙니다. 가져오기에 실패했다면 먼저 응답 유형과 구조를 확인한 뒤 클라이언트의 지원 여부를 살펴보세요.

공유 링크에 담긴 SS, VMess, Trojan, VLESS 등의 형식은 매개변수 표현 방식과 인코딩, 이스케이프 방식이 서로 다릅니다. 변환기는 YAML로 옮길 때 인증과 전송, 보안, 확장 필드를 유지해야 합니다. 프로토콜 이름은 알아보지만 최신 매개변수를 인식하지 못하는 변환기는 겉보기에는 완전해 보여도 실제 설정이 빠진 노드를 만들 수 있습니다. 특히 REALITY와 flow, 플러그인, QUIC 관련 옵션은 변환에 성공했다는 이유만으로 온전히 유지됐다고 가정하지 마세요.

YAML 문법을 분석할 수 있어도 설정 내용이 올바르다는 뜻은 아닙니다

YAML에는 들여쓰기와 목록, 매핑에 관한 명확한 규칙이 있습니다. 들여쓰기에는 공백을 사용하고 특수 문자가 포함된 문자열은 적절한 인용 형식을 사용하세요. 파싱에 성공했다는 것은 파일 구조가 유효하다는 뜻일 뿐입니다. 프록시 그룹에서 존재하지 않는 노드를 참조하거나 규칙이 존재하지 않는 정책을 가리키면 실행이 실패할 수 있습니다. 노드 이름이 중복돼도 선택이 모호해집니다. 복잡한 구독은 문법 오류와 필드 오류, 참조 오류, 실행 중 발생하는 네트워크 오류를 구분하세요. 모든 문제를 '업데이트 실패' 하나로 뭉뚱그리지 마세요.

아래 예시는 원격 프록시 서버를 포함하지 않고 mihomo의 로컬 진입점과 규칙 사이의 최소 관계만 보여 줍니다. 혼합 포트는 HTTP와 SOCKS 프록시 요청을 받으며, LAN 접근은 꺼져 있고 일치하는 모든 트래픽은 직접 연결됩니다. 설정 계층을 이해하기 위한 예시이지 기존 구독을 대체할 원격 노드 설정은 아닙니다. 실제 프록시를 사용하려면 유효한 노드를 추가하고 프록시 그룹을 구성한 뒤 규칙에서 올바른 그룹 이름을 지정해야 합니다.

mixed-port: 7890
allow-lan: false
mode: rule
log-level: info
rules:
  - MATCH,DIRECT

로컬 포트와 원격 노드 포트는 서로 다른 연결 지점입니다. mixed-port를 변경하면 프록시를 수동으로 설정한 앱의 포트도 함께 바꿔야 합니다. 원격 서버 포트는 서버에서 실제로 수신 중인 포트와 일치해야 합니다. 구독의 allow-lan은 노드 성능 옵션이 아니라 로컬 진입점에 LAN 접근을 허용할지 정하는 설정입니다. 프록시를 공유하기 전에는 수신 범위와 방화벽, 인증을 모두 이해해야 합니다. 휴대폰을 연결해야 한다는 이유만으로 모든 네트워크 인터페이스를 외부에 노출하지 마세요.

원격 제공자, 덮어쓰기, 업데이트의 범위

proxy-providers는 노드 목록을 가져오고 rule-providers는 규칙 목록을 가져오는 데 사용됩니다. 역할이 다르므로 특정 노드 구조만 받는 제공자에 완성된 클라이언트 구독을 그대로 넣어서는 안 됩니다. DNS와 연결 경로, 서버 인증, 응답 내용, 로컬 파일 권한 문제로 업데이트가 실패할 수도 있습니다. 로그를 확인할 때는 다운로드 단계에서 실패했는지, 다운로드가 끝난 뒤 파싱에 실패했는지 기록하세요. 전자는 네트워크와 응답을 점검하고, 후자는 형식과 코어의 필드 지원 여부를 확인해야 합니다.

구독을 자동 업데이트하면 서버에서 원본 내용을 다시 가져오므로 규칙을 직접 수정해도 유지되지 않는 경우가 많습니다. 클라이언트가 지원하는 덮어쓰기나 병합 기능에 개인 설정을 저장하고 적용 순서를 이해하는 편이 안전합니다. 목록을 통째로 교체하는지 추가하는지, 이름이 같은 매핑을 어떻게 처리하는지는 클라이언트마다 다를 수 있습니다. 설정을 바꾼 뒤에는 실행 구성을 확인해 기존 프록시 그룹이 뜻하지 않게 삭제되거나 분기 규칙이 마지막 규칙 하나로 덮이지 않았는지 살펴보세요.

처음 가져오기와 업데이트 방법은 구독 가져오기 안내를 참고하세요. 호환성 문제를 해결할 때는 제공자에게 mihomo용으로 명시된 형식을 요청한 뒤 원본과 실행 설정의 차이를 비교하세요. 구독 파일의 확장자만 바꾸거나 노드 유형 이름만 수정하고 인코딩을 반복해도 사라진 프로토콜 설정을 복구할 수는 없습니다.

8. 사용 환경에 맞춰 선택하고 검증하기

데스크톱·모바일·서버별 제약을 확인하세요

데스크톱에서 일상적으로 웹을 이용한다면 호환성과 유지 관리를 우선 고려하세요. 안정적인 SS·VMess·Trojan 노드가 있다면 프로토콜을 바꾸기 위해서만 이전할 필요는 없습니다. VLESS의 특정 조합이 필요하다면 mihomo와 서버 설정이 일치하는지 확인하세요. 클라이언트는 다운로드 페이지에서 우선 안내하는 Clash Plus를 선택하거나 플랫폼에 따라 Clash Verge Rev, FlClash 등을 고려할 수 있습니다. 데스크톱은 대체로 자원이 넉넉하지만 시스템 프록시와 브라우저 확장 프로그램, 터미널 환경 변수는 서로 별개일 수 있으므로 각각 확인해야 합니다.

모바일 기기에서는 백그라운드 복구와 네트워크 전환 성능을 우선 살펴보세요. 먼저 검증된 안정적인 노드를 유지한 상태에서 현재 셀룰러 네트워크에서 Hysteria2나 TUIC가 이점을 주는지 비교하세요. 프로토콜과 측정 빈도, TUN 모드를 동시에 바꾸면 배터리 변화의 원인을 알기 어렵습니다. Android는 기기 아키텍처에 맞는 클라이언트를 다운로드 페이지에서 선택할 수 있습니다. iOS는 클라이언트 진입 방식과 시스템 네트워크 확장 기능이 다릅니다. Clash Plus를 사용할 때는 실제 지원하는 가져오기 형식과 기능을 기준으로 삼고, 데스크톱 mihomo의 모든 필드를 그대로 적용하지 마세요.

서버와 라우터에서는 아키텍처와 상시 실행, 외부 노출 범위가 특히 중요합니다. 코어 패키지를 선택하기 전에 CPU 아키텍처와 운영체제, 실행 환경을 확인하고 별도의 실행 디렉터리와 데이터 유지 정책을 설정하세요. 외부 제어 인터페이스를 신뢰할 수 없는 네트워크에 직접 노출하지 마세요. 로컬 프록시 포트와 제어 인터페이스, 원격 서버의 수신 포트는 구분해 관리해야 합니다. 헤드리스 환경에서 설치하려면 Linux 그래픽 클라이언트와 명령줄 서비스 설치를 참고하세요. 먼저 유지 관리가 가능한 서비스를 구성한 뒤 복잡한 분기 설정을 살펴보세요.

요청 경로를 따라 문제를 구분하세요

기기에서부터 확인을 시작하세요. 코어가 실행 중인지와 다른 프로그램이 포트를 사용하고 있지 않은지 확인한 다음, 앱 요청이 실제로 프록시로 들어오는지 살펴봅니다. 연결 목록에 해당 요청이 없다면 시스템 프록시와 앱 설정, TUN 라우팅을 확인하세요. 요청은 있지만 잘못된 노드가 선택됐다면 모드와 규칙, 프록시 그룹을 점검합니다. 노드를 올바르게 선택했는데도 실패하는 경우에만 인증과 TLS, 원격 연결을 살펴보세요. 이 순서를 따르면 로컬 진입점 문제를 프로토콜 비호환으로 오해하거나 규칙이 적용되지 않았는데도 속도 측정을 반복하는 일을 줄일 수 있습니다.

DNS 문제도 따로 판단해야 합니다. 서버 도메인을 해석하지 못하면 프록시 연결을 수립할 수 없습니다. 대상 사이트의 DNS 응답이 잘못되면 일부 사이트만 열리지 않을 수 있습니다. 가짜 IP 매핑을 사용하는 DNS 모드에서는 앱에 표시되는 주소가 대상 사이트의 실제 주소가 아닐 수도 있습니다. 코어 로그와 함께 확인하고 시스템에서 한 번 조회한 결과만으로 단정하지 마세요. DNS를 변경한 뒤에는 캐시와 기존 연결도 고려해야 합니다. 새 요청이 변경된 경로를 사용하는지 확인한 다음 효과를 평가하세요.

HTTP 프록시 진입점을 확인하려면 아래 명령을 사용해 로컬에서 테스트 사이트에 접속할 수 있습니다. 혼합 포트를 명시하므로 터미널이 시스템 프록시를 읽지 못하는 문제와 코어가 요청을 전달하지 못하는 문제를 구분하는 데 도움이 됩니다. 이 명령은 HTTP 요청 한 번만 확인하며 UDP나 다른 앱, 모든 분기 규칙을 검증하지는 않습니다. 포트를 변경했다면 명령에 입력된 포트도 바꾸세요. 테스트 대상 자체에 접속할 수 없다면 정상 작동이 확인된 다른 대상으로 교차 확인해야 합니다.

curl --proxy http://127.0.0.1:7890 --head https://example.com

옵션을 쌓기보다 되돌릴 수 있는 설정을 유지하세요

최종 설정에는 명확한 기본 노드와 필요한 대체 노드, 목적을 설명할 수 있는 분기 규칙이 있어야 합니다. 핵심 설정은 한 번에 하나씩만 바꾸고 변경 전 설정을 복사해 두세요. 효과가 확인되면 비슷한 사용 시간대에 다시 테스트하세요. 한 번만 빨라졌다고 장기간 사용에 적합하다고 판단할 수는 없습니다. 후보 노드가 자주 실패한다면 네트워크 조건이나 설정 차이부터 확인한 뒤 제외 여부를 결정하세요. 자원만 소모하는 고빈도 자동 측정 목록에 계속 둘 필요는 없습니다.

이 페이지의 선택 원칙은 한 문장으로 정리할 수 있습니다. 먼저 종단 간 호환성을 충족하고, 실제 사용 환경에서 비용을 비교하세요. 프로토콜을 선택한 뒤 연결 확인 방법에 따라 앱 접속을 테스트하세요. 시스템 프록시를 따르지 않는 프로그램까지 처리해야 한다면 TUN 모드 원리와 권한 확인 사항을 참고하세요. 프로토콜은 클라이언트와 서버 간 통신 방식을 정할 뿐, 올바른 로컬 진입점과 DNS, 규칙, 시스템 권한을 대신하지 않습니다.