Shadowrocket 프로토콜 설정
및 연결 유형 선택
기존 서버 정보를 바탕으로 프로토콜, 전송 방식, 라우팅을 구분하고 설정값과 속도, 배터리 영향을 확인합니다.
이 페이지는 문제별로 찾아보는 시스템 매뉴얼입니다. 프로토콜 선택 이유와 설정값 간의 관계, 연결 실패 시 먼저 확인할 계층을 설명합니다. 처음 사용하는 경우 사용 안내에 따라 가져오기와 연결을 마친 뒤 이 페이지에서 세부 내용을 확인하세요. 빠른 시작 절차를 대신하지 않으며 구독이나 서버 정보는 제공하지 않습니다.
iPhone / iPad 버전은 App Store에서 $2.99 일회성 결제로 구매할 수 있으며, 시스템 요구 사항은 App Store 페이지를 기준으로 합니다. Mac(Apple Silicon 및 Intel), Windows, Android, Linux 버전은 무료입니다. 전체 플랫폼 다운로드에서 플랫폼별 설치 방법을 확인하세요. 다른 플랫폼의 설치 파일은 사이트 내 다운로드 페이지에서 /dl/ 경로로 제공합니다.
- 프로토콜과 전송 방식을 구분해 확인
- 속도와 배터리를 따로 측정
- 한 번에 설정 하나만 변경
연결 계층: 프로토콜은 전체 연결 경로가 아닙니다
먼저 세 가지 질문을 구분하세요
Shadowrocket에서 프로토콜은 “클라이언트와 서버가 요청을 주고받는 방식”, 전송 방식은 “데이터가 전달되는 통로”, 라우팅은 “각 연결에 적용할 정책”을 말합니다. 서로 관련은 있지만 대체할 수는 없습니다. 예를 들어 VLESS를 선택했다고 WebSocket까지 선택되는 것은 아니며, TLS를 켰다고 모든 앱의 트래픽이 프록시를 통과하는 것도 아닙니다. 서버를 선택해도 Config의 모든 규칙이 해당 서버를 이용하는 것은 아닙니다. 문제를 진단하기 전에 이 세 계층을 구분하면 잘못된 설정을 반복해서 바꾸는 일을 줄일 수 있습니다.
일반적인 접속은 로컬 앱의 요청, 이름 확인, Global Routing 및 규칙 판정, 서버 연결, 인증 또는 핸드셰이크, 서버의 목적지 접속 순으로 진행됩니다. 캐시, 연결 재사용, 원격 이름 확인에 따라 일부 단계의 순서는 달라질 수 있지만 각 단계의 역할은 같습니다. Home에 서버 항목이 보이는 것은 설정이 존재한다는 뜻일 뿐입니다. Connectivity Test 결과도 해당 테스트 방식이 확인한 경로만 사용할 수 있음을 보여줄 뿐, 목적지 웹사이트와 UDP 앱, 모든 규칙이 정상이라는 뜻은 아닙니다.
프록시 프로토콜과 터널 프로토콜 이해하기
Shadowsocks, VMess, VLESS, Trojan, HTTP, SOCKS5는 보통 연결 또는 요청을 전달하는 데 사용됩니다. WireGuard는 IP 패킷 터널을 구성하며 주소, 라우팅 프리픽스, 상대 공개 키 등의 설정을 사용합니다. Hysteria2는 QUIC 기반으로 프록시 통신을 전달합니다. 이름만 다른 것이 아닙니다. 서버는 해당 프로토콜을 실행해야 하며 클라이언트의 인증 정보와 협상 방식도 일치해야 합니다. Trojan 비밀번호를 SOCKS5에 입력해도 포트가 같다는 이유만으로 연결되지는 않습니다.
| 계층 | 주요 항목 | 중점 확인 사항 |
|---|---|---|
| 프로토콜 및 인증 | Type、Password、UUID、PublicKey | 서버 유형과 인증 정보가 서로 맞는가 |
| 전송 및 보안 | TCP、UDP、TLS、WebSocket | 통신 경로, 인증서 이름, 경로가 일치하는가 |
| 라우팅 및 정책 | Config、Proxy、Direct、Rule | 요청이 예상한 정책으로 전달되는가 |
| 목적지 및 이름 확인 | DNS, 목적지 주소, 포트 | 이름 확인이 되는가, 목적지 서비스에 연결할 수 있는가 |
속도도 항목별로 나눠 살펴봐야 합니다. 페이지를 처음 열 때 걸리는 시간에는 이름 확인, 연결, 핸드셰이크가 포함됩니다. 대용량 파일 다운로드는 처리량을, 영상 통화는 지터와 패킷 손실, UDP 경로를 더 잘 보여줍니다. 프로토콜이 핸드셰이크 한 차례를 줄이면 첫 요청은 빨라질 수 있지만 지속적인 다운로드 속도까지 높아지는 것은 아닙니다. 서버 혼잡, 출구 대역폭, 네트워크 간 경로, 목적지의 속도 제한이 더 큰 영향을 줄 수도 있으므로 프로토콜을 일률적으로 빠르거나 느리다고 순위 매기지 마세요.
원인을 설명할 수 있는 범위 안에서 변수 제한하기
프로토콜 선택은 보유한 정보부터 확인하세요. 먼저 서버에 명시된 프로토콜을 확인한 다음 제공되는 전송 방식, 보안 설정, 사용 가능한 포트를 점검합니다. 구독을 가져온 뒤에는 원본 항목을 보존하고 복사본으로 시험하세요. Subscribe 업데이트가 항목을 다시 만들 수 있다면 구독에서 가져온 값과 로컬에서 수정한 값을 기록해 두세요. 프로토콜 유형, DNS, 규칙, 서버를 한꺼번에 바꾸면 연결이 복구되어도 어떤 변경이 효과가 있었는지 알기 어렵습니다.
iOS의 배터리 소모는 전체 연결 경로의 영향을 받습니다. 프로토콜 암호화는 연산 자원을 사용하고 재전송은 전송량을 늘리며, 연결 유지 신호는 무선 연결을 깨울 수 있습니다. 앱의 동기화와 미디어 디코딩도 계속 배터리를 소모합니다. VPN 상태 표시는 시스템 네트워크 확장이 작동 중이라는 뜻이지, 전력 소비를 측정한 결과가 아닙니다. 뒤의 테스트 방법에서는 변수를 나눠 앱의 백그라운드 활동을 프로토콜 탓으로 잘못 판단하지 않도록 합니다.
Shadowsocks: 간결한 프록시와 암호화 방식
설계 배경과 한계
Shadowsocks는 비교적 간결한 암호화 프록시 통신을 제공하도록 설계되었습니다. 클라이언트는 정해진 형식으로 목적지 주소와 데이터를 감싸고, 서버는 이를 확인해 요청을 전달합니다. 완전한 가상 사설망 솔루션은 아니며 Type으로 선택했다고 앱 라우팅이 자동으로 설정되지도 않습니다. 프로토콜의 역사를 외우기보다 같은 프로토콜에도 서로 다른 암호화 방식과 형식이 있다는 점을 알아두는 것이 중요합니다. 서버가 허용하는 방식을 클라이언트에서도 선택해야 하며 이름이 비슷하다는 이유만으로 호환된다고 볼 수 없습니다.
초기의 스트림 암호 방식과 이후의 AEAD 방식은 데이터 형식과 인증 기능이 다릅니다. AEAD는 암호화와 무결성 검증을 결합해 데이터 변조를 감지할 수 있습니다. 그렇다고 AEAD라는 이름이 포함된 모든 항목을 서로 바꿔 쓸 수 있는 것은 아닙니다. 일부 최신 방식은 키 길이와 인코딩 형식에도 특정 요구 사항이 있습니다. 실제 설정은 보유한 서버 구성을 기준으로 입력하고, 클라이언트 목록에 없는 방식은 이름이 비슷한 다른 항목으로 대신하지 마세요.
Address, Port, Method 및 Password
Add Server에서 Shadowsocks를 선택한 다음 Address와 Port부터 확인하세요. Address는 프록시 서비스를 제공하는 호스트 이름 또는 IP 주소이지 구독 링크나 방문할 웹사이트 주소가 아닙니다. Port는 해당 서비스가 연결을 수신하는 포트입니다. 호스트 이름에 웹페이지의 전체 경로를 포함하지 말고, IPv6 주소는 해당 입력란의 형식에 맞게 입력하세요. QR 코드나 구독에서 가져온 정보라면 자동으로 해석된 값을 우선 보존한 다음 원본과 하나씩 대조해 포트나 추가 설정을 빠뜨리지 않았는지 확인하세요.
Method는 양쪽에서 키와 암호문을 처리하는 방식을 결정하며 Password는 모든 문자가 정확히 일치해야 합니다. 일부 방식은 일반 비밀번호에서 키를 만들고 다른 방식은 정해진 형식의 키 자료를 요구합니다. 따라서 “비밀번호가 길수록 호환성이 높다”고 단순하게 볼 수 없습니다. 복사할 때 끝의 줄바꿈, 전각 기호, 눈에 보이지 않는 공백에 주의하세요. 서버 관리 화면에 표시된 인코딩 문자열을 다시 직접 인코딩하지 마세요. 인증에 실패하면 DNS를 바꾸기 전에 Method와 Password의 조합부터 확인하세요.
| 항목 | 의미 | 혼동하기 쉬운 항목 |
|---|---|---|
| Address / Port | 프록시 서비스 접속 주소 | 구독 주소, 목적지 웹사이트 주소 |
| Method | 암호화 및 인증 형식 | 이름이 비슷하다는 이유만으로 방식을 바꾸는 것 |
| Password | 해당 방식에서 사용하는 인증 정보 | 추가 인코딩, 복사할 때 포함된 공백 |
| UDP | 데이터그램 전달 지원 여부 | TCP만 확인한 뒤 UDP도 정상이라고 판단하는 것 |
UDP, 추가 전송 방식 및 iOS 동작
Shadowsocks의 TCP와 UDP 경로는 각각 확인해야 합니다. 웹페이지가 열린다고 게임이나 통화에 쓰이는 데이터그램까지 전달된다는 뜻은 아닙니다. 클라이언트 설정, 서버의 전달 기능, 중간 네트워크가 UDP를 제한할 수 있으며 목적지 앱에 따라 사용하는 포트도 다를 수 있습니다. 서버 정보에 추가 전송 설정이 있다면 현재 클라이언트에서 해당 옵션을 지원하는지 확인하고 그대로 입력하세요. 기본 프로토콜 이름이 같아도 추가 전송 방식의 호환성까지 같다는 뜻은 아닙니다.
iPhone에서는 비교적 간결한 데이터 캡슐화가 일부 처리 부담을 줄일 수 있지만, 실제 속도는 암호화 방식과 기기 성능, 네트워크 경로의 영향을 받습니다. 대용량 데이터를 계속 다운로드할 때는 연산 부담이 더 뚜렷할 수 있습니다. 메시지를 가끔 확인하는 경우에는 연결 설정과 무선 연결 활성화가 더 중요할 수도 있습니다. 구조가 간결하다는 이유만으로 배터리를 반드시 덜 쓴다고 단정하지 말고, 한 번의 속도 측정에서 나온 최고치를 지속적인 처리량으로 보지도 마세요.
문제 해결은 세 갈래로 나눌 수 있습니다. 접속이 계속 시간 초과되면 호스트, 포트, 현재 네트워크를 확인하세요. 연결 직후 실패하면 Method와 Password를 점검하세요. 웹은 되지만 일부 앱이 실패하면 UDP, 규칙 적용 여부, 이름 확인을 확인하세요. Subscribe에서 가져온 항목을 수정했다면 업데이트로 수정 사항이 덮어써지지 않도록 먼저 원본을 복사해 보존하세요. 관련 없는 설정을 무작정 바꾸기보다 이 순서대로 확인하는 편이 효과적입니다.
VMess와 VLESS: 인증, 전송 방식, TLS
한 설정에 여러 계층의 항목이 포함될 수 있습니다
VMess와 VLESS는 프로토콜 자체와 외부 전송 방식을 구분해야 합니다. 설정에 UUID, TLS, WebSocket, Host, Path 등의 항목이 함께 표시될 수 있으며 각 항목의 역할은 서로 다릅니다. UUID는 사용자 식별에 쓰이고 전송 설정은 데이터를 전달하는 방식을 정하며 TLS는 해당 통신 경로를 암호화하고 서버 신원을 확인합니다. 한 항목을 올바르게 입력해도 다른 계층이 맞지 않으면 연결되지 않습니다. 특히 UUID만 보고 항목의 프로토콜을 판단할 수는 없습니다.
VMess에는 자체 인증 및 데이터 보호 메커니즘이 있으며 설정에 보안 방식 같은 옵션이 포함될 수 있습니다. VLESS는 더 간결한 프로토콜 구조를 사용하며 내부 데이터 암호화를 핵심 기능으로 삼지 않고 보통 외부 보안 계층과 함께 사용합니다. 이를 “복잡한 방식은 무조건 느리고 간결한 방식은 무조건 빠르다”라고 단순화해서는 안 됩니다. 실제 연결에는 TLS와 다른 전송 방식이 함께 적용될 수 있으며 핸드셰이크 횟수, 연결 재사용, 서버 구현에 따라 전체 부담이 달라집니다.
UUID, 보안 방식 및 시스템 시간
UUID는 서버에서 할당한 값을 그대로 사용하세요. 임의로 다시 생성하거나 다른 사용자의 식별자를 현재 항목에 섞지 마세요. 일부 VMess 인증 절차는 시간과 관련되므로 기기 시간이 크게 어긋나면 설정이 맞아도 인증에 실패할 수 있습니다. 이 경우 시스템 날짜와 시간이 정상적으로 동기화되는지 확인한 다음 원본 정보가 여전히 유효한지 살펴보세요. 시간을 조정하는 것은 인증을 우회하는 방법이 아니라 로컬 시계 오류를 배제하기 위한 조치입니다.
VMess의 보안 방식은 서버 요구 사항에 맞춰 선택해야 합니다. 가져온 설정에 구형 호환성 항목이 나타나더라도 다른 안내의 스크린샷만 보고 특정 값으로 바꾸지 마세요. 배포 방식에 따라 허용 조건이 다릅니다. VLESS의 식별 정보로 외부 보안 설정을 대신할 수도 없습니다. 특히 TLS를 끈 상태에서도 VLESS로 표시될 수 있지만 프로토콜 이름이 빠진 암호화 계층을 자동으로 보완하지는 않습니다. 서버에서 제공한 전체 설정을 기준으로 확인하세요.
| 항목 | 역할 | 확인 방법 |
|---|---|---|
| Address | 실제 연결을 설정하는 서버 주소 | 이름 확인이 가능하고 포트가 해당 서비스와 일치하는지 확인 |
| Server Name / SNI | TLS 핸드셰이크 및 인증서 신원 확인 | 서버 요구 사항 및 인증서 이름과 일치하는지 확인 |
| Host | 일부 HTTP 계열 전송에서 사용하는 요청 호스트 | 전송 진입점 설정에 맞춰 입력 |
| Path | WebSocket 등 전송 방식의 요청 경로 | 대소문자, 슬래시, 전체 문자열 확인 |
WebSocket, TLS 및 연결 부담
WebSocket은 이후 데이터를 전달하기 전에 해당 HTTP 상호작용을 설정합니다. TLS를 켜면 보안 핸드셰이크도 완료해야 합니다. 따라서 첫 연결에는 여러 단계의 준비 시간이 포함될 수 있지만, 연결이 설정되어 재사용되면 모든 패킷마다 전체 절차를 반복할 필요는 없습니다. 첫 연결은 느리고 이후에는 빨라진다면 프로토콜의 불안정성을 단정하기 전에 이름 캐시, TLS 세션 복구, 연결 재사용을 고려하세요.
Address, SNI, Host는 같은 경우도 있고 배포 방식에 따라 서로 다를 수도 있습니다. 이 값을 억지로 통일하지 마세요. Address에 IP를 사용하더라도 인증서 검증에는 도메인이 필요할 수 있습니다. Path의 문자 하나가 달라도 서버에 요청이 도착한 뒤 올바른 프록시 서비스로 연결되지 않을 수 있습니다. 인증서 오류가 발생하면 이름, 유효 기간, 기기 시간을 확인하세요. 장기간 검증을 건너뛰는 설정은 권장하지 않습니다.
iOS에서는 추가 캡슐화가 연결 설정에 필요한 작업을 늘릴 수 있지만 연결 재사용으로 반복 핸드셰이크를 줄일 수도 있습니다. Wi-Fi와 셀룰러 네트워크를 자주 전환하면 하위 연결을 다시 설정해야 하므로 짧은 시간 동안의 재연결 횟수가 암호화 한 번의 부담보다 사용 경험에 더 큰 영향을 줄 수 있습니다. VMess와 VLESS를 비교할 때는 서버 경로, 외부 전송 방식, 부하를 비슷하게 맞춰야 결과를 프로토콜 차이로 설명할 수 있습니다.
Trojan, HTTP, SOCKS5: 연결 프록시의 역할 차이
Trojan에서 TLS가 필요한 이유
Trojan은 프록시 인증을 TLS 통신과 결합하도록 설계되었습니다. 클라이언트는 먼저 서버에 도달해 적절한 보안 연결을 설정한 뒤 서버의 인증 정보 확인과 요청 전달을 거칩니다. 따라서 Password, 서버 주소, 포트, TLS 신원 설정이 모두 필요합니다. 비밀번호가 맞아도 인증서 이름이 다르면 인증 전에 연결이 실패할 수 있습니다. 포트로 TCP 연결이 된다고 해서 그곳에서 예상한 Trojan 서비스가 실행 중이라는 뜻도 아닙니다.
설정할 때 Address는 접속 주소이고, Server Name 또는 SNI는 TLS 핸드셰이크에 필요한 이름이며, Password는 프록시 인증에 사용됩니다. 서버가 도메인 인증서를 사용하고 접속 주소가 IP라면 보유한 설정의 이름을 그대로 유지하세요. 인증서 유효 기간, 시스템 시간, 신뢰 체인이 검증에 영향을 줄 수 있습니다. 오류를 없애려고 인증서 확인을 장기간 건너뛰지 마세요. 서버 신원 확인이 약해지고 수정해야 할 설정 오류를 놓칠 수 있습니다.
HTTP 프록시는 HTTP 웹사이트 접속과 다릅니다
HTTP 프록시는 프록시 요청이나 CONNECT 등의 방식으로 연결을 대신 설정합니다. Type에 HTTP라고 표시되는 것은 클라이언트와 프록시 간의 통신 방식을 가리키며 HTTP 웹사이트만 방문할 수 있다는 뜻은 아닙니다. HTTPS 목적지는 일반적으로 터널 방식으로 전달됩니다. 반대로 목적지가 HTTPS라고 해서 클라이언트와 프록시 간의 모든 통신이 TLS로 보호되는 것도 아닙니다. 프록시 접속 경로가 암호화되는지, 인증 정보가 어느 계층에서 보호되는지 각각 확인하세요.
HTTP 프록시는 기존 조직 네트워크나 명확히 제공된 접속 환경에서 흔히 사용됩니다. Address, Port, Username, Password는 동일한 설정에서 가져와야 합니다. 서버는 사용자 이름을 비워 둔 경우와 입력하지 않은 경우를 다르게 처리할 수도 있습니다. 서버가 CONNECT 요청으로 목적지 포트에 접속하도록 허용하는지, 목적지 범위를 제한하는지는 프록시 정책에 포함됩니다. 어떤 웹사이트는 열리고 다른 서비스는 실패한다면 이러한 제한을 고려하세요. 목적지 DNS만 바꿔서는 해결되지 않을 수 있습니다.
SOCKS5 인증 및 UDP 조건
SOCKS5는 클라이언트가 프록시에 연결을 요청하는 방식을 정의하며 사용자 이름과 비밀번호 인증을 포함할 수 있습니다. 기본 SOCKS5는 전송 데이터 자체를 암호화하지 않습니다. 별도의 보호된 전송 경로가 있는지는 실제 배포 환경에서 확인해야 합니다. 관리되는 네트워크의 SOCKS5 접속점은 정해진 용도로 사용할 수 있지만, 로그인 비밀번호가 암호화 통신과 같다고 오해해서는 안 됩니다. 웹페이지가 HTTPS를 사용하더라도 다른 트래픽의 보호 범위를 확인해야 합니다.
| 프로토콜 | 필수 조건 | 흔한 실패 원인 |
|---|---|---|
| Trojan | TLS와 프록시 인증이 모두 일치 | 인증서 이름, 비밀번호, 포트 불일치 |
| HTTP | 필요한 요청과 목적지 포트에 접속할 수 있는 진입점 | 인증, CONNECT 권한, 접속 유형 오류 |
| SOCKS5 | 서버가 필요한 인증 및 명령을 지원 | UDP 전달 불가, 인증 방식 불일치 |
SOCKS5의 UDP 사용은 서버와 네트워크 경로 모두의 지원이 필요합니다. TCP CONNECT가 정상이어도 UDP ASSOCIATE 협상이나 이후 데이터그램이 제한될 수 있습니다. 프록시가 클라이언트에서 접근할 수 없는 데이터그램 주소를 반환하면 제어 연결은 성공해도 앱은 작동하지 않을 수 있습니다. 이때 TCP 테스트 결과를 모든 기능의 통과로 보지 말고 UDP 접속점, 반환 주소, 대상 앱을 각각 확인하세요.
iOS에서 나타나는 차이 이해하기
Trojan의 TLS 핸드셰이크에는 일정한 연결 설정 비용이 있지만, 연결이 안정되면 이후 데이터를 계속 전달할 수 있습니다. HTTP와 SOCKS5는 프로토콜 상호작용이 비교적 단순하지만 경로가 더 짧거나 속도가 더 빠르다고 보장되지는 않습니다. 제대로 비교하려면 같은 목적지와 서버 출구, 비슷한 연결 재사용 조건을 사용해야 합니다. 특정 프로토콜이 현재 Wi-Fi에서만 작동한다면 프로토콜에 영구적인 우열을 매기기보다 해당 네트워크에서 허용하는 전송 방식과 포트를 조사하세요.
선택 순서는 “기존 접속점에서 제공하는 방식, 사용 목적에 필요한 기능, 보호 범위가 명확한지”입니다. TLS 신원 확인이 필요하면 Trojan의 보안 설정을 확인하세요. 조직에서 HTTP 또는 SOCKS5 접속점을 제공한다면 지정된 권한에 따라 사용하세요. 일반적인 연결 문제는 자주 묻는 질문에서 확인할 수 있습니다. Type을 바꿔도 서버가 해당 프로토콜을 자동으로 추가하지 않으며 기존 계정의 접근 권한도 달라지지 않습니다.
WireGuard: 키, 주소 및 라우팅 프리픽스
일반 프록시와 설정이 다른 이유
WireGuard는 IP 패킷 터널을 위한 프로토콜로, 정해진 최신 암호화 구성 요소와 비교적 간결한 핸드셰이크를 사용합니다. 사용자 이름과 비밀번호 입력란으로 상대를 확인하지 않고 키로 신원 관계를 설정하며, 상대를 통해 전달할 주소 범위를 라우팅과 연결합니다. 따라서 Shadowrocket의 WireGuard 항목에서는 키, 터널 주소, Endpoint, AllowedIPs를 각각 이해해야 합니다. 일반 프록시처럼 “주소와 비밀번호”만 입력하는 방식으로 설정하지 마세요.
PrivateKey는 로컬의 개인 키이며 PublicKey는 보통 상대의 공개 키를 뜻합니다. 둘 다 인코딩된 문자열처럼 보이지만 신원과 방향이 다릅니다. 개인 키를 상대 공개 키 입력란에 넣지 말고, 문자열 길이가 비슷하다는 이유로 서로 바꾸지도 마세요. PresharedKey는 선택 사항인 추가 공유 정보이며 양쪽이 사용하기로 합의한 경우에만 입력해야 합니다. 임의의 값을 추가하면 작동이 좋아지는 것이 아니라 양쪽 핸드셰이크 조건이 맞지 않을 수 있습니다.
Endpoint와 터널 주소
Endpoint는 상대가 UDP 통신을 실제로 수신하는 호스트와 포트이고, 터널 Address는 로컬이 터널 안에서 사용하는 주소입니다. 서로 다른 계층의 항목입니다. 외부의 접속 주소에 도달할 수 있어도 내부 주소 할당이 올바르다는 뜻은 아닙니다. 내부 주소가 맞아도 접속 포트에 도달할 수 없는 문제는 해결되지 않습니다. 보유한 설정을 화면에 입력할 때 주소의 프리픽스 길이를 유지하고, IPv4와 IPv6를 각각 설정 정보에 따라 입력하세요. 로컬 네트워크 주소를 임의로 대신 사용하지 마세요.
AllowedIPs는 어떤 목적지 주소를 특정 상대에게 전달할지, 수신한 데이터의 출발지 주소를 어떻게 인정할지에도 영향을 줍니다. 넓은 프리픽스는 더 많은 목적지를 포함하고 좁은 프리픽스는 지정된 네트워크만 포함하지만, 일반적인 웹사이트 접근 허용 목록은 아닙니다. 클라이언트의 Global Routing, Config 규칙, 시스템 네트워크 확장에 따라 업무 트래픽이 이 항목으로 들어가는지가 달라질 수 있습니다. 전체 범위 프리픽스가 보인다고 모든 앱이 터널을 사용한다고 판단하지 마세요.
| 항목 | 역할 | 확인할 관계 |
|---|---|---|
| PrivateKey | 로컬 신원 정보 | 서버에 등록된 로컬 공개 키와 일치하는지 |
| PublicKey | 상대 신원 | 현재 상대의 키인지, 로컬 공개 키가 아닌지 |
| Endpoint | 외부 UDP 접속점 | 호스트, 포트 및 현재 네트워크에서의 연결 가능 여부 |
| AllowedIPs | 상대에 연결된 주소 범위 | 필요한 목적지를 포함하고 라우팅 범위를 올바르게 이해 |
| MTU | 터널이 전달할 수 있는 패킷 크기 | 하위 경로와 캡슐화 부담에 맞는지 |
MTU, 연결 유지 및 모바일 네트워크
MTU는 터널 패킷의 최대 크기를 정합니다. 하위 경로가 큰 캡슐화 패킷을 전달하지 못하면 작은 요청은 되지만 큰 페이지를 열거나 업로드할 때 멈출 수 있습니다. 인증 및 라우팅 오류를 제외한 뒤 MTU를 조정하고 원래 값을 보존하면서 단계적으로 테스트하세요. 특정 네트워크에서 유효한 값을 모든 기기의 고정된 정답으로 사용하지 마세요. IPv6와 IPv4의 경로가 다르다면 웹페이지 한 번만 열어보지 말고 각각 테스트해야 합니다.
PersistentKeepalive는 정해진 간격으로 일부 네트워크 주소 변환 매핑을 유지하는 기능이지, 간격이 짧을수록 더 안정적인 것은 아닙니다. 짧은 간격은 백그라운드 데이터 전송과 무선 연결 깨우기를 늘릴 수 있고, 긴 간격은 일부 매핑의 유지 시간에 맞지 않을 수 있습니다. 먼저 일정 시간 유휴 상태였다가 연결이 복구되지 않는 문제가 실제로 있는지 확인한 뒤 서버 안내에 따라 조정하세요. 모바일 네트워크 전환 시에는 접속 가능 여부, 주소 변경, 앱의 재시도 동작도 복구 과정에 영향을 줍니다.
WireGuard 핸드셰이크가 성공해도 키 관계와 일부 통신 조건만 확인된 것입니다. 내부 서비스에 접속하려면 상대의 전달 설정, 반환 경로, 주소 할당, DNS도 정상이어야 합니다. 핸드셰이크는 정상이지만 업무 트래픽이 없다면 AllowedIPs, 터널 주소, 서버의 반환 경로부터 확인한 뒤 규칙 적용 여부를 살펴보세요. 각 설정의 설명은 WireGuard 설정 안내에서 확인할 수 있습니다. 문제를 공유할 때는 개인 키와 실제 내부 네트워크 정보를 가리세요.
Hysteria2: QUIC, UDP 및 대역폭 설정
설계 목표와 실제 제약
Hysteria2는 QUIC을 기반으로 프록시 통신을 전달하며 처리량, 패킷 손실 상황, 다양한 네트워크 경로를 고려해 설계되었습니다. QUIC은 UDP에서 실행되며 보안 연결과 다중 스트림 전송을 제공하지만, 앱 데이터의 손실 복구가 필요 없다는 뜻은 아닙니다. 하위 네트워크가 UDP를 자동으로 허용한다는 뜻도 아닙니다. 사용하기 전에 보유한 서버가 Hysteria2를 제공하는지, 현재 클라이언트가 서버에서 요구하는 인증과 전송 설정을 지원하는지 확인하세요.
TCP 기반 방식과 비교하면 데이터 복구와 혼잡 제어가 서로 다른 계층에서 처리되므로 패킷 손실이나 경로 변화가 있는 일부 환경에서 다르게 동작할 수 있습니다. 하지만 “UDP 사용”만으로 속도가 더 빠르다고 볼 수는 없습니다. 일부 네트워크는 UDP 속도를 제한하거나 큰 데이터그램을 차단할 수 있으며 서버 출구와 목적지 사이트도 병목이 될 수 있습니다. 실제 경로와 부하가 맞을 때만 프로토콜 설계의 잠재력이 사용 경험으로 이어집니다.
접속점, 인증 및 TLS 신원
Address와 Port는 서버의 QUIC 접속점을 가리키며 인증란에는 기존 설정에 지정된 값을 사용해야 합니다. 인증 정보에 구분 기호가 포함될 수 있으므로 다른 프로토콜의 사용자 이름과 비밀번호라고 임의로 나누지 마세요. Subscribe에서 가져온 설정이라면 해석된 Type과 항목이 완전한지 먼저 확인하세요. 예전 유형의 이름이 비슷하거나 이름에 Hysteria가 들어 있다고 설정 형식을 바로 바꿔 쓸 수 있다는 뜻은 아닙니다.
QUIC에서도 TLS 상대 신원 확인은 중요합니다. Server Name은 서버 설정과 인증서 요구 사항에 맞아야 합니다. IP 접속점을 사용해도 인증서에 지정된 도메인 이름이 필요할 수 있습니다. 인증서 오류, 인증 오류, UDP 시간 초과는 서로 다른 단계에서 발생하므로 각각 처리해야 합니다. 인증서 문제는 이름과 신뢰 체인을, 인증 오류는 권한 정보를, UDP 시간 초과는 접속점과 네트워크 경로를 확인하세요. 모든 오류를 “대역폭 값이 잘못됐다”고 보면 실제 문제를 놓칠 수 있습니다.
| 설정 | 용도 | 주의 사항 |
|---|---|---|
| Address / Port | QUIC 연결 설정 | TCP 포트만 테스트하지 말고 UDP 경로 확인 |
| 인증 정보 | 사용이 허가된 클라이언트 식별 | 전체 값을 복사하고 임의로 분리하거나 인코딩하지 않기 |
| Server Name | TLS 상대 신원 확인 | 서버 요구 사항 및 인증서와 일치하는지 확인 |
| 업로드 / 다운로드 대역폭 | 관련 속도 제어 설정에 사용 | 단위와 방향을 확인하고 실제 경로에 맞게 입력 |
| 추가 설정 | 서버에서 지정한 설정과 일치 | 설정 정보에 필요하고 클라이언트가 지원할 때만 입력 |
대역폭 값은 성능 보장이 아닙니다
클라이언트에서 업로드 및 다운로드 대역폭을 설정할 수 있다면 단위와 방향부터 확인하세요. Mbps와 MB/s는 같은 단위가 아니며 업로드와 다운로드 값을 서로 바꿔 쓸 수도 없습니다. 더 큰 값을 입력해도 물리적인 대역폭이 늘어나지 않습니다. 해당 제어 방식에서 실제 경로와 맞지 않는 목표를 설정하면 대기열과 패킷 손실이 늘거나 다른 앱의 응답이 늦어질 수 있습니다. 설정이 적용되는지도 구체적인 협상과 서버 구성에 따라 달라지므로 임의로 높은 값을 공통 최적화 방법처럼 사용하지 마세요.
같은 네트워크에서 먼저 안정적인 속도 범위를 측정한 뒤 보유한 서버 안내에 맞춰 입력하고 웹 응답, 지속 다운로드, 통화 품질을 함께 살펴보세요. 다운로드 최고 속도만 보면 전송량이 많을 때 지연 시간이 크게 늘어나는 문제를 놓칠 수 있습니다. 셀룰러 네트워크의 실제 용량은 신호와 기지국 부하에 따라 달라지므로 고정 설정이 항상 맞는 것은 아닙니다. 테스트 당시의 네트워크 조건을 기록하고 정상 작동하는 원래 설정도 보존하세요.
iOS 배터리 소모와 실패 유형
지속적인 고속 전송, 패킷 손실 복구, 사용자 공간 데이터 처리는 연산 및 무선 전송 부담을 늘릴 수 있으므로 Hysteria2가 항상 배터리를 절약하거나 더 많이 소모한다고 단정할 수 없습니다. 같은 작업을 더 빨리 끝내면 무선 연결이 높은 활동 상태를 유지하는 시간이 줄 수도 있습니다. 유휴 상태에서 계속 재연결하면 반대 결과가 나타날 수 있습니다. 배터리를 비교할 때는 작업량과 시간을 고정하세요. 한 프로토콜의 대용량 파일 다운로드와 다른 프로토콜의 대기 시간을 비교해서는 안 됩니다.
특정 네트워크에서만 핸드셰이크가 전혀 되지 않는다면 UDP 사용 가능 여부부터 확인하세요. 연결 후 처리량이 계속 불안정하면 경로의 패킷 처리, 대역폭 설정, 서버 부하를 점검하세요. 일부 앱만 실패한다면 라우팅과 목적지 프로토콜을 확인하세요. Hysteria2 연결을 위해 관련 없는 규칙을 임의로 바꾸지 마세요. 보유한 정보에 없는 추가 설정은 기본값으로 두거나 설정 제공자에게 확인하는 편이 관련 없는 예제에서 값을 조합하는 것보다 안전합니다.
iOS 속도와 배터리: 비교 가능한 테스트 방법
네트워크와 테스트 대상을 먼저 고정
iPhone 또는 iPad에서 프로토콜을 비교할 때는 먼저 테스트 환경의 차이를 없애야 합니다. 기기, 네트워크, 대상 리소스, 테스트 시간을 고정하고 관련 없는 대용량 다운로드를 중지한 뒤 사진 동기화나 시스템 업데이트가 끝날 때까지 기다리세요. 테스트 전에 Wi-Fi인지 셀룰러인지, 기기가 뜨거운지, 저전력 모드인지 기록하세요. 신호가 크게 변하거나 기기의 온도 제한이 시작되면 이번 결과를 이전 데이터와 직접 비교하기 어렵습니다.
서버 조건도 통제해야 합니다. 프로토콜별 서버가 서로 다른 데이터센터에 있거나 출구가 다르면 측정 결과는 두 전체 경로를 비교한 것이지 프로토콜 자체의 차이를 입증하는 것은 아닙니다. 같은 서버여도 대역폭 제한이나 동시 사용자 부하가 다른지 확인하세요. 보유한 구독이 하나뿐이라 조건을 맞춘 접속점을 확보할 수 없다면 목표를 “현재 용도에 더 적합한 항목 찾기”로 정하세요. 보편적으로 적용되는 프로토콜 순위를 만들려 하지 마세요.
연결, 업무 트래픽, 라우팅을 각각 기록
Connectivity Test는 초기 점검에 유용하지만 결과는 구체적인 테스트 방식에 따라 달라집니다. 단순 연결 테스트는 실제 업무 트래픽을 모두 확인하지 않으며 HTTP 계열 테스트는 테스트 대상의 영향을 받습니다. 실제로 사용할 앱도 열어 처음 응답하는 시간, 지속 전송, 유휴 상태 이후 복구를 확인하세요. 이름 확인, 연결 설정, 콘텐츠 로드, 네트워크 전환 중 어느 단계에서 실패했는지 기록하면 “가끔 느리다”라고만 적는 것보다 원인을 판단하기 쉽습니다.
| 모드 | 용도 | 테스트 시 확인 사항 |
|---|---|---|
| Config 모드 | 현재 Config의 규칙에 따라 요청 처리 | 목적지가 어떤 규칙 및 정책에 적용되는지 먼저 확인 |
| Proxy 모드 | 해당 모드에서 지정된 트래픽을 프록시로 전달 | 규칙 영향을 분리할 때 유용하지만 실제 로그도 확인해야 함 |
| Direct 모드 | 해당 모드에서 직접 연결 | 기본 네트워크를 확인할 때 사용하며 프록시 작동 여부를 증명하지는 않음 |
Config에서 목적지가 DIRECT 규칙에 적용되면 그 로딩 속도로 현재 프록시 프로토콜을 평가할 수 없습니다. Proxy로 잠시 전환하면 규칙 문제와 서버 문제를 구분하는 데 도움이 되지만 모드 변경을 기록하고 테스트 후 원래 설정으로 되돌리세요. 정책 그룹, DNS, 로컬 연결도 요청에 영향을 줄 수 있으므로 연결 기록에서 실제 경로를 확인해야 합니다. 화면에서 서버 이름이 강조 표시된 것만 보고 결론 내리지 마세요.
결과를 잘못 해석하지 않고 배터리 측정하기
시스템 배터리 화면은 일정 시간 동안의 사용량 분류와 활동 정보를 보여줄 뿐, 특정 프로토콜만의 전력 소비를 측정하는 계기가 아닙니다. 화면 밝기, 미디어 디코딩, 앱 새로 고침, 신호 세기, 연결 재시도도 배터리 소모에 영향을 줍니다. 비교하려면 일정 시간의 유휴 연결, 같은 콘텐츠 탐색, 동일한 작업량의 다운로드를 각각 관찰하세요. 가능하면 여러 시간대에 반복하고 전경 및 백그라운드 활동을 기록하세요. 몇 분 사이의 배터리 백분율 변화만으로 판단하지 마세요.
유휴 연결에서는 백그라운드 깨우기, 연결 유지 신호, 반복 재연결을 확인하세요. 지속 전송에서는 작업당 소요 시간과 전송량, 기기 온도를 살펴보세요. 이동 중에는 Wi-Fi와 셀룰러 네트워크를 전환한 뒤 복구 상태를 확인하세요. On Demand는 조건에 따라 연결을 언제 설정할지 정하는 기능이지 속도 향상 스위치가 아닙니다. 규칙 때문에 연결이 자주 설정되고 끊기면 배터리 사용량도 달라질 수 있으므로 프로토콜 소모를 논하기 전에 트리거 조건을 확인하세요.
테스트에서 TCP와 UDP도 구분해야 합니다. 웹페이지는 정상이지만 통화가 끊기면 UDP 경로, 지터, 패킷 손실 문제일 수 있습니다. 대용량 파일은 정상인데 첫 접속이 느리면 이름 확인이나 핸드셰이크가 원인일 수 있습니다. 한동안 유휴 상태였던 뒤 첫 요청이 실패한다면 매핑, 연결 유지, 앱 재시도를 확인하세요. 현상을 구분해 기록하면 매번 프로토콜을 바꾸지 않고도 다음 점검 항목을 정할 수 있습니다.
최종 선택은 최고 속도보다 반복 측정 결과를 기준으로 해야 합니다. 짧은 테스트 한 번은 빠르지만 수동 재연결이 자주 필요한 설정은 일상적으로 쓰기 적합하지 않을 수 있습니다. 처리량이 조금 낮아도 응답이 안정적이고 유휴 상태 이후 정상적으로 복구되는 설정이 메시지와 업무에 더 적합할 수도 있습니다. 여기서 비교하는 것은 현재 네트워크와 작업에 대한 적합성이지 회선 서비스 품질을 보장하는 것이 아닙니다.
사용 환경별 선택: 규칙 확인과 문제 해결
이름이 아니라 요구 사항부터 따져 선택
일반 웹사이트와 일상적인 앱을 사용하려면 보유한 정보 중 설정이 완전하고 안정적으로 연결되는 항목부터 선택하세요. 프로토콜 이름만 보고 서버를 바꿀 필요는 없습니다. 내부 네트워크와 주소 라우팅이 필요하면 WireGuard 상대와 허용된 네트워크를 확인하세요. 조직에서 HTTP 또는 SOCKS5 접속점을 제공하면 인증과 접근 권한을 확인하고, UDP를 사용하는 앱은 해당 기능을 별도로 테스트하세요. 요구 사항이 충족되지 않으면 설정, 서버 기능, 네트워크 제한 중 어디에 원인이 있는지 판단하세요.
VMess, VLESS, Trojan은 각각 필요한 전송 방식과 TLS 조합을 유지해야 합니다. Shadowsocks는 암호화 방식과 데이터그램 지원 여부를 확인하고 Hysteria2는 UDP 경로와 속도 설정을 점검하세요. Type만 바꿔 다른 프로토콜의 서버와 자동으로 호환되는 방식은 없습니다. 기존 구독에 여러 유형이 있다면 원본 항목을 보존하고 하나씩 테스트하세요. 서버 설정에 없는 조합을 만들기 위해 UUID, 비밀번호, 전송 경로를 섞지 마세요.
규칙이 실제로 해당 프로토콜을 사용하는지 확인
프로토콜 검증과 규칙 검증은 나눠서 진행해야 합니다. 먼저 지정된 테스트 요청으로 서버가 작동하는지 확인한 다음 Config에서 목적지가 예상한 정책을 사용하는지 확인하세요. 아래는 Shadowrocket .conf 규칙 매칭 순서를 설명하는 예시이며 완전한 설정이 아닙니다. 사용하기 전에 현재 설정에 사용할 수 있는 PROXY 정책이 정의되어 있는지 확인하세요. 예시 도메인은 설명용 텍스트일 뿐 접속해야 할 서비스를 뜻하지 않습니다.
[Rule]
DOMAIN-SUFFIX,example.com,PROXY
IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
GEOIP,CN,DIRECT
FINAL,PROXY규칙은 보통 순서대로 확인하며 일치하는 규칙을 찾으면 해당 정책을 적용합니다. DOMAIN-SUFFIX는 지정 도메인과 하위 도메인을 포함하고 IP-CIDR은 주소 범위를 지정합니다. no-resolve는 규칙 매칭을 위해 도메인을 직접 조회하지 않도록 합니다. 이미 목적지 주소가 있으면 주소 매칭에 사용될 수 있습니다. GEOIP는 주소 위치 데이터베이스를 기준으로 판단하며 웹사이트의 소속 지역과 같은 의미가 아닙니다. FINAL은 최종 대체 규칙이므로 먼저 확인해야 하는 규칙 뒤에 배치하세요. 그렇지 않으면 뒤에 둔 규칙이 적용되지 않을 수 있습니다.
목적지가 REJECT 규칙에 적용되면 정책 단계에서 연결이 차단되므로 프로토콜을 바꿔도 해결되지 않습니다. DIRECT에 적용된다면 먼저 의도한 동작인지 확인하세요. 차단 정책의 역할과 동일한 도메인의 콘텐츠 적용 범위는 REJECT 규칙 안내에서 확인할 수 있습니다. 규칙을 조정할 때는 설정을 복사해 두세요. 목적지 하나를 확인하려다 다른 앱의 기존 경로까지 모두 바뀌지 않도록 주의하세요.
실패 단계에 따라 점검 범위 좁히기
| 증상 | 먼저 확인 | 우선 바꾸지 말 것 |
|---|---|---|
| 접속점에서 응답이 전혀 없음 | 주소, 포트, TCP / UDP 경로 | 규칙 세부 설정과 앱 설정 |
| 핸드셰이크 또는 인증 실패 | 프로토콜, 인증 정보, TLS 이름, 시스템 시간 | 대역폭 목표와 속도 측정 방식 |
| 연결은 성공했지만 목적지에 접속할 수 없음 | DNS, 규칙 적용 여부, 반환 경로, 접근 권한 | 근거 없이 암호화 방식 변경 |
| 작은 요청은 정상인데 대용량 전송이 멈춤 | MTU, 경로의 패킷 처리, 패킷 손실, 서버 부하 | 인증 정보를 전부 다시 입력 |
| 유휴 상태 이후 또는 네트워크 전환 후 실패 | 연결 유지, 매핑, 재연결, On Demand | 간헐적 증상을 프로토콜의 영구적인 비호환으로 판단 |
도메인으로 접속할 때만 실패하고 직접 목적지 테스트가 정상이라면 이름 확인이 이루어지는 위치, 반환 주소 유형, DNS 요청의 라우팅을 확인하세요. 모든 문제를 인증서 검증 변경으로 처리하지 마세요. IPv6 네트워크에서만 문제가 생기면 서버 접속점, 목적지 주소, 터널 주소가 각각 IPv6를 지원하는지 확인하세요. 사용 가능한 설정을 복구한 뒤 필요한 규칙을 하나씩 다시 추가하면 문제를 일으킨 변경 사항을 찾기 쉽습니다. 설명하기 어려운 설정 스위치만 남기는 일을 피할 수 있습니다.
재현 가능한 결과를 기록
문제 해결을 마친 뒤 실제 사용한 프로토콜, 외부 전송 방식, 성공한 테스트 작업, 남아 있는 제한 사항을 기록하고 더 이상 필요하지 않은 테스트 항목은 삭제하세요. Subscribe 업데이트로 서버 설정이 바뀔 수 있고 시스템 네트워크 변화로 이전 결론이 유효하지 않을 수도 있습니다. 새 문제가 발생하면 예전 조정을 기계적으로 반복하지 말고 현재 설정 정보를 다시 확인하세요. 설정, QR 코드, 로그에는 민감한 정보가 포함될 수 있으므로 공유 전에 하나씩 점검하고 원본 내보내기 파일을 그대로 공개하지 마세요.
처음부터 작업 절차를 다시 확인하려면 사용 안내로 돌아가세요. 증상별로 간단한 답을 찾으려면 자주 묻는 질문을 확인하세요. 이 매뉴얼의 목적은 각 유형을 선택할 때 서버 정보를 근거로 삼고, 설정을 바꿀 때마다 검증 가능한 이유를 확인하도록 돕는 것입니다. 프로토콜 이름으로 연결 조건을 판단하는 일을 대신하지 않습니다.