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

이 글의 핵심 내용

Shadowrocket은 여러 연결 프로토콜을 지원하지만, 프로토콜 이름이 같다고 해서 설정값을 서로 바꿔 쓸 수 있는 것은 아닙니다. 이미 서비스와 연결 설정을 보유한 사용자를 대상으로 인증, 전송, 암호화, 라우팅의 네 가지 측면에서 점검 방법을 안내합니다. 읽고 나면 Password, UUID, TLS, UDP 또는 키 필드 중 무엇을 확인해야 하는지 판단하고, 정해진 순서에 따라 가져오기와 연결 확인을 진행할 수 있습니다. 이 사이트는 노드나 구독을 제공·판매·추천하지 않습니다.

프로토콜·전송 방식·라우팅 설정 구분하기

프로토콜은 클라이언트와 서버가 통신하는 방식을 결정하고, Global Routing은 트래픽이 어떤 경로로 처리될지 정합니다. 서로 다른 설정 항목입니다. Home에서 Trojan을 추가해도 모든 요청이 자동으로 해당 항목을 사용하지 않으며, Config에 규칙을 작성해도 서버에 누락된 인증 정보가 채워지지는 않습니다.

Shadowrocket은 Apple 플랫폼용 유료 클라이언트로, 주로 iPhone과 iPad에서 사용하며 App Store에서만 받을 수 있습니다. 소스가 공개되지 않은 상용 앱이며 일회성 구매 방식입니다. 클라이언트 구매와 회선 요금제는 별개입니다. 시스템 요구 사항과 구매 가능 범위는 App Store 페이지를 기준으로 확인하세요.

구분	주요 항목	확인할 내용
프로토콜 및 인증	Shadowsocks、VMess、VLESS、Trojan	Type, 비밀번호 또는 UUID가 서버 설정과 일치하는지
전송 및 핸드셰이크	TCP、UDP、WebSocket、TLS、QUIC	서버에서 동일한 전송 방식과 핸드셰이크 조건을 사용하는지
서버 항목	주소, 포트, 인증 필드	올바른 서버 접속 지점에 연결되는지
트래픽 라우팅	Global Routing, Config의 Rule	대상 요청이 실제로 테스트 중인 항목을 사용하는지

포트 번호만으로 프로토콜을 추정할 수는 없습니다. 443은 TLS 서비스에서 흔히 사용되지만, 443을 입력한다고 TLS가 자동으로 활성화되지는 않습니다. 서버가 다른 포트를 사용한다면 기존 설정에 적힌 값을 그대로 입력하세요. 아래 비교는 설정값을 이해하기 위한 것이며 프로토콜별 성능 순위를 뜻하지 않습니다.

Shadowsocks·VMess·VLESS: 먼저 인증 필드 확인

이 세 프로토콜은 우선 Type과 인증 매개변수가 일치하는지 확인한 다음, 추가 전송 설정을 점검해야 합니다. 한 항목의 주소와 비밀번호를 다른 Type에 그대로 입력하지 마세요. 클라이언트 옵션을 바꾼다고 서버가 지원하는 프로토콜이 바뀌지는 않습니다.

프로토콜	주요 필드	암호화 및 전송 시 확인 사항
Shadowsocks	서버, 포트, Password, 암호화 방식	암호화 방식이 일치해야 합니다. UDP 지원 여부는 양쪽 설정과 네트워크 환경에 따라 달라집니다.
VMess	서버, 포트, UUID, 암호화 및 전송 매개변수	인증에는 시간 동기화가 중요합니다. WebSocket 또는 TLS를 사용한다면 해당 필드도 일치해야 합니다.
VLESS	서버, 포트, UUID, 전송 및 보안 매개변수	프로토콜 자체는 페이로드를 암호화하지 않습니다. 보안은 설정에서 사용하는 외부 보호 방식에 달려 있습니다.

Shadowsocks: 암호화 방식을 추측하지 마세요

Shadowsocks의 Password와 암호화 방식은 한 세트로 확인해야 합니다. 예를 들어 기존 설정에 aes-128-gcm이라고 되어 있다면 임의로 chacha20-ietf-poly1305로 바꾸면 안 됩니다. 일부 방식은 키 형식에 별도 요건이 있으므로 모든 인증 정보를 길이에 상관없는 일반 비밀번호처럼 취급해서는 안 됩니다. 먼저 가져온 설정을 유지하고 기존 설정과 필드별로 비교하세요.

VMess: UUID와 시스템 시간이 모두 정확해야 합니다

VMess는 UUID를 주요 인증 정보로 사용하므로 기기 시간이 크게 어긋나면 인증에 실패할 수 있습니다. 문제를 확인할 때는 시스템 날짜와 시간이 정확한지 먼저 확인한 다음 UUID가 온전히 입력되었는지 살펴보세요. 서버에서 WebSocket을 사용한다면 Path와 Host도 확인해야 합니다. TLS까지 사용한다면 서버 이름과 인증서 검증 조건도 점검하세요. 이러한 매개변수는 UUID만으로 알아낼 수 없습니다.

VLESS: 인증과 암호화는 다릅니다

VLESS의 UUID는 사용자 식별을 위한 정보이며, 전송 내용이 암호화된다는 뜻은 아닙니다. 기존 설정에 따라 TLS 또는 지원되는 다른 보안 매개변수를 확인하세요. 설정에 Flow가 있다면 양쪽 모두 해당 설정을 지원하며 동일하게 사용하는지도 확인해야 합니다. VLESS와 VMess가 모두 UUID를 쓴다고 해서 Type만 바꾸고 나머지 설정을 그대로 두면 안 됩니다.

인증 실패: Password, UUID, 암호화 방식과 시간을 먼저 비교하세요.
핸드셰이크 실패: TLS, 서버 이름, 인증서 관련 설정을 확인하세요.
WebSocket 사용 시: Path와 Host를 확인하고 대소문자와 첫 슬래시도 살펴보세요.

Trojan·Hysteria2: TLS와 UDP를 각각 확인

Trojan은 비밀번호와 TLS가 핵심이고, Hysteria2는 네트워크에서 UDP를 사용할 수 있는지도 확인해야 합니다. 두 프로토콜 모두 포트에 연결된다는 사실만으로 핸드셰이크와 실제 요청의 성공을 확인할 수는 없습니다.

프로토콜	연결 방식	우선 확인할 항목
Trojan	일반적으로 TLS 연결 안에서 인증과 프록시 통신을 수행	Password, TLS 서버 이름, 인증서, 시스템 시간
Hysteria2	QUIC 기반이며 UDP에 의존	인증 정보, TLS, UDP 연결 가능 여부, 기존 설정의 추가 매개변수

Trojan에서 도메인 인증서를 사용하는 경우 연결 주소와 TLS 검증에 쓰이는 서버 이름이 서로 다를 수 있으므로 설정에 따라 각각 입력해야 합니다. 예를 들어 서버 주소가 IP이고 인증서는 도메인에 발급되었다면, IP 주소를 인증서 이름 대신 사용하면 안 됩니다. 인증서 오류가 발생하면 검증을 끄는 것을 기본 해결책으로 삼지 말고 이름, 인증서 유효 기간, 시스템 시간을 확인하세요.

Hysteria2는 다른 프로토콜의 전송 옵션을 UDP로 바꾸는 방식이 아닙니다. 자체적인 핸드셰이크와 인증 절차를 사용하며, 다른 세대의 Hysteria 설정과 혼용할 수 없습니다. 현재 네트워크에서 UDP가 제한되면 일반 웹 페이지와 TCP 서비스에 접속할 수 있어도 Hysteria2 연결은 실패할 수 있습니다. 기존 설정에 대역폭 또는 난독화 매개변수가 있다면 그대로 확인하고, 경험에 따라 임의로 큰 값을 입력하지 마세요.

요점: 먼저 네트워크 환경 확인

같은 Hysteria2 설정이 특정 Wi-Fi에서만 실패한다면 먼저 셀룰러 네트워크로 바꿔 다시 테스트하고 차이를 기록한 뒤, 해당 Wi-Fi에서 UDP를 사용할 수 있는지 확인하세요. 인증 필드부터 바꾸거나 다른 프로토콜이 반드시 더 빠르다고 단정하지 마세요.

HTTP·SOCKS5·WireGuard: 프록시 접속 지점과 터널 구분

HTTP, SOCKS5, WireGuard는 필드 구성이 서로 달라 동일한 계정 입력 방식을 적용할 수 없습니다. 앞의 두 가지는 일반적인 프록시 접속 방식이고, WireGuard는 키를 사용해 네트워크 계층 터널을 구성합니다. 대상 리소스에 접근할 수 있는지는 서버에서 허용한 전달 범위에도 좌우됩니다.

HTTP: 서버, 포트, 사용자 이름과 비밀번호가 필요한지 확인하세요. HTTP 프록시 접속 지점이라고 해서 프록시 서버까지의 연결이 자동으로 암호화되는 것은 아닙니다. TLS 사용 여부는 실제 설정에 따라 달라집니다. HTTPS 웹사이트에 접속할 때는 대상 웹사이트의 TLS와 프록시 접속 지점 자체의 TLS를 구분해야 합니다.
SOCKS5: 서버, 포트, 인증 요건을 확인하세요. SOCKS5 자체는 페이로드를 암호화하지 않으며, UDP 전달에는 서버의 해당 기능 지원이 필요합니다. TCP 요청이 성공해도 UDP 요청까지 전달된다고 볼 수는 없습니다.
WireGuard: 로컬 Private Key, 터널 주소, 상대편 Public Key, Endpoint와 설정에 필요한 Allowed IPs 등의 정보를 확인하세요. Preshared Key가 제공된 경우 상대편 설정과 일치해야 하며, 공개 키와 개인 키 쌍을 대신할 수는 없습니다.

WireGuard의 Endpoint에는 서버 주소와 포트가 들어가고, 터널 주소는 터널 내부에서 사용되므로 둘을 바꿔 쓸 수 없습니다. Allowed IPs는 주소 범위와 상대편 선택에 관여하는 값이지 도메인 규칙이 아니며, Config의 DOMAIN-SUFFIX를 대신할 수도 없습니다. 문제를 확인할 때는 키의 대응 관계, UDP 연결 가능 여부, 상대편의 응답 경로를 함께 살펴보세요.

기존 설정 가져오기: Home → Type 확인

복잡한 매개변수를 유지하려면 직접 다시 설정하는 것보다 가져오기가 편리하지만, 가져온 뒤에도 주요 필드를 확인해야 합니다. 아래 절차는 이미 구독 또는 단일 설정을 보유한 경우를 전제로 합니다. 구독은 서버 항목을 관리하고 Config의 구성 파일은 규칙과 관련 동작을 관리하므로, 두 항목을 같은 설정으로 취급하면 안 됩니다.

기존 설정 보존

현재 선택된 서버와 Home → Global Routing 설정을 기록하세요. 변경하기 전에 복구할 수 있도록 기존 설정을 보관해 문제를 확인하는 도중 연결 매개변수와 규칙을 함께 잃지 않도록 합니다.
가져오기 방식 선택

연결 하나를 직접 추가하려면 Home → 오른쪽 위 “+” → Type으로 이동해 기존 설정과 동일한 프로토콜을 선택하세요. 구독을 사용하는 경우 같은 경로의 Type에서 Subscribe를 선택하고 본인의 구독 주소를 입력합니다.
항목별로 확인

저장한 뒤 서버, 포트, Password 또는 UUID를 확인하세요. 이어서 프로토콜에 따라 TLS, WebSocket, UDP 또는 WireGuard 키 필드를 점검합니다. 구독을 업데이트한 뒤에는 원격 설정으로 항목이 바뀌었는지도 살펴보세요.
연결 후 확인

Home으로 돌아가 테스트할 항목을 선택하고 연결을 켠 다음, 시스템 안내에 따라 VPN 구성을 허용하세요. 현재 Global Routing 상태를 기록하고 명확한 테스트 대상에 접속합니다. 목록에 표시된 지연 시간만으로 결과를 판단하지 마세요.

구독 업데이트 실패와 서버 연결 실패는 별도로 처리해야 합니다. 전자는 구독 주소 만료, token 변경, 가져오기 경로에 접근할 수 없는 문제일 수 있고, 후자는 인증, 핸드셰이크 또는 데이터 전달 문제일 수 있습니다. 기존 항목을 보존하고 어느 단계에서 실패했는지 확인한 뒤 기존 구독을 업데이트하세요. 반복해서 삭제하고 다시 추가해도 서버 측 매개변수 오류는 해결되지 않습니다.

Global Routing으로 프로토콜 문제와 규칙 문제 구분하기

프로토콜을 테스트할 때는 서버와 대상을 고정하고 라우팅 설정 한 가지만 바꾸세요. Home → Global Routing의 Proxy, Direct, Config, Scene은 라우팅 모드이지 연결 프로토콜이 아닙니다. Scene은 설정된 조건에 따라 작동하며 새로운 전송 방식을 추가하는 기능이 아닙니다.

Config

권장

현재 활성화된 Config 규칙에 따라 요청 경로를 결정합니다. 규칙은 DIRECT, 프록시 정책 또는 REJECT로 요청을 보낼 수 있으며, 규칙에 일치하지 않는 요청이 모두 자동으로 직접 연결되는 것은 아닙니다.

적합한 경우: 유효한 규칙이 있고 분기 결과를 항목별로 확인해야 하는 일상적인 사용

Proxy

프록시 경로를 전역 라우팅으로 선택해 일반 분기 규칙의 영향을 분리할 수 있습니다. 그렇다고 모든 시스템 트래픽이 반드시 처리되는 것은 아니며, 프로토콜 인증 실패를 해결해 주지도 않습니다.

적합한 경우: 선택한 서버와 대상 요청의 연결 여부를 일시적으로 확인할 때

Direct

요청을 직접 연결 경로로 처리합니다. 이때 웹 페이지가 열려도 Home에서 선택한 프록시 서버의 핸드셰이크가 완료되었다고 볼 수는 없습니다.

적합한 경우: 로컬 네트워크와 대상에 직접 접근할 수 있는지 문제 해결용으로 확인할 때

다음은 규칙 구문 예시일 뿐, 전체 설정을 대체할 수 있는 완성본이 아닙니다. PROXY는 현재 설정 문맥에서 유효한 프록시 정책을 가리켜야 합니다. 규칙은 순서대로 평가되며 FINAL은 앞선 규칙에 일치하지 않은 요청을 처리합니다.

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

DOMAIN-SUFFIX는 도메인 접미사로, IP-CIDR은 주소 대역으로 일치 항목을 찾습니다. GEOIP는 지리 데이터베이스를 이용해 주소의 위치를 판별합니다. Proxy에서는 접속되지만 Config에서 실패한다면 곧바로 프로토콜을 바꾸지 말고 일치한 규칙, 정책, DNS 결과를 확인하세요. 테스트가 끝나면 이후 요청에 테스트 설정이 계속 영향을 주지 않도록 원래 라우팅 모드로 되돌리세요.

프로토콜 연결 관련 자주 묻는 질문

포트에 443을 입력했는데도 핸드셰이크에 실패하는 이유는 무엇인가요?

포트는 프로토콜을 결정하지 않습니다. Home으로 돌아가 해당 항목을 편집하고 Type을 확인한 다음 TLS, 서버 이름, 인증 필드가 필요한지 살펴보세요. WebSocket을 사용한다면 Path와 Host도 확인해야 합니다. 포트에 연결할 수 있다는 이유만으로 전체 핸드셰이크가 성공했다고 판단하지 마세요.

지연 시간은 표시되는데 웹 페이지가 열리지 않는 이유는 무엇인가요?

지연 시간 테스트는 특정 테스트 과정의 결과만 보여 줍니다. 먼저 Home → Global Routing에서 Direct로 설정해 테스트할 항목을 우회하고 있지 않은지 확인한 뒤, Proxy로 규칙의 영향을 잠시 분리하고 같은 대상에 접속하세요. 그래도 실패하면 DNS, 인증, TLS, 서버 전달 단계 중 어디에서 문제가 발생하는지 확인합니다.

Wi-Fi를 바꾼 뒤 Hysteria2 또는 WireGuard만 연결되지 않나요?

먼저 설정을 그대로 유지하고 셀룰러 네트워크로 바꿔 다시 테스트하세요. 두 연결 모두 UDP에 의존하므로 네트워크 환경 변화를 우선 확인할 만합니다. 다음으로 Settings → On Demand에 네트워크별 자동 연결 설정이 있는지 확인해 자동 변경이 테스트에 영향을 주지 않도록 하세요. 수동 테스트 중에는 관련 자동 연결 조건을 기록하고 잠시 끈 뒤, 테스트가 끝나면 복원합니다.

구독 업데이트 후 Type을 원래 프로토콜로 되돌리기만 하면 되나요?

Type만 바꿔서는 안 됩니다. 기존 구독에서 제공한 전체 필드를 확인하고 서버의 실제 프로토콜이 바뀌었는지 살펴보세요. 업데이트 내용이 잘못된 경우 본인이 이용하는 서비스 제공업체에 문의하세요. 인증, 전송, TLS 매개변수는 서로 맞는 한 세트여야 하며, 기존 비밀번호를 유지한다고 연결이 복구되는 것은 아닙니다.

문제 해결 기록에는 현재 네트워크, 선택한 프로토콜, Global Routing, 대상 주소, 실패 단계가 포함되어야 합니다. “안 됨”이라고만 적지 마세요. 한 번에 변수 하나만 바꾸고 같은 대상을 다시 테스트해야 문제가 설정, 네트워크, 규칙 중 어디에서 비롯되었는지 판단할 수 있습니다. 처음 권한을 허용하는 과정과 기본 조작부터 확인하려면 사이트의 사용 설명을 참고하세요.