Clash 프로토콜 및 mihomo 코어 가이드

1. 프로토콜·전송 방식·트래픽 처리의 차이

연결 과정의 각 계층부터 구분하기

Mac 클라이언트에 표시되는 아웃바운드 이름에는 여러 기술이 얽혀 있습니다. 가장 안쪽에는 브라우저의 웹 요청이나 터미널의 코드 저장소 연결처럼 앱에서 발생한 트래픽이 있습니다. 클라이언트는 먼저 트래픽을 처리할지 결정하고, 규칙에 따라 정책 그룹을 선택한 뒤, 지정된 아웃바운드로 요청을 서버에 전달합니다. 프록시 프로토콜은 클라이언트와 서버 간 인증, 대상 주소 표현, 데이터 전달 방식을 정합니다. TCP, UDP, TLS, WebSocket, HTTP/2, QUIC는 서로 다른 계층의 전송 방식이나 보안 메커니즘입니다. 이 이름들을 서로 바꿔 쓸 수 있는 프로토콜처럼 취급하면 가져오기나 문제 해결 과정에서 방향을 잘못 잡기 쉽습니다.

예를 들어 VLESS는 여러 전송 방식과 조합할 수 있지만, 서버가 WebSocket을 사용한다면 주소와 사용자 ID만 맞게 입력한 뒤 전송 방식을 일반 TCP로 바꿔서는 연결되지 않습니다. 경로, 요청 헤더, TLS 설정, 서버 이름 등이 연결 과정에 관여할 수 있습니다. 화면에 표시된 프로토콜 이름은 보통 한 계층만 나타냅니다. 완전한 호환성을 확인하려면 프로토콜, 전송 방식, 보안 설정, 확장 옵션을 함께 살펴야 합니다. 구독에 해당 값이 포함되어 있다면 원래 설정을 유지하고, 여러 서버 설정을 인터넷 가이드에 나온 값과 임의로 조합하지 마세요.

시스템 프록시·TUN과 프로토콜 유형은 별개

시스템 프록시는 macOS 설정을 따르는 앱이 연결을 로컬 프록시 포트로 보내도록 합니다. TUN은 가상 네트워크 인터페이스를 만들고 라우팅을 통해 대상 트래픽을 처리합니다. 둘은 트래픽이 클라이언트에 들어오는 방식을 정할 뿐, 서버에 SS를 사용할지 Trojan을 사용할지는 결정하지 않습니다. 같은 아웃바운드를 시스템 프록시와 TUN에서 모두 사용할 수 있습니다. 따라서 터미널에서 접속할 수 없다고 바로 프로토콜을 바꾸는 것이 해결책은 아닐 수 있습니다. 요청이 클라이언트에 전달되지 않았을 가능성도 있습니다. 먼저 연결 기록을 확인한 뒤 트래픽 처리, 규칙, 아웃바운드 중 어느 단계의 문제인지 살펴보세요.

규칙 모드·전역 모드·직접 연결 모드 역시 프로토콜이 아닙니다. 규칙 모드는 도메인, 주소 등 조건에 따라 연결 경로를 선택하고, 전역 모드는 처리 대상 연결에 하나의 정책을 적용합니다. 직접 연결 모드는 보통 해당 연결을 원격 서버를 거치지 않고 대상에 직접 보냅니다. 전역 모드를 켜더라도 시스템 프록시를 따르지 않는 앱까지 자동으로 처리되는 것은 아닙니다. 반대로 TUN으로 트래픽을 처리해도 규칙에 따라 분기할 수 있으므로 모든 요청을 원격 서버로 보낼 필요는 없습니다. 구체적인 설정 방법은 macOS TUN 강화 모드 안내를 참고해 권한과 라우팅을 확인하세요.

보안 기능과 사용 조건을 함께 확인하기

암호화, 서버 인증, 설정 정보 보호는 각각 다른 문제를 해결합니다. TLS를 사용한다고 인증서 검증을 꺼도 되는 것은 아니며, 설정에 임의 식별자를 썼다고 구독 주소를 공개해도 되는 것도 아닙니다. 프로토콜을 선택하기 전에 서버 제공자, 인증서의 신뢰성, 구독 출처를 확인하세요. 프록시 서버는 연결 대상과 접속 시각 등의 정보를 볼 수 있지만, 콘텐츠 보호는 앱 자체의 HTTPS 암호화가 담당합니다. 연결을 일시적으로 성사시키려고 인증서 검증을 장기간 생략해서는 안 됩니다.

이후 비교 내용을 살펴볼 때는 ‘프로토콜이 지원하는 기능’과 ‘현재 구현에서 실제로 지원하는 기능’을 구분해야 합니다. 프로토콜 설계에 UDP 전달 기능이 포함되어 있어도 모든 서버, 플러그인, 구독 변환기가 이를 완전히 구현한다는 뜻은 아닙니다. 클라이언트의 스위치만으로 서버에 없는 기능을 사용할 수도 없습니다. 실제 선택은 이름에 기술 약어가 얼마나 많이 포함됐는지가 아니라 사용하는 코어의 지원 범위, 서버 요구 사항, 연결 로그를 기준으로 해야 합니다.

2. Shadowsocks와 VMess의 설계 차이

Shadowsocks: 간결한 암호화 전달 구조

Shadowsocks는 보통 SS라고 부르며, 클라이언트와 서버 사이에 인증된 암호화 전달 채널을 만드는 방식입니다. 기본 설정은 서버 주소, 포트, 암호화 방식, 비밀번호를 중심으로 구성되며 필요한 매개변수가 비교적 적습니다. 서버 정보가 명확하고 전송 계층 조합을 단순하게 유지하고 싶은 경우에 적합합니다. 초기 스트림 암호 방식과 이후 AEAD 방식은 보안과 호환성에 차이가 있으므로 SS 링크라고 해서 모두 같은 구현으로 보면 안 됩니다. 설정 항목이 적은지만 따지기보다 현재 코어와 서버가 함께 지원하는 최신 방식을 선택하는 것이 중요합니다.

기존 AEAD와 Shadowsocks 2022는 암호화 방식 이름만 바꾼다고 서로 호환되지 않습니다. 후자는 키 형식과 길이, 일부 프로토콜 처리에 명확한 요구 사항이 있어 클라이언트와 서버 설정이 맞아야 합니다. 구독을 가져온 뒤 키 길이 오류가 발생하면 키를 자르거나 문자를 덧붙이지 말고 원본 설정과 암호화 방식을 확인하세요. 일부 SS 설정은 플러그인에 의존합니다. 플러그인은 별도의 요구 사항이며 모든 클라이언트에서 동일한 플러그인 프로그램을 실행할 수 있는 것은 아닙니다. Mac 그래픽 인터페이스가 기본 SS 필드를 인식한다고 해서 외부 플러그인 실행 환경까지 갖춘 것은 아닙니다.

SS는 기본 구조가 간단하지만 모든 네트워크에서 더 빠르다는 뜻은 아닙니다. 암호화 방식의 하드웨어 가속 지원, 서버 부하, 단일 연결의 패킷 손실, 로컬 네트워크 품질에 따라 결과가 달라집니다. UDP 전달을 사용하려면 서버에서 해당 트래픽을 허용하고 클라이언트 설정도 일치해야 합니다. 웹페이지는 열리는데 음성 통화나 게임이 되지 않는다면 UDP 지원, 대상 규칙, NAT 동작을 따로 확인하세요. TCP 요청이 성공했다고 아웃바운드 전체가 정상이라고 단정할 수 없습니다.

VMess: 인증과 다양한 전송 방식의 조합

VMess는 V2Ray 생태계에서 나온 프로토콜로, 사용자 인증과 데이터 전달을 중심으로 설계되었으며 사용자 ID와 암호화 옵션을 지정해 아웃바운드를 구성하는 경우가 많습니다. 여러 전송 방식과 조합할 수 있는 대신 기본 SS보다 일치시켜야 할 매개변수가 많습니다. 서버에서 TLS와 WebSocket을 함께 사용한다면 사용자 ID뿐 아니라 TLS 서버 이름, 경로, 필요한 요청 헤더도 맞춰야 합니다. VMess 프로토콜과 바깥쪽 전송 방식은 각각 역할이 다릅니다. 문제를 진단할 때는 한 번의 핸드셰이크 실패를 모두 프로토콜 오류로 취급하지 말고 계층별로 확인하세요.

오래된 가이드에는 과거 인증 방식과 관련된 필드가 자주 등장하지만, 최신 설정은 보통 VMess AEAD를 사용하며 예전 조합은 현재 코어에서 허용되지 않을 수 있습니다. 오래된 화면을 그대로 따라 하려고 더 이상 쓰지 않는 매개변수를 추가하지 마세요. 시스템 시간이 크게 어긋나도 인증에 영향을 줄 수 있습니다. Mac을 오랫동안 오프라인으로 사용했다면 시스템 설정에서 날짜와 시간을 확인하세요. 로그에 인증 실패가 표시되면 시간, 사용자 ID, 서버 요구 사항을 함께 점검하세요. 로그가 인증 이전의 인증서나 전송 핸드셰이크에서 멈췄다면 해당 계층부터 해결해야 하며, 실패 결과만으로 사용자 ID 오류라고 판단해서는 안 됩니다.

실제로 선택할 때 이미 안정적인 SS 서버를 사용하고 있고 특수 플러그인에 의존하지 않는다면, 다른 프로토콜에 설정 항목이 더 많다는 이유만으로 옮길 필요는 없습니다. VMess 서버가 관리 상태가 양호한 완전한 설정을 제공한다면 교체를 논하기 전에 기존 설정부터 검증하세요. 복잡한 프로토콜이 제공하는 기능은 실제 필요에 맞아야 하며, 그렇지 않으면 설정만 복잡해집니다. 서버를 변경할 수 없는 일반 사용자는 매개변수 조합을 직접 설계하기보다 구독 결과가 현재 코어에 맞는지 확인하고, 비교 기준으로 사용할 검증된 아웃바운드를 하나 남겨 두는 것이 중요합니다.

3. Trojan, VLESS와 TLS 설정

Trojan: TLS 연결 안에서 인증

일반적인 Trojan 구성은 TLS를 외부 보안 채널로 사용하고, 그 안에서 비밀번호 인증과 프록시 요청을 처리합니다. 널리 쓰이는 인증서와 TLS 생태계를 활용하므로 주소, 포트, 비밀번호, 서버 이름만 설정하면 되는 것처럼 보이지만 실제 사용 가능 여부는 인증서 체인, 도메인, 서버 구성에 크게 좌우됩니다. 서버 주소는 연결 대상을 찾는 데 사용하고 TLS 서버 이름은 인증 등에 사용합니다. 두 값이 다를 수 있지만 임의로 서로 바꿔서는 안 됩니다. 구독에 도메인이 지정되어 있다면 IP 주소로 바꿀 경우 DNS 결과가 달라지거나 인증서 이름 검증에 실패할 수 있습니다.

클라이언트의 SNI 또는 서버 이름 필드는 HTTP Host와 다릅니다. 전자는 TLS 핸드셰이크에 사용되고 후자는 HTTP 요청의 의미를 결정합니다. WebSocket 같은 외부 전송을 사용하는 구성에서는 두 값이 각각 나타날 수 있습니다. 같은 도메인을 모든 필드에 기계적으로 입력해도 호환성이 보장되지 않으며 원래 설정의 구조를 파악하기 어려워질 수 있습니다. 인증서 오류를 진단할 때는 시스템 시간, 인증서 유효 기간, 중간 인증서 체인을 확인한 뒤 구독에 지정된 이름을 점검하세요. 인증서 검증을 계속 건너뛰면 서버 신원을 확인하는 중요한 보호 기능을 잃게 됩니다.

VLESS: 경량 프로토콜과 외부 보안 계층

VLESS도 V2Ray 관련 생태계의 프록시 프로토콜이며 비교적 간결하게 설계되었습니다. SS와 같은 의미의 데이터 암호화를 자체 제공하지 않으므로 연결을 보호하려면 TLS나 명확히 설정된 다른 보안 계층을 사용하는 경우가 많습니다. 따라서 ‘VLESS가 가볍다’를 ‘보안 옵션을 몇 개 끄면 더 빠르다’로 해석해서는 안 됩니다. 서버에서 TLS를 요구한다면 클라이언트 설정도 일치해야 합니다. 신뢰할 수 있는 외부 보호 계층이 없는 연결은 사용자 ID를 쓴다는 이유만으로 암호화되었다고 볼 수 없습니다. 사용자 ID는 인증에 쓰이며 콘텐츠 기밀성을 보장하지 않습니다.

VLESS는 다양한 전송 방식 및 확장 기능과 조합할 수 있으며, 호환 범위는 코어 구현에 따라 달라집니다. Reality 매개변수, 클라이언트 지문, 흐름 제어 옵션에는 각각 맞춰야 할 조건이 있습니다. 특정 조합을 위한 가이드를 모든 VLESS 아웃바운드에 적용하지 마세요. 특히 흐름 제어 필드는 범용 속도 향상 버튼이 아닙니다. 서버, 전송 구조, 클라이언트 구현이 모두 조건을 충족할 때만 사용할 수 있습니다. 구독에 없는 공개 키나 짧은 ID를 클라이언트에서 임의로 만들어도 연결이 되지 않습니다. 해당 값은 서버와 짝을 이루는 설정에서 제공되어야 합니다.

인증서 문제와 프로토콜 문제를 따로 살펴보기

TLS 연결 실패는 인증 전에 발생할 수 있습니다. 인증서 만료, 이름 불일치, 시스템 신뢰 체인 문제, 네트워크 중간 장비의 간섭 때문에 Trojan이나 TLS를 사용하는 VLESS가 실패할 수 있습니다. 이런 문제는 프록시 프로토콜 자체의 오류가 아닐 수 있습니다. 일반 HTTPS 사이트도 브라우저에서 열 때 문제가 발생한다면 먼저 Mac 시간과 네트워크 환경을 확인하세요. 특정 아웃바운드에서만 문제가 생긴다면 서버 설정을 살펴보세요. 오류 유형별 자세한 내용은 HTTPS 인증서 오류 원인과 해결 방법을 참고하세요. 출처가 불분명한 루트 인증서를 시스템에 설치해 문제를 우회하지 마세요.

연결 속도에서는 Trojan과 VLESS의 실제 차이가 외부 TLS, 전송 방식, 서버 네트워크에 가려지는 경우가 많습니다. 최초 핸드셰이크, 연결 재사용, 혼잡 제어, 대상 사이트 응답이 주요 비용이 될 수 있습니다. 웹페이지 한 번이 더 빨리 열렸다고 특정 프로토콜이 항상 더 낫다고 볼 수는 없습니다. Mac 사용자는 최신 조합을 좇기보다 설정 항목이 완전하고 인증서를 신뢰할 수 있으며 코어에서 명확히 지원하는 구성을 먼저 선택한 뒤, 같은 네트워크와 대상에서 성능을 비교하는 것이 효과적입니다. 유지 관리 비용도 고려해야 합니다. 업데이트 때마다 필드를 수동으로 보충해야 한다면 기존의 안정적인 설정이 장기적으로 더 나을 수 있습니다.

4. Hysteria2, TUIC와 UDP 네트워크 조건

QUIC는 다른 전송 기반을 제공

Hysteria2와 TUIC는 모두 UDP 기반 QUIC 기술을 활용하지만 서로 다른 프로토콜이므로 유형 이름만 바꿔 가져올 수 없습니다. QUIC는 보안 핸드셰이크, 안정적인 데이터 스트림, 혼잡 제어 등의 메커니즘을 결합하고 여러 스트림이 한 연결을 공유하도록 합니다. 그 결과 스트림 간 TCP 계층의 헤드 오브 라인 블로킹 영향을 줄일 수 있습니다. 다만 각 안정적 스트림 안에서는 여전히 순서에 따라 데이터를 전달해야 하며, 네트워크 혼잡도 전체 대역폭에 영향을 줍니다. QUIC가 패킷 손실을 없애는 것은 아닙니다. 복구와 스케줄링 방식이 다를 뿐이며, 장점을 누리려면 네트워크에서 UDP를 허용하고 구현도 적절해야 합니다.

일부 게스트 네트워크, 기업 무선 네트워크, 핫스팟에서는 UDP를 차단하거나 속도를 제한하거나 세션 만료 시간을 짧게 설정할 수 있습니다. 이때 TCP 기반 아웃바운드가 연결된다고 해서 QUIC 아웃바운드도 정상이어야 하는 것은 아닙니다. Mac에서는 UDP 경로를 판단하기 전에 검증된 TCP 기반 설정을 비교 대상으로 남겨 두세요. 잠자기에서 깨어난 뒤에만 네트워크가 끊긴다면 인증 정보 오류로 단정하기보다 NAT 매핑 만료와 클라이언트 재연결 동작도 고려해야 합니다. 같은 프로토콜이 가정용 네트워크와 공용 네트워크에서 다르게 작동하는 것은 네트워크 조건 차이로 설명할 수 있습니다.

Hysteria2의 대역폭 설정은 속도 측정값이 아닙니다

Hysteria2는 높은 지연 시간이나 패킷 손실이 있는 환경 등을 고려한 전송 방식이며, 구체적인 혼잡 제어 동작은 클라이언트와 서버 설정에 따라 달라집니다. 일부 설정에는 업로드와 다운로드 대역폭을 지정하는 항목이 있습니다. 이 값은 전송 정책에 영향을 주기 위한 것이며 서버가 보장하는 실제 속도가 아닙니다. 다운로드 값을 높게 설정한다고 속도가 빨라지는 것은 아닙니다. 실제 병목보다 훨씬 큰 값을 넣으면 큐 대기, 패킷 손실이 늘거나 같은 네트워크를 쓰는 다른 앱에 영향을 줄 수 있습니다. 다른 사람의 숫자를 그대로 따라 하기보다 안정적으로 유지 가능한 회선 성능과 서버 제한을 기준으로 설정하세요.

Hysteria와 Hysteria2는 프로토콜 세대가 다르므로 유형 이름만 바꿔 기존 설정을 옮길 수 없습니다. 인증 필드, 난독화 옵션, 전송 매개변수도 버전에 맞춰야 합니다. 가져오기 도구가 유형을 이전 프로토콜로 인식한다면 mihomo에 맞는 설정을 다시 받는 것이 좋습니다. 클라이언트가 설정을 저장했다고 해서 서버와 핸드셰이크에 성공한 것은 아닙니다. 연결 로그가 인증 단계까지 진행되는지 확인하고, UDP 연결, TLS 검증, 프로토콜 인증 중 어느 단계에서 실패하는지 살펴보세요.

TUIC의 연결 재사용과 UDP 전달 방식

TUIC도 QUIC 기반이며 프록시 연결 재사용과 TCP·UDP 트래픽 전달에 중점을 둡니다. 프로토콜 세대별 구현은 서로 호환되지 않을 수 있으므로 인증 필드와 전달 옵션을 서버 설정에 맞춰야 합니다. 일부 UDP 전달 방식은 신뢰성, 실시간성, 캡슐화 비용 사이에서 절충합니다. 안정적인 전송이 언제나 실시간 앱에 적합한 것은 아닙니다. 음성 통화나 게임에서는 늦게 도착한 데이터가 쓸모없을 수 있지만 파일 전송은 데이터가 빠짐없이 전달되는 것이 중요합니다. 서버에서 권장하는 방식을 우선 사용하고 실제 앱으로 검증하세요.

이 두 프로토콜은 모든 상황의 기본값이 아니라 후보로 고려할 만한 선택지입니다. 네트워크의 UDP 품질이 안정적이고 장거리 연결에서 패킷 손실이 뚜렷한 영향을 준다면 비교 테스트를 해볼 수 있습니다. UDP 지원이 불확실하거나 여러 사무실 네트워크를 오가야 한다면 TCP 기반 대체 아웃바운드를 남겨 두세요. 네트워크를 바꿀 때마다 설정을 다시 해야 하는 방식보다 변수를 줄이는 선택이 낫습니다.

5. 연결 속도·리소스 사용량·모바일 배터리

‘속도’를 관찰 가능한 세 가지 지표로 나누기

연결 속도는 적어도 연결 수립 시간, 지속 전송 처리량, 상호작용 응답의 안정성으로 나눠 볼 수 있습니다. 웹 브라우징은 첫 응답과 여러 작은 리소스가 제때 로드되는지가 중요하고, 대용량 파일 다운로드는 지속 처리량이 더 중요합니다. 원격 터미널이나 화상 회의에서는 지터와 연결 끊김이 중요합니다. 지연 시간 측정값이 낮다고 모든 작업에서 더 빠른 것은 아닙니다. 클라이언트에서 흔히 제공하는 지연 시간 측정은 지정된 주소에 요청을 보내는 데 걸린 시간을 재는 경우가 많습니다. 순수한 물리적 왕복 시간만이 아니라 DNS 조회, 핸드셰이크, 대상 서버 처리 시간도 포함될 수 있습니다.

프로토콜을 비교할 때는 Mac, 네트워크, 대상, 테스트 시간을 동일하게 맞추고 가능하면 같은 서버 위치와 비슷한 리소스 조건을 사용하세요. 두 설정이 서로 다른 서버를 사용한다면 측정 결과는 프로토콜 자체가 아니라 두 경로 전체의 차이를 반영합니다. 연속 측정 결과는 캐시, 연결 재사용, 서버 부하 변화에도 영향을 받습니다. 첫 접속, 재방문, 지속 전송 성능을 따로 기록할 수 있지만 한 번의 최고 기록을 평소 성능으로 보지 마세요. 일상적인 작업 중 시간 초과, 재연결, 눈에 띄는 멈춤이 반복되는지 확인하는 것이 더 중요합니다.

CPU·메모리·네트워크 캡슐화는 단순 비교할 수 없습니다

CPU 사용량은 암복호화, 프로토콜 파싱, 데이터 복사, 네트워크 스택 처리에서 발생합니다. Apple 칩과 Intel에서 알고리즘별 하드웨어 가속 성능이 다를 수 있고 클라이언트 빌드 방식도 결과에 영향을 줍니다. TUN을 사용하면 가상 인터페이스와 트래픽 처리 작업이 추가되며 DNS, 규칙 매칭, 연결 기록, 상세 로그도 리소스를 사용합니다. 따라서 TUN을 켠 뒤 전체 전력 소모가 늘었다고 모두 프로토콜 탓으로 돌릴 수는 없습니다. 서로 다른 그래픽 클라이언트의 메모리 사용량만으로 내부 프로토콜 효율을 비교하는 것도 적절하지 않습니다.

macOS의 ‘활성 상태 보기’에서 클라이언트와 관련 코어 프로세스의 CPU, 메모리, 에너지 사용 추이를 함께 확인할 수 있습니다. 테스트 작업은 동일하게 유지하고 한쪽에서만 전체 다운로드를 하는 식으로 조건을 바꾸지 마세요. 메모리 사용량이 계속 늘어난다면 먼저 연결 수, 로그 양, 구독 규모를 점검하고 프로토콜 누수라고 단정하지 마세요. 고속 전송 중에만 CPU 사용량이 올라가는 것은 정상적인 처리 비용일 수 있습니다. 유휴 상태에서도 사용량이 계속 높다면 반복 재연결, 비정상적인 DNS 요청, 라우팅 루프를 살펴보고 증상에 따라 도움말 센터에서 추가로 진단하세요.

모바일 기기는 무선 연결 상태와 기기 깨우기가 배터리에 더 큰 영향을 줍니다

모바일 기기의 배터리는 암호화 연산에서만 소모되지 않습니다. 셀룰러 모듈의 활성 시간, 연결 유지 빈도, 백그라운드 재연결, 신호 세기, NAT 시간 초과가 더 큰 비중을 차지할 수 있습니다. 장시간 연결을 유지하면 핸드셰이크 횟수를 줄일 수 있지만, 연결 유지를 너무 자주 보내면 무선 모듈이 자주 깨어날 수 있습니다. UDP 기반 방식은 어떤 네트워크에서는 잘 작동하지만 다른 네트워크에서는 세션을 계속 다시 설정해야 할 수 있습니다. SS, Trojan, QUIC 같은 이름만으로 고정된 배터리 효율 순위를 매길 수 없으며 Mac의 CPU 테스트 결과를 휴대폰에 그대로 적용해서도 안 됩니다.

Mac이 휴대폰 핫스팟으로 인터넷에 연결되어 있다면 핫스팟 기기도 별도의 배터리 소모 요소로 봐야 합니다. 대용량 테스트는 Mac의 네트워크 처리 부하와 휴대폰의 무선 부하를 동시에 높일 수 있습니다. 일상적인 선택을 위해서는 대역폭을 최대로 사용하는 테스트만 하지 말고 자주 쓰는 작업과 잠자기 후 연결 복구도 확인하세요. 불필요한 속도 측정, 지나치게 잦은 정책 그룹 검사, 디버그 로그를 줄이는 편이 프로토콜을 바꾸는 것보다 효과적일 때도 있습니다. 검사 간격도 무조건 줄이지 마세요. 장애를 빨리 발견하는 것과 백그라운드 요청이 늘어나는 것 사이의 비용을 실제 전환 빈도에 맞춰 조정해야 합니다.

최종 설정에서는 작업마다 서로 다른 정책 그룹을 사용할 수 있어야 합니다. 웹, 개발 도구, 실시간 앱이 같은 아웃바운드를 사용할 필요는 없지만 그룹은 분명한 목적이 있어야 합니다. 테스트를 위해 규칙을 지나치게 세분화하지 마세요. 먼저 안정적인 기준 설정을 찾고 구체적인 문제에 맞춰 후보 하나를 추가하면 프로토콜, DNS, TUN, 정책 그룹을 한꺼번에 바꾸는 것보다 신뢰할 만한 결과를 얻기 쉽습니다.

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

코어는 설정을 실행하고 그래픽 클라이언트는 관리합니다

Clash 생태계에서 코어는 설정을 해석하고 규칙에 따라 네트워크 연결을 처리합니다. 그래픽 클라이언트는 메뉴 막대, 구독 관리, 시스템 프록시, 권한 승인, 설정 화면을 제공합니다. 둘은 연결되어 있지만 같은 것은 아닙니다. Clash Plus, Clash Verge Rev, FlClash 등은 사용자가 선택하는 클라이언트이며, 실제 프로토콜 지원 여부는 어떤 코어를 포함하거나 호출하는지에 따라 달라집니다. 클라이언트 화면이 업데이트되어도 인터페이스만 바뀌고 모든 프로토콜 구현이 함께 업데이트되지 않을 수 있습니다. 다운로드와 선택은 설치 파일 페이지에서 확인하고 처음 설정한다면 Clash Plus부터 시작하세요.

원본 Clash는 아웃바운드, 정책 그룹, 규칙 등 기본 구조를 포함하는 널리 쓰이는 YAML 설정 방식을 정착시켰습니다. 원본 오픈소스 코어와 과거의 다른 배포판을 같은 것으로 볼 수 없으며, 분기마다 기능이 다를 수 있습니다. Clash Meta는 관련 생태계를 바탕으로 프로토콜과 네트워크 기능을 확장했으며 이후 프로젝트 이름으로 mihomo를 사용하게 되었습니다. 구독이나 가이드에서 Meta라는 이름이 나오더라도 별도의 ‘Meta 플러그인’을 설치하라는 뜻이 아니라 발전 과정의 한 단계를 가리키는 경우가 많습니다. 이름의 변천을 알면 자료를 해석하는 데 도움이 되지만 실제 기능 확인을 대신하지는 않습니다.

기본 구조가 비슷해도 모든 필드가 양방향으로 호환되는 것은 아닙니다

mihomo는 많은 Clash 설정 구조를 이어받으면서 프로토콜 유형, 규칙 기능, 네트워크 설정을 추가했습니다. 원본 코어에서 특정 아웃바운드를 인식하지 못하는 것은 기능 한계이지, 반드시 YAML 들여쓰기 오류인 것은 아닙니다. 반대로 설정을 이전 코어에서 새 코어로 옮길 때 폐기된 필드, 기본 동작 변경, 더 엄격해진 검증 때문에 문제가 생길 수 있습니다. 설정을 불러오는 것은 첫 단계일 뿐입니다. 규칙이 의도대로 적용되는지, DNS가 올바른지, 정책 그룹 참조가 유효한지, TUN이 대상 앱의 트래픽을 실제로 처리하는지도 확인하세요.

마이그레이션 전에 현재 사용 가능한 설정과 클라이언트 설정을 저장하세요. 그런 다음 새 클라이언트에서 가져온 것이 원본 구독인지, 병합된 설정인지, 내보낸 실행 설정인지 확인하세요. 세 가지가 서로 다를 수 있습니다. 그래픽 클라이언트가 코어를 시작하기 전에 포트, DNS, 제어 인터페이스, TUN 필드를 덮어쓸 수도 있습니다. 기존 실행 파일을 그대로 복사하면 새 환경에 맞지 않는 매개변수까지 따라올 수 있습니다. 먼저 클라이언트 기본 네트워크 설정으로 구독을 가져와 기본 연결을 확인한 뒤, 사용자 지정 규칙과 덮어쓰기 설정을 하나씩 복원해 여러 문제 원인이 한꺼번에 생기는 것을 피하세요.

간단한 설정으로 문법과 기본값 확인하기

아래는 mihomo 설정에서 모드, 포트, 로그 수준을 이해하기 위한 일반 필드 예시입니다. 원격 아웃바운드는 포함하지 않으므로 이것만으로 프록시 연결을 만들 수 없습니다. 병합하기 전에 전체 설정에 같은 이름의 최상위 키가 있는지 확인해 중복 정의를 피하세요. 혼합 포트는 로컬 HTTP와 SOCKS 연결을 모두 제공하며 포트 값은 현재 클라이언트가 실제로 수신 대기하는 설정을 기준으로 해야 합니다. 이 값은 원격 서버 포트가 아니며 모든 클라이언트가 같은 기본값을 사용하는 것도 아닙니다.

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

로그에 알 수 없는 프로토콜 유형이 표시되면 먼저 코어가 해당 유형을 지원하는지, 구독에서 올바른 형식이 출력되는지 확인하세요. 정책이나 프록시 이름을 찾을 수 없다는 오류라면 참조 관계와 구독 필터 결과를 점검하세요. 설정이 실행되지만 규칙이 적용되지 않는다면 규칙 순서와 클라이언트 덮어쓰기 설정을 확인하세요. 자세한 차이는 mihomo와 원본 Clash 기능 비교에서 살펴볼 수 있습니다. 모든 오류를 ‘코어가 오래돼서’라고 단정하지 말고 백업 없이 설정 파일 전체를 반복해서 교체하지 마세요.

Apple Silicon과 Intel용 설치 파일의 차이는 프로그램 아키텍처에 맞추기 위한 것이지 프로토콜 차이 때문이 아닙니다. Mac에 맞는 빌드를 우선 사용하면 불필요한 변환 과정을 줄일 수 있지만, 프로토콜 지원 여부는 여전히 코어 구현에 달려 있습니다. ClashX Meta 같은 보관된 클라이언트는 기존 환경을 참고하는 용도로 사용할 수 있습니다. 장기 사용을 고려한다면 유지 관리 상태와 시스템 호환성도 확인하세요. 화면 디자인만 보는 것보다 계속 관리되고 코어 상태를 명확히 보여주는 클라이언트를 선택하는 편이 이후 설정 문제를 처리하기 쉽습니다.

7. Clash YAML, 노드 목록, 구독 변환

구독 주소만으로는 콘텐츠 형식을 알 수 없습니다

구독 링크는 설정 데이터를 가져오는 경로입니다. 응답은 전체 Clash YAML, 아웃바운드 목록만 포함된 YAML, 인코딩된 공유 링크 모음, sing-box JSON 등일 수 있습니다. URL 확장자나 링크 이름만으로 형식을 확정할 수 없으며, 일부 서비스는 요청 매개변수나 클라이언트 식별자에 따라 다른 콘텐츠를 반환합니다. 가져오기에 실패하면 다운로드 문제인지, 콘텐츠 파싱 문제인지, 실행 검증 문제인지 먼저 구분하세요. 다운로드는 성공했는데 HTML이 나타난다면 로그인 페이지, 오류 페이지, 접근 안내일 수 있으며 YAML 문법을 고쳐야 한다는 뜻은 아닙니다.

전체 설정에는 보통 아웃바운드, 정책 그룹, 규칙, 기타 실행 설정이 함께 들어 있습니다. 노드 목록에는 연결에 필요한 필드만 있을 수 있습니다. 클라이언트가 목록을 가져올 수 있다고 해서 모든 사용자에게 적합한 분기 규칙까지 포함된 것은 아닙니다. 일부 클라이언트는 자체 템플릿으로 빠진 항목을 채우고, 다른 클라이언트는 사용자가 직접 지정해야 합니다. 가져온 뒤 아웃바운드는 보이는데 원하는 정책 그룹이 없다면 서버 비밀번호를 다시 입력하기보다 구독 유형과 템플릿을 확인하세요. 설정 구조의 완성도와 아웃바운드 개수는 별개의 문제입니다.

인코딩·변환·병합은 각각 어떤 역할을 하나요?

Base64는 인코딩 방식일 뿐 암호화나 프록시 프로토콜이 아닙니다. 인코딩된 콘텐츠에는 SS, VMess, Trojan 등의 공유 링크가 포함될 수 있으며 각 링크에 고유한 매개변수가 들어 있습니다. 텍스트를 디코딩해도 원래 표현으로 되돌아올 뿐 규칙, DNS, 정책 그룹이 자동으로 만들어지지 않습니다. 공유 링크 표준마다 표현할 수 있는 매개변수가 다르므로 최신 확장 필드를 구형 파서에서 이해하지 못할 수도 있습니다. 한 클라이언트에서 가져온 링크가 다른 모든 클라이언트에서도 똑같이 해석된다고 볼 수 없습니다.

구독 변환기는 한 데이터 모델을 다른 모델로 바꾸면서 템플릿, 이름 변경, 필터링을 적용하는 경우가 많습니다. 변환 대상 형식에 대응 항목이 없으면 특정 전송 확장, 지문 옵션, 정책 그룹 동작, DNS 라우팅 의미 등이 사라질 수 있습니다. sing-box JSON과 Clash YAML은 괄호와 들여쓰기만 다른 형식이 아닙니다. 최상위 구조와 동작 모델 일부가 다릅니다. 파일 확장자만 바꾸거나 필드 이름을 그대로 옮긴다고 안정적인 설정이 만들어지지는 않습니다. 변환한 뒤에는 실제 코어에서 다시 검증해야 합니다.

개인정보 보호와 업데이트 시 덮어쓰기를 미리 확인하세요

구독에는 연결에 사용할 인증 정보가 포함되는 경우가 많고 주소에 접속 자격 증명이 들어갈 수도 있습니다. 전체 주소를 공개 스크린샷이나 온라인 게시물, 검증되지 않은 변환 서비스에 올리지 마세요. 원격 변환을 사용하면 제3자가 구독 내용을 볼 수 있으므로 처리 주체와 데이터 이동 경로를 확인해야 합니다. 제공자가 mihomo 또는 Clash Meta 형식을 직접 지원한다면 중간 변환을 줄이기 위해 해당 출력을 우선 사용하세요. 기술 지원이 필요하다면 오류 유형, 프로토콜 종류, 민감 정보를 지운 설정 구조만 공유해도 충분합니다. 비밀번호, 사용자 ID, 전체 구독 주소를 공개할 필요는 없습니다.

업데이트 방식도 설정 유지 관리에 영향을 줍니다. 구독으로 생성된 파일을 직접 편집하면 다음 업데이트에서 수정 사항이 덮어써질 수 있습니다. 로컬 규칙을 보존하려면 클라이언트의 덮어쓰기, 병합, 확장 기능을 사용하는 편이 좋습니다. 다만 클라이언트마다 병합 순서가 다르고 목록을 추가하면 중복이나 순서 변경이 생길 수 있습니다. 어떤 필드를 구독이 관리하고 어떤 필드를 클라이언트가 제어하는지 먼저 확인한 뒤 수정 위치를 정하세요. 특히 규칙 목록은 앞쪽에 범위가 넓은 규칙이 있으면 뒤쪽의 세부 규칙이 적용되지 않을 수 있습니다.

업데이트 후 일부 아웃바운드만 사라졌다면 필터 조건, 이름 변경 규칙, 유형 지원 여부를 확인하세요. 모두 사라졌다면 응답 콘텐츠와 다운로드 상태를 확인해야 합니다. 업데이트는 성공했지만 동작이 달라졌다면 템플릿과 덮어쓰기 설정도 함께 바뀌었는지 살펴보세요. 자격 증명이 포함된 파일을 여러 개 공개 동기화 폴더에 보관하기보다 민감 정보를 제거한 필드 목록으로 업데이트 전후를 비교할 수 있습니다. 세 가지 일반 형식의 변환 한계는 구독 링크 형식과 변환 안내에서 확인한 뒤 변환 과정이 필요한지 판단하세요.

8. 상황별 프로토콜 선택과 단계별 검증

안정적인 기준 설정부터 만들고 프로토콜 후보를 추가하세요

일반 웹 브라우징과 업무용 연결에는 서버 정보가 완전하고 현재 네트워크에서 안정적으로 접속할 수 있으며 클라이언트가 명확히 지원하는 아웃바운드를 우선 선택하세요. 검증된 SS, Trojan, VMess, 올바르게 설정된 VLESS는 모두 후보가 될 수 있습니다. 반드시 하나의 프로토콜로 통일해야 하는 것은 아닙니다. 기존 설정이 자주 사용하는 네트워크에서 안정적이라면 프로토콜 이름의 오래됨이나 새로움이 아니라 특정 전송 방식의 차단, 인증서 관리 문제, 앱의 UDP 요구처럼 분명한 이유가 있을 때 마이그레이션하세요. 기존 설정을 남겨 두면 새 방식의 변화를 명확하게 비교할 수 있습니다.

개발 도구를 사용할 때는 먼저 트래픽이 클라이언트에 들어오는 경로를 확인하세요. 브라우저는 정상인데 터미널에서만 실패한다면 도구가 시스템 프록시 설정을 읽는지 확인하고, 필요한 경우 도구 자체의 프록시 옵션이나 환경 변수를 설정한 뒤 TUN을 고려하세요. 요청이 클라이언트에 들어오지 않았을 수 있으므로 프로토콜을 바꾸거나 속도 테스트를 반복하지 마세요. macOS 터미널에서 아래 명령을 실행하면 현재 시스템 프록시 정보를 확인할 수 있습니다. 이 명령은 원격 프로토콜을 검증하지 않으며 명령줄 도구가 해당 설정을 따른다는 것도 보장하지 않습니다. 실제 수신 대기 포트는 클라이언트 설정 화면에서 확인하세요.

scutil --proxy

실시간 회의, 음성 통화, 게임에서는 UDP 전달, 지터, 연결 복구를 우선 살펴보세요. 먼저 앱 트래픽이 처리되는지 확인한 뒤 규칙 적용 여부와 아웃바운드의 UDP 지원을 점검합니다. Hysteria2와 TUIC도 후보가 될 수 있지만 네트워크에서 UDP를 허용하고 서버 설정이 일치할 때만 비교할 가치가 있습니다. 가정, 사무실, 게스트 네트워크 사이를 자주 이동하는 Mac에서는 TCP 기반 대체 아웃바운드를 남겨 두는 편이 실용적입니다. 정책 그룹의 상태 검사는 테스트 대상의 응답 여부만 확인할 뿐 모든 앱에서 사용할 수 있음을 보장하지 않습니다.

동일한 작업을 고정해 검증을 마무리하세요

설정을 변경할 때마다 같은 대상과 절차로 확인하세요. 먼저 클라이언트에서 설정을 정상적으로 불러왔는지 확인한 다음 대상 앱을 열고 연결 기록이 생기는지 살펴봅니다. 기록이 없다면 시스템 프록시, TUN 권한, 앱 자체 설정을 확인하세요. 기록은 있지만 잘못된 정책으로 연결된다면 규칙 순서와 도메인 해석을 점검하세요. 정책은 맞지만 핸드셰이크에 실패한다면 프로토콜, 인증, 인증서, 네트워크 경로를 확인합니다. 이렇게 하면 ‘인터넷에 연결되지 않음’이라는 문제를 단계별로 좁힐 수 있어 DNS, 포트, 프로토콜을 한꺼번에 바꾸는 일을 피할 수 있습니다.

복구와 대체 경로도 선택의 일부입니다

Mac 덮개를 닫았다가 열면 클라이언트가 인터페이스, 라우팅, 연결을 복구해야 할 수 있습니다. 깨어난 뒤에만 연결이 실패한다면 네트워크가 복구되었는지 확인한 뒤 검증된 아웃바운드로 한 번 전환하거나 클라이언트 연결을 다시 설정하고 로그를 살펴보세요. 문제가 반복된다면 서비스 권한, 네트워크 확장 기능, 다른 VPN이 동시에 라우팅을 변경하는지 확인하세요. 트래픽 처리 도구 여러 개를 동시에 실행하면 라우팅 루프나 우선순위 충돌이 생길 수 있으며 프로토콜만 바꿔서는 해결되지 않습니다. 클라이언트를 종료한 뒤에는 시스템 프록시가 원래 상태로 돌아왔는지도 확인하세요. 실행이 중단된 로컬 포트를 계속 가리키고 있으면 안 됩니다.

최종 선택은 다음 네 가지 조건으로 좁힐 수 있습니다. 현재 코어가 지원하고, 서버 매개변수가 완전하며, 자주 쓰는 네트워크에서 접속할 수 있고, 실제 작업에서 안정적으로 작동해야 합니다. 이 조건을 충족한 뒤 성능과 배터리 소모를 비교하세요. 새 조합을 유지하려고 수많은 설정을 수동으로 보완해야 한다면 유지 관리 비용도 고려해야 합니다. 처음 설치한다면 빠른 시작에 따라 기본 설정을 마치고, 구체적인 증상은 도움말 센터에서 찾아보세요. 익숙하지 않은 용어는 용어집에서 확인할 수 있습니다. 이 프로토콜 가이드는 판단 기준을 제공하며 최종 근거는 사용 중인 기기와 현재 네트워크, 실제 앱에서 반복해 확인한 결과입니다.