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

코어 계열과 클라이언트의 역할

Clash는 특정 설치 파일 하나가 아니라 생태계 전체를 가리키는 이름입니다. 그래픽 클라이언트는 창, 구독 관리, 시스템 프록시 전환, 권한 요청을 담당하고, 코어는 설정을 읽고 도메인을 해석하며 규칙을 적용해 외부 연결을 설정합니다. 두 구성 요소는 서로 다른 프로젝트에서 관리될 수 있습니다. 기능을 확인할 때는 앱 이름에 Clash가 있는지만 볼 것이 아니라 실제로 사용하는 코어와 릴리스 정보를 확인해야 합니다. 화면에 옵션이 보여도 현재 코어가 해당 설정 항목을 지원한다는 뜻은 아닙니다.

원본 Clash, Meta, mihomo의 관계

원본 Clash는 YAML 설정, 정책 그룹, 규칙 기반 트래픽 분기의 기본 모델을 정립했습니다. 과거에는 기능이 서로 다른 오픈소스 버전과 Premium 코어도 있었으므로 ‘원본이 무엇을 지원하는가’를 판단하려면 구체적인 브랜치를 구분해야 합니다. Clash.Meta는 이 생태계를 바탕으로 프로토콜과 네트워크 기능을 확장했고, 이후 mihomo라는 이름으로 발전했습니다. 이전 가이드의 Meta 코어나 일부 클라이언트의 Meta 표기는 대체로 이 계보를 가리키지만, 이름이 비슷하다고 실제 기능까지 같다고 볼 수는 없습니다.

mihomo는 proxies, proxy-groups, rules, dns 등 익숙한 설정 구조를 유지하면서 VLESS, Hysteria2, TUIC 및 관련 매개변수를 지원합니다. 호환성은 기본 구조가 이어진다는 뜻이지, 모든 브랜치가 서로 양방향으로 호환된다는 의미는 아닙니다. mihomo에서 읽을 수 있는 설정을 구버전 코어에 넣으면 알 수 없는 프로토콜, 규칙 유형, DNS 항목 때문에 시작되지 않거나 해당 기능을 사용할 때 오류가 날 수 있습니다.

프로토콜, 전송 방식, 트래픽 진입 경로를 따로 살펴보기

노드의 type은 프록시 프로토콜을 나타내고, TCP, WebSocket, gRPC, QUIC은 사용하는 전송 방식이나 기반을 나타냅니다. TLS는 연결의 신원을 확인하고 암호화로 보호합니다. 시스템 프록시와 TUN은 앱의 트래픽이 코어로 들어가는 경로입니다. TUN을 켜도 SS 노드가 QUIC 노드로 바뀌지 않고, Hysteria2로 변경해도 모든 앱이 자동으로 시스템 프록시를 따르는 것은 아닙니다. 각 요소는 서로 다른 계층에 있으므로 문제를 해결할 때도 각각 확인해야 합니다.

클라이언트는 다운로드 센터에서 찾아보세요. 먼저 Clash Plus의 해당 플랫폼 다운로드를 확인하고, 데스크톱 연동 방식이나 관리 편의에 따라 Clash Verge Rev, FlClash 등을 비교할 수 있습니다. 같은 Clash 생태계에 속한다고 해서 모든 클라이언트가 같은 파일을 그대로 가져올 수 있는 것은 아닙니다. 구독 형식을 변환하는 클라이언트도 있고, 설정을 다른 코어에 전달하는 클라이언트도 있으며, 플랫폼에 따라 백그라운드 네트워크 동작이 제한될 수 있습니다.

기존 설정을 옮길 때는 원본 파일을 따로 보관하고 최소한의 기능만으로 먼저 연결을 확인하세요. 기본 노드가 작동하는 것을 확인한 뒤 규칙 제공자, TUN, 고급 DNS를 차례로 활성화하면 프로토콜 호환성 문제와 시스템 연동 문제를 구분할 수 있습니다. 자세한 실행 방법은 mihomo 사용 안내를 참고하세요. 다음 장에서는 설정에 따라 결과가 달라지는 이유를 설명합니다.

SS, VMess, Trojan의 설계 차이

이 세 프로토콜은 구독에 함께 포함되는 경우가 많지만 서로 바꿔 쓸 수는 없습니다. 서버가 사용하는 프로토콜에 맞는 구현과 인증 매개변수를 클라이언트에서도 사용해야 합니다. 노드 이름을 바꿔도 프로토콜은 달라지지 않으며, type의 값을 다른 이름으로 바꾼다고 변환되는 것도 아닙니다. 주요 차이는 암호화와 인증 방식, 전송 조합, 배포 요건, 과거 버전과의 호환 부담에 있으며, 정해진 속도 순위가 있는 것은 아닙니다.

Shadowsocks: 간결한 암호화 프록시 모델

SS는 Shadowsocks의 일반적인 약칭입니다. 비교적 간결한 프로토콜 구조로 프록시 연결을 전달하며, 기본 설정에는 서버, 포트, 암호화 방식, 비밀번호가 포함됩니다. 현재 사용 시에는 기존 AEAD 방식과 Shadowsocks 2022 계열을 구분해야 합니다. 두 계열은 키 요건, 핸드셰이크 설계, 구현 지원이 완전히 같지 않습니다. 서버에서 지정한 방식을 클라이언트에도 그대로 설정해야 하며, 목록에 둘 다 SS로 표시된다는 이유만으로 서로 호환된다고 볼 수 없습니다.

SS의 기본 구조는 간결하지만, ‘구조가 단순하다’고 해서 모든 기기에서 연산 부담이 더 적은 것은 아닙니다. AES 계열은 하드웨어 가속을 지원하는 플랫폼에서 좋은 성능을 낼 수 있고, ChaCha20 계열은 관련 가속 기능이 없는 기기에 적합할 수 있습니다. 실제 성능은 구현 방식, 프로세서, 트래픽 형태에 따라 달라집니다. 플러그인을 사용하는 SS 노드는 전송 요건이 하나 더 추가됩니다. 비밀번호만 복사하고 플러그인 모드, 호스트 이름, 경로를 빠뜨리면 인증 정보가 맞아 보여도 연결되지 않을 수 있습니다.

VMess: 기존 생태계와 전송 방식 조합

VMess는 V2Ray 생태계에서 시작해 사용자 식별자, 인증, 데이터 전송을 아우르는 프로토콜로 설계됐습니다. 다양한 전송 방식을 조합할 수 있으므로 구독에 같은 VMess 노드로 표시되어도 핸드셰이크 경로와 연결 비용은 다를 수 있습니다. 문제를 해결할 때는 UUID, 암호화 옵션, 전송 유형, TLS, 경로 매개변수를 함께 확인하세요. 시스템 시간이 크게 어긋나도 인증에 영향을 줄 수 있으므로 정책 그룹을 계속 바꾸기보다 먼저 시스템 시간을 정상적으로 동기화하세요.

이전 가이드에는 과거 버전과의 호환을 위해 남겨 둔 매개변수가 있을 수 있으므로 현재도 통용되는 권장 설정으로 그대로 받아들이면 안 됩니다. 특히 구형 설정의 인증 매개변수를 새 서버에 무작정 복사하지 마세요. VMess는 이미 구축된 서버와 도구가 많다는 장점이 있습니다. 기존 서버가 안정적으로 작동하고 클라이언트 지원도 충분하다면, 프로토콜을 바꾸기 위해서만 이전하는 것보다 그대로 사용하는 편이 합리적일 수 있습니다. 업그레이드 여부는 노드 이름의 신구가 아니라 코어 지원, 보안 유지 관리, 연결 상태를 기준으로 판단하세요.

Trojan: TLS 연결 기반 프로토콜

Trojan은 일반적으로 TLS 연결을 통해 인증 정보와 프록시 데이터를 전달합니다. 클라이언트에 올바른 비밀번호, 서버 주소, 인증서 검증 정보가 필요합니다. 연결 주소, SNI, 인증서에 포함된 도메인은 서로 달라도 되지만 서버 배포 방식에 맞아야 합니다. 인증서 만료, 불완전한 신뢰 체인, 호스트 이름 불일치가 있으면 핸드셰이크가 실패합니다. 인증서 검증을 끄면 문제를 가릴 뿐이므로 일반적인 연결 방법으로 사용하지 마세요.

Trojan의 연결 비용은 TLS 핸드셰이크, 세션 재개, 네트워크 왕복 시간에 따라 달라지므로 ‘TLS를 적용하면 무조건 느리다’고 단정할 수 없습니다. 장시간 연결을 유지하는 다운로드와 짧은 연결을 자주 여는 웹페이지는 체감 비용이 다릅니다. WebSocket 같은 전송 방식을 추가하는 경우 경로, Host, 서버 전달 규칙도 일치해야 합니다. 기본 Trojan과 전송 방식을 추가한 Trojan은 서로 다른 조합으로 검증해야 하며, 한 번의 비교에서 섞어 판단하지 마세요.

세 프로토콜 모두 일상적인 웹 이용에 사용할 수 있지만, UDP 지원 여부와 실제 활성화 상태는 프로토콜 구현, 서버 설정, 클라이언트 연결 경로를 함께 확인해야 합니다. 웹페이지가 열린다는 사실은 일부 TCP 요청이 성공했다는 뜻일 뿐, 음성 통화, 게임, 기타 UDP 트래픽도 같은 방식으로 처리된다는 보장은 없습니다. QUIC 기반 프로토콜을 비교할 때도 이 점을 염두에 두고 테스트해야 합니다.

VLESS, Hysteria2, TUIC의 사용 범위

새 프로토콜은 기존 연결 모델의 일부 문제를 개선하기 위해 설계됐지만 네트워크 경로 자체의 제약까지 없애지는 못합니다. VLESS는 간결한 인증 및 전송 계층 설계에 중점을 둡니다. Hysteria2와 TUIC는 QUIC을 기반으로 합니다. 최신 코어에서 함께 지원되는 경우가 많아 같이 언급되지만, 전송 방식까지 동일한 것은 아닙니다. 가져오기 전에 프로토콜 버전과 세부 매개변수를 확인하세요.

VLESS: 인증 계층과 보안 전송의 분리

VLESS는 V2Ray 관련 생태계에서 시작됐으며 VMess보다 간결한 프로토콜 설계를 채택했습니다. 특히 VLESS 자체에는 이름에서 연상되는 독립적인 데이터 암호화 계층이 없습니다. 일반적으로 TLS, REALITY 등 외부 보안 메커니즘으로 연결을 보호합니다. UUID로 인증할 수 있다고 해서 연결에 충분한 기밀성 보호가 적용된 것은 아닙니다. 서버에서 제공하는 전체 전송 방식에 맞춰 설정하고, 서버 주소와 UUID만 입력해서는 안 됩니다.

VLESS의 실제 성능은 전송 방식 조합에 크게 좌우됩니다. TCP 직접 전송, WebSocket, gRPC는 연결 설정, 프록시 경로, 중간 서비스 지원 요건이 서로 다릅니다. 일부 서버에서는 특정 flow도 사용합니다. 이는 어디서나 쓸 수 있는 가속 옵션이 아니므로 서버와 하위 전송 방식에 맞춰야 합니다. REALITY의 공개 키, 짧은 ID, 서버 이름도 각각 의미가 있으므로 하나라도 빠지면 핸드셰이크가 완료되지 않을 수 있습니다.

Hysteria2: QUIC과 대역폭 활용

Hysteria2는 QUIC 기반으로, 지연 시간이 길거나 패킷 손실이 발생하는 환경 등을 고려해 설계됐습니다. 연결 가능한 UDP 경로가 필요하며 안정적인 전송, 암호화 핸드셰이크, 혼잡 제어 등의 기능을 결합합니다. 1세대 Hysteria와 매개변수 및 프로토콜이 호환되지 않으므로 구독 유형을 확인해야 합니다. 노드 목록에 Hysteria라고 적혀 있는 것만으로는 충분하지 않습니다. hysteria2 유형과 서버 지원 여부를 확인하세요.

대역폭 설정은 실제 연결 경로와 서버 정책에 맞춰 이해해야 합니다. 일부 모드에서는 대역폭 추정치가 전송 동작에 영향을 주므로 실제 회선보다 훨씬 높은 값을 입력하면 처리량이 공짜로 늘어나는 대신 대기열이나 패킷 손실이 생기거나 다른 트래픽에 영향을 줄 수 있습니다. 서버에 속도 제한이 있다면 클라이언트에서 값을 높여도 이를 넘어설 수 없습니다. 먼저 제공자의 안내에 따라 기본값이나 합리적인 추정치를 사용하고, 지속 전송과 동시 웹 이용으로 안정성을 확인하세요.

TUIC: QUIC 연결과 다중화

TUIC도 QUIC을 활용하며 연결 다중화 등의 설계로 프록시 트래픽을 전달합니다. 인증 항목, 프로토콜 버전, 혼잡 제어, UDP 전달 방식이 서버와 일치해야 합니다. TUIC이라는 이름만으로 서로 다른 버전 간 호환성을 단정할 수 없습니다. 가져오기 도구가 구형 공유 링크를 변환했다면 연결 실패 후 DNS를 계속 바꾸기보다 생성된 노드 유형과 인증 항목을 확인하세요.

QUIC은 하나의 연결에서 여러 스트림을 제공합니다. 따라서 한 스트림에서 데이터가 손실되어도 같은 TCP 바이트 스트림처럼 이후의 모든 스트림 데이터가 막힐 필요는 없습니다. 다만 스트림은 여전히 연결의 혼잡 제어와 네트워크 경로를 공유합니다. 다중화가 완전한 격리를 의미하거나 모든 동시 연결에 독립적인 대역폭을 제공하는 것은 아닙니다. 모바일 기기가 네트워크를 전환할 때도 QUIC의 연결 마이그레이션 지원만으로 서비스가 끊기지 않는다고 단정할 수 없습니다. 프록시 구현, 서버 정책, 운영체제 역시 결과에 영향을 줍니다.

현재 네트워크에서 UDP 지원이 원활하지 않으면 QUIC 기반 노드의 핸드셰이크가 시간 초과되거나 연결이 간헐적으로 끊길 수 있습니다. 기기 성능 문제라고 판단하기 전에 정상 작동이 확인된 TCP 기반 방식과 비교해 보세요. 반대로 패킷 손실이 있고 UDP 경로가 안정적인 환경이라면 Hysteria2나 TUIC을 테스트해 볼 수 있지만, 결론은 실제 서비스 이용 결과를 바탕으로 내려야 합니다. 한 번의 연결 확인 결과만으로 판단하지 마세요.

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

‘어떤 프로토콜이 더 빠른가’를 판단하려면 첫 연결에 걸리는 시간, 웹페이지가 표시되기 시작하는 시점, 지속 다운로드 처리량, 백그라운드 연결 유지에 필요한 리소스를 나눠 봐야 합니다. 각 지표가 서로 다른 결과를 보일 수도 있습니다. 지속 다운로드는 빠르지만 핸드셰이크 경로가 길어 짧은 요청에는 답답한 노드가 있을 수 있고, 속도 측정 결과는 보통이어도 일상적인 웹 이용은 안정적인 노드도 있습니다. 프로토콜은 여러 변수 중 하나일 뿐이며 서버 부하와 네트워크 경로도 중요합니다.

핸드셰이크, 처리량, 실제 이용 경험을 구분하기

첫 요청에는 도메인 조회, 서버 연결, TLS 또는 QUIC 핸드셰이크, 프록시 인증, 대상 사이트 연결이 포함될 수 있습니다. 연결 재사용과 세션 재개로 이후 요청의 비용을 줄일 수 있으므로 첫 연결과 이미 연결된 상태의 테스트를 섞어서는 안 됩니다. 한 클라이언트가 백그라운드에서 미리 연결을 설정했고 다른 클라이언트는 막 실행한 상태라면 첫 웹페이지 열기만으로 비교하는 것은 공정하지 않습니다. 테스트 전에 연결을 초기화할지, 캐시를 사용할지, 다른 트래픽이 동시에 발생하는지를 정하세요.

지연 시간 측정은 대개 현재 정책을 통해 지정된 URL에 요청을 보냈을 때의 결과만 보여 줍니다. 동영상, 코드 저장소, 대용량 파일, 대화형 앱의 성능을 모두 나타내지는 않습니다. 지속 처리량은 서버의 외부 연결, 대상 사이트의 제한, 혼잡 제어, 로컬 대역폭에 영향을 받습니다. 프로토콜은 다르지만 지역이나 통신망도 서로 다른 노드를 비교하면 프로토콜 차이가 아니라 경로 차이를 측정하게 되는 경우가 많습니다.

CPU 및 메모리 사용량의 원인

암호화 알고리즘, 사용자 공간 네트워크 스택, 데이터 복사, 연결 수 모두 CPU를 사용합니다. QUIC은 일반적으로 사용자 공간에서 암호화와 전송을 처리하므로 TCP 기반 방식과 리소스 사용 양상이 다르지만, 이를 근거로 배터리를 반드시 더 많이 소모한다고 단정할 수는 없습니다. 구현 최적화, 하드웨어 성능, 데이터 양, 패킷 손실과 재전송에 따라 결과가 달라집니다. 시스템 대역폭이 이미 한계에 가까운 상황에서는 CPU 사용량 증가가 단순히 더 많은 데이터를 전송한 결과일 수도 있습니다.

메모리 사용량은 프로토콜만으로 결정되지 않습니다. 큰 규칙 집합, DNS 캐시, 연결 추적, 로그 버퍼, 그래픽 인터페이스도 영향을 줄 수 있습니다. 클라이언트 두 개를 비교할 때는 같은 설정, 규칙 집합, 비슷한 연결 수를 사용하세요. 유휴 상태의 메모리 사용량이 낮다고 해서 동시 연결이 많은 상황에서도 리소스를 적게 쓴다는 뜻은 아닙니다. 사용량이 늘어나는 원인을 찾을 때는 총량을 프로토콜 탓으로 돌리기보다 인터페이스 프로세스, 코어 프로세스, 시스템 네트워크 서비스를 구분하세요.

모바일 배터리와 백그라운드 깨우기

모바일 네트워크의 무선 모듈 작동 상태는 배터리 소모에 큰 영향을 줍니다. 잦은 하트비트, 연결 끊김 후 재접속, 백그라운드 탐색, 짧은 간격의 구독 업데이트는 무선 모듈을 계속 활성 상태로 만들 수 있습니다. 매번 전송하는 데이터가 적다고 해서 반드시 절전되는 것은 아닙니다. 연결이 안정적으로 유지되면 반복해서 연결을 새로 만드는 것보다 나을 수 있지만, 지나치게 잦은 연결 유지는 기기를 더 자주 깨웁니다. 클라이언트와 서버가 권장하는 기본 설정부터 사용하고, 임의의 공격적인 설정을 그대로 복사하기보다 시스템 배터리 기록을 확인하세요.

절전 모드, 저전력 모드, 백그라운드 권한도 측정에 영향을 줍니다. 화면이 꺼지면 시스템이 백그라운드 작업을 제한할 수 있으므로 다시 앱을 열었을 때 잠시 재연결되는 것이 반드시 프로토콜 오류는 아닙니다. iOS의 네트워크 확장과 Android의 VPN 서비스는 수명 주기도 서로 다릅니다. 배터리 소모를 비교할 때는 Wi-Fi인지 모바일 네트워크인지, 화면 상태, 이용 시간, 데이터 사용량을 기록하고 조건을 최대한 일정하게 유지한 뒤 프로토콜을 바꾸세요.

데스크톱에서는 코어 로그와 시스템 리소스 모니터를 함께 확인하고, 모바일에서는 시스템 배터리 통계를 참고하세요. 프로토콜을 바꾼 뒤 처리량이 늘었다면 실행 중의 순간적인 사용량만 볼 것이 아니라 같은 작업을 완료할 때까지의 총 배터리 소모를 비교해야 합니다. 첫 연결을 확인하는 자세한 방법은 노드 선택, 지연 시간 측정 및 프록시 작동 확인을 참고하세요. 여기에 안내된 확인 순서는 프로토콜 비교에도 사용할 수 있습니다.

DNS, Fake-IP, 규칙 매칭의 관계

DNS는 도메인에서 주소를 얻는 방식을 결정하고 규칙은 요청을 어느 정책으로 보낼지 결정하므로 서로 영향을 줍니다. 노드 핸드셰이크가 정상인데도 웹페이지가 열리지 않는다면 노드 프로토콜이 아니라 대상 도메인 조회, 규칙 적용, 앱 캐시가 원인일 수 있습니다. ‘프록시 서버 주소 조회’와 ‘실제 서비스 도메인 조회’를 먼저 구분하세요. 전자는 노드에 연결할 수 있는지, 후자는 실제 서비스 연결과 트래픽 분기 판단에 영향을 주며 두 조회가 반드시 같은 경로를 사용하는 것은 아닙니다.

Fake-IP는 도메인과 연결의 매핑 정보를 유지합니다

Fake-IP 모드에서는 앱에 매핑용 가상 주소를 반환하고, 코어가 그 주소와 도메인의 대응 관계를 저장합니다. 이후 연결을 받으면 이 매핑을 바탕으로 처리합니다. 덕분에 대상 IP만 보고 서비스 종류를 추측하는 대신 도메인 정보를 유지할 수 있습니다. 원격 웹사이트의 실제 주소를 바꾸거나 웹사이트를 로컬로 옮기는 기능은 아닙니다. 가상 주소는 코어가 연결을 식별하기 위한 중간 표식입니다.

Fake-IP 주소 풀은 보통 일반 공용 서비스 주소가 아니라 전용 테스트 주소 공간에서 가져옵니다. 앱이 조회 결과를 장기간 캐시하거나 네트워크 전환 후 이전 매핑을 계속 사용하면 연결 문제가 생길 수 있습니다. 문제를 해결할 때는 관련 앱을 재시작하고 앱의 DNS 캐시를 지운 뒤 다시 연결해 보세요. 시스템과 앱이 각각 주소 기록을 보관할 수 있으므로 브라우저 캐시만 지우는 것으로는 충분하지 않을 수 있습니다.

예외 처리와 DNS 조회 경로

일부 로컬 네트워크 검색 기능, 실제 주소가 필요한 앱, 특정 네트워크 장치는 가상 주소를 그대로 받으면 제대로 작동하지 않을 수 있습니다. 이 경우 fake-ip-filter를 사용해 해당 도메인만 예외로 지정할 수 있지만, 목록이 길수록 좋은 것은 아닙니다. 많은 도메인을 한꺼번에 제외하면 매핑을 전제로 하던 트래픽 분기 경로가 바뀌어 문제를 재현하기 어려워질 수도 있습니다. 실제로 확인된 예외만 추가하고 어떤 문제를 해결하기 위한 것인지 기록하세요.

아래 내용은 구조를 설명하기 위한 예시이며 전체 설정을 대신하지 않습니다. DNS 서비스는 로컬 루프백 주소에서만 수신하고, 확인된 암호화 DNS 주소를 조회 서버로 사용합니다. 앱의 DNS 요청이 여기에 도달하게 하려면 클라이언트가 시스템 DNS를 가로채거나 TUN의 DNS 하이재킹 같은 방식으로 요청을 유도해야 합니다. enable: true만 입력한다고 모든 앱의 DNS 조회 경로가 자동으로 바뀌지는 않습니다.

dns:
  enable: true
  listen: 127.0.0.1:1053
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  default-nameserver:
    - 1.1.1.1
  nameserver:
    - https://cloudflare-dns.com/dns-query

규칙 순서와 TUN의 범위

규칙은 일반적으로 위에서 아래 순서로 처리되며 먼저 일치하는 규칙의 정책을 적용합니다. 도메인 규칙, 규칙 집합, GEOIP, 최종 MATCH의 순서가 요청 결과에 영향을 줍니다. 범위가 넓은 규칙에 먼저 일치하면 뒤에 있는 세부 규칙은 실행되지 않습니다. 일부 규칙은 실제 IP를 조회해야 하고 다른 규칙은 도메인만으로 판단할 수 있습니다. 따라서 규칙 순서를 바꾸면 정책 이름뿐 아니라 조회 횟수와 외부 연결 경로도 달라질 수 있습니다.

TUN은 가상 네트워크 인터페이스를 통해 대상 트래픽을 처리하므로 코어로 들어오는 앱 트래픽의 범위가 넓어집니다. 하지만 모든 DNS 요청이 예상한 경로를 따른다는 보장은 없습니다. 브라우저의 자체 암호화 DNS, 앱 내 DNS 조회기, 네트워크의 다른 인터페이스를 따로 확인해야 합니다. 프로토콜 암호화는 해당 연결을 보호할 뿐이며, 시스템 전체의 DNS 경로가 일치한다는 뜻은 아닙니다. 상태를 확인할 때는 설정이 켜졌는지만 볼 것이 아니라 실제 조회와 연결 기록을 확인하세요.

Fake-IP에서 실제 주소를 반환하는 모드로 바꾼 뒤에는 영향을 받는 앱을 다시 테스트하고 이전 캐시도 확인하세요. 조회 경로를 점검하려면 DNS 테스트 및 Fake-IP 설정을 참고하세요. 매칭 순서를 조정하려면 사용자 지정 규칙 안내를 확인하세요. DNS와 규칙을 따로 검증하면 트래픽 분기 문제를 특정 프로토콜의 불안정으로 오해하지 않을 수 있습니다.

구독 형식과 설정 호환성의 한계

구독 링크는 설정을 가져오는 경로일 뿐, 응답 내용의 형식이 통일되어 있다는 뜻은 아닙니다. 전체 Clash YAML을 반환하는 링크도 있고 노드 목록만 제공하는 링크도 있습니다. 여러 줄의 공유 링크로 구성되거나 다른 코어용 JSON을 제공하는 경우도 있습니다. 클라이언트가 URL을 저장할 수 있다고 해서 응답 내용을 올바르게 해석한다는 보장은 없습니다. 가져오기에 실패하면 노드 만료나 네트워크 문제를 따지기 전에 내용의 형식과 대상 코어부터 확인하세요.

전체 설정, 노드 구독, 공유 링크

전체 설정에는 일반적으로 포트, DNS, 노드, 정책 그룹, 규칙이 포함되어 있어 가져온 뒤 독립적으로 실행할 수 있습니다. 노드 구독은 주로 연결 정보를 제공하므로 정책 그룹과 규칙을 구성할 기존 설정이 필요합니다. 단일 공유 링크는 대개 하나의 노드 정보만 담으며 전체 트래픽 분기 로직을 정의하지 않습니다. 노드 목록을 전체 설정처럼 실행하면 정책 그룹이 없을 수 있고, 전체 설정을 프록시 제공자 데이터로 읽으면 형식 오류가 날 수 있습니다.

mihomo에서 proxy-providers는 프록시 소스를 관리하고 rule-providers는 규칙 소스를 관리합니다. 두 항목은 서로 바꿔 쓸 수 없습니다. 정책 그룹에서 프록시 소스를 명시적으로 참조해야 하며 규칙에서도 해당 규칙 집합을 참조해야 합니다. 다운로드에 성공했다는 것은 원격 파일을 가져왔다는 뜻일 뿐, 내용이 올바르게 참조된다는 뜻은 아닙니다. 업데이트 후 화면에 노드가 없다면 제공자 해석이 성공했는지, 정책 그룹이 참조하는지, 이름이 정확히 일치하는지 확인하세요.

변환만으로 의미까지 완전히 옮길 수는 없습니다

형식마다 표현할 수 있는 항목이 다릅니다. 변환 도구가 기본 서버와 인증 정보는 유지하더라도 전송 옵션, REALITY 매개변수, UDP 모드, 특정 프로토콜 항목을 누락할 수 있습니다. 변환 결과가 문법 검사를 통과해도 원래 노드와 똑같이 작동한다는 보장은 없습니다. 특히 최신 프로토콜은 원본 정보를 항목별로 비교해 유형, 인증서 매개변수, 경로, 인증 방식이 기본값으로 바뀌지 않았는지 확인하세요.

구독 서비스는 요청 정보에 따라 서로 다른 형식으로 응답할 수도 있으므로 브라우저에서 확인한 내용과 클라이언트가 가져오는 내용이 다를 수 있습니다. 이 경우 URL 매개변수를 임의로 조합하기보다 제공자가 명시한 Clash 또는 mihomo 형식의 링크를 사용하세요. 원격 서버가 로그인 페이지, 오류 페이지, 기타 HTML을 반환하면 클라이언트에서 YAML 해석 오류가 발생할 수 있습니다. 이런 경우는 가져온 내용의 문제이므로 로컬 들여쓰기를 수정하지 마세요.

설정 덮어쓰기와 자동 업데이트

클라이언트는 구독 원본에 로컬 덮어쓰기, 병합 스크립트, 전역 설정을 추가할 수 있습니다. 원본 파일에 DNS 값이 하나만 적혀 있어도 실제 실행 설정은 화면에서 변경됐을 수 있습니다. 문제를 찾을 때는 구독 원본, 클라이언트가 생성한 실행 설정, 코어 로그를 구분해야 합니다. 자동으로 내려받은 파일을 직접 수정하면 다음 업데이트 때 변경 내용이 사라질 수도 있습니다. 계속 유지해야 하는 규칙은 클라이언트에서 공식 지원하는 덮어쓰기 또는 사용자 설정 메뉴에 추가하세요.

자동 업데이트 주기는 구독 내용의 변경 빈도와 모바일 백그라운드 동작을 고려해 설정하세요. 자주 업데이트한다고 안정성이 높아지는 것은 아닙니다. 원격 서버에 문제가 생기면 요청과 로그만 늘어날 수 있습니다. 업데이트에 실패하면 최근에 정상 작동한 설정을 보존하고 오류 원인을 확인하세요. 모든 파일을 바로 삭제하지 마세요. 구독 링크에는 계정 식별 정보가 포함되는 경우가 많으므로 스크린샷이나 지원 요청 로그를 공유할 때 전체 URL, 인증 정보, 개인 노드 정보를 가려 접근 권한이 노출되지 않도록 하세요.

처음 가져오기와 업데이트 방법은 구독 링크 가져오기를 참고하세요. 기존 설정을 mihomo로 옮길 때는 새 설정 항목을 만들고 기존 항목은 비교용으로 남긴 뒤 덮어쓰기 규칙을 단계적으로 복원하는 것이 좋습니다. 이렇게 하면 자동 업데이트로 수동 변경 내용이 사라지는 일을 막고, 어느 계층에서 호환되지 않는 항목이 생겼는지 더 쉽게 찾을 수 있습니다.

기기와 사용 사례에 맞는 프로토콜 선택

먼저 ‘어떤 트래픽을 처리해야 하는가’를 정한 다음 ‘서버 연결에 어떤 프로토콜을 쓸 것인가’를 선택하세요. 클라이언트 플랫폼, 권한, 서버 배포 방식, 네트워크 경로가 우선 조건입니다. 서버가 한 가지 프로토콜만 제공한다면 화면에서 다른 유형을 시도하기보다 해당 프로토콜을 클라이언트가 완전히 지원하는지 먼저 확인하세요. 실제로 선택할 수 있을 때 연결 설정 시간, 패킷 손실 대응, 배터리 소모, 관리 편의성을 비교하면 됩니다.

데스크톱 웹 이용 및 개발 도구

일반적인 웹페이지와 문서 이용은 설정이 완전하고 인증서가 올바른 TCP 기반 방식부터 사용해 볼 수 있습니다. SS, VMess, Trojan, VLESS 모두 적합할 수 있습니다. 중요한 것은 안정적인 연결 경로와 명확한 규칙입니다. 개발 도구, 패키지 관리자, 터미널 프로그램은 데스크톱 시스템 프록시를 따르지 않을 수 있으며 HTTP/SOCKS 프록시나 환경 변수를 별도로 설정해야 하는 경우도 있습니다. 브라우저는 되는데 명령줄에서 실패한다면 노드 프로토콜을 바꾸기 전에 트래픽 진입 경로를 확인하세요.

Windows와 macOS에서는 Clash Plus를 먼저 확인하고 사용 방식에 따라 Clash Verge Rev 또는 FlClash를 비교할 수 있습니다. Windows에서는 Clash Nyanpasu도 선택할 수 있습니다. 보관용 클라이언트인 Clash for Windows와 ClashX Meta는 유지 관리가 중단됐으므로 과거 호환성 자료로만 참고하는 것이 좋습니다. 이전 가이드의 익숙한 스크린샷만 보고 새 설치의 기본 선택으로 삼지는 마세요. 지원 플랫폼과 설치 안내는 클라이언트 다운로드 목록을 확인하세요.

모바일에서 일상적으로 사용하기

모바일에서는 백그라운드 연결 유지, 네트워크 전환, 배터리를 함께 고려해야 합니다. Android에서는 Clash Plus, Clash Meta for Android, FlClash, Surfboard의 설정 지원을 확인할 수 있습니다. iOS에서는 Clash Plus를 우선 살펴보고 공식 웹사이트 clashplus.io에서 제품 정보를 확인하세요. 앱마다 구독을 해석하는 방식이 다를 수 있으므로 이전할 때는 노드 수만 확인하지 말고 정책 그룹과 규칙도 다시 점검해야 합니다.

매일 모바일 네트워크와 Wi-Fi를 자주 오간다면 화면을 껐다가 켰을 때의 복구, 네트워크 전환, 백그라운드 대기를 중점적으로 테스트하세요. 화면을 켠 상태의 속도 측정만으로는 충분하지 않습니다. QUIC 기반 방식은 UDP 경로가 안정적일 때 테스트해 볼 만하지만 기본 절전 옵션으로 볼 수는 없습니다. 안정적인 TCP 연결이 더 적합한 기기도 있습니다. 필요하지 않은 잦은 탐색 기능은 끄고, 프로토콜 이름만 보고 판단하기보다 시스템 배터리 기록을 확인하세요.

패킷 손실이 큰 환경, 실시간 서비스, 리소스가 제한된 기기

패킷 손실이 뚜렷한 연결에서는 Hysteria2 또는 TUIC을 기존 TCP 기반 방식과 비교해 볼 수 있습니다. 서버 위치와 실제 작업은 최대한 동일하게 유지하고 웹 응답, 지속 전송, 동시 작업을 확인하세요. 전송 처리량이 늘어난 뒤 음성 품질이 떨어진다면 로컬 대기열이나 대역폭 경쟁이 원인일 수 있으므로 혼잡 상태와 속도 설정을 먼저 점검하세요. 게임과 음성 같은 UDP 서비스는 서버의 전달 지원, 규칙 적용 여부, 대상 경로 연결 가능성도 확인해야 합니다.

서버, 라우터, 저전력 기기에서는 대개 CPU 성능, 메모리, 장기 유지 관리가 더 중요합니다. mihomo 코어를 직접 사용할 수 있지만 서비스, 권한, 로그, 설정 업데이트를 직접 관리해야 합니다. 아키텍처가 맞아야 하며 데스크톱 설치 파일을 라우터 코어로 사용할 수는 없습니다. Linux 데스크톱에서는 시스템 연동을 직접 처리하는 부담을 줄이기 위해 Clash Verge Rev 또는 FlClash를 고려할 수 있습니다. 아키텍처별 다운로드는 다운로드 센터의 코어 섹션에서 확인하세요.

시스템 프록시와 TUN은 트래픽을 처리하는 방식의 차이이며 프로토콜의 우열로 대신 판단할 수 없습니다. 앱이 요청을 코어에 전달하지 않으면 아무리 좋은 노드도 연결에 사용되지 않습니다. 두 가지 진입 방식을 비교하려면 TUN 모드와 시스템 프록시의 차이를 참고하세요. 먼저 트래픽이 올바른 경로로 들어가는지 확인한 뒤 실제 작업의 완료 여부로 프로토콜을 선택하는 편이 단일 속도 측정 결과에만 의존하는 것보다 신뢰할 수 있습니다.

연결 확인 및 단계별 문제 해결

연결 경로를 따라 설정을 읽을 수 있는지, 앱 트래픽이 코어에 들어오는지, 어떤 정책이 적용되는지, 노드 핸드셰이크가 성공하는지, 대상 요청이 완료되는지 차례로 확인하세요. 한 번에 변수 하나만 바꾸고 원래 오류 메시지와 정상 작동 설정을 보관하세요. DNS, 프로토콜, 규칙, TUN을 한꺼번에 바꾸면 우연히 복구된 상황을 해결로 착각할 수 있고, 진짜 원인을 알 수 없으며 다음에 같은 문제를 재현하기도 어렵습니다.

설정과 로컬 진입 경로부터 확인

코어가 시작되지 않으면 먼저 맨 처음 발생한 파싱 오류와 해당 설정 항목을 확인하세요. YAML 들여쓰기, 알 수 없는 유형, 존재하지 않는 정책 그룹 참조 때문에 실행이 중단될 수 있습니다. 마지막의 ‘시작 실패’ 메시지만 보지 마세요. 독립형 mihomo 코어를 사용한다면 아래 명령으로 파일을 확인할 수 있습니다. 그래픽 클라이언트에는 대개 설정 검사나 로그 메뉴가 있으며 실제 실행 설정은 클라이언트 관리 디렉터리에 있을 수 있습니다. 처음 가져온 파일과 다를 수도 있습니다.

mihomo -t -f config.yaml

문법 검사를 통과했다면 앱에 설정된 프록시 포트와 코어가 실제로 수신하는 포트가 일치하는지 확인하세요. 설정의 mixed-port가 로컬 7890이라면 다음 명령으로 HTTP 프록시를 거치는 요청을 보낼 수 있습니다. 이 명령은 지정된 경로만 확인할 뿐 모든 앱과 트래픽이 처리된다는 뜻은 아닙니다. 로컬 포트가 다르면 실제 설정에 맞게 바꾸세요. 명령줄에는 제어 인터페이스나 DNS 포트를 입력하지 마세요.

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

규칙과 노드 핸드셰이크 확인

로그에 해당 요청이 없다면 앱의 프록시 설정, TUN 권한, 라우팅부터 확인하세요. 요청은 있지만 DIRECT로 처리됐다면 인증 정보를 바꾸기보다 규칙 순서와 정책 그룹을 확인해야 합니다. 정책 그룹에서 자동 선택을 사용하는 경우 테스트 당시 실제 선택된 노드를 기록하세요. 백그라운드 전환이 테스트를 혼란스럽게 만들 수 있습니다. 재현을 위해 정상 작동이 확인된 노드를 잠시 선택할 수 있지만 테스트가 끝나면 원래 정책으로 되돌리세요.

핸드셰이크 실패는 오류 유형별로 확인해야 합니다. 인증 오류라면 비밀번호, UUID, 프로토콜 유형을 확인하세요. 인증서 오류라면 시스템 시간, 서버 이름, 신뢰 체인을 살펴보세요. 연결 시간 초과라면 서버 주소, 포트, 네트워크 연결 가능성을 확인하세요. QUIC 기반 노드는 UDP 경로도 추가로 확인해야 합니다. ‘연결이 종료됨’처럼 모호한 메시지가 나오면 서버 설정과 전송 매개변수도 함께 살펴봐야 합니다. 로그 한 줄만으로 특정 프로토콜이 작동하지 않는다고 판단하지 마세요.

대상 서비스 문제와 네트워크 스택 문제 구분

노드 연결 확인은 되는데 특정 사이트만 열리지 않는다면 해당 도메인의 DNS 결과, 규칙 적용 여부, 대상 서비스 상태를 비교하세요. 모든 웹페이지는 정상인데 실시간 앱만 실패한다면 UDP 지원, 앱의 연결 방식, 규칙을 확인하세요. 대용량 요청이나 지속 전송에서만 문제가 생기면 경로 MTU, 패킷 손실, 동시 연결 제한을 추가로 살펴볼 수 있습니다. 이런 현상은 비교 테스트로 확인해야 하며, 시간 초과만 보고 MTU를 바꾸거나 인증서 검증을 끄지 마세요.

TUN을 켠 뒤 문제가 생기지만 HTTP 프록시 요청은 정상이라면 프로토콜 연결 경로가 적어도 일부 작동하고 있다는 뜻입니다. 권한, 라우팅, DNS 하이재킹, 다른 네트워크 프로그램과의 충돌을 확인하세요. Windows UWP 앱에는 루프백 액세스 제한이 관련될 수도 있으므로 UWP 루프백 문제를 참고하세요. 같은 트래픽을 처리하려는 도구를 여러 개 동시에 실행하면 진입 경로가 서로 경쟁해 간헐적인 오류가 생길 수 있습니다.

문제를 해결한 뒤에는 오류 로그가 사라졌는지만 볼 것이 아니라 실제 서비스 이용도 확인하세요. 웹페이지, 원래 실패했던 앱, 백그라운드 복구, 네트워크 전환을 차례로 테스트해 규칙이 예상대로 작동하는지 확인해야 합니다. 문제를 찾기 위해 필터를 느슨하게 하거나 모드를 바꾸고 자동 업데이트를 껐다면 각 설정을 하나씩 원래대로 복구하세요. 임시 설정을 계속 두면 다음 업데이트와 문제 해결이 복잡해지고 원래 필요한 트래픽 분기 동작이 달라질 수 있습니다.

이 페이지의 최종 판단 기준은 연결 경로를 설명할 수 있고 설정의 출처를 추적할 수 있으며 기능의 한계가 분명한지 여부입니다. 처음 연결할 때는 사용 가이드를 참고하고, 자주 묻는 내용은 FAQ에서 확인하세요. 프로토콜 선택은 이름 하나를 고르는 일이 아닙니다. 코어 지원, 서버 설정, 실제 네트워크 조건에 맞는 조합을 찾아 검증하는 과정입니다.