Shadowrocket 프로토콜 설명
종류 선택과 설정값 확인

먼저 연결 양쪽을 확인하세요

Shadowrocket에서 프로토콜을 선택한다는 것은 클라이언트가 서버에서 처리할 수 있는 통신 형식을 사용하도록 설정하는 것입니다. Type은 속도 등급이 아닙니다. 서버가 Shadowsocks를 제공한다면 클라이언트에서 Trojan으로 바꾸기만 해서는 다른 방식으로 연결되지 않습니다. 주소, 포트, 인증 정보, 암호화 방식, 전송 조건이 모두 갖춰져야 사용할 수 있으며, 필수 항목이 하나라도 빠지면 연결을 시작하기 전에 실패할 수 있습니다. 기존 구독에는 보통 이런 정보가 포함되지만, 가져오기에 성공했다는 것은 설정을 읽어들였다는 뜻일 뿐 현재 서버에 연결할 수 있다는 뜻은 아닙니다.

연결 과정을 이해하려면 요청을 세 가지로 나눠 볼 수 있습니다. 앱이 접속하려는 대상, Shadowrocket이 연결하는 서버, 요청을 서버까지 전달하는 로컬 네트워크입니다. 대상 사이트의 HTTPS와 클라이언트에서 서버까지의 TLS는 서로 다른 계층입니다. 브라우저에 안전한 연결로 표시되더라도 대상 사이트 연결의 인증서 검증 결과만 알 수 있을 뿐, 프록시 프로토콜의 외부 연결에도 암호화가 적용됐다고 단정할 수 없습니다. 반대로 외부 연결에 TLS를 사용하더라도 앱의 대상 인증서 검증을 대신하지는 않습니다.

프로토콜 종류와 전송 방식은 다릅니다

Shadowsocks, VMess, VLESS, Trojan은 핵심 동작 방식이 서로 다릅니다. TCP와 UDP는 하위 전송 계층의 개념이며 WebSocket, HTTP/2, QUIC은 각각 별도의 세션 및 캡슐화 방식을 사용합니다. 어떤 프로토콜이 특정 전송 방식을 지원하더라도 서버에서 해당 방식을 활성화했다는 뜻은 아니며, 임의의 클라이언트 조합이 서로 호환된다는 의미도 아닙니다. 설정 정보를 확인할 때는 프로토콜 유형, 전송 유형, TLS 조건을 구분해 기록하세요. 이름이 길게 나열되어 있다고 해서 서로 자유롭게 바꿔 쓸 수 있는 동의어는 아닙니다.

전체 작업을 기준으로 속도와 배터리 사용량 비교

속도에는 연결 설정 대기 시간, 첫 응답이 도착할 때까지의 시간, 지속 전송 처리량, 연결 중단 후 복구가 모두 포함됩니다. 간단한 연결 테스트는 이 중 일부만 측정합니다. TCP 연결이 빠르다고 대용량 파일 전송도 빠른 것은 아닙니다. 다운로드 처리량이 높더라도 짧은 요청이 잦은 환경에서는 응답이 늦을 수 있습니다. 모바일 기기의 성능은 무선 신호, 통신사 네트워크 관리, 서버 부하, 대상 사이트의 제한에도 영향을 받습니다. 따라서 이 매뉴얼은 프로토콜 이름만으로 속도를 순위화하거나 한 번의 측정 결과를 지속적인 성능으로 간주하지 않습니다.

배터리 사용량은 같은 작업을 완료하는 데 드는 전체 처리량에 따라 달라집니다. 암호화 연산, 캡슐화, 재전송, 연결 유지, 무선 모듈 깨우기는 모두 자원을 사용합니다. 신호가 약하면 프로토콜 차이보다 무선 통신에 드는 비용이 더 클 수 있습니다. 비교할 때는 기기, 네트워크, 서버, 테스트 작업을 동일하게 유지하고 일정 시간 동안 완료 결과를 관찰하세요. 연결을 켠 직후 배터리 잔량이 바뀌는지만 확인해서는 안 됩니다. 연결 유지는 일부 복구 대기 시간을 줄이지만 백그라운드 깨우기를 늘릴 수 있으므로 사용 방식에 맞게 판단해야 합니다.

라우팅은 별도의 판단 과정입니다. 서버 정보가 모두 정확해도 요청이 Direct로 직접 전송될 수 있습니다. 문제를 진단하기 전에 Global Routing 설정과 실제로 일치하는 규칙을 확인한 뒤 프로토콜 동작을 점검하세요. Config, Proxy, Direct는 각각 설정, 프록시, 직접 연결 경로를 의미합니다. 이 설정은 요청의 경로를 결정할 뿐 서버를 다른 프로토콜로 바꾸지는 않습니다.

설계 배경과 주요 고려 사항

Shadowsocks는 비교적 가벼운 암호화 프록시 전달 방식을 제공하도록 설계되었습니다. 클라이언트가 대상 요청을 캡슐화해 서버로 보내면 서버가 대상에 연결합니다. 기기에 원격 네트워크의 전체 주소 체계를 부여하는 가상 네트워크 인터페이스 프로토콜은 아닙니다. 일반적으로 필요한 설정은 서버 주소, 포트, 암호화 방식, 비밀번호입니다. 항목이 적어 보여도 암호화 방식을 생략하거나 이름이 비슷한 구현을 모두 호환되는 것으로 간주해서는 안 됩니다.

암호화 방식은 세대별로 키 처리 방식과 데이터 형식이 다릅니다. AEAD 방식은 기밀성과 메시지 무결성을 함께 다루며, 최신 방식에서는 키 자료의 형식과 길이 요구 사항이 달라질 수도 있습니다. 따라서 설정 자료에 적힌 방식 이름을 클라이언트에서 지원하는 항목과 정확히 맞춰야 합니다. 이름에 AES가 들어간다는 이유만으로 임의로 바꾸거나, 더 강해 보인다는 이유로 서버에 설정되지 않은 방식을 선택하지 마세요. 양쪽의 형식이 다르면 서로 주고받은 데이터를 올바르게 해석할 수 없습니다.

핵심 설정 항목 네 가지 확인하기

Server에는 도메인 이름이나 IP 주소를 입력합니다. 접속할 웹사이트가 아니라 프록시 서버 주소입니다. Port에는 서버에서 지정한 리스닝 포트를 입력해야 하며, 프로토콜 이름을 보고 임의로 추측해서는 안 됩니다. Method는 양쪽에서 합의한 암호화 방식이고 Password는 원문 그대로 입력해야 합니다. 비밀번호를 복사할 때 앞뒤 공백, 줄바꿈, 비슷하게 생긴 문자를 확인하세요. 일부 방식은 정해진 형식의 키 자료를 요구하므로 임의로 한 번 인코딩한 값을 입력하지 마세요.

공유 링크의 인코딩은 설정 정보를 표현하는 방식일 뿐 기반 프로토콜을 바꾸지 않습니다. 링크에 방식과 인증 정보가 함께 인코딩되거나 추가 매개변수가 포함될 수 있습니다. 클립보드에서 이름을 읽어들였다고 해서 확장 매개변수까지 모두 복원된 것은 아닙니다. 가져온 뒤 항목을 열어 Type, Server, Port, Method, Password를 확인하세요. 설정에 플러그인이나 특수 전송 조건이 명시되어 있다면 양쪽에서 지원하는지도 확인해야 합니다. 기본 항목 네 개만 남기면 원래 설정과 달라질 수 있습니다.

TCP는 정상인데 UDP가 실패하는 이유

Shadowsocks는 TCP를 전달할 수 있으며, 호환되는 구현과 설정에서는 UDP도 처리할 수 있습니다. 두 경로를 따로 확인하세요. 서버에서 TCP 포트를 열었다고 해서 같은 포트의 UDP도 열려 있는 것은 아닙니다. 웹 요청이 가능한 네트워크라고 모든 UDP 데이터가 허용되는 것도 아닙니다. 웹사이트는 열리지만 일부 실시간 작업이 실패한다면 먼저 해당 작업에서 실제로 어떤 전송 방식을 사용하는지 확인하고 UDP 조건을 점검하세요. 바로 비밀번호를 바꾸지는 마세요. DNS 조회 경로도 다른 트래픽과 다를 수 있으므로 별도로 확인해야 합니다.

iOS에서 Shadowsocks의 자원 사용량은 사용 방식, 데이터 양, 프로세서 성능에 따라 달라집니다. 일부 기기는 특정 알고리즘을 하드웨어로 가속해 연산 부담을 줄일 수 있지만, 모든 기기와 방식에 해당하지는 않습니다. 가벼운 캡슐화는 추가 처리를 줄일 수 있어도 신호가 약할 때의 재전송이나 서버 혼잡까지 없애지는 못합니다. 지속적으로 데이터를 전송한다면 동일한 파일을 완료하는 데 걸리는 시간과 안정성을 비교하세요. 계층이 적다는 이유만으로 배터리를 덜 쓴다고 판단해서는 안 됩니다.

문제 해결은 주소 조회와 포트 연결 가능 여부부터 확인한 뒤 암호화 방식과 인증 정보를 점검하세요. 기본 통신이 되는데 특정 앱에서 문제가 계속되면 암호화 항목을 반복해서 바꾸지 말고 규칙, DNS, UDP를 확인하세요. 한 번에 조건 하나만 바꾸고 작동하는 기존 항목을 보존하면 경로 문제와 인증 문제를 구분하기 쉽습니다.

두 프로토콜의 역할은 서로 다릅니다

VMess는 프로토콜에 인증 및 데이터 보호 기능을 포함하며 UUID 등의 정보로 클라이언트를 식별합니다. 인증 방식은 세대에 따라 다를 수 있습니다. VLESS는 더 간결한 프로토콜 구조를 사용하며 VMess와 같은 내장 데이터 암호화 기능을 제공하지 않습니다. 따라서 일반적으로 클라이언트와 서버 사이의 통신을 보호하려면 함께 사용하는 보안 전송에 의존합니다. 두 프로토콜 모두 UUID를 사용할 수 있지만 UUID가 같다고 서로 바꿔 쓸 수 있는 것은 아닙니다. Type은 서버 설정과 일치해야 합니다.

VLESS가 간결하게 설계됐다고 해서 모든 상황에서 VMess보다 빠르다는 뜻은 아닙니다. 실제 연결에는 TLS, 다양한 전송 방식, 다중화, 서버 측 전달이 함께 적용될 수 있으며 전체 조합이 최종 처리 비용을 결정합니다. 일부 구형 VMess 설정에는 추가 호환성 매개변수가 포함되기도 합니다. 기존 자료에 이런 정보가 있다면 서버 요구 사항을 확인하세요. 모든 환경에 동일한 값을 적용해서는 안 됩니다. 모르는 항목이 있으면 해당 세대에서 사용하는 설정인지 확인하고, 이전 매개변수를 새로운 인증 방식에 무리하게 추가하지 마세요.

UUID, 시간, 보안 계층

UUID는 인증 정보이지 서버 주소나 임의의 메모가 아닙니다. 복사할 때 하이픈을 포함해 모든 문자를 그대로 유지하세요. 클라이언트가 대소문자를 자동으로 정리하더라도 빠진 문자를 복구해 주지는 않습니다. 시간 범위를 사용하는 VMess 인증에서는 기기의 시간이 크게 어긋나면 인증에 실패할 수 있으므로 먼저 시스템의 날짜와 시간을 자동으로 설정하세요. 시간이 올바른데도 실패한다면 UUID, 프로토콜 세대, 서버 상태를 확인하세요. 모든 인증 오류를 네트워크 연결 실패로 단정해서는 안 됩니다.

VLESS 설정의 Encryption이 자료에 none으로 지정되어 있다면 연결 전체가 보호되지 않는다고 단정할 수 없으며 외부 TLS를 무시해서도 안 됩니다. 프로토콜 계층의 항목과 보안 전송 항목을 나눠 확인하세요. 반대로 외부에 보안 채널이 설정되지 않았다면 프로토콜 이름만으로 데이터가 같은 수준으로 보호된다고 볼 수 없습니다. TLS 사용 여부, 서버 인증 방식, 특정 Flow 사용 여부를 모두 원본 설정과 하나씩 대조해야 합니다.

WebSocket, Host, Path의 관계

기존 설정에서 WebSocket을 사용한다면 클라이언트는 해당 HTTP 업그레이드 절차에 따라 연결을 만든 뒤 그 안에 프로토콜 데이터를 전달합니다. Path는 서버 또는 리버스 프록시에서 요청을 구분하는 경로로, 일반적으로 맨 앞의 슬래시와 대소문자를 그대로 유지해야 합니다. Host는 HTTP 요청의 호스트 정보로 가상 호스트 선택에 쓰일 수 있습니다. 실제 연결 주소와 다를 수는 있지만, 이 차이는 서버 설정에 근거해야 합니다. 접속을 시도하려고 흔히 쓰이는 도메인을 임의로 입력해서는 안 됩니다.

SNI는 TLS 핸드셰이크에서 서버가 인증서와 사이트 설정을 선택하도록 돕습니다. WebSocket의 Host와는 계층이 다릅니다. 일반적인 설정에서는 두 항목에 같은 도메인을 쓰기도 하지만, 한 항목이 다른 항목을 자동으로 지정하지는 않습니다. Server에 IP 주소를 입력하고 인증서가 도메인 이름으로 발급됐다면 서버 이름을 올바르게 지정해야 인증서를 확인할 수 있습니다. Host만 바꾸고 SNI를 확인하지 않으면 HTTP 계층은 정상이어도 TLS 계층에서 실패할 수 있습니다.

iOS에서는 외부 TLS와 전송 계층에 따라 핸드셰이크 단계가 늘어날 수 있습니다. 짧은 연결을 자주 새로 만들면 대기 시간에 차이가 더 잘 드러납니다. 연결 재사용은 일부 반복 설정 비용을 줄이는 대신 여러 요청이 하나의 전송 연결을 공유하게 해 혼잡의 영향을 키울 수도 있습니다. 항상 최적인 고정 설정은 없습니다. 사용 중인 서버와의 호환성을 먼저 확인하고 실제 앱에서 시험하세요. 속도를 높여 줄 것처럼 보이는 옵션을 모두 동시에 켜지는 마세요.

긴 공유 링크를 가져온 뒤에는 화면 캡처만 남기지 말고 설정 항목도 글로 기록하세요. 특히 Transport, TLS, Host, Path, SNI, Flow의 원래 관계를 보존해야 합니다. 구독을 갱신하면 항목이 다시 생성될 수 있어 구독에서 파생된 항목을 직접 수정해도 변경 내용이 계속 유지되지 않을 수 있습니다. 시험이 필요하면 용도를 명확히 표시한 별도의 테스트 항목으로 복사하세요. 그러면 다음 갱신 뒤 설정이 사라졌다고 오해하는 일을 줄일 수 있습니다.

Trojan에 TLS 설정이 필요한 이유

Trojan은 TLS 보안 연결 안에서 인증과 프록시 요청 전달을 수행하도록 설계됐습니다. TLS는 클라이언트와 서버 사이의 연결을 암호화하고 서버 신원을 확인하며, Password는 프로토콜 인증에 사용됩니다. 두 기능은 서로 대체할 수 없습니다. 비밀번호가 맞아도 인증서 이름이 일치하지 않으면 TLS 단계에서 연결이 멈출 수 있습니다. 인증서가 정상이어도 비밀번호가 틀리면 이후 인증 단계에서 실패할 수 있습니다. 따라서 먼저 보안 채널을 확인한 뒤 프로토콜 인증 정보를 확인하세요.

Server는 실제 연결 대상이며 SNI는 TLS 핸드셰이크에 필요한 서버 이름을 제공하고 인증서는 상대 서버의 신원을 증명합니다. 기존 설정에 도메인이 있다면 DNS 조회 결과로 얻은 IP로 임의 변경하지 말고 도메인을 유지하세요. 도메인은 주소 분산과 인증서 확인에도 쓰일 수 있습니다. IP를 고정하면 당장은 연결되더라도 서버 이전 후 작동하지 않을 수 있습니다. 자체 테스트 환경에서 특수 인증서를 사용한다면 명확한 신뢰 관계에 따라 설정하세요. 검증을 건너뛰는 방식으로 문제를 해결하려고 해서는 안 됩니다.

HTTP 프록시와 HTTPS 대상은 다른 개념입니다

HTTP 프록시는 보통 요청 대상에 따라 HTTP 트래픽을 전달하며 CONNECT 방식으로 대상까지 바이트 터널을 만들 수도 있습니다. HTTPS 사이트에 접속할 때는 보통 먼저 프록시에 CONNECT를 요청한 뒤 터널 안에서 대상 서버와 TLS 연결을 설정합니다. 대상 서버와의 TLS 연결 여부와 클라이언트에서 프록시까지 TLS를 사용하는지는 서로 다른 문제입니다. 프록시 연결이 암호화되지 않았다면 대상 URL이 HTTPS로 시작하더라도 프록시 인증 정보가 전송되는 외부 연결까지 보호된다고 볼 수 없습니다.

Shadowrocket 항목의 Type, TLS 및 관련 인증 항목은 기존 자료에 따라 각각 확인하세요. Username과 Password는 프록시 인증 정보일 수 있으며 대상 웹사이트 계정을 입력해서는 안 됩니다. 일반적인 HTTP CONNECT는 주로 TCP를 처리하므로 모든 UDP 작업이 프록시를 거친다고 단정할 수 없습니다. 더 다양한 트래픽을 처리하는 확장 방식도 있지만, 클라이언트와 서버 및 설정에서 명확히 지원해야만 사용할 수 있습니다. 일반 HTTP 프록시 설정에 이런 기능이 있다고 가정하지 마세요.

SOCKS5가 제공하는 기능과 제공하지 않는 기능

SOCKS5는 대상 연결, 인증 방식, UDP 연결 같은 요청을 표현할 수 있는 일반 프록시 협상 프로토콜입니다. 기본 프로토콜 자체는 데이터를 암호화하지 않습니다. 사용자 이름과 비밀번호를 사용한 인증도 암호화된 전송을 의미하지 않습니다. 사용하려는 네트워크 환경과 외부 보안 조건을 확인하세요. 관리되는 네트워크나 용도가 명확한 프록시 연결에 적합하지만, 일반적인 프로토콜이라는 이유만으로 모든 서버에 자동으로 연결되거나 모든 경로를 보호하는 것은 아닙니다.

SOCKS5의 UDP 전달에는 UDP ASSOCIATE, 서버가 반환하는 릴레이 정보, 이후의 데이터 경로가 관여합니다. TCP 제어 연결에 성공했다고 UDP 중계도 사용할 수 있다고 볼 수는 없습니다. 서버 권한, 네트워크 주소 변환, 포트 개방이 결과에 영향을 줄 수 있습니다. 도메인을 어느 쪽에서 조회하는지도 구분해야 합니다. 요청에 도메인 이름을 담아 보내는 방식과 로컬에서 먼저 조회한 뒤 IP를 보내는 방식은 조회 경로가 다릅니다. 실제 동작은 클라이언트 라우팅, DNS 설정, 요청 유형에 따라 달라집니다.

모바일 기기에서 TLS 핸드셰이크에는 네트워크 왕복과 인증서 처리가 필요합니다. 기존 연결을 재사용하면 반복 비용을 줄일 수 있지만 신호가 약하거나 네트워크가 자주 바뀌거나 서버가 연결을 종료하면 다시 연결해야 합니다. 프로토콜이 일반 HTTPS처럼 보인다는 이유로 배터리를 덜 쓴다고 단정하지 마세요. 같은 작업에서 연결 성공률, 백그라운드 복구 속도, 기기 온도 변화를 비교하고 화면 밝기와 앱 자체 활동이 미친 영향도 고려하세요.

프로토콜 세 가지에 우열을 매길 필요는 없습니다. 기존 서버에서 Trojan을 제공한다면 TLS와 비밀번호가 제대로 설정됐는지 확인하세요. 관리되는 HTTP 또는 SOCKS5 연결을 사용한다면 권한, 외부 보안, 대상 트래픽 범위를 먼저 확인하세요. 프로토콜 이름만 보고 복잡한 조합을 선택하는 것보다 서버 설정과 정확히 맞추는 것이 중요합니다.

프록시 요청에서 IP 패킷 전달로

WireGuard는 암호화된 IP 터널을 중심으로 설계됐으며, 정해진 최신 암호 알고리즘 조합과 공개 키로 신원을 확인합니다. 사용자가 다양한 암호화 방식 가운데 하나를 고르는 구조가 아닙니다. 대상 연결 요청 중심의 프록시 프로토콜과 달리 지정된 상대에게 IP 패킷을 전달하는 방식에 가깝습니다. 네트워크, 주소, 라우팅이 이미 갖춰진 환경에 적합하지만 로컬 터널 주소, 상대방 신원, 터널을 통과시킬 대상 범위를 함께 설정해야 합니다. 서버 주소만 입력해서는 충분하지 않습니다.

WireGuard는 일반적으로 UDP를 사용해 전체 IP 터널을 신뢰성 있는 바이트 스트림 하나에 고정하지 않습니다. 간결한 설계는 일부 구현의 복잡성을 줄여 주지만 Shadowrocket에서의 실제 성능은 클라이언트 통합 방식, 시스템 네트워크 확장, 서버 처리 능력, 네트워크 경로에도 영향을 받습니다. 다른 운영 환경에서의 테스트 결과를 iPhone에 그대로 적용하거나, 알고리즘이 고정되어 있다는 이유만으로 모든 작업에서 배터리를 덜 쓴다고 단정하지 마세요.

Private Key와 Public Key의 관계

Private Key는 로컬에서만 보관해야 하는 비밀 정보입니다. 공개 화면 캡처, 로그, 문의 내용에 포함하지 마세요. Public Key는 상대를 식별하며 양쪽에 올바른 키 쌍이 설정되어야 합니다. 클라이언트에는 서버 공개 키를 저장하고 서버에는 클라이언트 공개 키를 등록합니다. 두 키를 반대로 입력하거나 다른 기기의 설정을 복사하면 핸드셰이크에 실패할 수 있습니다. Preshared Key는 선택 사항인 추가 공유 비밀이며 양쪽 설정이 일치해야 사용할 수 있습니다. 한쪽에만 임의로 추가하지 마세요.

Address는 터널 인터페이스에 할당하는 주소이고 Endpoint는 실제로 연결할 상대의 공용 또는 접근 가능한 주소와 포트입니다. 두 항목의 역할은 다릅니다. 터널 내부 주소를 Endpoint에 입력하면 외부 네트워크에서 초기 연결을 설정할 수 없는 경우가 많습니다. IPv4와 IPv6도 각각 확인하세요. 기존 설정에 한 주소 체계만 있다면 다른 주소를 임의로 만들어 보완하지 마세요. DNS 설정은 도메인을 조회하는 방식에 관한 것이며 Endpoint 주소를 대신하지 않습니다.

Allowed IPs는 전체 규칙을 대신하지 않습니다

WireGuard에서 Allowed IPs는 피어에 전달할 패킷 범위를 판단하는 데 사용되며, 어떤 대상을 해당 피어로 보낼지도 지정하는 경우가 많습니다. Shadowrocket의 전체 규칙 시스템을 대신하지는 않습니다. 앱 요청이 이 항목으로 전달되는지는 Global Routing과 설정 정책에 따라 달라집니다. 터널 핸드셰이크는 정상이지만 내부 네트워크에 접속할 수 없다면 대상 주소가 허용 범위에 포함되는지, 원격 서버가 전달을 지원하는지, 반환 경로에서 클라이언트의 터널 주소를 찾을 수 있는지도 확인하세요.

MTU가 너무 크면 일부 큰 패킷이 경로를 통과하지 못해 짧은 요청은 정상인데 많은 콘텐츠를 불러올 때 멈출 수 있습니다. MTU를 낮추면 원인을 찾는 데 도움이 될 수도 있지만, 무조건 작을수록 좋은 것은 아닙니다. 너무 작으면 패킷 분할과 처리 부담이 늘어납니다. 먼저 기존 설정을 사용하고 큰 패킷 오류를 재현할 수 있을 때만 조금씩 조정하면서 차이를 기록하세요. DNS나 원격 라우팅이 실제 원인이라면 MTU를 바꿔도 지속적으로 개선되기 어렵습니다.

Persistent Keepalive는 필요한 경우 네트워크 주소 변환 매핑을 유지하며, 클라이언트가 NAT 뒤에 있고 원격 서버에서 먼저 연결해야 하는 상황에 자주 사용됩니다. Keepalive 간격이 짧으면 무선 활동이 늘어 모바일 기기의 대기 중 배터리 사용량에 영향을 줄 수 있습니다. 완전히 끄면 한동안 사용하지 않은 뒤 첫 통신까지 지연될 수 있습니다. 필요한지는 네트워크 구성과 사용 목적에 따라 판단하세요. 특정 간격을 모든 기기에 적용할 고정 권장값으로 간주해서는 안 됩니다.

WireGuard 문제를 확인할 때 핸드셰이크와 실제 데이터 전송을 구분하세요. 핸드셰이크가 성공하면 키와 일부 기본 경로가 작동한다는 뜻이지만 DNS, Allowed IPs, 원격 전달, 대상의 반환 경로까지 정상이라는 의미는 아닙니다. Wi-Fi와 셀룰러 네트워크를 바꾼 뒤 복구가 느리다면 먼저 피어 정보 갱신과 UDP 연결 가능 여부를 확인한 다음 Keepalive 설정을 점검하세요. 신원 항목을 확인하기도 전에 주소, 라우팅, MTU를 한꺼번에 바꾸지 마세요.

QUIC을 사용하는 이유

Hysteria2는 UDP 위에서 동작하는 QUIC 기반 전송 방식을 사용하며, QUIC은 보안 연결과 멀티스트림 같은 기능을 제공합니다. 지연이나 패킷 손실, 대역폭 변동이 있는 네트워크에서의 전송 성능을 고려해 설계됐으며 이에 맞는 혼잡 제어 방식을 함께 사용할 수 있습니다. UDP를 사용한다고 해서 신뢰성 처리를 모두 사용자가 맡는 것은 아닙니다. QUIC이 확인 응답, 손실 감지, 재전송을 처리합니다. UDP를 쓴다는 이유만으로 데이터가 임의로 손실되거나 TCP보다 반드시 빠르다고 이해해서는 안 됩니다.

QUIC의 독립 스트림은 신뢰성 있는 바이트 스트림의 순차 전달로 인해 스트림 사이에 발생하는 일부 지연을 줄일 수 있습니다. 다만 각 스트림 안에는 여전히 순서가 있으며 모든 스트림은 사용 가능한 대역폭과 혼잡의 영향을 받습니다. 로컬 네트워크에서 UDP를 제한하거나 엄격한 속도 및 매핑 규칙을 적용하면 프로토콜의 장점이 드러나지 않을 수 있습니다. 서버가 Hysteria2를 제공하더라도 현재 네트워크에서 연결할 수 있다는 보장은 없습니다. 먼저 포트, UDP 경로, 인증 정보를 확인하세요.

인증, 보안, 추가 조건

Server와 Port는 실제 서버를 가리켜야 하며 인증 항목은 기존 자료와 일치해야 합니다. 기반 전송이 QUIC이라고 TLS 관련 서버 이름 및 인증서 검증을 생략할 수는 없습니다. 설정에 혼잡 방지 조건이 포함되어 있다면 활성화 여부와 해당 비밀 정보도 확인하세요. 양쪽 설정이 다르면 초기 통신 단계에서부터 실패할 수 있습니다. 혼잡 방지용 비밀번호, 인증 비밀번호, 인증서 이름은 서로 다른 역할이므로 한 항목에 대신 입력하지 마세요.

Hysteria2와 이전 세대 프로토콜은 이름이 비슷하다는 이유로 함께 사용할 수 없습니다. 가져온 뒤 Type이 올바른지 확인하고 공유 링크를 읽어들인 결과가 현재 자료의 프로토콜 유형과 일치하는지 살펴보세요. 서버에서 요구하는 ALPN, 인증서 조건, 기타 확장 설정이 클라이언트에 제대로 반영되지 않으면 핸드셰이크에 실패할 수 있습니다. 링크를 인식하지 못한다면 이해하지 못한 매개변수를 삭제하고 계속 다시 가져오기보다 먼저 설정 자료의 항목 설명을 확인하세요.

대역폭 설정은 속도를 보장하지 않습니다

일부 설정에는 특정 혼잡 제어 방식의 동작에 영향을 주는 업로드 및 다운로드 대역폭 값이 포함됩니다. 이 값은 알고리즘이 참고하는 조건이지 네트워크에 대역폭을 요청하는 설정이 아닙니다. 값을 높인다고 해당 처리량을 얻을 수 있는 것도 아닙니다. 실제 회선 용량보다 훨씬 높게 입력하면 대기열, 패킷 손실, 재전송이 늘어 상호작용이 필요한 요청이 오히려 느려질 수 있습니다. 너무 낮게 입력해도 활용 가능한 처리량이 제한될 수 있으므로 클라이언트와 서버에서 사용하는 방식의 의미를 확인하세요. 다른 네트워크의 값을 그대로 복사하지 마세요.

단위도 중요합니다. 초당 메가비트와 초당 메가바이트는 서로 다른 단위이며 통신사에서 표시하는 접속 속도, 시스템 다운로드 속도, 설정 항목이 각기 다른 단위를 사용할 수 있습니다. 업로드와 다운로드도 구분해야 합니다. 모바일 네트워크의 두 방향은 대칭적이지 않은 경우가 많습니다. 다운로드 최고 속도를 한 번 측정했다고 지속적인 업로드 성능까지 알 수는 없습니다. 작업에 영상 통화나 파일 업로드가 포함되면 업로드 대기열이 다른 요청에 영향을 줄 수도 있습니다. 값을 변경하기 전에 원래 값을 저장해 되돌아갈 기준을 남기세요.

iOS에서 높은 처리량이 지속되면 무선 통신과 프로세서가 계속 작동합니다. UDP 기반 전송, 사용자 공간 처리, 패킷 손실 복구에도 추가 작업이 필요합니다. 그러나 같은 작업을 더 빨리 끝내면 무선 통신이 지속되는 시간이 줄어들 수도 있으므로 순간 소비 전력만으로 전체 에너지 사용량을 판단해서는 안 됩니다. 짧은 작업, 연속 다운로드, 백그라운드 대기 상태를 각각 관찰하세요. 최대 속도 전송 상태를 유휴 상태와 직접 비교한 뒤 프로토콜의 배터리 성능을 단정하지 마세요.

네트워크의 UDP 지원이 불안정하다면 대역폭 값을 반복해서 올리지 말고 비교 기준으로 사용할 수 있는 다른 기존 조합을 보존하세요. 네트워크 경로 문제, 인증서 불일치, 알고리즘 설정 문제는 서로 다른 유형이므로 계층별로 확인해야 합니다. 먼저 연결을 정상화한 뒤 처리량을 조정하면 불필요한 시도를 줄일 수 있습니다.

설정 항목의 역할에 따라 가져온 결과 확인

구독을 가져오면 수동 입력을 줄일 수 있지만 확인 작업까지 생략할 수는 없습니다. 네 가지 그룹으로 점검하세요. 주소에는 Server와 Port, 인증에는 Password, UUID 또는 키, 전송에는 Transport, Host, Path, 보안에는 TLS, SNI, 인증서 검증 설정이 포함됩니다. 프로토콜마다 모든 항목을 사용하는 것은 아니므로 없는 항목을 완전한 설정처럼 보이게 하려고 추가할 필요는 없습니다. 이름이 같더라도 현재 프로토콜에서의 의미를 확인하세요. 특히 Password와 각종 추가 비밀 정보를 혼용해서는 안 됩니다.

주소에 포함된 도메인은 로컬 DNS에서 먼저 조회되거나 클라이언트 DNS 정책의 영향을 받을 수 있습니다. 대상 웹사이트 도메인은 다른 방식으로 조회될 수도 있습니다. 서버 도메인을 조회하지 못하면 프록시 서버에 연결할 수 없습니다. 대상 도메인 조회에 문제가 있으면 프록시에는 연결되지만 특정 사이트가 열리지 않을 수 있습니다. 두 문제를 혼동하지 마세요. 먼저 어떤 도메인에서 실패하는지 확인한 다음 해당 조회 경로를 점검하는 편이 모든 DNS 설정을 바꾸는 것보다 원인을 찾기 쉽습니다.

세 가지 모드로 요청의 경로를 결정합니다

Global Routing의 Config는 현재 설정에 있는 규칙에 따라 요청을 처리하고, Proxy는 처리 가능한 요청을 프록시 경로로 보내며, Direct는 직접 연결합니다. 각 모드에 해당하는 한국어 설명은 설정, 프록시, 직접 연결입니다. 프록시 경로를 이용하려면 사용할 수 있는 항목과 정책 선택이 필요합니다. Proxy로 전환한다고 서버가 자동으로 검색되는 것은 아닙니다. Config에서는 요청이 Direct로 분기될 수 있으므로 웹사이트가 열린다는 사실만으로 선택한 프로토콜이 통신에 사용됐다고 볼 수 없습니다.

규칙은 일반적으로 순서에 따라 일치 여부를 판단합니다. 더 구체적인 조건이 의도한 대로 적용되는 위치에 배치하세요. DOMAIN-SUFFIX는 도메인 접미사를 일치시키고 GEOIP는 주소 위치 데이터베이스를 기준으로 판단하며 IP-CIDR은 주소 범위를 일치시킵니다. FINAL은 앞에서 일치하지 않은 요청을 처리합니다. 도메인 규칙과 IP 주소 규칙은 서로 다른 정보를 사용하며, 일부 주소 규칙은 조회 결과가 필요합니다. 데이터베이스 범위, IPv6, 대상의 실제 주소, 조회 시점도 규칙 일치에 영향을 줄 수 있습니다. 규칙 키워드를 프로토콜 설정 항목과 혼동하지 마세요.

[Rule]
DOMAIN-SUFFIX,example.com,PROXY
IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
GEOIP,CN,DIRECT
FINAL,PROXY

이 예시는 Shadowrocket 설정에서 규칙 행이 구성되는 방식을 보여 주며, 전체 설정을 대체해 바로 사용할 수 있는 완성본이 아닙니다. PROXY와 DIRECT는 예시에서 사용한 정책 식별자입니다. 실제 설정에는 사용할 수 있는 프록시 선택과 기타 필수 항목이 필요합니다. 첫 번째 행은 예시 도메인 접미사를 프록시로 보내고, 두 번째 행은 지정한 사설 주소 범위를 직접 연결하며, 세 번째 행은 주소 위치를 기준으로 판단하고 마지막 행은 기본 처리를 제공합니다. 순서를 설명하기 위한 조각을 백업하지 않은 개인 설정에 덮어쓰지 마세요.

설정 파일과 구독 자료의 역할은 서로 다릅니다

구독은 보통 서버 항목을 갱신하고 설정 파일은 규칙 및 기타 설정을 담을 수 있습니다. 서로 같은 종류의 자료가 아닙니다. 구독을 갱신한 뒤 서버 항목은 사용할 수 있어도 Config가 이전 정책을 가리키면 예상과 다른 결과가 나올 수 있습니다. 반대로 규칙 파일이 정상이어도 항목의 인증 정보가 만료됐다면 프록시 요청을 처리할 수 없습니다. 문제를 확인할 때는 현재 사용 중인 항목과 설정을 각각 기록하세요. 같은 표시 이름이 갱신 후에도 재사용될 수 있으므로 이름만 저장하지 마세요.

IPv6도 주의해서 확인해야 합니다. 서버 도메인이 IPv4와 IPv6 주소를 모두 반환할 수 있고 대상 사이트도 두 주소 체계로 접속될 수 있습니다. 로컬 네트워크에서 한 주소 체계를 제대로 지원하지 않으면 간헐적인 오류나 일부 대상의 긴 대기 시간이 생길 수 있습니다. 먼저 프로토콜이 지원되지 않는다고 단정하지 말고 실제 연결에서 어떤 주소가 선택됐는지 확인해 두 경로를 각각 검사하세요. 규칙의 IP-CIDR과 IP-CIDR6도 해당 주소 체계에 맞게 사용해야 합니다. IPv4 범위 규칙 하나가 IPv6까지 포함할 것이라고 기대하지 마세요.

프로토콜을 검증할 때는 해당 정책으로 전달될 요청 하나를 명확히 정한 뒤 연결 기록으로 경로를 확인하세요. 검증을 마치면 일상적으로 사용하는 Config로 돌아가 자주 쓰는 앱을 다시 테스트합니다. 임시 테스트 모드를 최종 설정으로 오해하지 않도록 하세요. 프로토콜 연결은 기본 조건이며 라우팅과 이름 조회까지 정상이어야 제대로 사용할 수 있습니다.

제약 조건을 먼저 정한 뒤 조합을 비교하세요

프로토콜 선택의 첫 질문은 어느 프로토콜이 가장 빠른지가 아니라 현재 서버에서 실제로 사용할 수 있는 전체 조합이 무엇인지입니다. 사용 가능한 프로토콜, UDP 조건, 인증서 요구 사항, 사용 목적을 정리한 뒤 호환되지 않는 항목을 제외하세요. 사용할 수 있는 설정이 하나뿐이라면 먼저 올바르게 연결하는 데 집중하세요. 여러 조합을 비교할 때는 같은 서버 지역, 같은 시간대, 같은 작업을 사용해 서버 성능 차이를 프로토콜 성능 차이로 오해하지 않도록 하세요.

안정적인 Wi-Fi에서 웹을 탐색할 때는 짧은 요청, DNS, 연결 설정이 중요하고, 파일을 오래 전송할 때는 지속 처리량과 혼잡이 중요합니다. Wi-Fi와 셀룰러 네트워크를 자주 전환한다면 복구 시간과 앱의 재연결 동작을 확인하세요. 기존 내부 네트워크에 접속할 때는 주소 계획, 반환 경로, 권한도 고려해야 합니다. WireGuard의 IP 터널 방식, 일반 프록시의 요청 방식, QUIC의 전송 특성은 각각 적합한 조건이 다릅니다. 이름만 보고 일괄적으로 순위를 정하지 마세요.

6단계로 문제 범위 좁히기

1단계는 로컬 네트워크의 기본 상태를 확인하는 것입니다. Direct에서 네트워크 자체가 필요한 연결을 지원하는지, 네트워크 로그인이 필요한지 확인하세요. 2단계에서는 Server 도메인 조회와 포트 조건을 점검하되 TCP와 UDP를 구분하세요. 서버에 전혀 연결할 수 없다면 UUID, Password, 규칙 순서를 바꿔도 대개 해결되지 않습니다. 오류 현상을 기록하고 이미 연결이 확인된 다른 네트워크에서 비교하세요. 여러 항목을 연달아 바꾸지 마세요.

3단계에서는 시스템 시간, SNI, 인증서 도메인, 인증서 체인을 포함해 TLS와 인증서를 확인합니다. 4단계에서는 Type에 따라 암호화 방식, 비밀번호, UUID, 키 쌍 등 프로토콜 인증 정보를 확인합니다. 핸드셰이크 오류와 인증 오류가 화면에 모두 연결 실패로 표시될 수 있으므로 로그에 명시된 단계 정보를 함께 살펴보세요. 로그에서 충분한 근거를 얻을 수 없다면 불확실성을 밝히세요. 시간 초과만으로 비밀번호가 맞다거나 틀렸다고 단정해서는 안 됩니다.

5단계에서는 라우팅과 DNS를 확인합니다. 테스트 요청이 선택한 정책으로 전달되는지, 대상 도메인이 정상적으로 조회되는지, 필요한 주소 체계를 사용할 수 있는지 살펴보세요. 6단계에서는 MTU, UDP 중계, 혼잡 설정, 서버 부하, 대용량 트래픽 제한처럼 지속 전송과 관련된 문제를 확인합니다. 앞 단계가 정상이어야 성능 설정 변경의 효과를 판단할 수 있습니다. 짧은 요청은 되지만 큰 요청이 실패한다면 재현 가능한 작업으로 시험하세요. Connectivity Test만 반복하지 마세요.

배터리와 속도를 유효하게 비교하는 방법

신호 조건이 비슷한 같은 기기에서 테스트와 무관한 대용량 작업을 중지한 뒤 같은 웹사이트 묶음 또는 같은 크기의 파일을 각각 전송하세요. 작업 시작부터 완료까지 걸린 시간, 실패 횟수, 네트워크 전환 후 복구 여부, 일정 시간 동안의 시스템 배터리 사용량을 기록합니다. 화면 밝기, 신호 세기, 실행 중인 앱이 다른 상태에서 얻은 결과로 프로토콜을 비교하지 마세요. 순간적인 온도 변화나 배터리 잔량이 한 번에 변하는 현상에는 다른 원인이 있을 수 있으므로 반복 측정해야 참고할 만한 결과를 얻을 수 있습니다.

On Demand는 조건에 따라 연결을 시작하는 기능이지 모든 앱의 세션을 항상 유지하는 기능은 아닙니다. 시스템 네트워크 전환, 앱 일시 중지, 원격 서버의 연결 종료로 새로운 연결이 필요할 수 있습니다. Keepalive를 자주 보내면 일부 유휴 연결의 복구가 개선되는 대신 대기 중 활동이 늘 수 있습니다. 장시간 연결을 재사용하면 핸드셰이크 일부를 줄일 수 있지만 여러 요청이 같은 혼잡 경로를 공유할 수도 있습니다. 먼저 기존 설정으로 사용하고 명확하고 반복되는 문제가 있을 때만 조건을 바꾸세요.

검증을 마친 기준 설정을 보존한 뒤 항목별로 최적화를 시도하세요. 프로토콜 설정은 이 페이지의 해당 절에서 확인하고, 처음 연결하는 방법은 사용 설명서를 참고하세요. 반복되는 사용 문제는 문제 해결에서 확인할 수 있으며, 다운로드 및 최초 설치 문제는 설치 및 실행 안내를 참고하세요. 올바른 결론은 모든 기기와 네트워크에 영구적으로 적용할 최적의 프로토콜을 정하는 것이 아니라, 특정 네트워크에서 특정 작업을 완료한 설정이 무엇인지 기록하는 것입니다.