Shadowrocket 지원 프로토콜 한눈에 보기: Shadowsocks, VMess, VLESS, Trojan, WireGuard, Hysteria2

이 글 미리보기

Shadowrocket은 여러 프록시 및 터널 프로토콜을 지원하지만, 클라이언트에서 한 서버를 임의로 다른 프로토콜로 바꿀 수는 없습니다. 이미 서비스와 설정을 보유하고 직접 추가하거나 가져온 항목을 확인하려는 사용자를 위해, 먼저 프로토콜과 전송 계층을 구분하고 주소, 포트, 인증 정보, TLS 매개변수를 차례로 점검하는 방법을 안내합니다. 마지막으로 Connectivity Test와 실제 웹 요청으로 연결을 확인합니다.

1. 지원 프로토콜: 프로토콜, 전송 방식, 트래픽 라우팅 구분하기

Shadowsocks, VMess, VLESS, Trojan, HTTP, SOCKS5, WireGuard, Hysteria2를 이 글에서 다룹니다. 각 프로토콜이 해결하는 문제는 서로 다릅니다. 프록시 프로토콜도 있고 암호화 터널도 있으며, 같은 프록시 프로토콜이라도 전송 방식이 다를 수 있습니다. 추가할 때는 이름이나 포트, 예상 속도로 짐작하지 말고 기존 설정에 따라 Type을 선택하세요.

프로토콜 유형과 Global Routing은 서로 다른 두 가지 설정입니다. 전자는 클라이언트가 서버에 연결하는 방식을 정하고, 후자는 어떤 요청을 프록시로 보내고 어떤 요청을 직접 연결할지 정합니다. 프로토콜이 맞아도 라우팅이 Direct라면 해당 요청은 선택한 서버를 거치지 않습니다. 규칙이 올바르더라도 서버 인증에 실패하면 프록시 연결을 만들 수 없습니다.

2가지

이 글에서 다루는 전송 계층: TCP와 UDP

4개 항목

Global Routing：Proxy / Direct / Config / Scene

프로토콜	전송 방식과 보안 경계	추가 전에 준비할 매개변수
Shadowsocks	설정에 지정된 암호화 방식을 사용합니다. TCP와 UDP 지원 여부는 양쪽이 모두 해당 기능을 지원해야 합니다.	서버 주소, 포트, Password, Method 및 기존 설정에서 요구하는 추가 매개변수
VMess	인증 정보와 전송 방식은 각각 설정하며, WebSocket이나 TLS 등의 옵션이 포함될 수 있습니다.	주소, 포트, UUID, 암호화 옵션 및 전송 매개변수
VLESS	프로토콜 자체는 데이터를 암호화하지 않습니다. 보안은 설정에 사용된 보안 계층에 따라 달라집니다.	주소, 포트, UUID와 서버에서 요구하는 TLS, 전송 방식, Flow 등의 매개변수
Trojan	일반적으로 TLS 연결을 통해 프록시 데이터를 전송하고, 인증에는 비밀번호를 사용합니다.	주소, 포트, Password, TLS 서버 이름 및 관련 전송 설정
HTTP / SOCKS5	기본 프록시 프로토콜이며, 이름만으로 연결이 암호화된다고 볼 수 없습니다.	주소, 포트와 서버에서 요구하는 사용자 이름, 비밀번호 및 보안 연결 옵션
WireGuard	UDP 기반 암호화 IP 터널로, 일반적인 사용자 이름 인증 대신 키를 사용합니다.	로컬 Private Key, 터널 주소, 상대 Peer Public Key, Endpoint 및 라우팅 매개변수
Hysteria2	QUIC 기반이며, UDP를 전송 계층으로 사용하고 TLS 검증이 포함됩니다.	주소, 포트, 인증 정보, SNI 및 설정에서 요구하는 난독화 매개변수

결론: 전체 매개변수를 확인한 뒤 연결 테스트

주소와 포트만 받았다고 설정이 완성된 것은 아닙니다. 기존 설정 출처에서 Type, 인증 방식, 전송 계층을 먼저 확인하세요. UUID, 키 또는 TLS 서버 이름이 빠져 있다면 다른 항목으로 대신하지 마세요.

2. Shadowsocks, VMess, VLESS, Trojan의 입력 항목 비교

이 네 가지 유형은 가져온 설정에서 자주 볼 수 있지만, 인증 항목을 서로 바꿔 쓸 수는 없습니다. Shadowsocks의 Password는 VMess나 VLESS의 UUID와 다르며, Trojan의 Password에 서버 도메인을 입력해서도 안 됩니다. 기존 항목을 수정할 때는 원래 설정을 보존하고 하나씩 확인하세요. 여러 값을 한꺼번에 바꾸면 실패 원인을 찾기 어렵습니다.

Shadowsocks: Method는 서버 설정과 일치해야 합니다. 예를 들어 기존 설정에 aes-128-gcm이 지정되어 있다면, 단순히 보안을 강화하겠다는 이유로 다른 알고리즘으로 바꾸지 마세요. 기존 설정에 플러그인이나 난독화 옵션이 있으면 함께 확인해야 합니다. 기본 인증 정보가 맞아도 전송 방식이 다르면 연결되지 않을 수 있습니다.
VMess: UUID는 인증 식별자입니다. 전송 방식으로 WebSocket을 사용한다면 Path와 Host도 일치해야 합니다. TLS를 사용하는 경우 서버 이름도 확인하세요. 화면에 Alter ID가 표시되면 오래된 안내를 참고해 임의의 값을 넣지 말고 설정 출처에 따라 입력하세요.
VLESS: UUID를 확인한 다음 보안 계층, 전송 방식, Flow를 점검하세요. 설정에서 명시적으로 요구하는 경우에만 해당 옵션을 입력합니다. VLESS 자체가 암호화되지 않는다는 이유로 기존 설정의 TLS를 끄면 안 됩니다.
Trojan: 먼저 Password를 확인한 뒤 TLS 서버 이름과 인증서 검증을 점검하세요. 연결 주소가 IP이고 인증서는 도메인에 발급된 경우, 설정에 지정된 도메인을 SNI로 입력해야 할 수 있습니다. IP 주소를 인증서 이름으로 간주하지 마세요.

일부 추가 입력 항목은 Type, 전송 옵션, 플랫폼 인터페이스에 따라 달라집니다. 기존 설정에 명시된 항목만 입력하세요. 항목이 보이지 않으면 메모나 비밀번호에 내용을 붙여 넣지 말고, 먼저 선행 옵션을 확인하세요. 인증서 검증에 실패하면 기기의 시간, 서버 이름, 인증서 체인을 점검해야 합니다. 검증을 끄는 것은 일반적인 해결 방법이 아닙니다.

3. HTTP, SOCKS5, WireGuard, Hysteria2 구분하기

HTTP와 SOCKS5는 기존 프록시 엔드포인트가 지원하는 기능에 맞춰 사용합니다. HTTP 프록시는 CONNECT를 통해 터널을 만들 수 있지만, 클라이언트와 프록시 서버 사이의 연결이 암호화되었다는 뜻은 아닙니다. SOCKS5의 UDP 기능은 클라이언트와 서버 양쪽에서 지원해야 합니다. Type이 SOCKS5라는 이유만으로 모든 UDP 요청을 사용할 수 있다고 단정하지 마세요.

WireGuard와 Hysteria2는 모두 하위 계층에서 UDP 연결이 가능해야 하지만, 용도와 인증 방식은 다릅니다. WireGuard는 IP 터널이고 Hysteria2는 QUIC을 통해 프록시 트래픽을 전송합니다. 네트워크에서 TCP가 허용되어도 UDP까지 허용된다는 보장은 없습니다. 따라서 다른 프로토콜이 연결된다고 해서 이 두 유형의 네트워크 제한 가능성이 사라지는 것은 아닙니다.

확인 항목	세부 확인 사항	헷갈리기 쉬운 점
HTTP / SOCKS5	서버에서 Username과 Password를 요구하는지, 프록시 엔드포인트에 연결할 때 별도의 TLS 설정이 필요한지 확인하세요.	웹사이트가 HTTPS를 사용해도 프록시 엔드포인트 자체에 TLS가 적용된다는 뜻은 아닙니다. 사용자 이름과 비밀번호를 서로 바꿔 입력하지 마세요.
WireGuard 키	Private Key는 로컬 기기에, Peer Public Key는 상대편에 속합니다. Preshared Key가 있다면 이 값도 일치해야 합니다.	로컬 공개 키를 로컬 Private Key 자리에 입력하거나 일반 비밀번호로 키를 대신할 수 없습니다.
WireGuard 주소와 라우팅	터널 Address, Endpoint, Allowed IPs를 확인하세요. `0.0.0.0/0`은 모든 IPv4 주소 범위를 의미합니다.	Address는 터널 내부 주소이지 서버의 공인 주소가 아닙니다. Allowed IPs도 웹사이트 도메인 목록이 아닙니다.
Hysteria2	인증 정보, UDP 포트, SNI, 인증서 검증 여부와 기존 설정에서 난독화를 요구하는지 확인하세요.	Type만 바꿔 Hysteria와 Hysteria2를 서로 전환할 수 없습니다. 난독화 비밀번호가 인증 비밀번호와 같다고 볼 수도 없습니다.

WireGuard의 Allowed IPs는 터널 계층 매개변수이며, Shadowrocket의 Config에서 사용하는 도메인별 트래픽 라우팅 규칙과는 다릅니다. Hysteria2의 실제 성능은 UDP 연결 가능 여부, 패킷 손실, 서버 부하, 설정에 모두 영향을 받습니다. 프로토콜 이름만으로 속도를 예상하지 말고, 측정하지 않은 상태에서 지나치게 높은 대역폭 값을 입력하지 마세요.

4. Add Server에서 추가하고 연결 확인하기: 4단계

아래 내용은 Home, Config, Settings 화면을 기준으로 설명합니다. 직접 추가하기 전에 필요한 매개변수를 모두 준비하세요. 이미 구독이나 전체 설정이 있다면 원래 가져온 내용을 유지하고 편집 화면에서 확인하는 것이 좋습니다. 이 글은 사용자가 이미 보유한 설정을 사용하는 방법만 안내하며, 연결 리소스를 제공하거나 추천하지 않습니다.

유형 선택

Home → 오른쪽 위 “+”를 눌러 Add Server를 연 다음, Type에서 기존 설정과 같은 프로토콜을 선택하세요. 두 항목의 포트가 모두 443이라는 이유만으로 같은 Type을 고르면 안 됩니다.
인증 정보 입력

서버 주소와 포트를 입력한 뒤 유형에 따라 Password, UUID 또는 키를 입력하세요. 포트에는 기존 설정에 지정된 숫자만 입력하고 프로토콜 접두사는 붙이지 않습니다. 인증 정보를 복사한 다음 앞뒤 공백과 줄바꿈이 없는지 확인하세요.
전송 설정 확인

기존 설정에 따라 TLS, SNI, WebSocket의 Host와 Path 등을 설정하세요. WireGuard는 터널 및 상대편 매개변수를 확인합니다. 저장한 뒤 Home으로 돌아가 해당 서버를 기본 서버로 선택하고, 선택 표시가 원하는 항목에 있는지 확인하세요.
연결 확인

Home → Global Routing에서 임시로 Proxy를 선택하고 연결 스위치를 켠 다음 Connectivity Test를 실행하세요. 이어서 정상 작동을 확인한 HTTPS 페이지에 접속합니다. 확인이 끝나면 원래 사용하던 Config 또는 Scene으로 되돌리고 실제 요청을 다시 점검하세요.

Connectivity Test 결과는 테스트 대상에 대한 연결 상태를 확인하는 용도이지, 모든 앱과 모든 프로토콜 트래픽이 정상이라는 증거는 아닙니다. 테스트는 통과했지만 특정 앱이 작동하지 않는다면, 해당 앱이 TCP와 UDP 중 무엇을 사용하는지, 요청이 예상한 정책에 적용되는지, DNS에서 유효한 결과를 받는지 차례로 확인하세요.

5. 구독, 설정 파일, 프로토콜 항목의 역할

구독은 주로 기존 서버 정보를 가져오고 업데이트하는 데 사용합니다. Config의 설정 파일은 주로 트래픽 라우팅과 관련 설정을 담습니다. 구독을 업데이트하면 항목의 주소, 인증 정보, 전송 매개변수가 바뀔 수 있으므로 구독 항목을 항상 같은 상태로 유지되는 수동 복사본처럼 취급하지 마세요. 시험 삼아 수정해야 한다면 먼저 원래 정보를 저장해 두세요. 그래야 다음 업데이트로 내용이 덮어써져도 비교할 수 있습니다.

기존 구독 가져오기: Home → “+” → Type → Subscribe를 선택하고 본인의 구독 주소를 입력해 저장한 뒤 Home으로 돌아가 해당 구독을 업데이트하세요. 구독 주소는 민감한 인증 정보이므로 공개 스크린샷이나 로그에 포함하지 마세요.
업데이트 결과 확인: 예상한 항목이 생성되었는지 확인한 다음 항목을 열어 Type과 전송 설정을 점검하세요. 구독 데이터 다운로드에 성공해도 현재 네트워크에서 모든 서버에 연결할 수 있다는 뜻은 아닙니다.
평소 트래픽 라우팅으로 복원: Global Routing의 Proxy는 모든 트래픽을 프록시로 보내는 점검에, Direct는 직접 연결에 사용합니다. Config는 선택한 설정을 따르고 Scene은 지정한 시나리오에 따라 처리합니다. 진단을 마친 뒤에는 원래 사용하던 방식으로 복원하세요.
규칙 확인: Config 모드에서는 DOMAIN-SUFFIX, GEOIP, IP-CIDR 등의 규칙과 마지막 FINAL을 차례로 확인하세요. 규칙은 트래픽 처리 방식을 선택할 뿐, VLESS를 Trojan으로 바꾸거나 WireGuard 키를 수정하지 않습니다.

아래 규칙은 순서를 이해하기 위한 예시이며, 완전한 설정이나 서버 정보가 포함되어 있지 않습니다. PROXY는 해당 설정에서 사용할 수 있는 프록시 정책을 가리켜야 합니다. IP-CIDR에 나온 대역은 문서 예시용이므로 실제 서비스의 트래픽 라우팅 기준으로 바로 사용하지 마세요.

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

규칙은 보통 위에서 아래 순서로 적용됩니다. 대상 도메인이 먼저 DIRECT에 해당하면 뒤에 있는 FINAL은 해당 요청을 프록시로 보내지 않습니다. 반대로 임시로 Proxy를 선택했을 때 접속되다가 Config로 돌아간 뒤 실패한다면, 서버 인증 정보를 다시 입력하기 전에 규칙 적용 결과와 선택된 정책을 먼저 확인하세요.

6. 자주 묻는 질문: 실패한 단계부터 원인 좁히기

주소와 비밀번호가 같은데 Type을 바꾸면 왜 연결되지 않나요?

Type에 따라 핸드셰이크와 인증 형식이 달라집니다. 주소와 포트가 같다고 해서 서버가 여러 프로토콜을 모두 제공하는 것은 아닙니다. Home에서 서버를 편집하고 원래 설정의 Type으로 되돌린 다음 Password 또는 UUID를 확인하세요. 속도를 높이려고 Type을 바꾸지 마세요.

VMess 또는 VLESS가 시간 초과되면 무엇부터 확인해야 하나요?

먼저 Home에서 Address, Port, UUID를 확인한 뒤 전송 방식을 점검하세요. WebSocket을 사용한다면 Host와 Path를 확인하고, TLS를 사용한다면 SNI와 기기 시간을 확인하세요. 한 번에 한 종류의 매개변수만 수정하고 Connectivity Test를 다시 실행해 연결 시간 초과와 명확한 인증 또는 인증서 오류를 구분하세요.

Hysteria2가 Wi-Fi에서는 실패하고 모바일 네트워크에서는 정상 작동하나요?

먼저 서버와 매개변수는 그대로 둔 채 네트워크만 바꿔 다시 테스트하세요. 차이가 계속 나타나면 실패하는 네트워크에서 해당 UDP 포트를 제한하는지 확인하고 연결 로그에서 시간 초과가 발생한 위치를 살펴보세요. 비밀번호부터 바꾸지 마세요. 이미 사용 가능한 다른 항목을 비교 대상으로 쓰더라도 UDP 연결이 정상이라는 사실까지 증명되지는 않습니다.

테스트는 통과했는데 웹페이지가 열리지 않는 이유는 무엇인가요?

먼저 Home에서 방금 테스트한 서버가 선택되어 있는지 확인하고, Global Routing이 Direct인지 살펴보세요. Proxy를 임시로 선택해 다시 테스트합니다. 접속이 복구되면 Config의 규칙과 정책을 확인하고, 여전히 실패하면 DNS, TLS 오류, 대상 웹사이트의 접속 가능 여부를 점검하세요. 한 번의 테스트 통과가 모든 요청의 성공을 뜻하지는 않습니다.

문제 해결 기록에는 최소한 프로토콜 유형, 네트워크 유형, 실패 증상, 구체적인 오류 정보를 남기세요. 기록을 공유하기 전에 구독 주소, 비밀번호, UUID, Private Key를 삭제하고, 항목 간 관계를 설명할 때는 필드 이름만 적으세요. 이렇게 하면 전송, 인증, 트래픽 라우팅 중 어디서 문제가 발생했는지 파악하고 같은 설정을 반복해서 만들 필요도 줄일 수 있습니다.