Shadowrocket에서 Home → + → Type으로 이동해 서비스 제공업체가 안내한 설정에 맞는 프로토콜을 선택한 뒤 주소, 인증 정보, 전송 매개변수를 확인하세요. 설정 정보는 있지만 프로토콜 이름과 TLS, TCP, UDP의 의미가 헷갈리는 사용자를 위한 안내입니다. 먼저 프로토콜 표를 확인하고 단계에 따라 입력한 다음, Global Routing에서 프로토콜 연결 문제와 규칙 문제를 구분해 점검하세요.
프로토콜 비교: Type을 먼저 확인하고 전송 방식과 암호화를 살펴보세요
Home에서 기존 항목의 편집 화면을 열거나 오른쪽 위의 +를 눌러 Type을 확인하세요. 여기서 선택하는 것은 서버와 통신하는 프로토콜이지 속도 설정이 아닙니다. Shadowrocket은 아래 표의 프로토콜을 지원합니다. 세부 추가 항목과 사용 가능한 전송 방식 조합은 현재 앱 화면과 사용 중인 서비스 제공업체의 설정 안내를 따르세요.
| 프로토콜 | 전송 특징 | 암호화 및 인증 | 입력 전 확인 사항 |
|---|---|---|---|
| Shadowsocks | TCP와 UDP를 전송에 사용할 수 있습니다. 실제 UDP 지원 여부는 서버와 네트워크 환경에 따라 달라집니다. | 지정된 암호화 방식과 공유 키를 사용합니다. 일반적인 AEAD 방식은 암호화와 무결성 보호를 함께 제공합니다. | Address, Port, Password, 암호화 방식이 서로 일치해야 합니다. |
| VMess | TCP 등의 전송 방식을 사용할 수 있으며, 설정에 따라 WebSocket과 TLS를 조합할 수도 있습니다. | UUID로 사용자를 식별합니다. 프로토콜 자체의 암호화 설정과 외부 TLS는 서로 다른 계층입니다. | UUID, 암호화 옵션, 전송 방식, TLS 매개변수 |
| VLESS | 전송 방식과 외부 보안 계층은 서버 설정에 따라 결정됩니다. | UUID로 인증합니다. VLESS 자체는 페이로드를 암호화하지 않으며, 일반적으로 TLS 같은 외부 보안 계층을 사용합니다. | UUID, 전송 방식, TLS, 서버에서 요구하는 추가 항목 |
| Trojan | 일반적으로 TLS 연결을 사용합니다. UDP 포워딩은 구현 방식과 서버 지원 여부에 따라 달라집니다. | Password로 인증하며, TLS가 연결을 보호하고 서버의 신원을 확인합니다. | Password, SNI, 인증서 검증, 실제 수신 포트 |
| HTTP / SOCKS5 | HTTP 프록시는 주로 CONNECT로 터널을 설정합니다. SOCKS5는 CONNECT를 지원하며 UDP ASSOCIATE도 정의합니다. | 기본 HTTP 프록시와 SOCKS5는 클라이언트와 프록시 사이의 연결을 자체적으로 암호화하지 않습니다. 사용자 이름과 비밀번호를 설정해도 전송 암호화가 되는 것은 아닙니다. | 프록시 유형, 주소, 포트, 인증 정보, 별도의 TLS 사용 여부 |
| WireGuard | UDP 기반 네트워크 계층 터널로, Peer와 주소 설정을 사용합니다. | 공개 키와 개인 키를 사용하며, Pre-shared Key를 추가로 설정할 수 있습니다. | Private Key, Peer Public Key, 터널 주소, Allowed IPs, MTU |
| Hysteria2 | QUIC 기반이며 UDP를 사용합니다. 네트워크 경로에서 해당 UDP 통신이 허용되어야 합니다. | QUIC의 TLS 1.3 보안 메커니즘을 사용하며, 서버 요구에 맞춰 인증 정보를 설정합니다. | 인증 정보, SNI, 포트, 선택적 난독화 매개변수 |
서비스 제공업체의 안내에서 WebSocket, TLS, QUIC을 보더라도 이를 모두 Type으로 간주하지 마세요. WebSocket은 전송 캡슐화 방식이고, TLS는 보안 계층이며, QUIC은 UDP 기반의 보안 전송 프로토콜입니다. Shadowsocks나 VMess 같은 이름과는 분류 계층이 다릅니다. 먼저 프로토콜을 확인하고 각 계층의 항목을 차례로 맞추면 주소와 비밀번호가 맞는데도 핸드셰이크가 실패하는 문제를 줄일 수 있습니다.
매개변수 계층 구분: 주소, 인증, TLS는 서로 대체할 수 없습니다
편집 화면에서 먼저 Address와 Port를 입력한 다음 Type에 맞는 인증 정보를 입력하세요. Address는 연결 대상이고 Port는 서버가 실제로 수신 대기하는 포트입니다. SNI는 TLS 핸드셰이크에서 서버 이름을 지정합니다. Address에 IP 주소를 입력했더라도 SNI에는 인증서에 해당하는 도메인 이름이 필요할 수 있으므로 두 값을 무조건 같게 설정하지 마세요.
인증 항목에서 Shadowsocks의 Password, VMess/VLESS의 UUID, WireGuard의 Private Key는 서로 바꿔 쓸 수 없습니다. WireGuard의 로컬 Private Key는 서버에 등록된 클라이언트 공개 키와 짝을 이루어야 하며, Peer Public Key에는 상대편의 공개 키를 입력합니다. 클라이언트 자신의 공개 키를 Peer Public Key에 입력하면 일반적으로 의도한 핸드셰이크를 설정할 수 없습니다.
- 암호화 방식: Shadowsocks의 방식 이름은 서버 설정과 정확히 일치해야 합니다. Password만 복사한 뒤 임의의 방식을 선택하지 마세요.
- 전송 경로: VMess 또는 VLESS에서 WebSocket을 사용하는 경우 Host와 Path도 일치해야 할 수 있습니다. Path의 대소문자와 앞에 붙는 슬래시는 원래대로 유지하세요.
- 인증서 검증: Trojan 또는 다른 TLS 설정에서 인증서 오류가 발생하면 먼저 SNI, 기기 시간, 인증서 유효성을 확인하세요. Allow Insecure를 일반적인 해결 방법으로 사용하지 마세요.
- 키 보호: Private Key, Password, UUID, 구독 token은 모두 민감한 설정 정보로 취급해야 합니다. 문제를 확인할 때는 항목 이름만 표시하고 값은 가리세요.
정리: 이름을 추측하지 말고 항목별로 맞추세요
서버 설정 정보를 연결 대상, 인증, 전송, 보안 계층의 네 부분으로 나눠 각각 입력하세요. 안내에 없는 항목은 필수인지 먼저 확인하고, 다른 설정에서 사용한 값을 가져오지 마세요.
추가 단계: 직접 입력과 가져오기 모두 Type을 다시 확인하세요
Home에서 서버 항목을 추가하고, Config에서 구성 파일과 규칙을 관리하며, Settings에서 앱을 설정합니다. 프로토콜 항목을 추가하는 것과 규칙 설정을 바꾸는 것은 별개의 작업입니다. 전자는 서버에 연결하는 방식을, 후자는 어떤 요청에 어떤 정책을 적용할지를 결정합니다. 아래 단계는 사용자가 서비스 제공업체의 설정 정보를 이미 가지고 있는 경우를 전제로 합니다.
-
유형 확인
Home → + → Type을 열고 안내에 명시된 프로토콜을 선택하세요. Trojan을 VLESS로 바꿔 호환되게 만들 수 없으며, Hysteria2도 포트만 변경한다고 다른 프로토콜이 되지 않습니다.
-
연결 대상 입력
추가 화면으로 돌아가 안내에 따라 Address, Port, 해당 프로토콜의 인증 정보를 입력하세요. 실제 포트 번호를 사용해야 합니다. 안내에 8443으로 되어 있다면 TLS를 사용한다는 이유만으로 443으로 바꾸지 마세요.
-
전송 설정 맞추기
선택한 Type에 따라 표시되는 항목에서 TLS, SNI, 전송 방식, 추가 매개변수를 확인하세요. 저장하기 전에 도메인에 공백이 들어갔는지, Password 끝에 줄바꿈이 추가됐는지, UUID가 전부 입력됐는지 확인하세요.
-
가져온 설정 확인
구독을 사용 중이라면 Home → + → Type → Subscribe에서 본인의 구독 링크를 입력하고 저장할 수 있습니다. 가져온 뒤에는 해당 항목을 열어 Type과 주요 항목을 확인하세요. 구독을 업데이트하면 직접 수정한 내용이 덮어써질 수 있으므로 원래 설정 정보를 보관해 두고 비교하세요.
-
연결 확인
Home으로 돌아가 테스트할 항목을 선택한 다음 연결 스위치를 켜고, 시스템 안내에 따라 VPN 구성을 허용하세요. 먼저 연결 여부를 확인할 수 있는 대상을 테스트한 뒤 실제 요청이 의도한 정책을 따르는지 확인하세요. 한 번 측정한 지연 시간만으로 모든 서비스의 사용 가능 여부를 판단할 수는 없습니다.
구독 업데이트 후 프로토콜 항목이 바뀌었다면 서버 설정도 함께 변경됐는지 확인한 다음 다시 테스트하세요. 구독은 설정을 배포하고 업데이트하는 기능이며, 각 항목의 서버가 항상 정상 작동한다고 보장하지는 않습니다. 항목을 직접 수정하기 전에 원래 값을 기록해 두면 업데이트 후 원래 설정 오류와 로컬 수정 오류를 구분하기 쉽습니다.
Global Routing: 프로토콜 연결과 규칙 적용을 따로 확인하세요
Home → Global Routing에서 현재 모드를 확인한 뒤 요청이 선택한 항목을 사용하지 않는 이유를 점검하세요. Config, Proxy, Direct, Scene은 라우팅 제어 항목이지 프로토콜 이름이 아닙니다. Scene에서는 상황별 라우팅 동작을 구성하며, 실제 결과는 해당 Scene 설정을 확인해야 합니다. Scene을 다른 암호화 방식으로 해석하지 마세요.
Config
권장현재 설정된 규칙과 정책에 따라 요청을 처리합니다. 매칭 결과는 DIRECT, 프록시 또는 지정된 다른 정책일 수 있습니다. 앞선 규칙에 일치하는 항목이 없으면 일반적으로 FINAL이 처리 방향을 결정합니다.
적합한 경우: 규칙을 확인한 뒤 일상적인 트래픽을 분기할 때
Proxy
프록시 처리 경로로 들어가는 요청을 선택한 프록시 정책으로 전달해 규칙 매칭에 따른 변수를 일시적으로 줄일 수 있습니다. 테스트가 끝나면 기존 모드로 되돌리세요. 이 테스트만으로 모든 앱의 트래픽이 검증됐다고 볼 수는 없습니다.
적합한 경우: 서버 연결 실패와 규칙 미적용을 구분할 때
Direct
직접 연결 경로를 사용합니다. 이 상태에서 웹페이지가 열리더라도 방금 입력한 Trojan, WireGuard 또는 다른 프로토콜 설정이 유효하다는 뜻은 아닙니다. 요청이 해당 서버를 거치지 않았을 수 있습니다.
적합한 경우: 로컬 네트워크의 기본 연결 상태를 비교할 때
Config에 등록된 구성 파일에서 규칙 순서에 따라 매칭 대상과 정책 이름을 확인하세요. 아래는 구문 예시일 뿐 완전한 구성은 아닙니다. 실제 설정에서 PROXY는 사용 가능한 정책과 연결되어 있어야 합니다. DOMAIN-SUFFIX는 도메인 접미사를, IP-CIDR은 주소 대역을 매칭하며, GEOIP는 IP 지리 데이터베이스를 기준으로 판단합니다. 앞선 규칙에 모두 일치하지 않은 요청은 FINAL이 처리합니다.
DOMAIN-SUFFIX,example.com,PROXY
IP-CIDR,192.168.0.0/16,DIRECT
GEOIP,CN,DIRECT
FINAL,PROXYSettings → On Demand에서는 조건에 따라 연결을 자동으로 시작하는 동작을 설정합니다. 특정 프로토콜의 매개변수를 보완하는 기능은 아닙니다. 프로토콜 자체의 연결을 확인하기 전에는 먼저 수동으로 연결해 정상 작동하는지 확인한 뒤 On Demand를 설정하세요. 그러면 자동 연결 조건과 핸드셰이크 오류를 분리해 점검할 수 있습니다. 규칙 매칭에 관한 자세한 설명은 사용 설명서의 라우팅 섹션을 참조하세요.
자주 묻는 질문: 증상에 따라 프로토콜 문제 범위 좁히기
Home에서 테스트할 항목을 선택한 뒤 연결 설정, TLS 핸드셰이크, 대상 사이트 열기 중 어느 단계에서 실패했는지 기록하고 연결 로그를 확인하세요. 시간 초과는 어떤 단계가 제때 완료되지 않았다는 뜻일 뿐, 이 메시지만으로 비밀번호가 틀렸거나 프로토콜이 지원되지 않는다고 단정할 수는 없습니다. 아래 절차는 변수를 하나씩 줄여 확인하는 방법이며, 비슷한 증상이 모두 같은 원인으로 발생한다는 뜻은 아닙니다.
Hysteria2는 시간 초과가 발생하지만 다른 항목은 연결됩니다. 무엇이 다를까요?
먼저 Hysteria2의 Address, Port, 인증 정보, SNI를 확인한 다음 현재 네트워크에서 서버로 UDP 통신이 가능한지 점검하세요. 신뢰할 수 있는 다른 네트워크에서 같은 설정을 시험해 비교할 수도 있습니다. TCP 기반 연결에 성공하더라도 동일한 대상의 UDP 포트에 도달할 수 있다는 뜻은 아닙니다.
Trojan에서 인증서 오류가 발생하면 Allow Insecure를 켜면 되나요?
먼저 항목 편집 화면에서 SNI가 인증서의 도메인 이름과 일치하는지 확인하세요. 그런 다음 기기의 시스템 설정에서 날짜와 시간을 점검하고, 서비스 제공업체에 전체 인증서 체인을 확인하세요. Allow Insecure를 사용하면 서버 신원 확인이 약해지므로 기본 설정으로 계속 사용하지 마세요.
VLESS의 UUID가 맞는데도 연결에 실패하는 이유는 무엇인가요?
Home으로 돌아가 해당 항목을 열고 전송 방식, TLS, SNI, 서버에서 요구하는 Host, Path 및 기타 추가 항목을 하나씩 확인하세요. UUID는 인증의 일부만 처리하므로 전송 캡슐화나 보안 계층이 일치하지 않는 문제를 해결하지 못합니다.
WireGuard에서 핸드셰이크는 되지만 일부 페이지가 계속 로딩될 때는 어떻게 하나요?
먼저 Allowed IPs에 의도한 대상이 포함되어 있는지 확인한 다음 DNS와 MTU를 점검하세요. MTU를 무작정 높이지 말고 서버 권장값과 네트워크 경로 상태에 따라 조정하세요. 매번 한 항목씩만 변경하고 결과를 기록하면 라우팅 누락과 패킷 크기 문제를 구분하기 쉽습니다.
어떤 프로토콜이 가장 빠른가요? 하나를 바로 선택해도 될까요?
먼저 서버가 어떤 프로토콜을 제공하는지 확인한 다음 같은 네트워크와 대상, 비슷한 시간대에 연결 성공률, 응답 시간, 지속적인 데이터 전송 상태를 비교하세요. 프로토콜 이름만으로 연결 품질을 판단할 수는 없으며, Shadowsocks만 제공하는 서버에 Trojan으로 연결할 수도 없습니다.
문제 해결 정보를 공유하기 전에 구독 링크의 token, 인증 정보, 키를 가리고 Type, 전송 방식, 포트, 오류 발생 단계, 네트워크 전환 후 나타난 현상만 남기세요. 추가 분석이 필요하면 연결 문제 해결 섹션의 순서에 따라 기록을 정리하세요. 모든 옵션을 반복해서 바꾸는 것보다 원인을 찾기 쉽습니다.