Shadowrocket 지원 프로토콜과 설정 방법: Shadowsocks·VMess·VLESS·Trojan·Hysteria2

이 글 미리보기

Shadowrocket에서 사용하는 프로토콜은 이미 보유한 서버 설정과 일치해야 합니다. Type을 바꾼다고 한 서비스가 다른 서비스로 바뀌지는 않습니다. 직접 연결 정보나 구독을 보유하고 있고 Add Server의 각 항목이 무엇인지 알고 싶은 사용자를 위한 글입니다. 프로토콜, 전송 방식, TLS를 구분한 뒤 프로토콜별 필수 정보를 확인하고, 정해진 순서에 따라 문제가 설정값, 네트워크, 규칙 중 어디에서 발생했는지 살펴봅니다.

1. 프로토콜·전송 방식·규칙 구분하기

Shadowrocket은 여러 연결 프로토콜을 지원하지만, 지원한다는 사실이 임의의 설정 조합까지 사용할 수 있다는 뜻은 아닙니다. 서버에서 해당 프로토콜을 제공해야 하며, 클라이언트에 입력하는 주소, 포트, 인증 정보와 전송 옵션도 서버 설정과 일치해야 합니다. 이 글은 사용자가 이미 서비스와 구독을 보유한 경우를 전제로 클라이언트 항목만 설명하며, 연결 서비스를 제공하거나 추천하지 않습니다.

Home에서 오른쪽 상단의 “+”를 눌러 Add Server로 이동하면 Type에서 항목의 프로토콜 유형을 정합니다. TLS, WebSocket 등의 옵션은 연결의 다른 계층에 해당하므로 Type과 혼동하지 마세요. 아래 세 가지 계층은 각각 “어떻게 인증하는가”, “어떻게 전송하는가”, “어떤 요청에 이 연결을 사용할 것인가”를 설명합니다.

계층	주요 항목	확인할 내용
프로토콜 및 인증	Shadowsocks、VMess、VLESS、Trojan	Type, Password 또는 UUID, 프로토콜별 추가 필드
전송 및 보안	TCP、UDP、TLS、WebSocket、QUIC	서버에서 사용하는 전송 방식, 인증서 이름과 경로 등의 설정값
트래픽 경로 선택	Global Routing, Config에 설정된 규칙	요청이 DIRECT, 프록시 정책, REJECT 중 어떤 경로를 따르는지

예를 들어 포트가 443이라고 해서 해당 항목이 Trojan 또는 TLS를 사용한다고 단정할 수는 없습니다. 포트는 서버가 연결을 수신하는 위치일 뿐입니다. 서버에서 TLS에 8443을 사용할 수도 있습니다. 포트 번호로 프로토콜을 추측하지 말고 보유한 설정에 맞춰 입력하세요. 아래의 영어 용어는 설정 항목을 식별하기 위한 것입니다. 실제로 표시되는 필드와 선택 가능한 조합은 앱에 표시된 내용을 기준으로 확인하세요.

2. Shadowsocks·VMess·VLESS·Trojan 설정값 비교

이 네 가지 연결은 주소가 같다는 이유로 서로 바꿔 쓸 수 있다고 오해하기 쉽습니다. 하지만 같은 도메인에서 서로 다른 서비스를 제공할 수 있으므로 주소만 정확하다고 인증과 이후 전송까지 성공하는 것은 아닙니다. 먼저 Type을 확인하고, 다음으로 인증 정보를 확인한 뒤 전송 옵션을 점검하면 관련 없는 항목을 반복해서 바꾸는 일을 줄일 수 있습니다.

프로토콜	주요 특징	Add Server에서 확인할 항목
Shadowsocks	정해진 암호화 방식과 비밀번호로 프록시 연결을 구성합니다. TCP와 UDP 사용 가능 여부는 설정 및 서버에 따라 다릅니다.	Address, Port, Method, Password. 보유한 설정에 혼합 방식 등 추가 항목이 있다면 해당 값도 일치해야 합니다.
VMess	UUID 등의 정보로 인증하며, 서버 설정에 따라 여러 전송 방식을 조합할 수 있습니다.	Address, Port, UUID, 암호화 옵션과 보유한 설정에서 요구하는 TLS, WebSocket 등의 항목
VLESS	UUID로 인증합니다. 프로토콜 자체에서 전송 내용을 암호화하지 않으므로 실제 보안 수준은 전송 설정과 함께 확인해야 합니다.	Address, Port, UUID와 서버에서 지정한 TLS, 전송 방식 및 기타 확장 설정
Trojan	일반적으로 TLS 연결에서 비밀번호로 인증합니다. 인증서 이름과 연결 주소가 서로 다를 수 있습니다.	Address, Port, Password, TLS 설정. 특히 서버에서 요구하는 SNI를 확인하세요.

UUID·Password·TLS는 서로 대체할 수 없습니다

Shadowsocks: Method와 Password는 함께 확인해야 합니다. 비밀번호만 복사하고 다른 항목의 Method를 그대로 두면 통신이 되지 않을 수 있습니다.
VMess 및 VLESS: 둘 다 UUID를 사용하더라도 Type을 서로 바꿔 쓸 수는 없습니다. 보유한 설정에서 WebSocket을 지정했다면 TLS만 켜는 데 그치지 말고 경로와 Host도 확인하세요.
Trojan: Password가 맞아도 SNI가 틀리면 TLS 단계에서 연결에 실패할 수 있습니다. 먼저 서버에서 안내한 도메인과 인증서 정보를 확인하세요. 인증서 검증을 끄는 방법은 일반적인 해결책이 아닙니다.
TLS: 연결 주소는 서버를 찾는 데 사용하고, SNI는 TLS 핸드셰이크에서 서버 이름을 지정합니다. 둘은 같을 수도 있고, 보유한 설정에 따라 서로 다른 값일 수도 있습니다.

결론: 프로토콜 이름만 보지 말고 전체 설정값을 확인하세요

연결에 실패하면 먼저 해당 항목의 Type, 포트, 인증 정보, TLS와 전송 옵션을 원래 설정과 하나씩 대조하세요. Type만 바꾸거나 다른 항목의 SNI, Host, 경로를 가져와 합치지 마세요.

3. HTTP/SOCKS5·WireGuard·Hysteria2의 용도

HTTP/SOCKS5는 프록시 프로토콜, WireGuard는 키 기반 터널 프로토콜, Hysteria2는 QUIC 기반 프로토콜입니다. 이름뿐 아니라 인증 정보, 하위 전송 방식과 문제 해결 방법도 서로 다릅니다. 서버 환경과 로컬 네트워크에 관계없이 항상 가장 빠른 프로토콜이 정해져 있는 것은 아닙니다.

유형	전송 특성	필요한 정보
HTTP/SOCKS5	HTTP 프록시는 일반적으로 CONNECT로 TCP 터널을 구성합니다. SOCKS5는 TCP를 협상할 수 있고 UDP 릴레이 방식도 정의하지만, 실제 지원 여부는 양쪽 설정에 따라 달라집니다.	주소, 포트, 서버에서 요구하는 Username과 Password. HTTP 프록시 연결 자체에서 TLS를 사용하는지는 별도로 확인해야 합니다.
WireGuard	UDP를 통해 암호화된 터널을 구성하고 키로 인증하며, 일반적인 계정과 비밀번호 방식은 사용하지 않습니다.	로컬 Private Key, 터널 주소, 상대편 Public Key, Endpoint와 설정에서 요구하는 라우팅 범위 및 기타 항목
Hysteria2	QUIC 기반이며 하위 계층에서 UDP와 TLS를 사용합니다. 네트워크에서 해당 UDP 통신을 허용해야 합니다.	주소, 포트, 인증 정보, SNI. 서버에서 혼합 방식을 사용한다면 해당 혼합 설정도 필요합니다.

이름으로 결과를 추측하지 말고 프로토콜 특성에 따라 확인하세요

HTTP/SOCKS5: 서버에서 인증을 요구한다면 Username과 Password를 비워 두지 마세요. 이름만 보고 SOCKS5의 UDP 지원을 단정할 수는 없습니다. 서버와 클라이언트 설정 모두에서 지원해야 합니다.
WireGuard: 로컬 Private Key를 상대편 Public Key 항목에 입력하지 마세요. 터널 주소는 서버 주소와 다릅니다. Endpoint의 호스트와 포트가 상대편을 찾는 데 사용됩니다.
Hysteria2: 일반 웹페이지가 TCP로 열린다고 해서 UDP도 사용할 수 있는 것은 아닙니다. 현재 네트워크에서 UDP를 제한한다면 비밀번호를 반복해서 바꿔도 하위 전송 문제는 해결되지 않습니다.
키 보호: UUID, Password, Private Key와 전체 구독 주소는 민감한 정보로 취급해야 합니다. 문제를 확인할 때는 필드가 일치하는지만 기록하고 전체 내용은 공개하지 마세요.

대역폭, 패킷 손실, 서버 부하와 네트워크 정책은 모두 실제 사용 경험에 영향을 줍니다. 같은 네트워크와 시간대, 비교 가능한 서버 환경에서 테스트하지 않았다면 한 번의 Connectivity Test 결과만으로 프로토콜 성능을 판단할 수 없습니다. 지연 시간이 낮다고 지속적인 다운로드 속도까지 더 빠른 것은 아닙니다.

4. Add Server에서 정보 추가 및 확인하기

보유한 설정 정보를 빠짐없이 유지하는 것이 우선입니다. 수동 추가는 항목이 적고 출처가 명확할 때 적합하며, 구독은 이미 보유한 여러 항목을 관리할 때 유용합니다. Subscribe는 정보를 가져오고 관리하는 메뉴이지 Shadowsocks나 Trojan과 나란히 놓이는 전송 프로토콜이 아닙니다. 구독에 포함된 각 항목에는 고유한 Type이 있습니다.

설정 정보 준비

보유한 설정에서 프로토콜, 주소, 포트와 인증 정보를 확인합니다. VMess 또는 VLESS라면 TLS, 전송 방식, Host, 경로에 지정된 값이 있는지도 확인하세요.
추가 화면 열기

Home → 오른쪽 상단 “+” → Add Server → Type으로 이동해 원래 정보와 일치하는 프로토콜을 선택합니다. 주소 이름이나 포트만 보고 유형을 추측하지 마세요.
입력 후 저장

화면에 표시된 항목에 Address, Port와 해당 유형에서 요구하는 값을 입력합니다. 복사한 값의 앞뒤에 공백이 붙지 않았는지 확인하세요. 저장한 다음 Home으로 돌아가 새 항목이 선택되어 있는지 확인합니다.
구독 설정

이미 구독을 보유한 경우 Home → “+” → Type → Subscribe에서 구독 주소를 입력하고 저장한 다음 Home에서 구독 내용을 업데이트합니다. 업데이트하면 원격 내용에 따라 항목이 새로 반영되므로 수동으로 변경한 설정은 별도로 기록해 두세요.
연결 확인

Home에서 Connectivity Test를 실행한 다음 연결을 켜고 실제로 사용하려는 대상에 접속해 보세요. 테스트 완료 여부, 연결 성립 여부, 대상 접속 가능 여부를 각각 기록해야 합니다. 이 세 가지는 서로 다른 결과입니다.

5. Global Routing은 항목의 프로토콜을 바꾸지 않습니다

프로토콜은 연결 방법을 정하고, Global Routing은 요청이 어떤 경로를 사용할지 정합니다. Proxy로 바꿔도 Shadowsocks가 Trojan으로 바뀌지 않으며, Config로 바꿔도 잘못된 UUID가 수정되지는 않습니다. 문제를 확인할 때는 “항목 자체를 사용할 수 있는가”와 “대상 요청이 예상한 규칙에 매칭되는가”를 분리해서 살펴보세요.

Config: 설정에 따라 판단

권장

현재 Config의 규칙에 따라 사용할 정책을 선택합니다. 기존 설정과 규칙을 확인한 뒤 일상적으로 사용할 때 적합합니다. 최종 경로는 매칭된 항목과 정책 정의에 따라 달라지며, 항상 “나머지는 모두 직접 연결”을 뜻하는 것은 아닙니다.

적합한 경우: 규칙을 확인했고 대상별 라우팅이 필요할 때

Proxy: 프록시 경로 집중 확인

클라이언트가 처리하는 요청을 프록시 경로로 보냅니다. 규칙 매칭의 영향을 일시적으로 분리해 확인할 때 사용할 수 있습니다. 전환 후 대상에 접속할 수 있다면 프로토콜에 문제가 있다고 단정하지 말고 원래 Config의 정책과 규칙을 확인하세요.

적합한 경우: 라우팅과 정책 선택을 잠시 점검할 때

Direct: 직접 연결 경로 확인

클라이언트가 처리하는 요청을 직접 연결 경로로 보냅니다. 이때 대상에 접속할 수 있다고 해서 방금 추가한 프록시 항목의 인증이나 데이터 전송이 정상이라는 뜻은 아닙니다.

적합한 경우: 현재 네트워크의 직접 연결 상태와 비교할 때

Global Routing의 Scene에서는 상황별 동작을 설정할 수 있습니다. 테스트 결과를 확인할 때는 실제로 적용 중인 Scene과 설정도 살펴보세요. Settings → On Demand는 조건에 따라 연결을 시작하는 기능이며 프로토콜을 다른 종류로 바꾸지는 않습니다. 연결이 자동으로 시작된다면 이 항목을 별도로 확인하세요.

Config 모드에서 규칙 확인하기

Config에서 현재 사용 중인 설정을 확인하세요. 규칙은 일반적으로 위에서부터 순서대로 매칭되며, 일치하는 규칙의 정책을 적용합니다. FINAL은 앞선 규칙에 매칭되지 않은 요청을 처리합니다. 다음은 규칙 텍스트의 예시일 뿐 서버 설정값이나 앱 화면이 아닙니다.

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

DOMAIN-SUFFIX는 지정한 도메인 접미사와 하위 도메인을 매칭하며 프로토콜 유형을 선택하는 데 사용되지 않습니다.
IP-CIDR은 대상 IP 대역을 매칭합니다. 예시에는 문서용 주소 대역을 사용했으며, no-resolve는 이 규칙에서 도메인을 별도로 조회하지 않도록 합니다.
GEOIP는 대상 IP의 지리적 위치 데이터에 따라 판단합니다. 웹페이지 언어만으로 규칙의 매칭 여부를 추측할 수는 없습니다.
PROXY, DIRECT, REJECT는 각각 프록시, 직접 연결, 거부를 지정하는 정책 키워드입니다. 정책 경로와 Type은 서로 다른 설정 계층에 속합니다.

6. 프로토콜 추가 후 자주 겪는 문제

문제를 확인할 때는 한 번에 한 종류의 설정만 변경하고 변경 전 값을 기록해 두세요. 아래 내용은 클라이언트 조작 방법을 기준으로 설명합니다. 설정 확인 대신 프로토콜을 바꾸거나 한 번의 시간 초과만으로 서버 문제라고 단정하지 마세요.

같은 주소인데 VLESS로 바꾸면 왜 연결되지 않나요?

Home으로 돌아가 해당 항목의 편집 화면을 열고 Type부터 확인하세요. 서버에서 VLESS를 실제로 제공하고 그에 맞는 UUID와 전송 설정을 안내해야 합니다. 주소만 같다고 사용할 수 있는 것은 아닙니다. 원래 정보가 VMess라면 VMess로 되돌린 다음 기존 설정을 하나씩 확인하세요.

Trojan 비밀번호가 맞는데도 왜 연결에 실패하나요?

항목 편집 화면에서 Address, Port와 TLS 관련 설정을 확인하고, 특히 SNI가 기존 설정과 일치하는지 살펴보세요. 그런 다음 기기의 “설정 → 일반 → 날짜 및 시간”을 확인합니다. 시스템 시간이 크게 어긋나면 인증서 유효 기간 판단에 영향을 줄 수 있습니다. 인증서 검증을 바로 끄지는 마세요.

Hysteria2가 시간 초과되지만 일반 웹페이지는 열리나요?

먼저 보유한 서버 주소, UDP 포트와 인증 정보가 일치하는지 확인한 뒤, 사용이 허용된 다른 네트워크에서도 다시 테스트하세요. 일반 웹페이지에 TCP로 접속할 수 있어도 QUIC에 필요한 UDP 연결이 가능하다는 뜻은 아닙니다. 두 네트워크에서 나타나는 현상을 따로 기록하세요.

구독을 업데이트한 뒤 수동으로 수정한 설정이 다시 바뀌었나요?

Home으로 돌아가 업데이트 전후의 같은 항목을 비교하세요. 구독을 업데이트하면 원격 내용을 다시 가져오므로, 사용자가 보유한 설정의 출처에서 값을 확인해야 합니다. 로컬에서 문제를 점검하려면 수동 항목을 별도로 만들어 차이를 기록하세요. 임시 변경을 원격 설정까지 수정된 것으로 착각하지 않도록 주의하세요.

Connectivity Test에 결과가 표시되면 설정이 올바른 건가요?

그렇다고 단정할 수는 없습니다. 먼저 현재 테스트 방식을 확인하고 연결을 켠 다음 실제 대상에 접속해 보세요. 일부 대상에서만 실패한다면 Home → Global Routing과 Config에서 매칭되는 규칙을 살펴보세요. 테스트 결과 하나만으로 모든 프로토콜 기능, UDP 릴레이 또는 모든 웹사이트 접속이 정상이라고 판단할 수는 없습니다.