Shadowrocket 프로토콜 매뉴얼

연결은 프로토콜 이름 하나로 설명되지 않습니다

프록시 연결에는 보통 대상 주소, 프록시 프로토콜, 전송 방식, 인증 정보, 보안 설정이 포함됩니다. 대상 주소는 클라이언트가 연결할 서버를 지정하고, 프록시 프로토콜은 대상에 접근하는 방법과 사용자 확인 방식을 정의합니다. 전송 방식은 메시지를 전달하고, 보안 설정은 TLS 사용 여부와 인증서를 확인할 대상을 정합니다. 각 계층을 함께 살펴야 “VLESS를 선택했는데 연결 하나만 작동하는” 상황을 이해할 수 있습니다. 프로토콜 이름이 같아도 포트, 전송 방식, 인증 정보까지 같은 것은 아닙니다.

TCP는 순서가 보장된 신뢰성 있는 바이트 스트림을 제공하고, UDP는 전달을 직접 보장하지 않는 데이터그램 전송을 제공합니다. WebSocket은 기존 연결에서 메시지를 전달하는 방식이지, Shadowsocks와 같은 프록시 인증 프로토콜이 아닙니다. TLS는 보호된 통신 채널을 설정하지만 프록시 계정을 대신하지 않습니다. 구독 정보에 프로토콜 이름, WebSocket, TLS가 함께 표시된다면 서로 경쟁하는 선택지가 아니라 조합 설정으로 이해해야 합니다. 실제로 선택할 수 있는 항목은 현재 화면과 연결 정보에 따라 다릅니다.

주소, 이름, 포트를 각각 확인하세요

서버 주소는 도메인일 수도 있고 IP일 수도 있습니다. 포트는 서버가 실제로 연결을 수신하는 지점이므로, 특정 프로토콜에서 흔히 쓰는 포트 번호를 그대로 가져다 쓰면 안 됩니다. TLS를 사용하는 경우 연결 주소와 인증서 확인에 사용하는 이름이 다를 수 있습니다. 앞의 값은 서버를 찾는 데, 뒤의 값은 연결 대상의 신원을 확인하는 데 쓰입니다. 정보에 SNI 또는 Server Name이 별도로 표시되어 있다면 원문 그대로 확인하세요. 서버 주소를 IP로 바꿔도 기존 인증서 확인 방식이 유지된다고 단정할 수 없습니다.

인증 정보의 형식도 서로 다릅니다. 비밀번호, UUID, 키 쌍은 서로 바꿔 쓸 수 없습니다. UUID는 무작위 문자열처럼 보여도 임의의 비밀번호와 같지 않습니다. 공개 키는 신원을 확인할 상대에게 전달할 수 있지만, 개인 키는 이 기기에서 비밀로 보관해야 합니다. 복사할 때 앞뒤 공백, 줄바꿈, 대소문자, QR 코드에 담긴 정보가 완전한지 확인하세요. 먼저 설정 항목이 어느 계층에 속하는지 파악한 다음 서버 관리자에게 문의할지, 시스템 시간을 확인할지, 인증서 이름을 점검할지 결정하면 관련 없는 설정을 반복해서 바꾸는 일을 줄일 수 있습니다.

Global Routing은 서버 프로토콜을 바꾸지 않습니다

Global Routing의 Config, Proxy, Direct는 각각 현재 설정 파일의 규칙에 따른 정책 선택, 클라이언트가 처리하는 요청을 프록시로 보내는 방식, 직접 연결을 뜻합니다. 여기서 설명하는 것은 라우팅 결정이며, 서버를 다른 프로토콜로 바꾸는 기능이 아닙니다. Proxy로 전환하면 “테스트 요청이 예상한 정책을 거치지 않은” 상황을 확인하는 데 도움이 될 수 있지만, 잘못된 비밀번호나 유효하지 않은 인증서, 서버에서 활성화되지 않은 UDP 전달을 해결하지는 못합니다.

규칙의 PROXY, DIRECT, REJECT는 정책 키워드이며, 화면에서 선택하는 라우팅 모드와 대소문자 표기가 다릅니다. 규칙은 위에서 아래로 확인하며 일치하는 항목을 찾으면 멈춥니다. FINAL은 기본 처리를 위해 맨 마지막에 배치해야 합니다. 아래의 example.com은 문서용 예시일 뿐, 실제 서버를 테스트하는 데 사용할 수 없습니다. 이미 알고 있는 대상을 선택하고 연결 기록에서 적용된 정책을 확인하세요. 설정 파일의 정책 이름은 파일에 실제로 정의된 값과 일치해야 하며, 예시를 그대로 실행 가능한 완성 설정으로 간주하면 안 됩니다.

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

도메인을 어느 쪽에서 해석하는지도 진단에 영향을 줍니다. 클라이언트의 해석 실패, 서버의 해석 실패, 프록시 인증 실패는 비슷한 로딩 시간 초과로 보일 수 있지만 서로 다른 단계의 문제입니다. 원본 설정을 보관한 뒤 접속 정보에 도달할 수 있는지 확인하고, 인증, 대상 주소 해석, 규칙 순서 순으로 점검하세요. 한 번에 하나씩만 변경해야 증상과 원인을 연결할 수 있습니다. 규칙 순서에 대한 자세한 설명은 사용자 지정 규칙과 FINAL 기본 처리 안내를 참고하세요.

설계 목표와 발전 방향

Shadowsocks는 프록시 요청을 암호화된 연결에 담아 비교적 간결한 절차로 대상 주소를 전달하고 데이터를 중계하도록 설계됐습니다. 완전한 네트워크 계층 터널은 아니며, 일반적으로 TCP 연결과 UDP 데이터그램을 중심으로 프록시 기능을 제공합니다. 이 범위를 이해하는 것이 중요합니다. 앱이 클라이언트의 처리를 받는지, 도메인을 어디에서 해석하는지, 로컬 네트워크 주소를 직접 연결하는지는 시스템 연결 방식과 Shadowrocket 설정에 따라 달라지므로 프로토콜 이름만으로 모든 트래픽의 경로를 판단할 수 없습니다.

프로토콜의 암호화 방식은 계속 발전해 왔습니다. 최근 자료에서 흔히 볼 수 있는 AEAD 방식은 기밀성과 무결성 검사를 결합해 수신자가 데이터 변조를 확인할 수 있게 합니다. 세대별 방식에 따라 키 형식과 패킷 구조가 달라질 수도 있습니다. 선택할 때는 서버에서 제공한 Method를 정확히 따라야 하며 이름이 비슷한지만 보고 판단해서는 안 됩니다. 클라이언트 목록에 특정 방식이 표시된다고 해서 서버에서도 이를 사용하도록 설정한 것은 아닙니다. 다른 방식으로 바꾸면 인증 또는 복호화가 실패할 수 있습니다.

Method, Password 및 추가 설정

기본 확인 항목은 Address, Port, Method, Password입니다. Method는 한 글자도 다르지 않게 입력하고 Password는 원래 문자를 그대로 유지해야 합니다. 일부 최신 암호화 방식은 지정된 길이의 인코딩 키가 필요하므로 임의로 만든 짧은 문구로 대체할 수 없습니다. 연결 정보에서 명시적으로 요구하지 않는 한 인코딩된 키를 직접 디코딩해 붙여 넣지 마세요. 가져오기 링크에 추가 옵션이 포함되어 있다면 먼저 전체를 가져온 뒤 수동 입력 화면에 표시되는 항목과 하나씩 비교해 서버에 필요한 설정이 빠지지 않았는지 확인하세요.

일부 연결 정보에는 추가 캡슐화나 확장 기능이 포함될 수 있습니다. 이런 옵션은 Shadowsocks라는 이름만으로 자동 제공되는 기능이 아니며, 플랫폼이나 클라이언트가 달라도 화면에 똑같이 표시된다고 보장할 수 없습니다. 서버에서 실제 사용하는 조합과 현재 Shadowrocket 화면에서 해당 옵션을 지원하는지 확인하세요. 자료에 “Shadowsocks”만 적혀 있고 Method와 인증 정보가 없다면 연결에 필요한 정보가 부족합니다. 흔히 쓰는 값을 추측하지 말고 이미 보유한 서버의 관리자에게 확인하세요.

속도와 iOS 배터리 사용량은 어떻게 볼까요?

Shadowsocks의 통신 구조는 비교적 간결하지만, 모든 상황에서 가장 빠르다는 뜻은 아닙니다. 최신 기기는 일부 암호화 알고리즘을 하드웨어로 가속하지만 칩에 따라 다른 방식의 효율은 달라질 수 있습니다. 패킷 길이와 연결 수, 무선 신호도 실제 처리 비용에 영향을 줍니다. 짧은 웹 요청은 주로 DNS 해석과 연결 설정 시간에 좌우되고, 지속적인 다운로드는 링크 용량과 서버 부하의 영향을 더 많이 받습니다. 같은 기기와 대상, 비슷한 네트워크 조건으로 측정하지 않았다면 속도 차이 전체를 암호화 방식 탓으로 돌릴 수 없습니다.

UDP는 별도로 테스트해야 합니다. 서버에서 TCP만 열었거나 방화벽이 UDP를 허용하지 않을 수 있고, 중간 네트워크가 UDP를 다르게 처리할 수도 있습니다. 따라서 웹 페이지는 열리는데 실시간 앱은 제대로 작동하지 않는 상황도 가능합니다. UDP 테스트가 실패했다고 바로 비밀번호를 바꾸지 마세요. TCP 인증이 안정적으로 통과했다면 이미 확인된 인증 항목을 반복해서 편집하기보다 UDP 전달 기능과 해당 포트, 서버 정책을 먼저 확인하는 편이 효과적입니다. 프로토콜이 데이터그램을 지원한다고 해서 앱이 예상대로 해당 접속 정보를 사용한다는 뜻은 아닙니다.

iOS에서 배터리 사용량에 흔히 영향을 미치는 요인은 네트워크 확장이 처리하는 데이터양, 연결 재설정, 무선 네트워크 품질, 백그라운드 작동입니다. 짧은 연결이 자주 반복되면 안정적인 장기 연결보다 핸드셰이크 비용이 더 크게 드러날 수 있고, 신호가 약하면 재전송 비용이 암호화 방식 간 차이를 가릴 수 있습니다. Shadowsocks는 이미 보유한 서버가 제공하는 경량 프록시 옵션으로 평가하되, 일정한 절전 순위를 정해 두지는 마세요. 사용할 수 있는 설정을 저장하고 안정성을 확인한 뒤 성능을 비교하면 문제 해결과 속도 측정이 서로 영향을 주는 일을 줄일 수 있습니다.

VMess에는 왜 더 많은 프로토콜 처리가 포함될까요?

VMess는 사용자 인증, 요청 정보, 데이터 보호를 자체 프로토콜 체계에 포함하도록 설계됐습니다. 서버가 사용자를 확인하고 대상 트래픽을 전달할 수 있도록 클라이언트는 정해진 형식에 따라 요청을 구성해야 합니다. 다양한 전송 방식과 조합할 수 있으므로 VMess 연결 정보에는 서버 주소와 UUID 외에도 보안 방식, 전송 유형, TLS 설정이 포함될 수 있습니다. 과거 설정에 호환성 관련 항목이 있더라도 이를 임의로 추가하거나 삭제해서는 안 됩니다. 현재 서버에서 실제로 사용하는 설정과 사용할 수 있는 가져오기 정보를 기준으로 확인하세요.

VMess의 인증 과정은 시간 동기화가 필요합니다. 접속 정보에 도달할 수 있는데 기기를 바꾼 뒤 계속 인증에 실패한다면 시스템의 날짜, 시간, 시간대를 확인하고 자동 시간 설정을 우선 사용하세요. 포트에 연결할 수 있다고 인증까지 성공한 것은 아닙니다. 네트워크 연결은 첫 단계일 뿐이며, 서버에서 이후 프로토콜 헤더와 인증을 거부할 수도 있습니다. 테스트 버튼을 반복해서 눌러도 시간 오차는 해결되지 않으며, 오히려 인증 오류를 불안정한 네트워크 문제로 오해할 수 있습니다.

VLESS는 무엇을 단순화하고, 무엇에 의존할까요?

VLESS는 가벼운 인증과 요청 전달에 중점을 두고 데이터 보호는 외부 보안 기능에 더 많이 맡기도록 설계됐습니다. UUID는 여전히 신원 확인에 사용되지만, 프로토콜 계층에 범용 데이터 암호화가 내장되어 있지는 않습니다. 그렇다고 연결 전체가 보호되지 않는다는 뜻은 아닙니다. TLS를 올바르게 설정해 사용하면 전송 채널을 보호할 수 있습니다. 반대로 외부 보안 기능이 없다면 VLESS를 선택했다는 이유만으로 데이터가 암호화된다고 가정해서도 안 됩니다. 보안 속성은 전체 설정 조합을 확인해야 합니다.

UUID를 그대로 둔 채 Type만 바꿔 VMess와 VLESS를 서로 전환할 수는 없습니다. 서버에서 해당 프로토콜을 수신해야 하고 외부 전송 방식도 일치해야 합니다. 일부 연결 정보에는 추가 흐름 제어 또는 보안 옵션이 포함될 수 있지만 모든 전송 조합에 적용되는 것은 아닙니다. 클라이언트에 항목이 표시되지 않는다면 현재 선택한 유형과 서버 요구사항, 지원 범위를 먼저 확인하세요. 항목을 표시하려고 다른 프로토콜로 임의 변경하면 원래 올바른 접속 정보와 연결이 어긋날 수 있습니다.

WebSocket, Host, Path의 관계

WebSocket을 사용할 때 Path는 서버가 해당 요청을 받는 경로이므로, 일반적으로 앞의 슬래시와 전체 문자열을 그대로 유지해야 합니다. Host는 HTTP 요청의 호스트 정보이며 SNI는 TLS 핸드셰이크와 인증서 선택에 사용됩니다. 두 값은 같은 경우가 많지만 서로 다른 계층에 속하므로 항상 같은 항목으로 볼 수는 없습니다. 서버 앞에 리버스 프록시가 있다면 Path나 Host가 일치하지 않아 프록시 프로토콜의 인증이 시작되기 전에 HTTP 오류가 반환될 수 있습니다. 이런 실패는 UUID를 바꿔도 해결되지 않습니다.

도메인 인증서를 사용할 때는 인증서 검증을 켜고 Server Name이 인증서에 포함된 이름과 일치하는지 확인하세요. 인증서 오류가 발생하면 시스템 시간, 이름 표기, 인증서 유효성, 서버 인증서 체인을 먼저 점검합니다. 인증서 검증을 건너뛰면 연결 대상의 신원을 확인하는 수준이 낮아지므로 일반적인 해결 방법으로 사용하면 안 됩니다. 관리자가 IP 접속 주소와 별도의 검증 도메인을 제공했다면 이 역할 분리를 유지하고 모든 이름을 IP로 바꾸지 마세요.

iOS에서 VMess와 VLESS의 배터리 사용량 차이를 프로토콜 헤더 크기만으로 예측할 수는 없습니다. 외부 TLS 핸드셰이크, WebSocket 캡슐화, 연결 재사용, 서버와의 거리도 결과에 영향을 줍니다. 자주 다시 연결하는 환경에서는 안정적으로 데이터를 전송할 때의 프로토콜 차이보다 연결 설정 비용이 더 크게 나타날 수 있습니다. 이미 보유한 서버가 한 종류만 제공한다면 해당 조합을 올바르게 사용하는 것이 우선입니다. 두 종류를 모두 제공한다면 대상과 테스트 조건을 고정하고 처음 접속, 연속 전송, 네트워크 전환 후 복구를 비교하세요. 한 번 측정한 최고 속도만으로 판단하지 마세요.

Trojan은 보안 채널을 먼저 설정합니다

Trojan은 일반적으로 TLS 연결 안에서 비밀번호 인증과 프록시 요청 전달을 수행하므로 인증서 검증이 연결 과정을 이해하는 핵심입니다. 클라이언트는 먼저 서버에 연결해 TLS를 설정한 다음 프로토콜 인증 정보를 보냅니다. 핸드셰이크 단계에서 실패했다면 아직 비밀번호를 정상적으로 확인하는 절차에 도달하지 않은 것입니다. TLS는 정상이지만 인증에 실패한다면 비밀번호와 서버의 프로토콜 설정을 확인해야 합니다. 두 오류를 구분하면 인증서 문제에 비밀번호를 반복해서 바꾸는 일을 줄일 수 있습니다.

Address, Port, Password와 TLS에 사용할 이름을 함께 확인하세요. SNI는 서버가 알맞은 인증서와 접속 정보를 선택하도록 돕지만 임의로 입력하는 장식용 항목은 아닙니다. 연결 정보에 도메인이 지정되어 있다면 기본 확인이 끝날 때까지 원래 값을 유지하세요. 서버 구조를 정확히 알고 있을 때만 주소와 검증 이름을 조정해야 합니다. Trojan이 TLS를 사용한다고 해서 TLS를 사용하는 모든 서버를 해당 프로토콜의 접속 정보로 쓸 수 있는 것은 아닙니다. 서버에서 실제로 Trojan 프록시 서비스와 인증 계정을 제공해야 합니다.

HTTP 프록시는 HTTP 웹사이트 접속을 뜻하지 않습니다

HTTP 프록시는 HTTP 의미에 따라 전달 요청을 받고, HTTPS 대상에 접속할 때는 보통 CONNECT로 바이트 통신 채널을 설정합니다. 여기서는 클라이언트와 프록시 서버 사이의 연결, 프록시 서버와 대상 웹사이트 사이의 연결을 구분해야 합니다. 대상 웹사이트가 HTTPS를 사용하더라도 첫 번째 연결이 자동으로 암호화된 프록시 연결이 되는 것은 아닙니다. 프록시 접속 정보 자체가 지원되는 TLS 등의 보호 기능을 사용할 때에만 첫 번째 연결도 그에 맞는 보호를 받습니다. 개인정보 보호 범위를 판단할 때 브라우저 주소창의 자물쇠 표시만 봐서는 안 됩니다.

HTTP 프록시는 Username과 Password가 필요할 수도 있고 서버의 다른 접근 제어 방식을 사용할 수도 있습니다. 인증 정보는 이미 보유한 서버 자료에서 확인해야 하며 웹사이트 계정을 프록시 인증 항목에 입력하면 안 됩니다. TLS로 보호되는 HTTP 프록시 접속 정보라면 해당 유형과 인증서 이름을 확인하세요. 일반 HTTP 포트처럼 테스트한 뒤 서버에 문제가 있다고 단정하지 마세요. HTTP 요청이 수락되어도 서버가 모든 CONNECT 대상이나 포트를 허용한다는 뜻은 아닙니다.

SOCKS5의 범용성과 명확한 한계

SOCKS5는 인증 방식과 대상 주소를 협상하는 범용 프록시 프로토콜입니다. 도메인과 IP 주소를 대상으로 지정할 수 있고 UDP 관련 방식도 정의하지만, 기본 프로토콜 자체는 일반적인 전송 암호화를 제공하지 않습니다. 사용자 이름과 비밀번호는 인증에 사용되며 이후 데이터에 자동으로 암호화 채널을 설정하지는 않습니다. 클라이언트와 서버 사이의 연결을 보호해야 하는 경우 실제 외부 보안 기능과 신뢰할 수 있는 네트워크 환경을 함께 확인해야 합니다. “비밀번호가 있다”는 사실을 “전체 연결이 암호화된다”는 뜻으로 해석하면 안 됩니다.

SOCKS5의 UDP를 사용하려면 클라이언트, 서버, 중간 네트워크가 모두 조건을 충족해야 합니다. 서버가 TCP 전달만 구현했을 수도 있고 UDP 연결에서 반환하는 주소에 네트워크 접근성이 부족할 수도 있습니다. 도메인을 어느 쪽에서 해석하는지도 요청 형식과 클라이언트 설정에 따라 달라집니다. IP 주소로는 연결되지만 도메인으로는 안 된다면 먼저 해석 경로를 확인하세요. TCP는 되는데 실시간 앱이 작동하지 않는다면 UDP를 점검하고 모든 실패를 계정 오류로 보지 마세요.

이 세 가지 프로토콜은 이미 보유한 접속 정보에 따라 선택해야 합니다. 회사 네트워크에서 HTTP 프록시를 제공한다면 인증과 접근 범위에 맞춰 설정하세요. 실험실이나 로컬 네트워크에서 SOCKS5 서비스를 제공한다면 보호 범위를 분명히 파악하세요. Trojan 연결 정보를 보유하고 있다면 TLS 설정을 그대로 유지하세요. 이름이 더 복잡해 보인다는 이유로 유형을 바꾸지 마세요. iOS에서는 특정 프로토콜 이름 하나보다 프록시 요청 방식, 핸드셰이크 빈도, 네트워크 품질이 로딩 속도와 배터리 차이를 더 잘 설명하는 경우가 많습니다.

애플리케이션 계층 프록시와의 차이

WireGuard는 IP 패킷을 위한 암호화 터널을 만들고, 간결한 프로토콜 구조와 고정된 최신 암호화 모음으로 설정을 단순화합니다. 주로 연결 요청을 전달하는 프록시 프로토콜과 달리 로컬 인터페이스 주소, 피어의 신원, 피어로 보낼 주소 범위를 설정해야 합니다. 따라서 WireGuard 연결 정보에는 서버 주소와 비밀번호뿐 아니라 로컬 개인 키, 피어 공개 키, 터널 주소, 라우팅 설정도 포함되는 경우가 많습니다. 항목 이름을 하나씩 외우는 것보다 이 관계를 이해하는 편이 유용합니다.

WireGuard는 외부 전송에 UDP를 사용하므로 현재 네트워크에서 UDP를 안정적으로 전송할 수 있어야 합니다. 웹사이트에 직접 연결된다고 해서 UDP 터널 접속도 가능하다는 뜻은 아닙니다. 엔드포인트 도메인 해석과 포트 개방, 서버에서의 응답 경로가 모두 정상이어야 합니다. 핸드셰이크에 성공한 뒤에도 대상 트래픽의 라우팅이 올바른지, 서버가 해당 트래픽을 전달하도록 허용하는지 확인해야 합니다. 따라서 “핸드셰이크가 표시됨”과 “모든 대상에 접속할 수 있음”은 서로 다른 결론입니다.

PrivateKey, PublicKey와 주소의 역할

PrivateKey는 로컬에서 비밀로 보관해야 하며 PublicKey는 피어가 로컬의 신원을 확인하는 데 사용됩니다. 서버 공개 키와 클라이언트 공개 키는 서로 바꿔 입력할 수 없습니다. 연결 정보에 사전 공유 키가 있다면 이는 양쪽에서 일치해야 하는 별도 항목이며, 공개 키와 개인 키를 대신하는 범용 비밀번호가 아닙니다. 문의용 스크린샷이나 문제 기록에 개인 키를 노출하지 마세요. 일반적인 Password 항목이 없어도 가져온 연결 정보에 직접 접속할 수 있는 민감한 신원 정보가 포함될 수 있습니다.

Address는 터널 인터페이스 안의 로컬 주소로, 서버의 공인 IP나 임의의 로컬 네트워크 주소를 뜻하지 않습니다. 일반적으로 서버 관리자가 할당하며 피어 설정과 연결되어 있습니다. 외부에서 연결할 수 있는 서버 엔드포인트는 Endpoint입니다. Address를 서버 IP로 바꾸면 터널 내부와 외부 네트워크를 혼동하게 됩니다. 다른 기기의 인터페이스 주소와 신원 정보를 복사하면 주소 충돌이나 피어 연결 대상 변경이 발생할 수 있으므로 현재 기기에 할당된 서버 정보를 사용하세요.

AllowedIPs, MTU, 연결 유지

AllowedIPs는 어떤 대상 주소를 해당 피어로 보낼지 판단하고, 수신 데이터의 주소가 해당 피어에 속하는지 확인하는 데도 사용됩니다. 도메인별 웹사이트 규칙 목록이 아닙니다. Shadowrocket의 정책 라우팅과 함께 작동하는지는 현재 가져오기 방식과 화면 기능을 고려해야 합니다. 특정 서브넷만 포함한 연결 정보를 호환성을 높이겠다고 임의로 모든 주소 범위로 바꾸지 마세요. 접근 경계가 달라질 수 있습니다. 특정 내부 네트워크에 접속할 수 없다면 터널 주소, 피어 범위, 서버의 응답 경로를 함께 확인하세요.

MTU는 터널 인터페이스에서 전달할 데이터 패킷의 크기 한도를 정합니다. 외부 캡슐화가 공간을 차지하고 경로마다 단편화나 큰 UDP 패킷을 처리하는 방식이 다를 수 있어 작은 요청은 정상인데 큰 응답은 멈추는 현상이 생길 수 있습니다. 문제를 확인할 때는 큰 데이터 전송에서만 이상이 발생하는지 먼저 살펴보고 서버의 권장값에 따라 조정하세요. 아무 값이나 작게 설정하는 것이 보편적인 해결책은 아닙니다. MTU를 낮추면 같은 양의 데이터를 보내는 데 필요한 패킷 수가 늘어나며 지나친 조정은 추가 부담을 일으킵니다. 변경할 때마다 구체적인 변화를 기록하세요.

PersistentKeepalive는 일부 네트워크에서 주소 변환 매핑을 유지하는 데 도움이 되지만, 패킷을 계속 보내면 무선 통신이 활성 상태로 유지되는 시간이 늘어날 수 있습니다. iOS에서는 서버 요구사항과 실제 유휴 연결 끊김 현상에 따라 사용할지 결정하고 간격을 무조건 줄이지 마세요. WireGuard의 연산 효율이 기기 전체의 배터리 절약을 뜻하지는 않습니다. 터널 트래픽, 연결 유지, 신호 강도, 네트워크 전환이 모두 결과에 영향을 줍니다. 명확한 네트워크 계층 주소와 서브넷 접근이 필요한 환경에서 사용할 수 있으며, 이를 위해서는 현재 기기에 맞는 완전한 피어 설정 정보가 있어야 합니다.

전송 방식에서 시작하는 설계 선택

Hysteria2는 QUIC를 기반으로 프록시 데이터를 전송하며 지연과 패킷 손실이 있는 네트워크 환경을 고려합니다. QUIC는 UDP 위에서 연결 관리, 신뢰성 있는 전송, 혼잡 제어 등을 구현하므로 “외부 전송에 UDP를 쓴다”는 말이 앱 데이터의 신뢰성 처리가 전혀 없다는 뜻은 아닙니다. 다만 사용 가능한 UDP 경로는 여전히 필요합니다. 네트워크에서 관련 패킷을 계속 버린다면 프로토콜 내부 기능만으로 연결 가능성을 만들어낼 수 없습니다. 프로토콜을 선택하기 전에 이 조건부터 확인하는 것이 대역폭 설정을 계속 바꾸는 것보다 중요합니다.

QUIC의 스트림 방식은 일부 스트림 간 지연 문제를 줄일 수 있지만 무선 신호가 약하거나 공유 회선이 혼잡하거나 서버 용량이 부족한 문제까지 없애지는 못합니다. 단일 연결의 실제 성능은 클라이언트 구현, 대상 서버의 응답, 네트워크 경로 변화에도 영향을 받습니다. Hysteria2와 다른 세대 프로토콜의 이름이 비슷해도 연결 정보를 그대로 함께 사용할 수 있다는 뜻은 아닙니다. Type, 인증 방식, 추가 설정은 실제 서버와 일치해야 합니다. 가져오기에 성공했다는 것은 정보를 읽을 수 있다는 뜻일 뿐이므로 핸드셰이크와 접속도 확인해야 합니다.

인증, TLS, 선택적 캡슐화

기본 확인 항목은 Address, Port, 인증 정보, TLS 이름입니다. 인증 문자열은 이미 보유한 서버에서 제공되며 구분 문자를 포함한 전체 내용을 그대로 유지해야 할 수 있습니다. 비밀번호처럼 보이는 부분만 복사하지 마세요. TLS 인증서 체인과 유효성, 이름도 정상적으로 검증해야 합니다. 클라이언트에서 인증서 오류가 표시되면 시스템 시간과 이름 설정을 먼저 확인한 다음 서버 인증서를 점검하세요. 잘못된 설정을 가리기 위해 인증서 검증을 계속 끄면 연결 대상의 신뢰할 수 있는 신원 확인이 불가능해집니다.

연결 정보에 선택적인 난독화 관련 설정이 추가로 포함될 수 있습니다. 이는 사용자 인증 및 TLS 인증서와 서로 다른 계층이며 양쪽에서 호환되는 설정을 사용해야 합니다. 서버에서 요구하지 않은 항목을 추가해도 서버가 패킷을 해석하지 못할 수 있습니다. 제공되지 않은 옵션은 기본값으로 두고 명시된 옵션은 하나씩 확인하세요. 특정 네트워크에서만 실패한다면 인증, 난독화, 대역폭을 한꺼번에 바꾸기보다 같은 연결 정보를 유지한 채 네트워크를 바꿔 테스트하는 편이 원인을 찾기 쉽습니다.

대역폭 값을 임의로 크게 입력하면 안 되는 이유

일부 설정에서는 업로드 및 다운로드 대역폭을 입력해 특정 혼잡 제어 모드의 속도 추정이나 상한 협상에 사용합니다. 효과는 클라이언트와 서버 설정에 따라 달라지므로 큰 값을 입력한다고 처리량이 늘어나는 것은 아닙니다. 실제 사용 가능한 용량보다 훨씬 높은 값을 설정하면 대기열 증가, 패킷 손실, 다른 트래픽과의 경쟁이 발생할 수 있습니다. 너무 낮으면 처리량이 제한될 수 있습니다. 먼저 단위를 확인해 bit와 byte를 구분하고 현재 접속 회선과 서버 권장값에 맞는 값을 사용하세요. 다른 사람의 속도 측정 화면에 나온 값을 그대로 가져오지 마세요.

모바일 네트워크 용량은 신호, 위치, 기지국 부하에 따라 변하므로 고정된 추정값이 모든 시간대에 맞지는 않습니다. 안정적인 Wi-Fi에서 셀룰러로 전환한 뒤 연결이 크게 불안정해지면 먼저 네트워크 자체의 가용 용량을 비교하고 대역폭 설정이 지나치게 공격적인지 확인하세요. 기본값이나 협상 방식으로 사용할 때도 매개변수가 적다는 이유만으로 더 나을 것이라고 판단하지 말고 짧은 요청과 지속 전송을 실제로 살펴보세요. 성능을 조정할 때는 명확한 증상을 정하고 한 번에 하나씩 변경하며 되돌릴 수 있도록 기록해야 합니다.

iOS에서 데이터 전송량이 많거나 패킷 손실 복구가 적극적이거나 대용량 전송이 지속되면 무선 통신 시간과 발열이 늘어날 수 있습니다. 한 번 다운로드가 더 빨랐다고 하루 종일 사용할 때 배터리를 덜 쓰는 것은 아닙니다. 반대로 같은 작업을 더 짧은 시간에 끝내면 전체 활성 시간이 줄어들 수도 있으므로 실제로 측정해야 합니다. 작업 시간, 실패율, 비슷한 사용 시간 동안의 배터리 소모를 함께 비교하고 한 가지 현상만으로 결론을 내리지 마세요. 테스트할 때는 관련 없는 대용량 작업을 중단해 백그라운드 다운로드를 프로토콜 탓으로 돌리지 않도록 합니다.

적용 조건은 “현재 네트워크에서 UDP를 사용할 수 있고 보유한 서버가 Hysteria2를 제공해 패킷 손실 환경에서의 성능을 확인할 필요가 있는 경우”로 설명하는 것이 적절합니다. 모든 TCP 방식을 무조건 대체하는 프로토콜은 아닙니다. 같은 서버의 다른 접속 정보는 정상인데 특정 네트워크에서만 이 접속 정보가 실패한다면 UDP 경로가 어떻게 처리되는지 먼저 살펴보세요. 모든 네트워크에서 실패한다면 서버 수신 설정, 인증, 인증서를 확인하세요. 조건에 따라 문제 범위를 좁히는 편이 대역폭 값을 계속 높이는 것보다 유용합니다.

“빠르다”를 관찰 가능한 과정으로 나누기

웹페이지를 여는 과정에는 도메인 해석, 연결 설정, 프록시 핸드셰이크, 대상 서버와의 핸드셰이크, 콘텐츠 전송이 포함됩니다. 처음 로딩이 느리다면 앞 단계에 시간이 걸렸을 수 있고, 대용량 파일 다운로드가 느리다면 지속 처리량이 제한됐을 수 있습니다. Connectivity Test 결과는 해당 테스트 방식과 대상의 성능만 보여줍니다. 모든 앱의 종합 속도도 아니며 기본 네트워크의 왕복 지연 시간과 같지 않을 수도 있습니다. 프로토콜을 비교할 때는 먼저 테스트로 확인하려는 내용을 정한 뒤 어떤 현상을 기록할지 결정하세요.

공정하게 비교하려면 기기, 연결 네트워크, 서버 지역, 대상 서비스, 테스트 시간을 가능한 한 동일하게 유지해야 합니다. 이름이 같은 서버라도 다른 경로로 나갈 수 있고 부하는 시간에 따라 변합니다. 연속 테스트 중 기기가 뜨거워지면 이후 결과에도 영향을 줄 수 있습니다. 한쪽을 먼저 충분히 테스트한 다음 기기가 달궈진 상태에서 다른 쪽을 측정하지 말고, 사용할 수 있는 두 설정을 번갈아 테스트하며 짧은 요청과 지속 전송을 반복하세요. 결과 차이가 작다면 변동 범위를 함께 기록하고 특정 프로토콜이 항상 우세하다고 단정하지 않아도 됩니다.

배터리 사용량은 암호화 연산만으로 결정되지 않습니다

iOS에서 프록시를 사용할 때는 네트워크 확장, 패킷 처리, 시스템 무선 연결 관리가 작동합니다. 암호화 연산에도 자원이 들지만 화면, 셀룰러 신호, 재전송, 백그라운드 작업, 연결 유지가 더 큰 비중을 차지할 수 있습니다. 시스템 배터리 화면의 앱별 사용량은 여러 요인이 합쳐진 결과이며 프로토콜 하나의 연산 비용을 따로 보여 주지는 않습니다. 프록시 사용 중 동영상을 보거나 다운로드하거나 화면을 오래 켜 두었다면 전체 배터리 변화를 Shadowrocket의 프로토콜 처리 비용으로만 볼 수 없습니다.

유휴 상태와 실제 사용을 나눠 살펴보세요. 유휴 테스트에서는 자주 깨어나는지, 연결이 다시 설정되는지, 연결 유지 패킷을 보내는지 확인합니다. 실제 사용 테스트에서는 같은 작업에 걸리는 시간과 발열, 재시도 실패를 확인하세요. On Demand는 조건에 따라 연결을 시작하는 기능이지 프로토콜 비용을 낮추는 버튼이 아닙니다. 설정으로 인해 네트워크 전환 때마다 연결이 반복해서 재설정된다면 계속 연결하는 것보다 사용 경험이 나빠질 수 있습니다. 자동 연결이 필요한지 먼저 정한 다음 트리거 조건이 일상적인 네트워크 환경에 맞는지 확인하세요. 배터리를 절약하려다 오히려 전환을 늘리지 않도록 주의해야 합니다.

TCP, UDP, 네트워크 전환이 실제 사용에 미치는 영향

TCP는 패킷 손실이 발생하면 순서가 보장되는 바이트 스트림을 복구해야 하므로 네트워크 품질이 나쁘면 대기 시간이 길어질 수 있습니다. UDP를 사용하는 상위 프로토콜도 자체적으로 복구와 혼잡 관리를 수행하므로 본질적으로 대기 시간이 없는 것은 아닙니다. 실시간 앱은 지연 변동과 패킷 도착에 민감하고 웹페이지는 짧은 요청을 마치는 시간에 더 영향을 받습니다. 대용량 파일 전송 한 번으로 통화나 대화형 사용 경험을 대표할 수 없으며, 한 실시간 앱의 이상만으로 프록시의 TCP 전달에 문제가 있다고 단정할 수도 없습니다. 실제 사용 목적과 같은 작업을 선택하세요.

Wi-Fi와 셀룰러 사이를 전환하면 외부 IP 주소, 사용 가능한 대역폭, 경로 MTU가 바뀌면서 기존 연결이 끊길 수 있습니다. 특정 전송 방식에 연결 이동 기능이 있더라도 실제 복구는 클라이언트 구현, 서버, 대상 앱에 따라 달라집니다. 테스트할 때는 “전환 후 새 요청을 보낼 수 있는지”와 “기존 요청을 계속 진행할 수 있는지”를 따로 기록하세요. 두 지표를 하나로 적으면 안 됩니다. 계속해서 상호작용해야 하는 환경에서는 순간적인 최고 속도보다 예측 가능한 복구가 더 중요할 수 있습니다.

라우팅이 동일한지도 확인하세요. 한 설정은 대부분의 요청을 직접 연결하고 다른 설정은 같은 요청을 원격 서버로 보내면 속도와 배터리 차이가 프로토콜 때문만은 아닙니다. Config로 테스트할 때는 동일한 규칙과 정책을 유지하세요. 필요한 경우 통제된 확인을 위해 잠시 Proxy 모드를 사용한 뒤 원래 설정으로 되돌립니다. Data의 서버 통계는 트래픽이 예상한 접속 정보를 거치는지 확인하는 데 도움이 될 수 있지만, 통계 수치 자체가 성공률을 뜻하지 않으며 모든 도메인 규칙이 적용됐다는 증거도 아닙니다.

자세한 수치 해석은 Data 트래픽 통계 안내를 참고하세요. 테스트 기록에는 작업, 네트워크, 라우팅 모드, 연결 전환 여부를 적고 계정 정보는 숨겨야 합니다. 재검증할 수 있는 결론은 “이 조건에서 이 설정으로 해당 작업을 더 안정적으로 완료했다”와 같은 형태여야 하며 “이 프로토콜은 언제나 더 빠르다”가 되어서는 안 됩니다. 두 방식의 성능 차이가 거의 없다면 사소한 차이를 쫓기보다 설정 정보가 완전하고 관리하기 쉬우며 복구 절차가 명확한 쪽이 실용적입니다.

선택 순서: 성능보다 지원 여부를 먼저 확인

이미 보유한 구독 정보만 있다면 전체를 가져오고 연결 유형을 확인하는 것이 첫 단계입니다. 먼저 선호하는 프로토콜을 결정할 필요는 없습니다. 서버에서 제공하지 않는 유형을 클라이언트가 새로 활성화할 수는 없습니다. 직접 입력해야 한다면 접속 정보, 인증, 전송 방식, 보안, 추가 설정을 모두 확인한 뒤 Add Server에서 해당 유형을 선택하세요. 구독과 수동 입력의 차이는 Subscribe, QR 코드 스캔, 수동 가져오기 안내를 참고하세요. 처음 사용할 때는 사용 가이드를 따라 진행하면 됩니다.

이미 보유한 환경에서 완전한 접속 정보를 여러 개 제공한다면 작업에 따라 고르세요. 일반 웹페이지는 짧은 요청의 안정성을, 지속 다운로드는 처리량과 발열을, 실시간 앱은 UDP 지원과 지연 변동을 확인합니다. 지정된 내부 네트워크에 접속해야 한다면 WireGuard의 터널 주소와 서브넷 설정이 필요한지 확인하세요. 프로토콜 이름은 설계에 관한 단서를 제공할 뿐, 종단 간 테스트를 대신하지 않습니다. 인증서 갱신, 키 관리, 설정 업데이트 등 유지 관리도 고려해 정보의 정확성을 계속 관리할 수 있는 조합을 선택하세요. 항목이 많은 조합이 항상 더 나은 것은 아닙니다.

최소 연결을 먼저 설정한 뒤 규칙 라우팅 복원

원래 연결 정보는 보관하고 테스트용으로 복사해 사용하세요. 먼저 시스템의 인터넷 연결이 정상인지 확인한 뒤 접속 주소와 포트를 테스트하고, 인증과 TLS를 점검한 다음 이미 알고 있는 대상에 접속합니다. 규칙의 영향을 배제해야 한다면 잠시 Global Routing의 Proxy 모드로 테스트할 수 있지만 끝나면 원래 설정으로 되돌리세요. 연결이 안정된 후 Config를 활성화하고 현재 파일, 규칙 순서, FINAL을 확인합니다. DNS, 프로토콜, 전송, 정책을 동시에 조정하면 복구하더라도 어떤 변경이 영향을 줬는지 알기 어렵습니다.

“특정 웹사이트만 실패”한다면 먼저 해당 사이트에 원래 접속할 수 있는지 확인하고, 어떤 규칙과 정책이 적용됐는지, 도메인 해석이 정상인지 살펴보세요. “모든 대상에서 실패”한다면 접속 정보와 인증을 먼저 확인합니다. “작은 요청은 되는데 큰 응답은 멈춤”이라면 경로, MTU, 전송 방식을 살펴보세요. “네트워크 전환 후 실패”한다면 새 네트워크에서 접속할 수 있는지와 연결이 다시 설정되는지 확인합니다. 증상에 따라 확인 범위를 좁히는 편이 모든 문제를 프로토콜 부적합으로 돌리는 것보다 효과적입니다.

구독 업데이트, 민감 정보, 다운로드 경로

Subscribe 업데이트로 주소, 포트, 항목 구성이 바뀔 수 있으며 수동으로 수정한 값이 새 구독 내용으로 덮어써질 수도 있습니다. “전에는 됐는데 업데이트 후 실패”한다면 변경된 항목을 비교하고 예상한 접속 정보를 계속 사용 중인지 확인하세요. 모든 전역 설정을 바로 바꾸지 마세요. 기존 서버 관리자에게 문의할 때는 프로토콜 유형, 오류 발생 단계, 연결 네트워크, 재현 여부를 제공할 수 있습니다. 구독 링크, UUID, 비밀번호, 개인 키, 인증 정보가 포함된 QR 코드는 가려야 합니다. 로그를 공유하면서 전체 접속 권한이 노출되지 않도록 주의하세요.

문제가 클라이언트 다운로드나 첫 실행 단계에서 발생한다면 먼저 설치 및 실행 허용 안내를 확인하세요. 설치 문제를 프로토콜 테스트와 혼동하지 마세요. Mac에서는 Apple 실리콘과 Intel을 구분해야 합니다. 처음 실행이 차단되면 출처를 확인한 다음 시스템의 개인정보 보호 및 보안 설정에서 처리하세요. Windows에서는 SmartScreen, Android에서는 앱 설치 권한, Linux에서는 실행 권한을 다운로드 페이지의 안내에 따라 확인해야 합니다. 다른 플랫폼의 설치 파일은 이 사이트의 /dl에서 제공하며 프로토콜 정보에서 대체 다운로드 주소를 찾지 마세요.

iPhone / iPad에서는 App Store 제품 페이지에서 개발자 Shadow Launch Technology Limited, 공식 아이콘, 앱 ID 932747118을 확인하세요. 시스템 요구 사항은 App Store 페이지의 안내를 기준으로 합니다. 다운로드 및 가격은 두 가지로 나뉩니다. iPhone / iPad 버전은 App Store에서 $2.99 일회성 결제로 제공되며 Mac / Windows / Android / Linux 버전은 무료입니다. 클라이언트 구매에는 서버 연결 정보가 포함되지 않습니다. 클라이언트를 설치하는 일과 이미 보유한 구독 정보를 가져오는 일은 별개이며, 연결 실패를 해결하기 위해 클라이언트를 반복 구매할 필요는 없습니다.

검증을 마친 설정 하나를 최종본으로 보관하고 적용 가능한 네트워크와 용도를 기록하세요. 이후에는 한 번에 하나의 항목만 변경하고 접속, 규칙, 연결 복구를 확인한 뒤 다음 단계로 진행합니다. 문제가 해결되지 않으면 이 페이지에서 해당 프로토콜의 설정 항목을 다시 확인하고 다운로드 및 설치 FAQ를 참고해 다운로드 문제와 연결 문제를 구분하세요. 프로토콜 선택의 기준은 이름의 최신 여부가 아닙니다. 서버가 지원하고 설정이 일치하며 테스트 결과가 명확하고 일상적인 네트워크에서 안정적으로 재현되는지가 중요합니다.