Clash 프로토콜 및 코어 기술 레퍼런스 프록시 프로토콜 선택 가이드

이 6가지 프로토콜은 서로 나란히 놓인 여섯 개의 선택지가 아니라, 같은 문제에 대해 각기 다른 시기에 나온 서로 다른 답입니다. 해야 할 일은 모두 같습니다. 로컬 트래픽을 암호화해 원격 서버로 보내고, 서버가 다시 요청을 내보내는 것입니다. 차이는 구현 경로에서 생깁니다. 전송 계층으로 TCP를 쓸지 UDP를 쓸지, 신원 인증을 핸드셰이크 전에 할지 후에 할지, 연결이 상태를 가지는지 아닌지입니다. 이 세 축이 프로토콜의 성능 특성, 호환 범위, 적합한 배포 환경을 결정합니다.

첫 번째 축: 전송 계층

Shadowsocks, Vmess, Trojan, VLESS는 모두 TCP 우선 계열입니다. QUIC이 성숙하기 전까지 TCP는 거의 모든 네트워크 환경이 감당할 수 있는 전송 계층이었고, 대가는 핸드셰이크에 왕복이 필요하고 패킷 손실 복구를 커널이 담당한다는 점이었습니다. Hysteria2와 TUIC는 UDP 위의 QUIC을 선택해 암호화, 혼잡 제어, 다중화를 모두 사용자 공간 구현에 넣었습니다. 장점은 핸드셰이크가 더 빠르고 손실 복구가 더 유연하다는 것이고, 대가는 CPU 사용량이 더 높다는 것입니다.

전송 계층 선택은 포트 요구 사항을 곧바로 결정합니다. TCP 계열 프로토콜은 TCP 포트 하나만 열면 되고, 서버 방화벽, 클라우드 보안 그룹, 컨테이너 포트 매핑 세 곳만 일치시키면 됩니다. QUIC 계열 프로토콜은 반드시 UDP 포트를 열어야 하는데, 일부 클라우드 사업자의 보안 그룹은 기본적으로 UDP를 허용하지 않아 설정할 때 이 단계를 빠뜨리기 쉽습니다. 증상은 '클라이언트는 연결되지 않고 서버 로그에는 아무것도 남지 않는' 형태로 나타납니다.

두 번째 축: 신원 인증과 특징

Shadowsocks에는 핸드셰이크 협상이 없습니다. 클라이언트와 서버가 키를 공유하고, 맞으면 바로 데이터를 보내기 시작하며 프로토콜 계층에서 신원을 밝히지 않습니다. Vmess는 UUID 신원을 도입해 인증을 프로토콜의 일부로 만들었고, 서버는 UUID로 사용자를 구분하고 트래픽을 집계하며 개별 속도 제한을 걸 수 있습니다. Trojan과 VLESS는 다른 길을 택했습니다. 트래픽을 표준 TLS 안에 넣고 인증 정보를 TLS 뒤에 숨겨, 서버가 인증서와 SNI 수준에서는 평범한 HTTPS 사이트와 구별되지 않게 합니다.

인증 방식이 복잡할수록 핸드셰이크 비용이 커지고, 그 대가로 얻는 관리 편의성도 달라집니다. 공유 비밀번호는 가장 단순하지만 비밀번호를 바꾸면 모든 사용자에게 알려야 합니다. UUID는 사용자별 관리에 유리하지만 설정 항목이 더 많습니다. TLS 기반 방식은 관리 편의성이 가장 좋지만 인증서와 도메인이라는 필수 조건이 붙습니다. 선택할 때는 '누가 서버를 관리하는가'를 함께 따져 보는 편이 프로토콜 성능만 비교하는 것보다 의미 있습니다.

세 번째 축: 상태와 오버헤드

상태 기반 프로토콜은 세션 테이블을 유지해야 하고, 무상태 프로토콜은 요청마다 독립적으로 처리합니다. VLESS는 무상태 설계의 대표로, 서버가 연결마다 세션을 저장할 필요가 없어 재시작과 이전 비용이 낮습니다. Vmess는 초기에 시간 창 검증에 의존했다가 나중에 이 메커니즘을 제거했는데, 이는 '상태'가 엔지니어링에서 언제나 부담이라는 사실을 보여줍니다. 클라이언트 입장에서 상태 기반 프로토콜은 연결 재사용(다중화)을 할 수 있어 반복되는 핸드셰이크를 줄여 주지만, 단일 대용량 연결에는 도움이 되지 않고 오히려 모든 연결이 같은 링크의 지터를 함께 떠안게 만들 수 있습니다.

세 축을 함께 놓고 보면 6가지 프로토콜의 위치가 분명해집니다. Shadowsocks와 Vmess는 범용형으로 호환 범위가 가장 넓고, Trojan과 VLESS는 TLS 기반형으로 표준 HTTPS 특징이 필요한 배포에 어울리며, Hysteria2와 TUIC는 UDP 우선형으로 손실과 높은 지연이 있는 링크에서 유리합니다. 이어지는 세 장에서 이 세 그룹을 하나씩 살펴봅니다.

Shadowsocks: 암호화 전달을 가볍게

Shadowsocks의 설계 목표는 하나뿐입니다. 로컬 트래픽을 암호화해 그대로 전달하고, 프로토콜에 별도의 협상을 넣지 않는 것입니다. 클라이언트와 서버가 비밀번호 하나를 공유하고, 비밀번호는 키 유도 함수를 거쳐 세션 키가 되며, AEAD 암호화(AES-256-GCM 또는 ChaCha20-Poly1305)가 데이터 스트림에 바로 적용됩니다. 첫 패킷이 곧 암호문이고 핸드셰이크 왕복이 없으므로, 연결 수립 지연은 사실상 TCP 핸드셰이크 한 번과 같습니다.

대가는 프로토콜 자체에 신원 표시가 없어 서버가 '누가' 연결하는지 알 수 없고 비밀번호로만 구분한다는 점입니다. Shadowsocks 2022 규격(SIP022)은 이 부분을 개선했습니다. 세션 ID와 재전송 보호를 도입하고 키 유도를 마스터 키와 세션 키 두 계층으로 나눴으며 UDP 처리 방식도 개선했습니다. 신버전과 구버전 서버·클라이언트 사이에는 호환성 차이가 있어, 배포 전에 서버 구현이 2022 규격을 지원하는지 확인해야 합니다. 그렇지 않으면 '비밀번호는 맞는데 연결되지 않는' 상황이 생깁니다.

암호화 스위트 선택도 중요합니다. AES-256-GCM은 하드웨어 가속 명령이 있는 기기에서 더 빠르고, 라우터와 저전력 기기에서는 ChaCha20-Poly1305가 더 안정적입니다. 두 방식의 보안 강도는 같고 차이는 구현 효율뿐이며, 클라이언트와 서버가 반드시 같은 암호화 방식을 써야 합니다.

Vmess: 전송 계층을 선택 항목으로

Vmess는 V2Ray 프로젝트의 자체 프로토콜이고, 핵심 변화는 전송 계층을 추상화한 것입니다. 같은 Vmess 신원을 순수 TCP, mKCP, WebSocket, gRPC, HTTP/2 위에서 실행할 수 있고 TLS를 덧씌울 수도 있습니다. 신원은 UUID로 표현되며 서버는 UUID로 사용자를 구분하고 통계와 속도 제한을 적용할 수 있습니다. 이 설계 덕분에 Vmess의 배포 형태는 매우 유연합니다. 표준 WebSocket 포트를 써야 하는 상황, gRPC 다중화가 필요한 상황 모두 같은 신원 설정을 재사용할 수 있습니다.

유연성은 설정 복잡도를 함께 가져옵니다. Vmess 공유 링크는 base64로 인코딩된 JSON이고, 필드 이름이 구현마다 통일되어 있지 않습니다(ps, add, port, id, aid, net, type, host, path, tls, sni가 각각 다른 정보를 나타냅니다). 변환 도구가 제대로 처리하지 못하면 필드가 유실됩니다. 또한 Vmess에 내장된 암호화 계층은 이미 TLS를 덧씌운 상태에서는 중복 암호화에 해당해 계산 비용이 VLESS보다 높습니다. 이것도 VLESS가 등장한 이유 가운데 하나입니다.

두 프로토콜의 장단점

호환성만 보면 Shadowsocks와 Vmess는 적용 범위가 가장 넓은 두 프로토콜입니다. 원본 Clash, mihomo, Surfboard, 그리고 각종 모바일 클라이언트가 모두 인식합니다. 차이는 리소스 사용량과 설정 비용입니다. Shadowsocks는 CPU를 덜 쓰고, Vmess는 더 유연합니다. UDP 전달에서는 Shadowsocks는 서버 구현에서 명시적으로 켜야 하고, Vmess는 UDP over TCP 방식 전달을 기본 지원해 TCP만 열려 있는 환경에서 더 간편합니다.

'프로토콜이 최신일수록 빠르다'는 흔한 오해입니다. 같은 서버, 같은 링크에서 Shadowsocks와 Vmess의 실측 처리량 차이는 보통 링크 자체의 변동보다 작습니다. 실제로 차이를 만드는 것은 핸드셰이크 횟수와 TLS 중첩 여부입니다. 선택할 때는 프로토콜이 등장한 순서보다 클라이언트 지원 범위와 서버 구현을 먼저 보세요.

Trojan: 인증을 TLS 뒤에 배치

Trojan의 방식은 단순합니다. 서버가 443을 수신하고 먼저 표준 TLS 핸드셰이크를 마치면, 클라이언트가 핸드셰이크 완료 후 비밀번호를 제출하고 서버가 검증을 통과해야 전달을 시작합니다. 중간 전달 장비 입장에서 이 포트의 트래픽은 평범한 HTTPS 사이트와 다르지 않습니다. 서버는 같은 포트에서 실제 웹사이트로 폴백(fallback)을 구성할 수도 있어, 인증을 통과하지 못한 요청은 웹사이트가 처리합니다. 그래서 도메인 하나로 웹사이트와 프록시 서비스를 함께 운영할 수 있습니다.

이 설계의 의존 요소는 분명합니다. 유효한 인증서, 인증서와 일치하는 도메인, 올바른 SNI입니다. 세 가지 가운데 하나라도 어긋나면 클라이언트는 핸드셰이크 단계에서 실패하고, 로그에는 보통 '연결이 재설정됨' 또는 'TLS 핸드셰이크 실패' 같은 두루뭉술한 메시지만 남습니다. Trojan의 UDP 지원은 구현마다 차이가 있으며, 네이티브 구현은 UDP associate를 제공하고 일부 구현은 확장 버전에 의존합니다. 설정 면에서 Trojan은 6가지 프로토콜 가운데 가장 단순한 편입니다. 주소, 포트, 비밀번호, SNI 네 가지만 있으면 동작합니다.

VLESS: 중복 암호화 제거

VLESS의 설계 전제는 이렇습니다. 바깥에 이미 TLS가 있으니 프로토콜 내부에서 다시 암호화할 필요가 없다는 것입니다. 그래서 VLESS 자체는 암호화하지 않고 신원(UUID)과 목적지 주소만 전달하며, 보안은 전적으로 하위 전송에 맡깁니다. 이 결정이 Vmess에서 가장 무거운 계산 비용을 덜어냈고, 서버를 무상태로 만들었습니다. 세션을 유지할 필요도, 타임스탬프를 검증할 필요도 없어 재시작이 이후 연결 수립에 영향을 주지 않습니다.

VLESS의 또 다른 변화는 흐름 제어입니다. Vision 흐름 제어(flow 필드에 xtls-rprx-vision)는 TLS 계층 안에서 패딩과 분할을 수행해 중첩 TLS 환경의 추가 비용을 줄입니다. 주의할 점은 flow 파라미터가 클라이언트와 서버 사이의 약속이라는 것입니다. 구독 변환 도구가 이 필드를 버리면 연결이 일반 TLS 모드로 퇴화합니다. 기능은 여전히 동작하지만 성능 특성이 예상과 달라집니다. 확인 방법은 연결 로그를 열어 실제로 쓰인 흐름 제어 방식을 보는 것입니다.

인증서와 시간: 가장 흔한 두 가지 문제

TLS 기반 프로토콜의 장애는 대부분 프로토콜 자체가 아니라 인증서 체인에서 생깁니다. 자체 서명 인증서는 클라이언트가 검증을 명시적으로 건너뛰어야 해서 장기 사용에 적합하지 않습니다. 인증서 체인이 불완전하면 데스크톱 브라우저는 중간 인증서를 캐시해 정상으로 보일 수 있지만 클라이언트는 곧바로 오류를 냅니다. 또 다른 문제는 시스템 시간입니다. 시간 오차가 인증서 유효 기간 허용 범위를 넘으면 검증이 실패하는데, 증상은 '노드를 쓸 수 없음'처럼 보여 서버 장애로 오인하기 쉽습니다.

점검 순서는 고정해 두는 것이 좋습니다. 먼저 클라이언트 로그에서 오류 유형(핸드셰이크 실패, 인증서 검증 실패, 연결 시간 초과)을 보고, 시스템 시간, 인증서 체인, SNI 세 가지를 차례로 확인합니다. 인증서 오류의 전체 점검 경로는 기술 노트 《Clash 환경의 HTTPS 인증서 오류: 흔한 원인과 점검 순서》에서 확인할 수 있습니다.

Hysteria2: 설정한 대역폭으로 전송

Hysteria2는 전송 계층을 QUIC(HTTP/3의 기반 프로토콜)으로 바꾸고 TLS 1.3을 내장해 별도의 암호화 스위트 설정이 필요 없습니다. 가장 눈에 띄는 부분은 혼잡 제어입니다. 기본값인 Brutal은 클라이언트에 설정된 상하향 대역폭에 맞춰 고정 속도로 전송하며, 링크에 패킷 손실이 생겨도 스스로 속도를 낮추지 않습니다. 이 전략은 손실률이 높은 링크에서 처리량을 유지할 수 있지만, 대역폭 파라미터를 실제 값에 가깝게 입력해야 합니다. 너무 크게 넣으면 같은 링크의 다른 트래픽을 밀어내고, 너무 작게 넣으면 프로토콜의 장점을 살리지 못합니다.

Hysteria2는 UDP 계층 난독화 옵션(salamander)도 제공해 QUIC 패킷을 가볍게 한 겹 감쌉니다. 서버는 UDP 포트 하나만 필요하고 사용자마다 포트를 할당할 필요가 없어, 배포와 확장이 TCP 계열 프로토콜보다 단순합니다. 설정 항목은 Trojan보다 조금 많습니다. 주소, 포트, 비밀번호, SNI, 대역폭 상하한, 그리고 인증서 검증 건너뛰기 여부입니다.

TUIC: 0-RTT와 네이티브 UDP 전달

TUIC도 QUIC을 기반으로 하며, 설계는 'QUIC의 능력을 최대한 그대로 활용한다'에 가깝습니다. v5 버전은 0-RTT 핸드셰이크를 지원해 세션을 재사용할 때 왕복 한 번을 절약합니다. UDP 전달에는 native와 quic 두 가지 모드가 있는데, 전자는 UDP 패킷을 그대로 캡슐화하고 후자는 QUIC 스트림을 사용하므로 링크 특성에 따라 고르면 됩니다. 혼잡 제어 알고리즘은 bbr, cubic, new_reno 사이에서 전환할 수 있어, Hysteria2의 고정 속도 전략과 대비됩니다.

TUIC의 신원은 UUID와 비밀번호를 함께 써서 표현하며 설정 항목 수는 Vmess에 가깝습니다. 클라이언트에 요구하는 수준은 더 높습니다. 코어가 QUIC 스택을 완전히 구현해야 하므로 현재는 mihomo 계열 코어만 지원합니다. 서버 역시 UDP 포트 하나만 필요하고, 여러 사용자가 같은 포트를 공유해도 서로 간섭하지 않습니다.

QUIC 계열의 공통 비용

QUIC은 사용자 공간에서 구현되는데, 이것이 가장 큰 엔지니어링 비용입니다. 암호화, 혼잡 제어, 재전송이 모두 응용 프로그램 안에서 이루어져 CPU 사용량이 커널 공간 TCP보다 높습니다. 모바일에서 지속적으로 전송하면 배터리 소모 차이가 TCP 계열 프로토콜보다 뚜렷해지고, QUIC의 버퍼 때문에 메모리 사용량도 더 큽니다. 데스크톱과 서버에서는 이 비용을 대체로 감당할 수 있지만, 라우터나 저사양 기기, 장시간 모바일 사용 환경에서는 저울질이 필요합니다.

또 하나의 현실적인 제약은 UDP 포트 자체입니다. 일부 기업 네트워크와 공용 Wi-Fi는 UDP를 제한하거나 우선순위를 낮추는데, 이때 QUIC 계열 프로토콜의 성능은 눈에 띄게 떨어지므로 TCP 계열로 되돌아가야 합니다. 그래서 Hysteria2와 TUIC는 유일한 노드가 아니라 예비 노드로 두는 편이 좋습니다. 구독에 TCP 계열 노드를 하나 함께 유지하면 전환 비용이 가장 낮습니다.

세 가지의 관계

원본 Clash 코어는 config.yaml의 기본 골격을 정의했습니다. proxies, proxy-groups, rules, proxy-providers, rule-providers, dns, tun 같은 섹션과 mode, log-level, mixed-port, external-controller 같은 최상위 필드입니다. 이 골격은 이후 생태계 전체의 사실상 표준이 되어, 거의 모든 클라이언트가 이 구조로 설정을 구성합니다. 원본 코어는 유지보수가 중단되었지만 필드 이름 규칙은 지금까지 이어지고 있습니다.

Clash.Meta는 원본을 기반으로 확장한 분기로, 새 프로토콜과 새 규칙 유형, 더 완성도 높은 TUN 구현을 추가했습니다. 이 분기는 이후 mihomo로 이름을 바꾸고 저장소와 문서를 MetaCubeX 조직으로 옮겨 관리하고 있습니다. 현재도 업데이트되는 그래픽 클라이언트인 Clash Verge Rev, Clash Meta for Android, FlClash, Clash Nyanpasu, ClashX Meta는 모두 mihomo 코어를 사용합니다. Clash for Windows는 원본 코어를 사용하며 아카이브되어 유지보수가 중단되었습니다. 원본 설정은 계속 불러올 수 있지만 이후 추가된 필드는 인식하지 못합니다.

클라이언트가 어떤 코어를 쓰는지 판단하는 가장 직접적인 방법은 로그의 버전 줄과 설정 파싱 결과를 보는 것입니다. 설정을 불러올 때 알 수 없는 필드가 있다고 알리면 코어의 필드 집합이 작은 것이고, sniffer, listeners, rule-set 같은 섹션을 인식하면 mihomo 계열입니다. 오픈소스 생태계 각 프로젝트의 관계는 기술 노트 《Clash 오픈소스 생태계 정리: 코어, 클라이언트와 규칙 세트의 관계》에서 확인할 수 있습니다.

기능 차이 비교

설정 호환성과 마이그레이션

원본 코어에서 mihomo로 옮기는 것은 거의 무리 없이 진행됩니다. 원본 설정의 섹션과 필드는 mihomo에서 모두 유지되므로 그대로 불러오면 됩니다. 반대 방향 이전은 주의가 필요합니다. mihomo의 확장 필드는 원본 코어에서 파싱 오류를 일으키므로 하나씩 삭제해야 합니다. 흔히 삭제해야 하는 섹션에는 sniffer, listeners, sub-rules, 그리고 rule-providers의 mrs 형식 선언이 있습니다.

# 다음 섹션은 mihomo 계열 코어만 인식하며, 원본 코어는 알 수 없는 필드로 오류를 냅니다
sniffer:
  enable: true
  sniff:
    HTTP:
      ports: [80, 8080]
      override-destination: true
    TLS:
      ports: [443, 8443]

두 코어의 파싱 방식은 모두 엄격합니다. 모르는 필드를 만나면 무시하지 않고 곧바로 오류를 냅니다. 이 특성은 마이그레이션할 때 오히려 장점입니다. 설정에 문제가 있으면 즉시 드러나고 조용히 성능이 떨어지는 일이 없습니다. unknown field 같은 로그가 보이면 먼저 클라이언트의 필드 집합을 확인하고, 필드를 삭제할지 클라이언트를 바꿀지 결정하세요.

또 하나 놓치기 쉬운 차이는 dns 섹션입니다. mihomo는 dns 설정 항목을 확장했고(nameserver-policy, fallback-filter의 매칭 방식, 해석이 규칙을 따르게 할지 여부 등), 원본 코어의 dns 섹션은 더 단순합니다. 이전할 때 예전 필드를 남겨 두었다면 새 코어가 여전히 받아들이는지 확인해야 하고, 반대로 확장 필드가 들어간 dns 섹션을 원본 코어에 넣으면 파싱이 바로 실패합니다.

네 가지 구독 형태

첫 번째는 완전한 YAML 구독입니다. 서버가 config.yaml 한 부를 그대로 반환하고 proxies, proxy-groups, rules, 포트 설정을 포함하며 클라이언트가 불러오면 바로 쓸 수 있습니다. 이 형태는 사용자에게 가장 편하지만, 규칙 정책을 구독 제공자가 정하게 되므로 사용자 자신의 규칙은 따로 관리해야 합니다. 두 번째는 공유 링크 목록입니다. base64로 인코딩된 여러 줄 텍스트로, 각 줄이 ss://, vmess://, trojan://, vless://, hysteria2://, tuic:// 링크 하나이며 클라이언트가 파싱해 노드 목록을 얻고 규칙은 클라이언트가 로컬에서 정합니다.

세 번째는 변환 서비스입니다. 공유 링크 목록을 Clash YAML로 변환하며 중간에 규칙 템플릿을 적용할 수 있습니다. 변환 서비스는 클라이언트가 공유 링크를 인식하지 못하는 문제를 해결하지만 새로운 정보 손실을 끌어들입니다. 네 번째는 proxy-providers입니다. 클라이언트가 원격 주소에서 노드 목록을 주기적으로 가져와 로컬 규칙과 분리하며, 여러 구독을 합치는 데 적합합니다.

proxy-providers: 노드와 규칙 분리

proxy-providers를 사용하면 클라이언트가 원격에서 노드 목록을 주기적으로 가져와 로컬 규칙과 분리합니다. 여러 구독을 합치거나 팀에서 설정을 공유할 때 적합합니다. 규칙은 로컬에 두고 노드는 원격에서 갱신합니다. 각 provider마다 갱신 간격, 상태 확인 주소, 필터 표현식을 따로 설정할 수 있습니다.

proxy-providers:
  provider-a:
    type: http
    url: "https://example.com/subscribe/xxxx"
    interval: 3600
    path: ./providers/provider-a.yaml
    filter: "(?i)(hk|sg|jp)"
    health-check:
      enable: true
      url: https://example.com/generate_204
      interval: 300

필터 표현식은 provider에서 가장 실용적인 두 필드인 filter와 exclude-filter이며, 정규식으로 노드 이름을 매칭합니다. 예를 들어 이름에 특정 지역 표시가 있는 노드만 남기거나 임시 노드를 제외할 수 있습니다. 주의할 점은 필터링이 클라이언트에서 일어난다는 것입니다. 서버가 반환한 노드는 여전히 로컬 파일로 내려받아지고, 단지 사용 가능한 목록에 들어가지 않을 뿐입니다. '노드가 줄었다' 같은 문제를 점검할 때는 필터 표현식을 먼저 보고, 그다음 서버가 반환한 내용을 확인하세요.

변환과 갱신에서 흔한 함정

공유 링크를 YAML로 변환하는 과정에서 정보가 유실되는 것이 가장 흔한 문제 원인입니다. vless://의 flow 파라미터, hysteria2://의 난독화와 검증 건너뛰기 옵션, tuic://의 혼잡 제어와 UDP 전달 모드는 일부 변환 도구에 대응하는 필드가 없어, 변환 후 연결이 기본 파라미터로 퇴화합니다. 판단 방법은 '연결이 되는지'만 보는 것이 아니라 변환 전후의 노드 파라미터를 비교하는 것입니다.

proxies:
  - name: "ss-a"
    type: ss
    server: 203.0.113.10
    port: 8388
    cipher: aes-256-gcm
    password: "your-password"
  - name: "vless-a"
    type: vless
    server: 203.0.113.11
    port: 443
    uuid: b831381d-6324-4d53-ad4f-8cda48b30811
    tls: true
    servername: example.com
    flow: xtls-rprx-vision
  - name: "hy2-a"
    type: hysteria2
    server: 203.0.113.12
    port: 443
    password: "your-password"
    sni: example.com
    up: "30 Mbps"
    down: "200 Mbps"

두 번째 유형의 문제는 YAML 문법 자체입니다. 노드 이름에 쉼표, 콜론, 따옴표가 있을 때 따옴표로 감싸지 않으면 설정 전체의 파싱이 실패합니다. 이런 오류는 보통 '구독 갱신은 성공했는데 노드 목록이 비어 있음'으로 나타납니다. 세 번째는 구독에 포함된 포트 설정입니다. 일부 구독은 port, socks-port 필드를 함께 보내는데, 클라이언트는 보통 이를 무시하고 로컬 설정을 사용합니다. 로컬 포트가 바뀌었다면 먼저 클라이언트의 포트 재정의 옵션을 확인하세요.

구독 갱신 실패의 점검 순서는 고정해 두는 것이 좋습니다. 먼저 링크가 브라우저에서 바로 접근되는지(로그인 페이지가 아니라 텍스트가 반환되는지) 확인하고, 다음으로 클라이언트 로그의 HTTP 상태 코드를 확인한 뒤, 마지막으로 구독에 클라이언트가 모르는 프로토콜이 들어 있는지 봅니다. 알 수 없는 프로토콜의 노드는 건너뛰고 나머지 노드는 정상적으로 불러옵니다. 구독 관련 점검 항목은 자주 묻는 질문 페이지에 더 정리되어 있습니다.

클라이언트가 프로토콜의 상한을 결정합니다

mihomo 계열 코어를 쓰는 클라이언트는 전체 프로토콜 집합을 지원합니다. Shadowsocks, Vmess, Trojan, VLESS, Hysteria2, TUIC를 모두 인식합니다. 원본 코어를 쓰는 Clash for Windows는 아카이브되어 유지보수가 중단되었고 Shadowsocks, Vmess, Trojan, Snell과 HTTP / SOCKS5 같은 1세대 프로토콜만 지원합니다. Surfboard의 프로토콜 범위도 Shadowsocks, Vmess, Trojan이 중심입니다. 구독에 VLESS나 Hysteria2 노드가 있으면 아카이브 클라이언트에서는 이 노드들이 그대로 건너뛰어져 '노드 수가 구독보다 적은' 증상이 나타납니다.

전 플랫폼에서 우선 추천하는 클라이언트는 Clash Plus입니다. Windows, macOS, Android, iOS 모두 대응 버전이 있고, iOS는 App Store에서 받을 수 있으며 공식 사이트 도메인은 clashplus.io입니다. 구독 가져오기와 규칙 분기 방식은 다른 클라이언트와 동일합니다. 데스크톱에서는 Clash Verge Rev(Windows / macOS / Linux), FlClash(전 플랫폼), Clash Nyanpasu(Windows)를 고를 수 있습니다. Android에서는 Clash Meta for Android와 FlClash를 많이 쓰고, macOS에서는 Clash Verge Rev 외에 아카이브된 ClashX Meta도 있습니다. 플랫폼별 설치 파일은 클라이언트 다운로드 페이지에 모아 두었습니다.

플랫폼별 차이

데스크톱은 리소스가 넉넉해 QUIC 계열 프로토콜을 부담 없이 쓸 수 있고 CPU 사용량이 병목이 되지 않습니다. Android에서는 시스템의 백그라운드 절전 정책을 주의해야 합니다. 절전 모드는 백그라운드 네트워크 활동을 제한하고, QUIC의 장기 연결은 백그라운드에서 시스템에 의해 일시 중단될 수 있어 '돌아오면 다시 연결해야 하는' 증상이 나타납니다. 이런 환경에서는 TCP 계열 프로토콜이 더 안정적이거나, 클라이언트의 킵얼라이브 설정을 더 느슨하게 조정하는 편이 좋습니다.

iOS는 시스템이 네트워크 확장을 통합 관리하므로 App Store에 등록된 버전을 기준으로 선택하며, 설정 가져오기 절차도 데스크톱과 같고 구독 링크로 가져옵니다. 라우터와 저사양 기기에서는 사용자 공간으로 구현된 QUIC 스택이 확실히 부담이 되므로 Shadowsocks 같은 경량 프로토콜이 더 적합합니다. 기기 메모리도 함께 고려해야 하는데, 규칙 세트 자체도 일정 부분을 차지합니다.

상황별 선택 표

프로토콜 자체 외에도 클라이언트 선택은 업데이트 주기의 영향을 받습니다. 유지보수가 계속되는 클라이언트는 코어의 새 프로토콜과 새 필드를 따라가지만, 아카이브된 클라이언트는 기존 기능만 유지합니다. 클라이언트 간 차이는 기술 노트 《주요 Clash 클라이언트 비교: 플랫폼과 사용 습관에 따른 선택》에서 확인할 수 있습니다.

마이그레이션 전 준비

클라이언트나 프로토콜을 바꾸기 전에 기존 설정을 먼저 내보내 백업하세요. 프로필 파일, 규칙 파일, 구독 링크입니다. 아카이브된 클라이언트(Clash for Windows, ClashX Meta)의 설정은 계속 사용할 수 있고, 내보낸 config.yaml은 mihomo 계열 클라이언트에서 대체로 그대로 불러올 수 있습니다. 삭제해야 하는 것은 코어가 인식하지 못하는 새 필드이며, 방향은 원본에서 mihomo로 옮길 때와 반대입니다.

프로토콜을 바꿀 때는 세 가지를 확인합니다. 서버가 대상 프로토콜을 지원하는지, 포트가 열려 있는지(QUIC 계열은 UDP 필요), 구독에 해당 프로토콜 노드가 들어 있는지입니다. 세 가지 가운데 하나라도 빠지면 클라이언트에 사용 가능한 연결이 나타나지 않습니다. 서버가 공유 링크만 제공한다면 먼저 링크의 프로토콜 접두사가 클라이언트 지원 범위와 맞는지 확인한 뒤 가져오세요.

마이그레이션 후 검증

검증 순서는 규칙부터 시작하는 것이 좋습니다. 클라이언트의 연결 로그를 열어 트래픽이 기본 직결이나 기본 프록시가 아니라 의도한 규칙과 정책 그룹에 매칭되는지 확인합니다. 다음으로 DNS를 검증합니다. 해석 결과가 설정의 nameserver와 정책에 맞는지, 예상치 못한 해석 출처가 나타나지 않는지 봅니다. 마지막으로 UDP 전달을 검증합니다. UDP가 필요한 앱이 정상 동작하는지 확인하는데, 이 항목은 QUIC 계열 프로토콜에서는 보통 네이티브로 지원되고 Shadowsocks에서는 서버 설정에 따라 달라집니다.

proxy-providers를 사용한다면 구독 정기 갱신이 성공하는지도 추가로 확인하세요. 로그에 매번 가져온 시간과 결과가 기록되고, 노드 목록이 필터 표현식으로 비워지지 않았는지도 함께 봐야 합니다. 갱신 실패의 흔한 원인은 링크 만료, 반환 내용이 YAML이 아님, 필터 표현식이 모든 노드를 제외한 경우입니다.

흔한 롤백 상황

QUIC 계열 프로토콜은 UDP를 제한하는 네트워크에서 성능이 떨어지므로, 이때는 구독을 바꾸지 않고 TCP 계열 프로토콜로 되돌리면 됩니다. 인증서 관련 문제는 시스템 시간과 인증서 체인을 먼저 확인하고, 구체적인 경로는 기술 노트 《Clash 환경의 HTTPS 인증서 오류: 흔한 원인과 점검 순서》를 참고하세요. 구독 갱신 실패는 링크 접근성과 클라이언트 로그를 먼저 확인하고, 흔한 원인은 자주 묻는 질문 페이지에 정리되어 있습니다.

마이그레이션의 목적이 유지보수가 중단된 클라이언트를 교체하는 것이라면, 전체 절차(설정 내보내기, 코어 교체, 대안 비교)는 기술 노트 《클라이언트 지원 종료 이후: 설정 내보내기, 코어 교체와 대안》에서 확인할 수 있습니다. 마이그레이션이 끝나면 새 설정과 이전 설정을 각각 한 부씩 남겨 두고 1~2주 관찰한 뒤 이전 파일을 삭제하는 것을 권합니다.