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

Shadowsocks, VMess, VLESS, Trojan, HTTP/SOCKS5, WireGuard, Hysteria2의 전송·암호화 방식과 Add Server의 입력 항목을 정리합니다.

이 글의 핵심

Shadowrocket은 다양한 프록시 및 터널 프로토콜을 지원하지만, 프로토콜 이름만으로 연결에 필요한 설정이 모두 정해지는 것은 아닙니다. 서비스와 구독을 이미 보유한 사용자를 위해 프로토콜·전송 방식·규칙의 차이를 먼저 살펴보고, Add Server에서 주소·포트·인증·TLS 설정을 확인한 뒤 가져오기, 테스트, 문제 해결 순서를 안내합니다. 구독은 이용 중인 서비스 제공업체에서 받으세요.

1. 프로토콜, 전송 방식, Global Routing의 차이

프로토콜은 클라이언트와 원격 서버가 데이터를 인증·캡슐화·전달하는 방식을 정하고, 전송 방식은 해당 데이터가 TCP, UDP, WebSocket, QUIC 등의 어떤 통로를 이용할지 정합니다. TLS는 해당 연결 계층의 암호화와 신원 확인을 담당합니다. 이들은 서로 대체할 수 있는 설정이 아닙니다. 같은 VLESS라도 전송 방식, TLS 설정, 서버 요구 사항이 다르면 설정값을 서로 바꿔 쓸 수 없습니다.

Home에서는 연결 항목을 관리하고 선택하며, Config에서는 구성 파일을 관리하고, Settings에서는 앱 설정을 변경합니다. Home의 Global Routing은 요청이 어떤 경로를 사용할지 결정하며, Shadowsocks 연결을 Trojan 연결로 바꾸지는 않습니다. Config 모드에서는 구성 파일의 규칙에 따라 트래픽을 분기합니다. 실제 결과는 일치하는 규칙과 대상 정책에 따라 달라지며, 특정 종류의 웹사이트가 항상 직접 연결되는 것은 아닙니다.

설정 항목예시확인할 내용
프로토콜 유형Shadowsocks、VMess、TrojanType이 서버 프로토콜과 일치하는지
전송 및 보안WebSocket、TLS、QUIC전송 방식, 경로, 도메인, 인증 정보
라우팅 모드Proxy、Direct、Config、Scene요청에 실제로 적용되는 경로 또는 Scene 설정
구성 규칙DOMAIN-SUFFIX、IP-CIDR、GEOIP、FINAL규칙 순서와 대상 정책

2. Shadowsocks: Method와 Password 확인

Shadowsocks는 사전 공유 인증 정보를 사용하며, 선택한 Method에 따라 프록시 데이터를 암호화하고 인증합니다. 흔히 쓰이는 AEAD Method에는 aes-128-gcm, aes-256-gcm, chacha20-ietf-poly1305가 있습니다. Method마다 필요한 키와 프로토콜 세부 사항이 다르므로 이름이 비슷하다고 호환되는 것은 아닙니다. 특정 확장 기능을 사용하는 경우 클라이언트와 서버가 모두 해당 확장을 지원하는지도 확인해야 합니다.

저장에 성공했다는 것은 해당 항목의 형식을 앱에서 받아들였다는 뜻일 뿐, 인증이 완료됐다는 의미는 아닙니다. 주소에 연결할 수 있는데도 요청이 계속 전달되지 않으면 원래 설정과 Method, Password, 추가 설정을 먼저 대조한 다음 UDP 전달 등의 기능을 확인하세요. 원인을 파악하기 전에 여러 옵션을 연달아 바꾸지 마세요.

3. VMess와 VLESS: UUID가 비슷해도 서로 바꿔 쓸 수 없습니다

VMess와 VLESS는 모두 UUID 형식의 사용자 식별자를 사용할 수 있지만 인증 및 데이터 처리 방식은 다릅니다. VMess에는 자체 인증 및 암호화 방식이 있습니다. VLESS 자체는 페이로드를 암호화하지 않으므로 서버 구성에 따라 TLS 또는 그 밖의 보안 방식을 함께 사용해야 합니다. Type만 VMess에서 VLESS로 바꾼다고 프로토콜이 변환되는 것은 아닙니다.

확인 항목VMessVLESS
사용자 인증UUID. 원래 설정에 AlterId가 있으면 함께 확인UUID. Flow가 필요한 경우 원래 설정에 따라 입력
프로토콜 암호화서버에서 요구하는 암호화 설정 유지프로토콜 자체는 페이로드를 암호화하지 않음
하위 전송 방식구성에 따라 TCP 또는 WebSocket 등을 확인구성에 따라 TCP 또는 WebSocket 등을 확인
TLS 설정사용 여부와 Server Name 등이 일치해야 함보안 계층 설정과 관련 인증 정보가 모두 입력되어야 함

Add Server에서 해당 Type을 선택한 뒤 Address, Port, UUID를 입력하고 전송 방식과 TLS 관련 옵션을 확인합니다. WebSocket을 사용하는 경우 Host와 Path도 확인하세요. /ws와 /는 서로 다른 경로이므로 임의로 줄여 쓰면 안 됩니다. 그 밖의 보안 확장 기능을 사용한다면 주소와 UUID만 복사하지 말고 원래 설정 전체를 확인하세요.

요점: 설정값 전체를 그대로 확인하세요

가져온 항목으로 연결되지 않으면 프로토콜을 바꾸거나 인증을 끄기 전에 서비스 제공업체의 원래 설정과 Type, 전송 방식, Path, 보안 계층 설정을 하나씩 대조하세요.

4. Trojan과 HTTP/SOCKS5: 인증과 암호화 구분하기

Trojan은 일반적으로 TLS로 전송을 보호하고 Password로 인증합니다. Add Server에서 Type, Address, Port, Password와 TLS 관련 설정을 확인하세요. 연결 주소와 인증서의 신원은 서로 다른 문자열일 수 있습니다. Address에는 IP를 입력하더라도 Server Name은 서버 요구 사항과 인증서 신원에 맞춰야 합니다. IP를 입력했다는 이유로 Server Name까지 IP로 바꾸면 안 됩니다.

HTTP와 SOCKS5는 범용 프록시 프로토콜입니다. HTTP 프록시는 CONNECT로 터널을 만들 수 있지만, CONNECT 자체가 클라이언트와 프록시 서버 사이의 통신을 암호화하는 것은 아닙니다. SOCKS5에서 사용자 이름과 비밀번호로 인증해도 전송 암호화가 자동으로 제공되지는 않습니다. 대상 웹사이트가 HTTPS를 사용하는지와 프록시 서버까지의 연결이 TLS로 보호되는지는 별개의 문제입니다.

5. WireGuard와 Hysteria2: UDP 연결도 확인하기

WireGuard는 UDP 기반 암호화 터널 프로토콜로, 공개 키와 비밀 키를 사용해 피어 간 연결을 설정합니다. VMess의 UUID나 Trojan의 Password 구조를 사용하지 않습니다. 직접 입력할 때는 기존 설정에서 로컬 Private Key, 터널 주소, 원격 Public Key, Endpoint와 필요한 라우팅 매개변수를 확인하세요. Pre-shared Key가 제공된 경우에도 반드시 입력해야 합니다. 비밀 키는 민감한 정보이므로 공개 스크린샷에 노출하지 마세요.

Hysteria2는 QUIC 기반 프로토콜로, UDP를 사용하고 TLS로 연결을 보호합니다. Add Server에서 Hysteria2를 선택한 뒤 주소, 포트, 인증 정보, Server Name 등 보안 설정을 확인하세요. 원래 설정에 난독화 매개변수가 있으면 함께 입력해야 합니다. 네트워크에서 TCP 443이 허용된다고 해서 UDP 443도 허용되는 것은 아닙니다.

프로토콜주요 매개변수연결 실패 시 먼저 확인할 항목
WireGuardPrivate Key, Public Key, 터널 주소, Endpoint키 쌍, UDP 연결 가능 여부, 터널 라우팅, 주소 충돌 여부
Hysteria2인증 정보, 포트, Server Name, 선택적 난독화 설정UDP 제한 여부, 인증 정보 일치 여부, TLS 신원 확인 통과 여부

프로토콜 이름만으로 실제 속도를 예측할 수는 없습니다. 지연 시간, 패킷 손실, 대역폭 제한, 서버 부하, 현재 네트워크의 UDP 정책이 모두 결과에 영향을 줄 수 있습니다. Hysteria2 항목이 셀룰러 네트워크에서는 작동하지만 같은 기기에서 특정 Wi-Fi에 연결하면 시간 초과되는 경우, 네트워크 경로나 UDP 제한을 점검해 볼 수 있습니다. 다만 이 현상만으로 원인을 단정할 수는 없습니다.

6. Add Server에 직접 입력하고 Subscribe로 가져오기

개별 연결 항목은 설정값을 확인하며 입력하기 좋고, 구독은 여러 항목을 한꺼번에 가져오고 나중에 업데이트하기에 적합합니다. 구독 주소는 연결 항목을 가져오는 경로이지 원격 프록시의 Address가 아닙니다. 아래 https://example.com/sub?token=xxxx는 형식을 보여 주기 위한 예시이며 연결에 사용할 수 없습니다. 실제 구독 주소는 서비스 제공업체에서 받으세요.

  1. 추가 화면 열기

    Home으로 이동해 오른쪽 상단의 “+”를 누르고 Add Server를 엽니다. 직접 입력하려면 먼저 Type에서 원래 설정과 일치하는 프로토콜을 선택하세요.

  2. 연결 정보 입력

    프로토콜에 따라 Address, Port, 인증 정보를 입력합니다. TLS, Server Name, 전송 방식, Path도 확인하고, 흔한 기본값을 서버 요구 사항 대신 사용하지 마세요.

  3. 구독 가져오기

    구독 주소가 있다면 Add Server → Type에서 Subscribe를 선택하고 전체 구독 주소를 URL에 입력한 뒤 저장합니다. 항목을 가져올 때까지 기다리세요. 구독 주소를 특정 프로토콜의 Address에 입력하면 안 됩니다.

  4. 확인 및 테스트

    Home으로 돌아가 가져온 항목 수와 각 항목의 Type을 확인합니다. 항목 하나를 선택해 연결한 뒤 명확한 테스트 대상으로 요청을 보내 보세요. 지연 시간 측정 결과와 실제 요청 결과를 구분해야 합니다.

  5. 업데이트 출처 유지

    서비스 제공업체의 변경 사항을 반영해야 한다면 Home에서 구독을 업데이트하세요. 업데이트 후 항목이 남아 있는지 다시 확인하세요. 구독으로 생성된 항목을 직접 수정하는 것은 설정을 장기간 보존하는 방법이 아닙니다.

7. 프로토콜 설정이 맞아도 Global Routing 확인하기

연결 항목 테스트는 정상인데 특정 웹사이트에 접속할 수 없다면 해당 요청이 실제로 선택한 연결 항목을 사용하는지 먼저 확인하세요. Global Routing의 Config는 구성 파일에 설정된 규칙을 적용합니다. 예를 들어 앞에 있는 DOMAIN-SUFFIX 규칙이 일치하면 뒤의 FINAL은 해당 요청을 처리하지 않습니다. IP-CIDR은 IP 대역을 기준으로 일치 여부를 확인하고, GEOIP는 대상 IP가 속한 지역을 기준으로 일치 여부를 확인합니다. 둘 다 프로토콜을 선택하는 설정은 아닙니다.

Config: 구성 규칙에 따라 트래픽 분기

권장

확인된 구성을 사용하고 규칙 순서에 따라 대상 정책이 선택되는지 확인하세요. 앞선 규칙에 일치하지 않은 요청은 보통 FINAL에서 처리되며, 최종 경로는 구성 내용에 따라 달라집니다.

적합한 경우: 명확한 트래픽 분기 요구가 있고 규칙을 확인한 뒤 일상적으로 사용하는 경우

Proxy: 프록시 경로 확인

Shadowrocket이 처리하는 요청에 프록시 경로를 사용해 규칙 분기가 테스트에 미치는 영향을 일시적으로 줄입니다. 잘못된 비밀번호, TLS 오류, 원격 서버 연결 불가를 해결해 주지는 않습니다.

적합한 경우: Config 규칙이 문제의 원인인지 임시로 확인할 때

Direct: 직접 연결 경로 확인

직접 연결 경로를 사용해 현재 네트워크에서 같은 대상에 접속한 결과와 비교합니다. Direct를 선택한 상태에서 웹페이지가 열려도 프록시 연결 항목이 정상적으로 연결됐다는 뜻은 아닙니다.

적합한 경우: 직접 연결과 프록시 연결 결과를 비교해 문제 범위를 좁힐 때

Scene은 상황별 관련 설정을 구성하는 기능이지 새로운 프로토콜이 아닙니다. Settings → On Demand에서는 자동 연결 조건을 관리하며 연결 항목의 Type은 바꾸지 않습니다. 문제를 점검할 때는 테스트 조건을 일정하게 유지하고 Global Routing과 현재 적용 중인 구성을 확인한 다음, On Demand에 따른 자동 연결이 작동하는지도 따로 확인하세요.

8. 자주 묻는 프로토콜 설정 문제

주소와 포트를 입력했는데도 연결되지 않는 이유는 무엇인가요?

Home에서 해당 항목의 편집 화면을 열고 Type과 인증 정보를 확인하세요. Shadowsocks에는 Method와 Password도 필요하고, VMess/VLESS에는 UUID와 전송 설정이, WireGuard에는 키와 터널 설정이 필요합니다. 주소와 포트는 원격 접속 지점을 나타낼 뿐입니다.

지연 시간 측정 결과가 있는데 웹페이지가 열리지 않는 이유는 무엇인가요?

지연 시간 측정에 성공해도 대상 웹사이트 요청이 성공한다는 뜻은 아닙니다. 먼저 Home에서 Global Routing을 확인하고 Proxy를 임시로 사용해 Config와 비교하세요. Config에서만 실패한다면 규칙을 점검합니다. 두 모드 모두 실패하면 DNS, 인증 정보, TLS를 확인하세요. 지연 시간 수치만으로 프로토콜이 정상 작동한다고 판단하지 마세요.

TLS 오류가 발생하면 인증을 건너뛰어도 되나요?

먼저 기기 시간, Address, Server Name, 서버 인증서가 서로 일치하는지 확인한 다음 서비스 제공업체에 전체 보안 설정을 문의하세요. 인증을 건너뛰면 신원 확인이 약화되므로 일반적인 해결 방법으로 사용해서는 안 됩니다. 잘못된 비밀번호나 전송 경로 불일치도 해결하지 못합니다.

구독을 업데이트한 뒤 직접 수정한 내용이 사라지는 이유는 무엇인가요?

구독으로 생성된 항목은 업데이트 과정에서 다시 만들어질 수 있습니다. Home에서 구독 출처와 업데이트 결과를 확인하고, 장기간 유지해야 하는 연결 설정은 서비스 제공업체에 확인하세요. 별도로 테스트해야 한다면 수동 항목을 새로 만들어 사용하고, 구독 항목을 수정해 설정을 보존하려고 하지 마세요.

지원 프로토콜이 여러 가지인데 무엇을 선택해야 하나요?

서비스 제공업체가 명확히 안내했고 필요한 설정이 모두 갖춰진 프로토콜을 먼저 사용하세요. 비교하려면 같은 기기와 네트워크에서 비슷한 시간대에 같은 대상에 접속하고 연결 성공률, 요청 시간, 오류 유형을 기록하세요. 한 번에 하나의 조건만 바꾸고 프로토콜 이름만으로 안정성을 판단하지 마세요.

App Store에서 다운로드