Clash 프로토콜 및 코어 가이드

연결 구조: 프로토콜, 전송 방식, 시스템 연결

한 번의 접속은 어떤 과정을 거칠까요?

앱이 접속을 시작하면 먼저 시스템 프록시, 앱 내 프록시 설정 또는 TUN 가상 네트워크 인터페이스를 통해 로컬 클라이언트로 연결됩니다. 코어는 대상 주소를 확인하고 규칙에 따라 직접 연결하거나 프록시 정책을 선택한 뒤 원격 서버와 연결합니다. 원격 서버는 최종 대상에 접속하고 응답을 같은 경로로 돌려보냅니다. 여기에는 앱에서 로컬 클라이언트까지, 클라이언트에서 원격 서버까지, 원격 서버에서 대상까지 최소 세 구간이 있습니다. 어느 한 구간에서든 DNS 조회, 핸드셰이크, 전달 또는 출구 회선 혼잡이 발생하면 페이지가 오래 열리지 않을 수 있습니다.

노드의 프로토콜 유형은 클라이언트와 원격 서버 사이의 인증·캡슐화·전송 방식을 나타냅니다. 시스템 프록시와 TUN은 앱 연결을 로컬에서 받는 방식이고, 규칙은 연결을 어디로 보낼지 정합니다. 서로 다른 계층의 설정입니다. TUN을 켜도 SS 노드가 Hysteria2로 바뀌지 않으며, 규칙 모드를 선택해도 서버 프로토콜은 달라지지 않습니다. 문제를 진단할 때는 이 세 계층을 따로 기록해야 합니다. 그래야 시스템 연결 문제인데 노드만 계속 바꾸거나, 설정 문법 비호환을 회선 성능 문제로 오해하는 일을 막을 수 있습니다.

프로토콜 이름만으로 알 수 없는 연결 설정

프로토콜은 보통 하위 전송 방식과 보안 계층에도 의존합니다. 예를 들어 VLESS는 TCP, WebSocket 또는 지원되는 다른 전송 방식과 함께 사용할 수 있고, 보안 계층으로 TLS나 REALITY를 적용할 수 있습니다. 구독의 포트, 서버 이름, 경로, 전송 유형이 맞아야 핸드셰이크가 완료됩니다. 두 노드가 모두 VLESS로 표시되어도 설정을 서로 바꿔 쓸 수 있는 것은 아닙니다. 같은 서버의 포트마다 다른 서비스가 실행될 수도 있습니다. 클라이언트에서 유형을 고르는 것은 시작 단계일 뿐이며, 실제 연결 규약은 전체 설정으로 결정됩니다.

TCP는 데이터 순서를 보장하는 안정적인 바이트 스트림을 제공하며, 패킷이 손실되면 재전송으로 복구합니다. UDP는 데이터그램을 전송하지만 자체적으로 확인 응답이나 재전송을 처리하지 않습니다. QUIC은 UDP를 기반으로 하지만 프로토콜 내부에서 암호화, 안정적인 스트림, 혼잡 제어를 구현합니다. 따라서 “UDP 기반”이라고 해서 데이터 손실을 처리하지 않는다는 뜻은 아닙니다. 외부 연결과 내부 트래픽도 구분해야 합니다. 프록시는 UDP를 통해 웹에서 사용하는 TCP를 전달할 수도 있고, 조건에 따라 앱의 UDP 트래픽을 중계할 수도 있습니다. UDP라는 표시만 보고 게임이나 영상에 적합하다고 단정할 수는 없습니다.

요구 사항을 정한 뒤 노드를 비교하세요

노드를 선택하기 전에 웹 탐색, 대용량 파일 전송, 실시간 통신, 휴대폰 백그라운드 연결 중 어떤 용도인지 먼저 정하세요. 웹은 첫 연결과 짧은 요청의 응답 속도, 대용량 파일은 지속 전송 속도, 실시간 통신은 지연 변동과 패킷 손실이 중요합니다. 휴대폰에서는 유휴 상태의 연결 유지와 절전도 고려해야 합니다. 테스트할 때 기기, 네트워크, 대상 사이트, 시간대를 동일하게 맞추고 클라이언트 로그에서 선택한 노드를 실제로 거쳤는지 확인하세요. 프로토콜과 서버 위치를 동시에 바꾸면 결과를 프로토콜 차이로 판단할 수 없습니다.

SS와 VMess: 암호화 방식과 설정 선택

가벼운 중계 방식의 Shadowsocks

Shadowsocks는 보통 SS라고 부르며, 비교적 단순한 프록시 중계 구조를 사용합니다. 클라이언트는 대상 주소와 트래픽을 정해진 방식으로 암호화하고, 서버는 이를 복호화한 뒤 대상에 연결합니다. 복잡한 전송 방식 조합을 내장하기보다 캡슐화 구조를 간결하게 유지하는 데 초점을 둡니다. 널리 쓰이는 AEAD 암호화 방식은 기밀성과 무결성 인증을 함께 제공해 수신 측에서 변조된 데이터를 확인할 수 있습니다. 실제 연결을 위해서는 서버 주소, 포트, 비밀번호, 암호화 방식이 모두 일치해야 합니다. 어느 하나라도 다르면 인증이나 복호화에 실패할 수 있습니다.

암호화 방식은 이름만 보고 “가장 강력한” 또는 “가장 빠른” 방식을 고르면 안 됩니다. 하드웨어 AES 가속이 있는 기기와 소프트웨어 연산에 주로 의존하는 기기는 알고리즘별 처리 비용이 다를 수 있습니다. SS 2022는 별도로 호환성을 확인해야 하는 프로토콜 계열이며, 키 형식과 구현 요구 사항이 기존 SS 설정과 다릅니다. 구독에 SS 지원이라고 표시되어 있어도 모든 SS 2022 방식을 지원한다는 뜻은 아닙니다. 서버가 제공한 키를 일반적인 짧은 비밀번호로 임의 변경하면 양쪽에서 같은 방식으로 인증할 수 없습니다.

일부 SS 노드에는 추가 전송이나 캡슐화를 제공하는 플러그인이 포함됩니다. 이때는 type: ss를 해석할 수 있는지만 볼 것이 아니라 코어가 해당 플러그인과 옵션을 지원하는지 확인해야 합니다. 모바일 그래픽 클라이언트에서 일부 플러그인 항목이 숨겨질 수도 있으므로 가져오기에 성공한 뒤에도 실제 연결 로그를 확인하세요. SS의 UDP 중계 역시 클라이언트와 서버 양쪽에서 지원해야 합니다. 웹은 잘 되는데 실시간 통신이 실패한다면 암호화 방식을 바로 바꾸기보다 UDP 지원, 포트 정책, 앱 연결 방식을 따로 점검하세요.

VMess의 세션 인증과 전송 방식 조합

VMess는 V2Ray 생태계에서 시작한 프로토콜로, 세션 인증과 데이터 보호를 제공하며 TCP나 WebSocket 등의 전송 방식과 함께 쓰이는 경우가 많습니다. 보통 SS처럼 공유 비밀번호를 쓰는 대신 UUID를 인증 정보로 사용합니다. 최신 설정은 서버 요구에 따라 AEAD 방식을 사용해야 합니다. 기존 구독에 있는 alterId를 임의로 조정해도 되는 최적화 항목으로 취급하지 마세요. 구형 인증 방식은 새 구현에서 지원 범위가 다를 수 있으므로 오래된 설정은 제공자의 실제 서버 구성을 확인해야 합니다. 숫자를 바꿔 가며 “공통값”을 찾으려 해서는 안 됩니다.

VMess의 일부 인증 방식은 시간에 영향을 받으므로 기기 시계가 맞지 않으면 핸드셰이크가 실패할 수 있습니다. 같은 구독이 다른 기기에서 정상 작동한다면 먼저 시스템 시간이 자동 동기화되는지 확인한 뒤 UUID, TLS, 전송 설정을 점검하세요. WebSocket은 경로와 Host가 일치해야 하고, TLS는 서버 이름과 인증서가 맞아야 합니다. 추가 핸드셰이크와 캡슐화가 첫 접속에 영향을 줄 수 있지만, 그 정도는 연결 재사용, 회선 왕복 시간, 구현 방식에 따라 달라집니다. 모든 VMess 노드의 속도가 같다고 볼 수는 없습니다.

SS와 VMess를 우선 고려할 때

기기 성능이 제한적이고 일반적인 웹 탐색과 안정적인 중계가 주된 용도라면 설정이 단순하고 정상적으로 관리되는 SS 노드부터 테스트할 수 있습니다. 완전한 VMess 설정과 이를 지원하는 서버가 이미 있다면 기존 전송 조합을 정확히 구성하는 것이 우선입니다. 실제 성능 차이는 서버 부하, 출구, 거리의 영향보다 작은 경우가 많습니다. 클라이언트에서 알 수 없는 암호화 방식이나 미지원 전송 오류가 발생하면 먼저 코어 호환성을 해결하세요. 연결은 됐지만 전송 속도가 불안정한 경우에 회선을 비교해야 설정 문제와 성능 문제를 혼동하지 않습니다.

Trojan과 VLESS: TLS, 보안 계층, 전송 설정

TLS를 활용하는 Trojan의 보안 전송

Trojan은 일반적으로 TLS 채널 안에서 인증과 프록시 중계를 처리하며, 검증된 TLS 구현으로 연결을 보호합니다. 클라이언트는 먼저 보안 채널을 만든 다음 프로토콜에 따라 인증 정보와 대상 정보를 전달합니다. 따라서 인증서 검증, 서버 이름, 서버의 수신 설정이 중요합니다. 노드 비밀번호가 맞더라도 TLS 연결이 성공하는 것은 아닙니다. 잘못된 주소, 일치하지 않는 서버 이름, 만료된 인증서, 기기 시계 오류로 인해 인증 전에 핸드셰이크가 중단될 수 있습니다.

서버 주소는 원격 호스트를 찾는 데 사용하고, SNI는 보통 TLS 핸드셰이크에서 서버 이름을 알리는 데 사용합니다. 두 값은 서로 다를 수 있지만 서버 구성과 일치해야 합니다. IP 주소로 연결하면서 도메인 이름으로 인증서를 확인하는 경우도 흔하므로 SNI를 IP 주소로 자동 변경하면 안 됩니다. 인증서 체인은 시스템이나 코어가 사용하는 신뢰 저장소에도 영향을 받습니다. 데스크톱에서는 연결되지만 휴대폰에서는 실패한다면 비밀번호가 만료됐다고 단정하지 말고 휴대폰의 시간, 신뢰 저장소, 클라이언트 TLS 구현을 확인하세요.

VLESS의 간결한 인증과 별도 보안 계층

VLESS 역시 V2Ray 관련 생태계에서 시작했습니다. 프로토콜 자체의 인증과 캡슐화 로직은 간결하지만, 범용적인 트래픽 암호화를 자체적으로 제공하지는 않습니다. 일반적으로 TLS나 REALITY 같은 보안 계층을 사용하며, 구체적인 방식은 서버와 클라이언트의 지원 여부에 따라 달라집니다. UUID가 맞더라도 보안 계층 설정을 무시할 수 없고, 이름에 “경량”이 들어간다고 모든 환경에서 리소스를 덜 사용하는 것도 아닙니다. 외부 TLS, 전송 방식, 흐름 제어 설정은 연결 과정과 데이터 처리에 모두 영향을 줍니다.

REALITY는 일반 TLS 인증서 대신 입력하는 단순한 항목이 아닙니다. 양쪽에서 REALITY 방식에 맞춰 설정해야 하는 보안 계층입니다. 클라이언트에는 공개 키, short ID, 서버 이름 등이 필요한 경우가 많으며, 이 값은 서비스 제공자가 안내한 내용을 사용해야 합니다. Vision은 특정 흐름 제어 설정으로, 서버와 전송 방식에 맞춰야 합니다. 임의의 VLESS 노드에서 켜는 가속 옵션이 아닙니다. 공개 키 누락, short ID 오류, 흐름 제어 불일치가 있으면 설정을 바로잡아야 합니다. 시스템 프록시나 TUN을 전환해도 필요한 설정값이 채워지지는 않습니다.

여러 전송 계층이 짧은 요청에 미치는 영향

TCP, TLS, WebSocket 등의 계층은 각각 필요한 역할을 하지만 핸드셰이크나 캡슐화 작업이 추가될 수 있습니다. 웹페이지가 여러 리소스를 불러올 때 연결 재사용으로 일부 비용을 줄일 수 있지만, 실제 재사용 여부는 클라이언트, 프로토콜, 서비스에 따라 달라집니다. HTTP/2 계열 전송과 다른 구현은 연결을 구성하는 방식도 다릅니다. “다중화”라는 말만으로 더 빠르다고 판단할 수 없습니다. 하나의 연결에서 발생하는 리소스 경쟁, 서버 제한, 중간 네트워크 정책도 여러 트래픽이 함께 흐를 때의 사용 경험에 영향을 줍니다.

Trojan과 VLESS를 비교할 때는 서버, TLS 조건, 전송 조합을 먼저 동일하게 맞춘 뒤 첫 접속, 연속 탐색, 대용량 파일 전송을 확인하세요. 이미 연결된 장시간 세션만 테스트하면 첫 핸드셰이크의 차이를 놓치고, 첫 접속만 보면 장기 다운로드의 영향을 과대평가할 수 있습니다. 같은 회선에서는 두 프로토콜의 성능 차이가 설정 복잡성을 감수할 만큼 크지 않을 수도 있습니다. 설정이 정확하고 클라이언트가 충분히 지원하며 서버가 꾸준히 관리되는 노드가 선택 기능만 많은 노드보다 안정적으로 쓰기 쉽습니다.

가져온 뒤 화면에 프로토콜 이름만 표시된다면 설정 미리보기에서 전송 및 보안 옵션을 확인할 수 있습니다. 다만 인증 정보가 포함된 설정 전체를 공개 게시판에 올려서는 안 됩니다. 항목 설명은 용어 설명에서 확인하고, 그래픽 클라이언트 선택은 클라이언트 비교를 참고하세요. 이 사이트에서는 Clash Plus를 우선 추천합니다. 다만 프로토콜 지원 여부는 해당 플랫폼에 실제 통합된 코어를 기준으로 확인해야 합니다. 클라이언트 이름만으로 호환성을 판단할 수는 없습니다.

Hysteria2와 TUIC: QUIC, 패킷 손실, 회선 조건

QUIC으로 프록시 연결 구성하기

Hysteria2와 TUIC는 모두 QUIC 기반 전송 방식을 사용하며, 최신 암호화 전송과 스트림 관리 기능으로 프록시 트래픽을 처리합니다. QUIC은 UDP 위에서 안정적인 스트림을 구현합니다. 한 스트림에서 데이터가 손실되어도 일반적으로 다른 독립 스트림이 같은 바이트 순서를 기다릴 필요는 없지만, 스트림끼리 회선 대역폭과 혼잡 자원을 공유합니다. 스트림 간 헤드 오브 라인 블로킹을 줄인다는 말이 패킷 손실, 무선 신호, 출구 혼잡을 무시해도 된다거나 모든 서비스의 지연 시간이 자동으로 낮아진다는 뜻은 아닙니다.

QUIC은 TLS 관련 보안 메커니즘을 사용하며, 연결 설정과 데이터 암호화는 구현이 함께 처리합니다. 연결 이동을 지원하는 프로토콜 기반도 있지만, 프록시 클라이언트에서 관련 기능을 실제로 완전히 활성화하는지는 구현과 실행 방식에 따라 다릅니다. 휴대폰이 Wi-Fi에서 모바일 네트워크로 전환될 때 주소 변경, NAT 상태, 시스템 백그라운드 제한으로 연결이 다시 만들어질 수 있습니다. 노드가 QUIC 유형이라는 이유만으로 앱 세션이 끊기지 않는다고 보장할 수는 없습니다. 특히 앱을 오랫동안 백그라운드에 둔 뒤 다시 여는 상황을 확인해야 합니다.

Hysteria2의 대역폭 설정은 속도 측정 결과가 아닙니다

Hysteria2는 지연 시간이 길거나 패킷 손실이 있는 회선에서 처리량을 높이도록 설계되었으며, 혼잡 제어와 대역폭 관련 설정은 실제 서버 구성을 고려해 해석해야 합니다. 일부 설정은 업로드 및 다운로드 대역폭 추정치를 제공하고 전송 정책에 영향을 줍니다. 실제 동작은 서버 제한과 협상 결과에 따라서도 달라집니다. 사용 가능한 회선 용량보다 훨씬 높은 값을 입력해도 대역폭이 늘어나지는 않습니다. 오히려 대기열과 패킷 손실이 늘고 다른 앱의 응답이 느려질 수 있습니다. 여러 사람이 함께 쓰는 가정용 네트워크라면 동시 사용량도 고려하세요.

Hysteria와 Hysteria2는 이름이 비슷하다고 설정을 서로 바꿔 쓸 수 없습니다. 프로토콜과 필드가 다르므로 클라이언트가 hysteria2 유형을 명확히 인식해야 합니다. 서버 주소, 포트, 인증, TLS 외에 서버에서 추가 난독화를 사용한다면 클라이언트 설정도 일치해야 합니다. 웹과 다운로드 모두 연결되지 않으면 대역폭 추정치를 계속 높이기 전에 UDP 경로, 프로토콜 유형, 인증 정보를 먼저 확인하세요.

TUIC 인증과 혼잡 제어의 호환 범위

TUIC 설정에는 보통 인증 정보, TLS, 혼잡 제어 관련 옵션이 포함됩니다. 프로토콜 버전과 구현에 따라 호환 범위가 다를 수 있으므로 구독에 있는 UUID, 비밀번호 또는 기타 인증 방식은 서버 요구에 맞게 사용해야 합니다. 혼잡 제어 알고리즘은 네트워크 용량 변화와 패킷 손실에 따라 전송량을 조절하는 방식이지, 회선과 무관한 속도 스위치가 아닙니다. 고정 회선에서 잘 작동하는 알고리즘이 지연 변동이 큰 무선 네트워크에서도 적합하다고 보장할 수 없습니다. 먼저 기본 설정으로 재현 가능한 기준을 만드세요.

대체 연결 옵션 유지

제한된 게스트 네트워크, 일부 모바일 네트워크, 특정 라우터 설정에서는 UDP가 불안정할 수 있습니다. 이런 환경에서 TCP 노드는 정상인데 QUIC 노드 두 개가 모두 실패한다면 구독을 반복해서 가져오기보다 접속 네트워크부터 확인하세요. 휴대폰 핫스팟이나 다른 네트워크로 비교하되 한 번에 한 조건만 바꾸세요. 일상적으로 쓸 설정에는 검증된 TCP 대안을 남겨 두면 네트워크가 바뀌어도 연결하기 쉽습니다. QUIC 선택 여부는 같은 회선에서 실제 사용 환경을 테스트해 결정해야 하며, 프로토콜의 출시 시점을 품질 순위로 삼아서는 안 됩니다.

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

속도를 세 가지 관찰 단계로 나누기

“빠르다”는 말은 페이지가 처음 열리는 속도일 수도 있고 다운로드 속도일 수도 있습니다. 첫 접속에는 DNS 조회, 연결 설정, 인증, 대상 서버 응답이 관여합니다. 지속 전송 속도에는 출구 용량, 혼잡 제어, 서버 부하, 접속 대역폭이 더 큰 영향을 줍니다. 연결 안정성은 실패, 재연결, 지연 변동으로 나타납니다. 프로토콜은 이 중 일부만 바꿉니다. 비교 전에 증상을 구체적으로 기록하세요. 클릭 후 화면이 오래 비어 있는지, 리소스 로딩이 중간에 멈추는지, 다운로드 속도가 점차 떨어지는지 확인하면 단일 속도 측정값보다 진단에 도움이 됩니다.

테스트 순서는 첫 접속, 같은 사이트의 리소스 연속 열기, 지속 다운로드, 네트워크 전환으로 정할 수 있습니다. 첫 접속을 테스트하기 전에는 관련 연결을 종료하고, 연속 접속에서는 일반적인 연결 재사용 조건을 유지하세요. 매번 같은 대상과 네트워크를 사용하고 여러 차례 반복해 변동을 확인합니다. 가장 높은 결과만 결론으로 삼지 마세요. 클라이언트의 테스트 주소는 짧은 요청만 확인할 수 있어 파일 다운로드 경로와 다를 수 있으며, 같은 지역의 노드라도 출구가 같다고 볼 수 없습니다. 자세한 내용은 노드 속도 측정과 배율 읽는 법을 참고하세요.

리소스 사용량은 전체 처리 과정에서 발생합니다

CPU 사용량에는 암호화, 캡슐화, 프로토콜 상태 관리, 규칙 매칭, 데이터 복사가 포함됩니다. 메모리 사용량은 연결 수, 캐시, 코어 구현에 영향을 받습니다. TLS, QUIC, 여러 전송 계층은 각각 추가 작업을 발생시키지만 하드웨어 가속과 연결 재사용에 따라 상대적인 비용은 달라집니다. 따라서 6가지 프로토콜의 메모리나 CPU 사용량을 항상 유효한 순위로 정리할 수는 없습니다. 데스크톱의 낮은 부하 환경에서 측정한 차이가 보급형 휴대폰, 라우터, 다중 연결 서버에서도 그대로 나타나지는 않습니다.

TUN은 가상 네트워크 인터페이스와 시스템 네트워크 스택 사이에 데이터 처리를 추가합니다. DNS 가로채기, 도메인 감지, 잦은 테스트도 리소스를 사용합니다. 규칙 집합이 크다고 반드시 눈에 띄게 느려지는 것은 아니지만, 반복 가져오기, 디버그 로그 상시 기록, 잦은 업데이트는 불필요한 작업을 늘릴 수 있습니다. 코어 부하를 평가할 때는 관련 설정을 함께 기록하세요. TUN을 켠 QUIC 설정과 시스템 프록시만 켠 SS 설정을 그대로 비교한 뒤 모든 차이를 프로토콜 탓으로 돌려서는 안 됩니다.

휴대폰 배터리 소모와 백그라운드 깨우기

모바일 기기의 배터리 소모는 CPU뿐 아니라 무선 통신 상태에도 영향을 받습니다. 잦은 연결 유지, 백그라운드 속도 측정, 구독 업데이트, 재연결은 기기가 계속 통신하도록 만들 수 있습니다. 신호가 약하면 전송과 재시도 비용도 증가합니다. 다운로드 중 전력 소모와 밤새 유휴 상태로 대기할 때의 소모는 서로 다른 테스트입니다. 파일을 더 빨리 전송하는 프로토콜이 백그라운드에서도 배터리를 덜 쓰는 것은 아닙니다. 유휴 연결이 조용하다고 해서 처리량이 높을 때도 전력 효율이 가장 좋은 것은 아닙니다.

배터리 소모를 점검할 때는 먼저 시스템 배터리 화면에서 앱의 전면·백그라운드 실행 시간을 확인한 뒤 클라이언트의 테스트 간격, 자동 업데이트, 연결 로그를 살펴보세요. 필요하지 않은 잦은 탐색을 끄고 같은 구독과 화면 상태를 유지해 비교합니다. 연결이 반복해서 끊기고 재인증되는지도 확인하세요. 휴대폰 시스템이 프록시 서비스를 네트워크 활동으로 집계하면 표시 기준이 결과에 영향을 줄 수 있습니다. 앱 목록의 백분율만으로 프로토콜 문제를 단정하지 말고 실제 전체 배터리 소모량과 사용 시간을 함께 보세요.

노드를 선택할 때는 먼저 자주 실패하는 노드를 제외하고 실제 서비스 응답을 비교한 뒤 배터리와 설정을 최적화하세요. 안정적인 TCP 노드가 특정 모바일 네트워크에 더 적합할 수도 있고, 패킷 손실이 있는 환경에서 QUIC이 지속 전송을 크게 개선할 수도 있습니다. 연결 유지와 혼잡 설정은 클라이언트 기본값에서 시작하고 문제가 확인된 뒤 서버 문서에 따라 조정하세요. 여러 설정을 한꺼번에 바꾸면 기준을 잃고 일시적인 네트워크 개선을 특정 옵션의 효과로 오해하기 쉽습니다.

기본 Clash, Meta, mihomo의 호환 관계

그래픽 클라이언트와 프록시 코어를 나눠 확인하기

그래픽 클라이언트는 구독 관리, 설정 화면, 시스템 연결, 프로세스 제어를 담당하고 프록시 코어는 설정을 해석하고 규칙을 적용해 연결을 중계합니다. 클라이언트에 특정 코어가 내장될 수도 있고 코어를 전환하는 기능이 제공될 수도 있습니다. 플랫폼마다 통합 방식도 다를 수 있습니다. 프로토콜 지원을 확인할 때는 앱이나 설치 파일의 이름이 아니라 현재 실행 중인 코어 정보를 확인해야 합니다. 화면에 특정 설정이 있어도 구형 코어가 해당 설정 필드를 이해한다고 볼 수는 없습니다.

기본 Clash는 널리 사용되는 YAML 설정 체계와 규칙 모드를 구축했습니다. 과거 오픈소스 코어와 Premium 분기는 기능이 달랐으므로 “기본 Clash 지원”이라고 할 때도 어떤 구현인지 확인해야 합니다. Clash.Meta는 Clash 생태계에서 프로토콜과 기능을 확장했으며, 이후 mihomo라는 이름으로 개발이 이어졌습니다. 오래된 가이드에서 Meta는 보통 이 계보를 가리키지만, 클라이언트에 포함된 구형 Meta 바이너리가 프로젝트명 변경만으로 현재 구현의 모든 기능을 갖추는 것은 아닙니다.

공통 구조가 모든 설정 필드의 호환성을 뜻하지는 않습니다

이 코어들은 프록시 노드, 정책 그룹, 규칙, 로컬 수신 포트 등 여러 설정 개념을 공유합니다. 하지만 새 프로토콜, 규칙 유형, DNS 옵션, TUN 동작이 자동으로 이전 버전과 호환되는 것은 아닙니다. 최신 mihomo 설정을 구형 코어에서 실행하면 알 수 없는 프록시 유형이나 규칙이 나오거나 필드 처리 방식이 달라질 수 있습니다. 반대로 기본 설정을 새 코어가 받아들여도 모든 기본 동작이 이전 환경과 완전히 같다는 뜻은 아닙니다. 마이그레이션 후에는 “불러오기 성공” 여부뿐 아니라 실제 로그와 연결을 확인하세요.

생성된 최종 설정 점검

클라이언트는 구독, 전역 설정, 로컬 재정의 항목을 병합한 뒤 코어에 전달할 설정을 생성하는 경우가 많습니다. 구독의 포트가 클라이언트 설정으로 덮어써질 수 있고 DNS나 TUN도 화면에서 일괄 관리할 수 있습니다. 따라서 문제를 찾을 때는 원본 구독만 보지 말고 최종 설정과 코어 로그를 우선 확인하세요. 파일을 수정해도 클라이언트가 다음 새로고침 때 설정을 다시 생성하면 직접 입력한 필드가 사라집니다. 계속 유지해야 하는 설정은 클라이언트에서 지원하는 재정의 또는 병합 기능에 추가해야 합니다.

이전하기 전에 로컬 규칙, 정책 그룹 선택, 필요한 설정을 저장하세요. 새 환경에서 기본 연결을 먼저 확인한 다음 TUN, DNS, 규칙 집합을 하나씩 활성화합니다. 코어 제어 인터페이스와 로컬 수신 포트는 의도한 범위로 유지하고, 원격 관리가 필요하지 않다면 수신 주소 범위를 임의로 넓히지 마세요. 로그를 확인할 때는 필요한 오류와 필드명만 보관하고 공유 전 구독 주소와 인증 정보를 삭제하세요. 설정 테스트는 통과했는데 인터넷에 연결되지 않는다면 시스템 연결 단계와 노드 핸드셰이크 단계부터 다시 확인해야 합니다.

플랫폼별로 계속 관리되는 클라이언트 선택

이 사이트에서는 Clash Plus를 우선 추천합니다. Windows와 macOS에서는 Clash Verge Rev와 FlClash를 비교할 수 있고, Windows에는 Clash Nyanpasu도 있습니다. Android에서는 Clash Meta for Android, FlClash, Surfboard를 비교해 보세요. Linux에서는 Clash Verge Rev 또는 FlClash를 사용할 수 있습니다. Surfboard가 사용하는 설정 생태계는 별도로 확인해야 합니다. Clash for Windows와 ClashX Meta는 유지 관리가 중단된 아카이브 버전이므로 기존 환경에서 계속 사용할 때는 새 프로토콜과 시스템 호환성에 특히 주의하세요.

클라이언트 설치 파일은 설치 파일 페이지에서 확인하세요. iOS용 Clash Plus 정보는 앱 스토어 안내와 공식 사이트 clashplus.io를 기준으로 합니다. 프로토콜을 선택하기 위해 앱 내부 바이너리를 임의로 교체해서는 안 됩니다. 서명된 앱이나 모바일 OS에서는 특히 주의하세요. 클라이언트가 제공하는 업데이트 방법을 우선 사용하고 코어 안내와 지원 구독 형식을 확인하세요.

구독 형식, 필드 변환, 여러 기기 간 호환성

구독은 설정을 배포하는 방식입니다

구독 링크는 노드나 설정을 업데이트하는 경로이지 프록시 프로토콜의 한 종류가 아닙니다. 링크에서 전체 Clash YAML, 노드 목록만, Base64로 인코딩된 공유 링크 또는 다른 클라이언트 형식이 반환될 수 있습니다. 확장자나 링크 이름만으로 실제 내용을 알 수 없으며 서버가 클라이언트 요청에 따라 형식을 다르게 반환하기도 합니다. 가져오기에 실패하면 다운로드 실패와 파싱 실패를 먼저 구분하세요. 전자는 주소, 인증, 네트워크 문제일 수 있고 후자는 반환된 내용과 클라이언트가 지원하는 구조가 맞지 않는 문제일 수 있습니다.

전체 설정에는 노드, 정책 그룹, 규칙, DNS 등의 항목이 포함될 수 있습니다. 노드 제공자는 보통 노드 목록만 제공하므로 이를 참조하는 기본 설정이 별도로 필요합니다. 노드 목록을 전체 설정으로 바로 활성화하면 정책 그룹이나 규칙이 빠질 수 있습니다. 반대로 노드 목록만 받는 화면에 전체 설정을 넣으면 거부될 수 있습니다. 클라이언트 안내에 맞는 가져오기 위치를 선택하고 “새 설정 만들기”, “노드 추가”, “제공자 추가”를 같은 작업으로 취급하지 마세요.

공유 링크 변환에는 정보 손실 가능성이 있습니다

ss://, vmess://, trojan://, vless:// 등의 링크는 노드 설정을 전달하지만, 선택 필드의 규약과 지원 범위는 도구마다 다릅니다. 변환기가 주소와 인증 정보는 올바르게 바꾸더라도 전송 경로, 플러그인, REALITY, UDP 설정을 누락할 수 있습니다. 변환된 YAML을 파싱할 수 있다는 것은 문법이 유효하다는 뜻일 뿐, 모든 프로토콜 설정이 동일하게 변환되었다는 증거가 아닙니다. 새 프로토콜을 사용해야 한다면 대상 코어가 기본적으로 지원하는 구독 형식을 우선 요청하세요.

변환 후 프로토콜 유형, 포트, 보안 계층, 서버 이름, 전송 필드를 하나씩 비교하세요. 클라이언트에서 DNS를 이미 재정의했는데 변환기가 노드를 수정했다고 착각하지 마세요. 정책 그룹에서 참조하지 못하는 이름도 프로토콜 오류와는 별개의 문제입니다. 노드 이름을 바꾸면 규칙이나 그룹의 참조가 깨질 수 있고, 지원하지 않는 노드를 제거하면 기존 그룹이 비어 버릴 수도 있습니다. 호환성은 필드가 보존됐는지뿐 아니라 참조 관계가 그대로 유지되는지도 확인해야 합니다.

업데이트 실패와 빈 목록을 나눠 확인하세요

업데이트에 실패하면 네트워크 오류, HTTP 상태 코드, 파싱 안내를 먼저 확인하세요. 클라이언트에 로그인 페이지, 오류 페이지, 빈 응답이 내려와도 형식 오류가 표시될 수 있습니다. 기존 설정이 계속 작동한다면 이를 남겨 두고 구독 유효성을 확인하세요. 유일하게 작동하는 연결을 먼저 삭제하지 마세요. 업데이트는 성공했지만 노드 목록이 비어 있다면 그룹 필터, 키워드 검색, 프로토콜 호환성을 확인하세요. 일부 노드만 사라졌다면 필터링된 유형을 비교해 변환 과정에서 정보가 누락됐는지 판단할 수 있습니다.

여러 기기에서 구독을 함께 사용하더라도 로컬 포트, TUN 권한, 재정의 설정은 기기마다 다를 수 있습니다. 노드를 공유한다고 전체 설정까지 같아지는 것은 아닙니다. 휴대폰에는 백그라운드 사용에 적합한 설정을 유지하고 컴퓨터에는 더 세부적인 규칙을 둘 수 있지만, 각 기기가 해당 노드 프로토콜을 지원해야 합니다. 설정 동기화 방법은 컴퓨터와 휴대폰 간 설정 동기화를 참고하고, 처음 가져오는 방법은 구독 가져오기 가이드를 확인하세요.

구독 형식을 비교할 때는 검증된 노드 하나를 기준으로 남겨 두고 단일 노드 연결부터 확인한 다음 정책 그룹과 규칙을 복구하세요. 이렇게 하면 변환 호환성과 라우팅 선택을 분리할 수 있습니다. 여러 문제가 복잡한 설정에 한꺼번에 섞여 결국 “구독이 안 된다”는 결론만 남는 상황을 피할 수 있습니다.

규칙 분기와 사용 환경에 따른 선택 순서

규칙이 실제로 선택한 출구부터 확인하세요

규칙 모드는 보통 연결을 순서대로 검사하며 먼저 일치한 규칙이 적용할 정책을 결정합니다. 정책은 직접 연결, 거부, 프록시 노드 또는 정책 그룹일 수 있습니다. 노드를 바꿨는데 접속 결과가 달라지지 않는다면 연결이 DIRECT 규칙에 일치했거나 기존 연결이 아직 재생성되지 않았을 수 있습니다. 프로토콜을 선택하기 전에 연결 기록에서 대상, 일치한 규칙, 실제 정책을 확인하면 사용되지도 않은 노드의 성능을 평가하는 일을 막을 수 있습니다.

도메인 규칙은 코어가 대상 도메인을 알아낼 수 있어야 하고, IP 규칙은 대상 주소를 기준으로 적용됩니다. 시스템 프록시, TUN, DNS 처리, 도메인 감지 방식에 따라 연결 기록에 표시되는 정보가 다를 수 있습니다. 도메인 정보가 사라졌다면 DOMAIN-SUFFIX를 수정해도 적용된다고 보장할 수 없습니다. 먼저 앱의 DNS 조회 방식과 코어가 도메인을 파악하는지 확인한 뒤 규칙을 점검하세요. DNS는 대상 주소를 결정하고 규칙은 출구를 결정합니다. 서로 영향을 주지만 같은 설정은 아닙니다.

다음은 규칙 순서와 정책 참조를 설명하는 기본 라우팅 예시입니다. 원격 노드가 포함된 완전한 구독 설정은 아닙니다. 실제 설정에 병합할 때는 PROXY 정책 그룹이 실제 노드를 참조하도록 해야 합니다. 여기서 DIRECT는 기본 제공 직접 연결 정책이고 REJECT는 기본 제공 거부 정책입니다. PROXY는 예시에서 정의한 정책 그룹 이름으로, 어떤 설정에서든 자동으로 제공되는 키워드가 아닙니다.

mode: rule
proxy-groups:
  - name: PROXY
    type: select
    proxies:
      - DIRECT
rules:
  - DOMAIN-SUFFIX,example.com,PROXY
  - DOMAIN-SUFFIX,example.org,REJECT
  - GEOIP,CN,DIRECT
  - MATCH,PROXY

이 예시의 PROXY 그룹에는 DIRECT만 포함되어 있어 원격 인증 정보 없이 문법과 규칙을 확인할 수 있습니다. 원격 프록시 연결을 만들지는 않습니다. 실제로 사용하려면 작동하는 노드를 그룹에 추가하고 해당 노드를 선택해야 합니다. GEOIP는 코어에서 사용할 수 있는 지리 데이터에도 의존하므로 데이터베이스 업데이트 문제를 노드 프로토콜 탓으로 돌릴 수 없습니다. MATCH는 마지막에 두어 어떤 규칙에도 일치하지 않는 연결을 처리합니다. 앞에 배치하면 뒤에 있는 규칙이 적용되지 않습니다.

사용 환경별로 첫 번째 후보 정하기

일반적인 웹 탐색이나 업무에는 설정이 완전하고 안정적으로 연결되는 SS, Trojan 또는 검증된 VLESS 노드부터 사용하면 됩니다. 정상 작동하는 설정을 프로토콜 이름만 보고 바꿀 필요는 없습니다. 대용량 파일 전송은 같은 네트워크에서 Hysteria2나 TUIC를 추가해 지속 전송을 테스트하고 패킷 손실 환경에서 처리량이 개선되는지 확인하세요. 실시간 통신은 앱의 UDP가 클라이언트에 전달되고 원격 서버도 이를 지원하는지 먼저 확인한 뒤 지연 변동을 살펴보세요. 측정 지연 시간이 가장 낮다고 실제 통신이 가장 안정적인 것은 아닙니다.

여러 기기에서 사용할 때는 모든 기기가 공통으로 지원하는 프로토콜과 구독 형식을 먼저 확인한 뒤 각 기기별 최적화를 고려하세요. 휴대폰을 장시간 백그라운드에서 사용할 때는 잦은 재연결과 자동 탐색을 배터리 점검 항목으로 삼으세요. 라우터나 서버에서는 하드웨어 암호화 지원, 동시 연결 수, 코어 리소스가 중요합니다. 정책 그룹에 서로 다른 전송 방식의 작동하는 노드를 남겨 두고 네트워크가 바뀔 때 수동으로 전환해 확인하세요. 조건을 확인하지 않은 자동 선택으로 테스트 환경을 계속 바꾸지 마세요.

문제가 생기면 계층별로 범위를 좁히세요

앱이 연결 기록에 나타나지 않으면 시스템 프록시, 앱 설정, TUN을 먼저 확인하세요. 연결 기록은 있지만 잘못된 정책이 적용되면 규칙 순서와 그룹 참조를 살펴보세요. 노드를 선택한 뒤 핸드셰이크가 실패한다면 인증, TLS, 전송 방식, UDP 경로를 점검하세요. 연결은 성공했는데 서비스가 느리면 출구, 대상, 지속 전송을 비교하세요. Windows 스토어 앱은 루프백 제한의 영향을 받을 수도 있습니다. 자세한 내용은 UWP 루프백 제한 해결 방법을 참고하세요. 이런 문제는 프로토콜을 바꿔도 해결되지 않습니다.

최종 선택은 다음 세 가지를 충족해야 합니다. 현재 코어가 설정을 완전히 이해하고, 접속 네트워크에서 전송 방식이 정상 작동하며, 실제 서비스와 리소스 사용량이 요구에 맞아야 합니다. 구체적인 설정 방법은 클라이언트 설정 가이드를 참고하고, 업데이트나 클라이언트 변경은 설치 파일 페이지에서 확인하세요. 프로토콜 표시는 작동 방식을 가늠하는 단서일 뿐입니다. 안정성은 실제 연결, 최종 설정, 서비스별 테스트를 함께 확인해야 합니다.