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

이 글의 핵심 내용

Shadowrocket은 다양한 연결 프로토콜을 지원하지만, 추가할 때는 임의로 Type을 고르지 말고 사용 중인 서비스의 설정값을 기준으로 해야 합니다. 이 글에서는 프로토콜, 전송 방식, 인증 정보를 비교한 뒤 가져온 설정을 확인하는 방법과 Global Routing의 역할, 연결 실패 시 점검 순서를 안내합니다. 기존 설정의 프로토콜 종류를 확인하려는 사용자에게 적합한 내용입니다.

프로토콜 한눈에 보기: Type은 서버 설정과 일치해야 합니다

Shadowsocks, VMess, VLESS, Trojan, HTTP, SOCKS5, WireGuard, Hysteria2는 서로 다른 연결 유형이며, 같은 연결의 속도 옵션이 아닙니다. 서버에서 사용하는 프로토콜에 맞는 설정을 Shadowrocket에서 선택해야 합니다. Type만 바꾼다고 기존 서비스가 다른 프로토콜로 변환되지는 않습니다. 주소, 포트, 인증 정보가 같아도 서로 연결된다는 뜻은 아닙니다.

프로토콜	주요 특징	우선 확인할 정보
Shadowsocks	지정된 암호화 방식과 공유 비밀번호를 사용합니다. TCP 및 UDP 지원 여부는 양쪽 설정에 따라 달라집니다.	서버 주소, 포트, 암호화 방식, 비밀번호, 추가 플러그인 요구 사항
VMess	UUID 등의 인증 정보를 사용하며, 다양한 전송 방식 및 TLS와 조합할 수 있습니다.	UUID, 전송 방식, TLS 사용 여부, Host, 경로 등 함께 설정해야 하는 항목
VLESS	UUID로 인증하며, 프로토콜 자체는 페이로드를 암호화하지 않습니다. 보호 방식은 외부 전송 설정에 따라 달라집니다.	UUID, 전송 방식, TLS 또는 지정된 기타 보안 설정. 주소만 입력해서는 안 됩니다.
Trojan	일반적으로 TLS를 사용하며 비밀번호로 인증합니다.	비밀번호, 포트, TLS 서버 이름, 인증서 일치 여부
HTTP / SOCKS5	일반적인 프록시 유형입니다. 인증 여부, UDP 지원 여부, 연결 보호 방식은 유형별로 다릅니다.	유형, 주소, 포트, 사용자 이름, 비밀번호. HTTP는 TLS가 필요한지도 확인해야 합니다.
WireGuard	UDP 기반 암호화 터널이며 키 쌍으로 상대방을 식별합니다.	로컬 개인 키, 상대방 공개 키, 터널 주소, 엔드포인트, 라우팅 관련 설정
Hysteria2	QUIC 기반으로, 하위 전송에 UDP를 사용하며 TLS 및 인증 관련 설정이 있습니다.	서버 UDP 포트, 인증 정보, 서버 이름, 선택적 난독화 설정

요약: 원래 설정값에 맞춰 Type 선택

먼저 사용 중인 서비스에서 제공한 프로토콜 이름을 확인한 다음 Home → “+” → Type에서 해당 항목을 선택합니다. 같은 계열의 프로토콜이나 선택 가능한 전송 설정이 있다면 항목별로 확인하고, 이름이 비슷하다는 이유만으로 바꾸지 마세요.

프로토콜·전송 방식·TLS: 세 가지 설정을 따로 확인

연결 정보에는 VLESS, WebSocket, TLS 같은 이름이 함께 표시되는 경우가 많지만, 각각 같은 계층을 가리키는 것은 아닙니다. 프로토콜은 양쪽에서 요청과 인증 정보를 주고받는 방식을 정하고, 전송 방식은 해당 데이터를 전달하는 방법을 정합니다. TLS는 전송 암호화 및 서버 신원 확인과 관련됩니다. 이 셋을 하나의 ‘프로토콜 이름’으로 혼동하면 가져온 설정을 직접 수정할 때 오류가 발생하기 쉽습니다.

첫 번째 계층: 연결 프로토콜: 예를 들어 VMess와 VLESS가 있습니다. 둘 다 UUID를 사용하더라도 Type을 서로 바꿔 쓸 수는 없습니다. 마찬가지로 Shadowsocks 비밀번호를 Trojan 인증 정보로 사용할 수 없습니다.
두 번째 계층: 전송 방식: 예를 들어 TCP와 WebSocket이 있습니다. 기존 설정에서 WebSocket을 지정했다면 경로와 Host도 확인해야 합니다. 일반 TCP로 바꿔도 서버의 전송 방식 요구 사항을 우회할 수는 없습니다.
세 번째 계층: 보안 설정: TLS 서버 이름은 서버 신원을 확인하는 데 사용되며 서버 연결에도 영향을 줄 수 있습니다. 연결 주소, HTTP Host, TLS 서버 이름은 서로 다를 수 있으므로 원래 설정의 값을 각각 유지해야 합니다.

포트 번호는 대상 서비스에 접속하는 입구일 뿐, 프로토콜을 식별하는 번호가 아닙니다. 예를 들어 443은 TCP 서비스에도, UDP 기반 QUIC 서비스에도 사용될 수 있습니다. 51820은 WireGuard에서 흔히 사용되지만 필수 포트는 아닙니다. 443이라고 해서 무조건 Trojan인 것은 아니며, WireGuard 설정의 포트를 모두 51820으로 바꿔서도 안 됩니다.

직접 추가 및 구독 가져오기: 저장 후 항목별 확인

다음 단계는 사용자가 직접 이용 중인 서비스와 구독을 보유하고 있으며 해당 연결 정보를 사용할 권한이 있다는 전제하에 안내합니다. 구독은 설정을 배포하고 업데이트하는 방식이지 연결 프로토콜이 아닙니다. 한 번 가져온 뒤 여러 Type이 표시되는 것은 정상입니다. 이 사이트는 노드나 구독 서비스를 제공하거나 판매하거나 추천하지 않습니다.

원본 설정 정보 확인

먼저 프로토콜 이름, 서버 주소, 포트, 인증 방식을 기록합니다. 직접 추가하려면 전송 방식과 TLS 설정도 빠짐없이 확인해야 합니다. 서버 주소만으로는 연결 설정을 복원할 수 없습니다.
추가 방법 선택

직접 추가하려면 Home → “+” → Type으로 이동해 원본 설정에 맞는 프로토콜을 선택합니다. 이미 구독을 이용 중이라면 Type에서 Subscribe를 선택하고 본인의 구독 주소를 입력한 뒤 저장하세요. 예시 https://example.com/sub?token=xxxx는 주소 형식을 보여 주기 위한 것으로, 연결에 사용할 수 없습니다.
연결 상세 정보 확인

Home으로 돌아가 SERVER 목록에서 해당 항목의 편집 화면을 열고 Type, 주소, 포트를 확인합니다. 이어서 비밀번호 또는 UUID, TLS, 전송 경로 등을 점검하세요. WireGuard는 전체 설정을 기준으로 키와 터널 관련 항목을 확인해야 하며, 비밀번호 입력 방식으로 이해하면 안 됩니다.
라우팅 설정 확인

Home → Global Routing에서 현재 선택 항목을 확인합니다. 규칙에 따라 사용하려면 Config를 선택하고 Config에서 현재 활성화된 설정을 확인하세요. 항목을 추가했다고 해서 모든 요청이 해당 연결을 통과하는 것은 아닙니다.
연결 후 결과 재확인

Home으로 돌아가 대상 항목을 선택하고 연결 스위치를 켭니다. 처음 연결할 때는 시스템 안내에 따라 VPN 설정 추가를 허용해야 합니다. Connectivity Test를 실행한 뒤 본인이 이용하는 대상 서비스에 접속해 연결 상태와 실제 요청 결과를 각각 확인하세요.

구독을 업데이트한 뒤에는 항목 상세 정보를 다시 확인해 주소, 포트, Type이 바뀌었는지 살펴보세요. 업데이트 성공은 구독 내용을 가져와 처리했다는 뜻일 뿐, 각 연결이 모두 작동한다는 보장은 아닙니다. 반대로 구독 주소에 일시적으로 접속할 수 없더라도 이미 저장된 연결 설정이 바로 무효가 되는 것은 아닙니다. 문제를 점검할 때는 ‘설정 가져오기’와 ‘설정을 이용한 연결’을 구분해 기록하세요.

Global Routing 비교: 프로토콜이 요청 경로를 결정하지는 않습니다

같은 Trojan 또는 WireGuard 연결도 Global Routing 설정에 따라 처리하는 요청이 달라질 수 있습니다. 여기서는 Shadowrocket의 라우팅 설정을 비교하며 프로토콜 성능을 비교하는 것이 아닙니다. 아래 Config의 ‘추천’은 규칙을 준비하고 확인한 뒤 규칙에 따라 사용하려는 경우에 적합합니다. 문제를 점검할 때는 한 항목을 고정하지 말고 테스트 목적에 맞게 바꿔 확인하세요.

Config

Proxy

적용 범위 내의 요청을 프록시 방식으로 처리합니다. Config에서 규칙 매칭 결과가 접속에 영향을 주는지 확인하기 위한 임시 비교 테스트에 사용할 수 있습니다. 이 옵션을 모든 시스템 트래픽이 반드시 프록시를 통과한다는 뜻으로 해석하지 마세요.

적합한 경우: 사용 가능한 연결이 있고 규칙과 연결 자체의 차이를 잠시 점검할 때

Direct

요청을 직접 연결 방식으로 처리합니다. 이때 Home에서 서버를 선택했더라도 실제 접속에 해당 서버가 사용되고 있다고 판단할 수는 없습니다.

적합한 경우: 직접 연결 결과와 비교해 문제가 프록시 경로에서만 발생하는지 확인할 때

Global Routing의 Scene은 설정된 조건에 따라 라우팅 동작을 선택하는 기능이지, 별도의 연결 프로토콜이 아닙니다. Settings → On Demand는 필요 시 연결과 관련된 설정을 관리하며 서버의 Type을 바꾸지 않습니다. VPN 자동 연결 여부, 요청이 어떤 규칙에 일치하는지, 최종적으로 어떤 프로토콜을 사용하는지는 각각 따로 확인해야 합니다.

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

아래는 규칙의 처리 순서를 이해하기 위한 예시이며, 완전한 연결 설정은 아닙니다. 첫 번째 규칙은 api.example.com을 먼저 PROXY에 일치시키고, 뒤에 있는 DOMAIN-SUFFIX 규칙은 example.com과 다른 하위 도메인에 적용됩니다. IP-CIDR의 192.0.2.0/24는 문서용 예시 대역이며, no-resolve는 해당 규칙을 위해 도메인을 직접 조회하지 않는다는 뜻입니다. GEOIP는 IP 지리 정보에 따라 일치 여부를 판단하고, FINAL은 앞선 규칙에 일치하지 않은 요청을 처리합니다. 여기서 PROXY는 정책 용어이지 프로토콜 이름이 아닙니다.

연결 실패 해결: 먼저 어느 계층에서 실패했는지 확인

‘지연 시간 표시’, ‘VPN 연결됨’, ‘대상 웹페이지 접속 가능’은 서로 다른 결과입니다. Connectivity Test 결과는 테스트 방식과 함께 해석해야 하며, 이것만으로 대상 서비스가 반드시 사용 가능하다고 판단할 수는 없습니다. 아래에는 관찰된 현상에 따라 확인할 순서를 정리했습니다. 실제 측정 결과를 임의로 만든 내용이 아니라 문제 점검을 위한 기준입니다.

관찰된 현상	먼저 확인할 항목	다음 조치
저장 직후 인증 관련 오류가 나타남	Type, 비밀번호, UUID 또는 키가 원본 설정과 일치하는지 확인합니다.	항목 편집 화면을 열어 하나씩 비교하고, 복사할 때 공백이 들어가거나 내용이 잘리지 않았는지 확인합니다.
TLS 또는 인증서 오류가 나타남	서버 이름, 인증서 유효성, 기기 시간, 전송 설정을 확인합니다.	인증 요구 사항을 유지한 상태에서 잘못된 설정을 바로잡고 다시 연결합니다.
Hysteria2 또는 WireGuard 연결이 계속 시간 초과됨	대상 UDP 포트가 맞는지, 현재 네트워크에서 필요한 UDP 통신을 허용하는지 확인합니다.	설정은 그대로 두고 사용 권한이 있는 다른 네트워크에서 비교 테스트합니다. 바로 TCP로 바꾸지 마세요.
일부 도메인만 실패하고 다른 요청은 정상 작동함	Global Routing, 현재 Config, 규칙 순서, 도메인 조회 결과를 확인합니다.	Proxy와 Config에서 같은 대상의 결과를 비교한 뒤, 일치한 규칙을 확인합니다.
구독 업데이트 후 항목에 문제가 생김	업데이트 후 주소, 포트, 인증 정보, Type이 바뀌었는지 확인합니다.	기존 서비스의 최신 설정과 비교해 구독을 읽는 과정의 오류와 연결 오류를 구분합니다.

요약: 한 번에 조건 하나만 변경

대상 주소와 설정을 고정한 뒤 네트워크를 비교하고, 이어서 라우팅 설정을 비교한 다음 프로토콜 설정을 확인하세요. Type, 포트, TLS 설정을 동시에 바꾸면 어떤 변경이 결과에 영향을 줬는지 알 수 없습니다.

자주 묻는 질문: 지원 목록에 있어도 모든 설정이 작동하는 것은 아닙니다

기존 Shadowsocks를 VLESS로 바꾸면 더 빨라지나요?

Type만 바꿔서는 안 됩니다. 두 프로토콜은 각각에 맞는 서버와 인증 정보가 필요합니다. 먼저 원래 설정을 유지한 채 Home에서 Connectivity Test를 실행하고 같은 대상에 접속해 보세요. 기존 서비스에서 완전한 다른 프로토콜 설정을 제공하는 경우에만 각각 추가해 결과를 비교하세요. 프로토콜 이름만으로 속도를 보장할 수는 없습니다.

HTTP와 SOCKS5는 둘 다 프록시인데 서로 바꿔 써도 되나요?

그렇지 않습니다. Home의 항목 편집 화면에서 기존 설정에 맞는 Type, 포트, 인증 정보를 확인하세요. 일반 HTTP 프록시와 SOCKS5는 프록시라는 이유만으로 자동 암호화되지 않습니다. HTTP CONNECT를 통한 대상 사이트의 HTTPS도 클라이언트와 프록시 서버 사이의 TLS 연결과는 다릅니다.

현재 네트워크에서 Hysteria2가 시간 초과되는데 포트를 바꿔야 하나요?

먼저 원본 설정의 UDP 포트와 인증 정보를 확인한 뒤 같은 설정으로 사용 가능한 다른 네트워크에서 다시 확인하세요. 포트는 서버가 실제로 수신 대기 중인 값이어야 하며 클라이언트에서 임의로 입력할 수 없습니다. Hysteria2는 QUIC 기반이므로 숫자를 443으로 바꾼다고 일반 TCP 연결로 변하는 것은 아닙니다.

구독에 프로토콜 이름이 있는데도 설정이 완전히 가져와지지 않는 이유는 무엇인가요?

프로토콜 계열을 지원하더라도 모든 공유 형식, 확장 설정, 조합을 바로 해석할 수 있는 것은 아닙니다. 가져온 뒤 항목 편집 화면에서 TLS, 전송 경로, 인증 항목을 확인하세요. 중요한 항목이 누락되었다면 추측해서 입력하지 말고 기존 서비스에서 현재 앱의 사용 가능한 옵션에 맞는 전체 설정 정보를 확인하세요.

WireGuard는 공개 키만 입력하면 되나요?

공개 키만으로는 충분하지 않습니다. 로컬 개인 키, 상대방 공개 키, 엔드포인트 주소와 포트, 터널 주소, 관련 라우팅 설정을 확인하세요. 서버에도 해당 클라이언트 설정이 필요합니다. 개인 키와 구독 인증 토큰은 비밀로 유지하고, 문제를 점검할 때 전체 내용을 공개된 페이지에 게시하지 마세요.