Clash 프로토콜·코어 선택 가이드

프로토콜·전송 방식·코어의 역할

클라이언트 화면이 곧 프로토콜 구현은 아닙니다

Clash에서 연결 항목 하나를 보면 실제로는 여러 계층이 관여합니다. 프로토콜은 인증 방식, 대상 주소의 표현, 데이터 캡슐화 방식을 정합니다. 전송 방식은 TCP, WebSocket 등의 통로로 데이터를 전달하고, TLS 같은 보안 계층은 암호화와 서버 인증을 담당합니다. 이 세 요소가 하나의 공유 링크에 함께 담기는 경우가 많지만, 서로 같은 개념은 아닙니다. VLESS라는 이름만 보고 TLS가 활성화됐거나 어떤 전송 방식을 사용하는지 단정할 수 없습니다.

그래픽 클라이언트는 구독 관리, 트레이 메뉴, 시스템 프록시, 설정 편집을 담당하고, 코어는 연결 수립, 규칙 매칭, DNS, 데이터 전달을 처리합니다. 화면에 특정 프로토콜이 표시된다고 해서 포함된 코어가 모든 확장 기능을 지원하는 것은 아닙니다. 코어가 매개변수를 인식하더라도 편집기에서 해당 값을 온전히 저장하지 못할 수도 있습니다. 호환성을 판단할 때는 설치 파일 이름만 보지 말고 클라이언트 설명, 실제 실행 중인 코어, 코어에 전달되는 최종 설정을 함께 확인하세요.

기존 Clash, Meta, mihomo의 관계

기존 Clash는 프록시 항목, 그룹, 규칙, 설정 파일을 사용하는 기본 방식을 마련했습니다. Clash.Meta는 이 생태계에서 프로토콜과 네트워크 기능을 확장했고, 이후 mihomo라는 이름으로 발전을 이어갔습니다. 따라서 이전 자료의 Meta 코어와 현재 mihomo 자료는 상당 부분 이어져 있지만, 모든 과거 설정을 그대로 사용할 수 있다는 뜻은 아닙니다. 기능이 추가된 시점, 필드 이름 변경, 기본 동작 조정 여부는 실제 코어 문서를 확인해야 합니다.

기존 오픈소스 코어, 과거 Premium 브랜치, 이후 파생 코어를 구분하는 것도 중요합니다. 오래된 가이드에 나오는 스크립트, 규칙 제공자, 가상 네트워크 어댑터 기능은 서로 다른 브랜치를 대상으로 할 수 있습니다. 'Clash 설정'이라는 이유만으로 그대로 가져오지 마세요. 마이그레이션할 때는 먼저 프록시 항목과 단순한 그룹만 유지하고, DNS, 규칙 세트, TUN을 차례로 복원하세요. 고급 필드를 한꺼번에 추가하면 파싱 오류와 실행 동작 변화가 겹쳐 원인을 찾기 어렵습니다.

기능부터 확인한 뒤 인터페이스를 비교하세요

Windows를 처음 사용하는 경우 다운로드 페이지에서 우선 추천하는 Clash Plus부터 시작하고, 설정에 따라 Clash Verge Rev, FlClash, Clash Nyanpasu를 비교해 보세요. 클라이언트를 고를 때는 구독을 가져올 수 있는지, 필요한 프로토콜이 실행되는지, 시스템 프록시와 서비스 모드를 쉽게 관리할 수 있는지 먼저 확인하세요. 두 클라이언트가 같은 링크를 가져올 수 있다고 해서 DNS, 오버라이드 순서, TUN 동작까지 완전히 같다고 볼 수는 없습니다.

지원이 종료된 클라이언트는 더욱 신중하게 다뤄야 합니다. Clash for Windows는 더 이상 유지 관리되지 않습니다. 기존 환경을 보존하거나 과거 설정을 확인할 때는 참고할 수 있지만, 새 프로토콜 지원 여부를 판단하는 용도로는 적합하지 않습니다. 코어를 교체하는 방법도 범용 업그레이드가 아닙니다. 클라이언트가 특정 제어 인터페이스, 실행 인자, 디렉터리 구조에 의존할 수 있습니다. 명확한 코어 관리 기능이 없다면 실행 파일을 직접 덮어쓰지 말고 지원되는 업데이트 방법을 이용하세요.

SS와 VMess: 암호화 캡슐화와 연결 구성

SS의 간결한 구조와 방식 호환성

Shadowsocks는 보통 SS라고 부르며, 비교적 단순한 암호화 프록시 캡슐화를 중심으로 설계됐습니다. 클라이언트와 서버는 서버 주소, 포트, 암호화 방식, 키 정보를 합의한 뒤 대상 연결을 전달합니다. 모든 연결을 웹 요청처럼 보이게 만들거나 완전한 인증서 체계를 덧붙이지 않아도 되므로, 설정이 단순하고 양쪽의 기능이 명확한 환경에서 관리하기 쉽습니다. 하지만 구조가 간단하다고 아무 조합이나 연결되는 것은 아닙니다. 암호화 방식이 서로 다르면 초기 단계에서 바로 실패합니다.

설정을 볼 때는 먼저 cipher와 password를 확인하세요. 기존 AEAD 방식과 Shadowsocks 2022 계열은 키를 정하는 방식이 다릅니다. 후자는 키 길이와 표현 형식이 정해져 있어 일반적인 짧은 비밀번호를 그대로 입력할 수 없습니다. 서버에서 받은 공유 링크에 특수 문자가 있다면 원래 인코딩을 유지하세요. 직접 나눠 복사하는 과정에서 공백이 들어가거나 잘못 디코딩되거나 접미사가 빠지면 포트에는 연결되지만 통신은 완료되지 않을 수 있습니다.

일부 SS 항목은 플러그인에 의존합니다. 플러그인은 추가 전송 방식이나 캡슐화를 담당하며, SS 핵심 프로토콜의 필수 구성 요소는 아닙니다. 코어가 특정 암호화 방식을 지원하더라도 공유 링크에 필요한 플러그인과 옵션까지 지원한다는 뜻은 아닙니다. 문제를 확인할 때는 서버, 암호화 방식, 플러그인 이름, 플러그인 매개변수를 각각 점검하세요. 설정 오류를 없애려고 플러그인 필드를 지우면 대개 문제가 파싱 단계에서 핸드셰이크 단계로 옮겨갈 뿐입니다.

VMess의 인증과 과거 옵션

VMess는 V2Ray 생태계에서 나온 프로토콜로, 사용자 식별자와 요청 인증, 데이터 암호화 메커니즘을 결합합니다. 일반적인 설정에서는 UUID로 사용자를 식별합니다. 단순한 TCP 연결로 실행할 수도 있고 WebSocket, TLS 등과 조합할 수도 있습니다. 실제 비용은 전체 조합에 따라 달라집니다. 일반 TCP 항목과 TLS·WebSocket을 추가한 항목을 비교한다면, 차이를 모두 VMess 프로토콜 자체의 탓으로 돌릴 수 없습니다.

오래된 자료에는 alterId가 자주 등장합니다. 이는 과거 호환성을 위한 항목이므로 오래된 가이드를 따라 임의로 값을 입력하지 마세요. 최신 AEAD 사용 방식에서는 보통 0을 사용하지만, 최종적으로는 서버 설정과 일치해야 합니다. 시스템 시간도 확인할 필요가 있습니다. 시간 범위에 영향을 받는 인증 방식은 시계가 크게 어긋나면 실패할 수 있습니다. Windows가 절전 모드에서 복귀한 뒤, 가상 머신을 일시 중지한 뒤, 시간을 수동으로 바꾼 뒤 문제가 생겼다면 UUID를 계속 바꾸기보다 먼저 시스템 시각을 동기화하세요.

전송 매개변수는 서로의 관계를 파악해 설정해야 합니다. WebSocket 경로, 요청 Host, TLS 서버 이름은 같을 수도 있고 각기 다른 역할을 할 수도 있습니다. 경로가 잘못되면 원격 서버가 일반 웹 페이지를 반환하거나 업그레이드 연결을 거부할 수 있으며, 명확한 '프로토콜 매개변수 오류'가 표시되지 않을 수도 있습니다. 서버가 제공한 전체 매개변수를 기준으로 설정하세요. 도메인 하나를 모든 필드에 복사하거나 브라우저에서 해당 도메인이 열린다는 이유로 프록시 핸드셰이크가 정상이라고 판단하지 마세요.

두 프로토콜 중 무엇을 선택할까요?

이미 안정적으로 작동하는 SS 설정이 있고 웹, 코드 저장소, 일상적인 앱이 주 사용처라면 다른 프로토콜의 이름이 더 최신이라는 이유만으로 옮길 필요는 없습니다. SS는 매개변수가 적어 오류를 찾기 쉽지만, 플러그인과 새로운 암호화 방식을 추가하면 호환 조건이 늘어납니다. VMess는 기존 V2Ray 설정 체계를 이어서 사용하고 전송 방식과 조합할 수 있다는 장점이 있습니다. 대신 서로 연관된 필드를 더 많이 관리해야 합니다.

UDP는 별도로 검증해야 합니다. 한 항목으로 웹 페이지가 열린다는 것은 해당 TCP 경로가 작동한다는 뜻일 뿐, 게임 음성, 실시간 통신, 기타 UDP 트래픽까지 전달된다는 증거는 아닙니다. 프로토콜 구현, 서버 설정, 설정 파일의 UDP 옵션, 앱 트래픽이 실제 클라이언트로 들어오는지 모두 확인하세요. 테스트할 때 같은 네트워크, 같은 대상, 같은 트래픽 처리 방식을 유지해야 프로토콜 기능과 로컬 라우팅 차이를 구분할 수 있습니다.

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

Trojan에서 올바른 TLS 설정이 중요한 이유

Trojan은 일반적으로 TLS를 통해 프록시 요청을 전달하고, 보안 연결 안에서 비밀번호 인증과 대상 전달을 처리합니다. 검증된 TLS 기능을 중요한 기반으로 삼으므로 인증서 검증은 선택 사항이 아닙니다. 설정의 서버 주소에는 IP를 입력해도 되지만, 인증서는 보통 도메인 이름에 발급됩니다. 이때 연결 주소와 TLS 서버 이름의 역할을 구분해야 합니다. 모든 필드에 똑같은 문자열을 입력해야 하는 것은 아닙니다.

클라이언트는 TLS 연결을 수립할 때 인증서 체인의 신뢰 여부, 유효 기간, 이름 일치 여부를 확인합니다. 어느 한 단계라도 실패하면 이후 Trojan 인증이 진행되지 않을 수 있습니다. 인증서 오류가 발생하면 먼저 도메인, 시스템 시간, 서버 인증서 설정을 확인하세요. 검증 생략을 계속 켜 두면 원격 서버의 신원을 확인하기 어려워지고 잘못된 서버에 연결된 문제를 놓칠 수도 있습니다. 일시적인 점검과 장기 설정은 분명히 구분해야 합니다.

비밀번호가 맞아도 전송 방식이 일치한다는 보장은 없습니다. 어떤 서버는 직접 TLS를 사용하고, 다른 서버는 WebSocket이나 별도의 전송 방식을 추가합니다. 클라이언트도 실제 조합에 맞게 설정해야 합니다. 서버는 직접 TLS만 받는데 로컬에서 WebSocket 경로를 추가했다면 비밀번호가 맞더라도 자동으로 연결이 협상되지는 않습니다. 구독을 가져온 뒤에는 변환 도구가 네트워크 유형을 유지했는지, 현재 코어가 관련 확장 기능을 인식하는지 확인하세요.

VLESS의 간소한 인증이 완전한 암호화를 뜻하지는 않습니다

VLESS도 V2Ray 관련 생태계에서 나왔으며, 프로토콜 자체의 일부 오버헤드를 줄이고 보안 보호를 외부 전송 계층에 더 많이 맡기는 구조입니다. 일반적으로 UUID로 사용자를 식별하고 TLS 또는 지원되는 다른 보안 메커니즘을 함께 사용합니다. 여기서 중요한 점은 VLESS라는 이름만으로 연결이 암호화됐다고 보장할 수 없다는 것입니다. 실제 보안 계층과 전송 매개변수를 확인하세요. 클라이언트에 표시된 프로토콜 이름만으로 연결 보호 방식을 판단하지 마세요.

VLESS 호환 문제는 특정 flow, 전송 유형, REALITY 관련 필드 등 확장 조합에서 자주 발생합니다. 기본 VLESS 프로토콜을 지원한다고 해서 모든 확장 기능이나 임의 조합까지 지원하는 것은 아닙니다. 특정 흐름 제어 옵션은 정해진 전송 방식 및 보안 조합에서만 사용할 수 있습니다. 다른 곳에서 본 매개변수를 설정에 그대로 추가하면 파서는 통과해도 연결 단계에서 실패할 수 있습니다. 서버와 합의한 설정 및 현재 코어의 지원 범위를 기준으로 하세요.

REALITY를 단순히 '서버 이름만 바꾸는 것'으로 이해해서는 안 됩니다. 연결에는 공개 키, 짧은 ID, 기타 협상 매개변수가 포함되며 클라이언트와 서버의 값이 일치해야 합니다. 공개 키는 정확하게 전달해야 하는 설정 정보이지, 사용자가 임의의 문자열을 만들어 입력하는 값이 아닙니다. 구독을 가져왔을 때 내용이 빠져 있다면 현재 클라이언트에 맞는 구독을 다시 받거나 원본 설정을 항목별로 확인하세요. 화면 검사를 통과하려고 누락된 필드에 임의의 값을 채우지 마세요.

도메인 필드는 각각 어떤 역할을 할까요?

서버 주소는 데이터 패킷을 보낼 곳을 정하고, TLS의 SNI는 핸드셰이크에서 이름을 전달합니다. 인증서 검증 이름은 서버 신원을 확인하며, HTTP Host는 애플리케이션 계층 요청에 속합니다. 단순한 구성에서는 이 값들이 같은 경우가 많지만 개념적으로는 별개입니다. 문제를 찾을 때 모든 도메인을 '열리는 사이트' 하나로 바꾸기보다 각 값의 출처를 기록하고 서버 요구 사항에 맞는지 확인하는 편이 정확합니다.

Trojan과 VLESS 중에서 고를 때는 먼저 현재 서버가 지원하는 방식과 설정의 완성도를 따져야 합니다. 서버가 표준 Trojan TLS 매개변수를 제공하고 인증서 관리가 명확하다면 일반적인 TLS 절차에 따라 확인하기 쉽습니다. 서버가 VLESS의 특정 확장 기능을 요구한다면 해당 조합을 지원하는 것으로 확인된 클라이언트와 코어를 선택하세요. 설정 필드 몇 개를 줄이려고 보안 계층을 제거하지 말고, 새 기능을 사용하려고 안정적인 설정에 불필요한 확장을 덧붙이지도 마세요.

Hysteria2와 TUIC: QUIC 기반 프로토콜의 선택 기준

QUIC의 변화와 전제 조건

QUIC은 UDP 위에서 보안 연결, 다중화, 혼잡 제어 등의 기능을 제공합니다. 여러 논리 스트림이 하나의 TCP 연결을 공유하는 경우와 비교하면, QUIC은 한 스트림의 데이터 손실이 전송 계층에서 다른 독립 스트림까지 직접 막는 상황을 피할 수 있습니다. 다만 각 스트림 내부의 데이터 손실은 여전히 처리해야 합니다. 패킷 손실을 없애거나 제한된 대역폭을 늘려 주는 것은 아닙니다. 관련 프로토콜을 검토하기에 앞서 네트워크에서 UDP 통신이 지속적으로 가능한지 확인해야 합니다.

Hysteria2와 TUIC은 모두 QUIC을 활용하지만 서로 바꿔 쓸 수 있는 같은 프로토콜은 아닙니다. 인증 방식, UDP 전달 구조, 혼잡 제어 옵션, 세부 매개변수가 다릅니다. 서버가 둘 중 하나를 사용한다면 클라이언트에서 프로토콜 유형만 바꾸고 나머지 필드를 그대로 써서는 안 됩니다. 이전 Hysteria 설정을 Hysteria2 설정으로 간주하지 마세요. 두 프로토콜은 설정과 동작에 명확한 차이가 있습니다.

Hysteria2의 대역폭 추정과 전송 동작

Hysteria2는 지연이 크거나 패킷 손실이 있는 복잡한 경로의 전송 성능을 고려해 설계됐으며, 대역폭 설정 및 혼잡 제어와 관련된 기능을 제공합니다. 설정의 업로드·다운로드 대역폭은 속도 측정 결과를 표시하는 값이 아니라 실제 전송 전략에 반영될 수 있습니다. 실제 회선 용량을 크게 웃도는 값을 입력해도 속도가 빨라지지는 않습니다. 오히려 큐가 쌓이고 패킷 손실과 응답 지연이 늘어날 수 있습니다. 현재 구현 문서, 서버 제한, 실제 회선 성능을 기준으로 대역폭을 설정하세요.

일부 구현은 대역폭 설정이나 협상 조건에 따라 다른 혼잡 제어 동작을 선택할 수 있습니다. 따라서 '비워 두면 항상 빠르다'거나 '최댓값을 입력하면 항상 빠르다'고 볼 수 없습니다. 공유 네트워크에서는 다른 사용자와 앱도 업로드 큐를 함께 사용합니다. 다운로드 용량이 충분해도 업로드가 꽉 차면 확인 응답과 상호작용에 영향을 줍니다. 테스트할 때는 대용량 파일 다운로드의 일시적인 최고 속도만 보지 말고 웹 응답, 음성 안정성, 지속 전송을 함께 확인하세요.

포트 호핑, 난독화, 기타 선택 기능도 서버 측 지원이 필요합니다. 기능을 켠 뒤 로컬 방화벽, 네트워크 장비, 서버 규칙에서 해당 UDP 포트 범위를 허용하지 않으면 연결이 간헐적으로 수립됐다가 끊길 수 있습니다. 이런 기능은 성능 문제를 해결하는 만능 스위치가 아닙니다. 기본 연결이 안정적이지 않다면 서버에서 작동이 확인된 단순한 설정부터 사용하고 추가 옵션을 하나씩 복원하세요.

TUIC의 연결 재사용과 UDP 처리

TUIC도 QUIC 전송으로 프록시 트래픽을 처리하는 데 중점을 두며, 일반적으로 UUID, 비밀번호, 혼잡 제어, UDP 릴레이 모드를 설정합니다. 프로토콜 버전이 다르다고 서로 호환되는 것은 아닙니다. 구독 변환 과정에서 유형 이름만 남고 인증 정보가 빠지면 가져오기는 성공해도 연결할 수 없습니다. UDP 릴레이 모드는 데이터그램을 전달하는 방식에 영향을 주므로 클라이언트와 서버가 같은 동작을 지원하는지 확인하세요. 온라인에서 본 모드 이름을 모든 환경에 적용되는 정답으로 여기지 마세요.

0-RTT 관련 옵션은 조건이 맞으면 연결 복구 대기 시간을 줄일 수 있지만, 첫 연결을 항상 빠르게 해 주는 기능은 아닙니다. 세션 복구, 보안상의 선택, 서버 지원이 관련됩니다. 프로토콜 라이브러리가 기능을 제공하더라도 애플리케이션이 항상 사용하는 것은 아닙니다. 일반 사용자라면 지연 시간 옵션을 전부 켜기보다 인증서, 인증 정보, 적절한 유휴 시간 제한을 먼저 점검하는 편이 좋습니다.

네트워크에서 UDP를 많이 제한한다면 Hysteria2와 TUIC이 유일한 연결 수단으로 적합하지 않을 수 있습니다. 검증된 TCP 기반 항목을 비교 대상으로 남겨 두면 서버 문제와 접속 네트워크 제한을 구분하는 데 도움이 됩니다. Wi-Fi와 모바일 네트워크를 바꾼 뒤에는 다시 검증하세요. 두 네트워크는 UDP 유휴 매핑, 경로 MTU, 혼잡 상태가 다를 수 있습니다. 사무실에서의 테스트 결과를 출퇴근 환경에 그대로 적용할 수는 없습니다.

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

'빠르다'를 비교 가능한 지표로 나누기

연결 속도는 적어도 세 가지로 나눠 봐야 합니다. 새 연결을 수립하는 데 걸리는 시간, 요청에 응답하는 시간, 장시간 전송 시 처리량입니다. 핸드셰이크 대기 시간을 줄이는 프로토콜이 대용량 파일 다운로드 속도까지 높인다는 뜻은 아닙니다. 지속 전송에 적합한 설정이 짧은 요청에는 더 오래 걸릴 수도 있습니다. 클라이언트에 표시되는 지연 시간은 특정 테스트 주소와 방식의 결과일 뿐, 모든 앱의 왕복 시간이나 웹 페이지의 전체 로딩 시간을 나타내지 않습니다.

결과에는 로컬 접속 환경, 서버 부하, 대상 사이트 응답, 경로 라우팅, 암호화 구현, 전송 캡슐화 등이 영향을 줍니다. 프로토콜을 비교할 때는 같은 기기와 네트워크, 비슷한 위치의 서버, 같은 대상을 사용하세요. 서로 다른 지역과 대역폭의 서버를 이용하는 두 설정을 비교하면 차이는 우선 전체 연결 경로를 반영하며 프로토콜의 우열을 의미하지 않습니다. 조건을 통제하기 어렵다면 성능 순위를 매기기보다 '현재 환경에 더 적합한 설정'이라고 기록하는 편이 정확합니다.

CPU와 메모리는 프로토콜 이름만으로 판단할 수 없습니다

암호화 알고리즘이 프로세서 명령어를 활용할 수 있는지에 따라 실제 CPU 사용량이 달라집니다. 사용자 공간 네트워크 스택, TUN, 규칙 세트 규모, 연결 수도 리소스 사용량에 영향을 줍니다. Windows 작업 관리자에서 보이는 클라이언트 프로세스에는 화면만 포함되고, 실제 전송을 담당하는 코어는 다른 프로세스일 수 있습니다. 화면 프로세스의 사용량이 낮다고 전체 프록시 경로가 리소스를 거의 쓰지 않는다고 단정하지 말고 관련 프로세스를 함께 살펴보세요.

연결 재사용은 반복적인 연결 수립과 핸드셰이크를 줄여 주지만 연결 수명 관리가 복잡해질 수 있습니다. 짧은 요청이 많은 환경에서는 도움이 될 수 있지만 장시간 연결 몇 개만 사용하는 경우에는 차이가 크지 않을 수도 있습니다. 규칙 제공자 업데이트, 구독 새로고침, 연결 로그, 잦은 속도 테스트도 백그라운드 작업을 발생시킵니다. 사용량이 비정상적으로 높다면 먼저 잦은 속도 테스트와 상세 로그를 중지하고 유휴 상태와 전송 중 상태를 관찰하세요. 모든 백그라운드 작업이 동시에 실행되는 상황에서 사용량을 특정 프로토콜 탓으로 돌리지 마세요.

휴대폰 배터리는 무선 연결의 활성화와 유지 시간에 더 크게 좌우됩니다

모바일 기기에서는 연산 비용뿐 아니라 무선 모듈이 깨어나고 활성 상태를 유지하는 시간도 고려해야 합니다. 지나치게 잦은 연결 유지 신호, 짧은 간격의 상태 확인, 반복적인 재연결은 무선 모듈의 작동 시간을 늘릴 수 있습니다. TCP나 QUIC 자체만으로 어느 쪽이 더 절전이라고 단정할 수는 없습니다. 신호가 약한 환경에서 계속 재전송하는 연결은 신호가 안정적인 다른 프로토콜보다 전력을 더 쓸 수 있습니다. 백그라운드 앱 수, 시스템 절전 설정, 네트워크 전환도 결과에 영향을 줍니다.

실제로 비교할 때는 읽기, 동영상 시청, 음성 통화 등 일정한 작업을 정하고 화면 밝기와 네트워크 조건을 비슷하게 유지한 채 배터리, 온도, 연결 끊김을 반복 관찰하세요. 테스트 전에 대규모 자동 속도 측정을 중지해 테스트 트래픽이 일반 사용량에 포함되지 않도록 하세요. 대기 중 배터리 소모가 크다면 연결 유지 간격, 상태 확인 빈도, 반복 재연결 로그부터 확인하세요. 대용량 전송 때만 발열이 심하다면 처리량, CPU, 암호화 구현을 살펴보고 유휴 상태의 소비와 작업 부하를 구분하세요.

일상적인 사용에서는 최고 속도만 좇기보다 충분히 빠르고 안정적인 연결을 선택하세요. 노트북은 전원 연결과 배터리 사용 상태를 나눠 관찰하고, 휴대폰은 Wi-Fi와 모바일 네트워크를 따로 기록하세요. 테스트 조건과 결과를 함께 적고 복구할 수 있도록 설정을 보관하세요. 클라이언트 테스트 항목을 더 자세히 알고 싶다면 노드 지연 시간 및 확인 절차를 참고하세요. 테스트 실패를 모든 서비스의 사용 불가로 단정하지 않는 데 도움이 됩니다.

설정 파일, 구독 형식, 매개변수 호환성

공유 링크, 노드 목록, 전체 설정

구독 링크는 콘텐츠를 가져오는 진입점일 뿐입니다. 응답 내용은 완전한 Clash YAML, 인코딩된 공유 링크 모음, 특정 앱 전용 설정 형식일 수 있습니다. 파일 확장자나 웹 페이지 제목만으로 형식을 확실히 판단할 수 없으므로 클라이언트의 인식 결과와 서비스 제공자의 안내를 확인하세요. 전체 설정에는 일반적으로 프록시 항목, 그룹, 규칙이 함께 들어 있습니다. 노드 목록에는 연결 정보만 있고 나머지 구조는 클라이언트 템플릿이 보충할 수 있으므로, 가져온 뒤의 동작도 서로 다릅니다.

공유 링크 하나를 인식한다고 해서 모든 고급 매개변수까지 복원되는 것은 아닙니다. 변환 도구가 전송 확장, UDP 모드, 클라이언트 지문, 보안 계층 필드를 빠뜨릴 수 있으며 대상 형식에 대응 항목이 아예 없을 수도 있습니다. '가져오기는 됐지만 이름만 보이고 계속 연결되지 않는' 경우에는 같은 구독을 반복해서 새로고침하기보다 주요 필드가 온전히 남아 있는지 먼저 확인하세요. 계정 접근 권한이 포함된 구독 주소는 안전하게 보관하고 신뢰할 수 없는 온라인 변환 도구에 입력하지 마세요.

YAML 문법과 설정 의미를 따로 확인하세요

YAML에서는 들여쓰기가 계층을 결정하므로 공백을 사용하고 탭 문자는 섞지 마세요. 콜론, 샵 기호 또는 특수 문자가 포함된 값은 구조나 주석으로 해석되지 않도록 적절한 따옴표로 감쌀 수 있습니다. 문법 검사를 통과해도 파일을 읽을 수 있다는 뜻일 뿐, 프록시 그룹 이름이 존재하거나 규칙 대상이 올바르거나 프로토콜 매개변수가 유효하다는 보장은 없습니다. 예를 들어 존재하지 않는 그룹을 참조하는 규칙은 로드 단계에서 오류를 일으키거나 예상한 라우팅을 하지 않을 수 있습니다.

아래는 mihomo에서 읽을 수 있는 최소한의 직접 연결 점검 설정입니다. 로컬 리스닝, 그룹, 규칙 구조를 확인하기 위한 것으로 원격 프록시 연결은 포함하지 않습니다. 원격 프록시 기능을 제공하지 않으며 특정 프로토콜의 성능 테스트에도 사용할 수 없습니다. 별도의 테스트 설정을 사용할 때는 현재 파일을 먼저 백업하세요. 클라이언트가 포트나 DNS 설정을 자동으로 병합한다면 편집 창의 내용만 보지 말고 최종 적용된 설정을 화면에서 확인해야 합니다.

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

proxy-groups:
  - name: ROUTE
    type: select
    proxies:
      - DIRECT

rules:
  - MATCH,ROUTE

여기서 mixed-port는 앱이 로컬 클라이언트에 연결하는 진입점이며 원격 서버 포트가 아닙니다. allow-lan: false는 로컬 네트워크의 접근을 제한해 같은 기기에서 점검할 때 적합합니다. MATCH는 앞선 규칙에 일치하지 않은 연결을 지정된 대상으로 보내는 최종 규칙입니다. 로컬 혼합 포트와 서버 포트를 혼동하는 일은 설정을 옮길 때 자주 발생하므로 점검 목록에 각각 따로 기록하세요.

오버라이드, 제공자, 규칙 순서

그래픽 클라이언트는 구독에 전역 오버라이드, 스크립트 처리, 설정 병합을 적용할 수 있습니다. 따라서 다운로드한 원본 파일과 코어가 실제로 사용하는 파일이 항상 같지는 않습니다. 구독 캐시를 직접 수정해도 다음 업데이트 때 덮어써질 수 있습니다. 안정적으로 관리하려면 클라이언트에서 지원하는 위치에 오버라이드를 저장하고 적용 순서를 확인하세요. 프로토콜 인증 정보와 서버 매개변수는 공통 템플릿이 개별 연결 전용 필드를 실수로 덮어쓰지 않도록 주의해야 합니다.

proxy-providers와 rule-providers는 각각 프록시 목록과 규칙 목록을 관리합니다. 둘 다 원격 파일을 가져오지만 내용 구조와 참조 방식이 달라 서로 바꿔 쓸 수 없습니다. 규칙은 보통 순서대로 매칭되므로 범위가 넓은 규칙이 앞에 있으면 뒤의 세부 규칙이 적용되지 않을 수 있습니다. 설정을 옮긴 뒤에는 프록시 목록의 개수만 비슷한지 확인하지 말고 그룹 이름, 제공자 참조, 최종 대상도 점검하세요.

구독 업데이트에 실패하면 먼저 접근 실패, 인증 만료, 잘못된 응답 내용, 미지원 형식을 구분하세요. 관련 절차는 구독 업데이트 실패 및 자동 업데이트 설정을 참고하세요. 다시 가져와야 한다면 구독 가져오기 가이드를 확인하세요. 별도의 설정에서 먼저 검증한 뒤 규칙과 오버라이드를 옮기면 형식 문제와 기존 환경 문제를 함께 겪는 일을 줄일 수 있습니다.

사용 환경에 맞는 프로토콜과 클라이언트 선택

웹, 개발 도구, 일상 업무

브라우저, 문서 사이트, 일반적인 개발 서비스는 대체로 안정적인 TCP 연결이 우선입니다. 기존 SS, Trojan, VMess, VLESS 설정으로 필요한 작업을 할 수 있다면 프로토콜 이름만 바꾸기보다 연결 안정성, 인증서 관리, 구독 유지 방법을 먼저 점검하세요. Windows 클라이언트를 처음 선택한다면 Clash Plus부터 시작할 수 있습니다. 설치 항목은 Windows 클라이언트 목록에서 확인하고 업무 방식에 맞춰 다른 지원 클라이언트와 비교하세요.

명령줄 도구는 시스템 프록시를 따르지 않을 수 있습니다. 브라우저에서는 접속되는데 터미널에서 실패한다면 터미널에 프록시 환경 변수가 설정되지 않았거나 도구 자체의 프록시 옵션만 인식하는 경우가 있습니다. 이때 원격 프로토콜을 바꿔도 해결되지 않습니다. 먼저 앱 트래픽이 클라이언트로 들어가는 방식을 확인하고 명시적 프록시와 TUN 중에서 선택하세요. 개발 환경에서는 컨테이너, 가상 머신, 호스트의 루프백 주소가 서로 다르다는 점도 유의해야 합니다. 컨테이너 안의 로컬 주소가 자동으로 Windows 호스트를 가리키지는 않습니다.

실시간 통신, 게임, 복잡한 네트워크

음성 통화와 실시간 상호작용은 평균 지연 시간뿐 아니라 지터, 패킷 손실, 연결 지속성이 중요합니다. 앱은 TCP 로그인과 UDP 미디어 스트림을 함께 사용할 수 있으므로 '로그인은 되지만 소리가 들리지 않는' 문제와 '아예 연결되지 않는' 문제는 서로 다른 경로에서 발생합니다. 프로토콜이 해당 UDP 트래픽을 전달해야 하고 트래픽 처리 방식이 앱의 통신을 포함해야 합니다. 일부 앱은 시스템 프록시를 우회해 직접 연결하기도 하므로 연결 목록과 규칙 적용 여부를 확인하세요.

지연이 크거나 패킷 손실이 있는 경로라면 Hysteria2와 TUIC을 후보에 추가하되 TCP 기반 연결도 비교 대상으로 남겨 두세요. 현재 네트워크에서 QUIC 기반 연결을 안정적으로 수립할 수 없다면 혼잡 제어 매개변수를 계속 바꿔도 효과가 제한적입니다. 반대로 UDP 연결이 가능하고 장기간 더 안정적이라면 기존의 일반적인 의견만으로 제외할 필요는 없습니다. 결론은 구체적인 접속 환경에 맞춰야 하며 네트워크가 바뀌면 선택을 다시 검토할 수 있습니다.

여러 기기 및 장기 유지 관리

휴대폰과 데스크톱에서 같은 구독을 사용한다면 데스크톱에서 쓸 수 있는 확장 기능을 휴대폰도 지원한다고 가정하지 말고, 모든 대상 클라이언트가 공통으로 지원하는 기능을 기준으로 삼으세요. Android에서는 필요에 따라 Clash Plus, Clash Meta for Android, FlClash, Surfboard를 비교할 수 있습니다. iOS에서는 다운로드 페이지에서 Clash Plus의 스토어 페이지로 이동할 수 있습니다. 클라이언트 이름이 다르다고 반드시 프로토콜 호환성이 달라지는 것은 아니지만, 설정 형식, 네트워크 확장 기능, 백그라운드 동작은 각각 확인해야 합니다.

macOS 사용자는 칩 아키텍처에 맞는 설치 파일을 선택해야 하며, Linux에서는 그래픽 클라이언트와 코어를 직접 실행하는 배포 방식을 구분해야 합니다. 데스크톱 클라이언트는 Clash Verge Rev와 FlClash를 비교할 수 있고, 서버 환경에서는 설정 디렉터리, 권한, 프로세스 서비스를 명확히 관리하는 편이 적합합니다. Linux mihomo 배포 및 systemd 서비스 설정도 참고하세요. 시스템 서비스가 안정적으로 실행된다고 해서 데스크톱 앱이 자동으로 프록시를 사용하는 것은 아닙니다.

장기 유지 관리를 위해 검증된 기본 설정과 간단한 변경 기록을 보관하면 유용합니다. 클라이언트 업데이트, 코어 교체, 구독 이전, TUN 활성화는 가능한 한 따로 진행하세요. 각 단계마다 브라우저, 터미널, 필요한 UDP 앱이 정상인지 확인한 뒤 다음 단계로 넘어가세요. 이렇게 하면 문제가 다시 발생했을 때 프로토콜, 규칙, 시스템 설정이 한꺼번에 바뀐 상태에서 원인을 찾는 대신 명확한 시점으로 되돌릴 수 있습니다.

프로토콜 연결 실패 단계별 점검

실패 단계를 찾은 뒤 매개변수를 수정하세요

문제 해결은 실패한 요청 하나를 기준으로 시작하세요. 앱, 대상, 사용한 설정, 발생 시각을 기록한 뒤 해당 로그를 확인합니다. 설정 로드 실패, 원격 연결 실패, 핸드셰이크 인증 실패, 실제 요청 시간 초과는 서로 다른 단계의 문제입니다. 시간 초과만 보고 프로토콜을 바로 바꾸거나 설정 로드에 성공했다는 이유로 원격 연결이 정상이라고 판단하지 마세요. 먼저 확인 가능한 오류 중 가장 앞서 발생한 항목을 찾으세요. 이후 반복해서 쌓이는 로그는 같은 원인이 되풀이된 결과인 경우가 많습니다.

설정 로드 단계에서는 알 수 없는 프로토콜이나 필드, 들여쓰기, 그룹 이름 참조를 먼저 확인하세요. 특정 유형을 지원하지 않는다는 안내가 나오면 클라이언트 설치 이름만 보지 말고 실제 실행 중인 코어를 확인해야 합니다. 네트워크 연결 단계에서는 서버 도메인 해석, 주소, 포트를 점검하세요. Windows에서는 아래 명령으로 TCP 포트에 연결할 수 있는지 확인할 수 있습니다. 도메인과 포트는 서버에서 실제로 제공한 값으로 바꾸세요. 예시에 적힌 도메인은 문서용이므로 그대로 사용하면 안 됩니다.

Test-NetConnection -ComputerName example.com -Port 443

이 명령으로는 프록시 인증이나 Hysteria2·TUIC에 필요한 UDP 경로를 확인할 수 없습니다. TCP 포트 연결에 성공해도 해당 TCP 연결에 기본적인 접근성이 있다는 뜻일 뿐입니다. QUIC 기반 연결은 코어 로그와 서버 기록을 함께 살펴봐야 합니다. 같은 숫자의 TCP 포트에 연결된다는 이유로 UDP도 허용됐다고 판단하지 마세요. 방화벽과 네트워크 장비가 두 전송 방식을 각각 다르게 처리할 수 있습니다.

핸드셰이크, DNS, 규칙을 각각 확인하세요

핸드셰이크 단계에 도달하면 프로토콜에 맞춰 인증 정보, 암호화 방식, TLS 이름, 전송 경로를 확인하세요. 인증서 오류는 시간과 이름을, 인증 오류는 UUID나 비밀번호를, HTTP 업그레이드 오류는 네트워크 유형, Host, 경로를 먼저 점검합니다. 로그에 최종 원인이 직접 표시되지 않더라도 범위를 좁히는 데 도움이 됩니다. 상세 로그를 켰다면 점검이 끝난 뒤 적절한 수준으로 되돌리세요. 로그를 공유하기 전에는 구독 주소와 민감한 연결 정보를 삭제해야 합니다.

연결은 수립됐지만 접속할 수 없다면 DNS와 규칙을 계속 확인해야 합니다. 도메인 해석은 로컬 시스템, 코어, 원격 서버 중 어디에서 수행되는지에 따라 결과와 경로가 달라질 수 있습니다. 특정 규칙이 대상을 직접 연결로 보내면 정상 작동하는 프록시 항목을 사용하지 않을 수 있습니다. 다른 광범위한 규칙이 먼저 적용될 수도 있습니다. 현재 선택된 그룹 이름만 보지 말고 클라이언트 연결 목록에서 대상, 적용된 규칙, 출구 정책을 확인하세요.

전역 모드는 규칙 변수를 줄이기 위한 임시 방법으로 사용할 수 있지만 프로토콜 인증, 서버 장애, 앱이 클라이언트로 들어오지 않는 문제를 해결하지는 않습니다. 확인한 뒤에는 원래의 트래픽 분기 방식으로 되돌려 테스트 설정이 계속 남지 않도록 하세요. 일부 도메인만 실패한다면 대상 DNS와 규칙을 살펴보는 편이 유용합니다. 모든 항목이 갑자기 실패했다면 기존 프로토콜 매개변수를 하나씩 바꾸기보다 시스템 네트워크, 구독 유효성, 서버 상태를 먼저 확인하세요.

로컬 포트와 TUN 문제 해결 범위

브라우저에서 로컬 프록시에 연결할 수 없다고 나오면 먼저 코어가 실행 중인지, 리스닝 포트와 시스템 프록시 설정이 일치하는지 확인하세요. 포트 충돌은 원격 프로토콜과 관계가 없습니다. 7890 포트 사용 중인 프로세스 확인을 참고하고, 변경한 뒤에는 포트 설정도 함께 확인하세요. 점유 중인 프로세스를 무작정 종료하면 다른 소프트웨어에 영향을 줄 수 있으므로 용도를 먼저 파악한 다음 이전 클라이언트를 종료하거나 포트를 바꾸세요.

TUN을 켠 뒤 문제가 생기면 서비스 권한, 가상 네트워크 어댑터, 라우팅, DNS 처리 여부를 별도의 계층으로 점검하세요. 먼저 TUN을 끄고 명시적 로컬 프록시로 같은 원격 연결을 테스트하세요. 명시적 프록시가 정상이라면 시스템 트래픽 처리 설정을 다시 확인하면 됩니다. 자세한 절차는 TUN 모드 및 서비스 모드 가이드를 참고하세요. Windows 스토어 앱에는 루프백 제한이 적용될 수도 있으므로 이 현상만으로 프로토콜이 호환되지 않는다고 판단하지 마세요.

마지막으로 재현에 필요한 정보를 남겨 두세요. 클라이언트와 코어 이름, 프로토콜 및 전송 조합, 실패 단계, 특정 네트워크에서만 발생하는지, 이미 검증한 비교 결과를 기록합니다. 추측을 늘어놓기보다 확인된 사실을 적어야 다음 조치에 도움이 됩니다. 클라이언트를 다시 선택하려면 다운로드 페이지로, 기본 사용 순서를 확인하려면 입문 가이드로 돌아가세요. 가장 단순한 연결 경로부터 작동시킨 다음 복잡한 설정을 하나씩 복원하세요.