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

지원 프로토콜과 각 이름의 관계

프로토콜끼리 서로 바꿔 쓸 수 있나요? 바로 바꿔 쓸 수는 없습니다. Shadowsocks, VMess, VLESS, Trojan, HTTP, SOCKS5, WireGuard, Hysteria2는 각각 핸드셰이크와 인증 방식이 다릅니다. 먼저 서비스에서 제공한 프로토콜 이름을 확인한 다음 Home 오른쪽 위의 “+”를 눌러 Add Server로 이동하고, 해당 Type을 선택하세요. 서버에서 지원하지 않는 프로토콜은 클라이언트의 선택 항목만 바꿔서는 사용할 수 없습니다.

Add Server에 같은 항목만 계속 표시되지 않는 이유는 무엇인가요? Type과 활성화한 옵션에 따라 입력 항목이 달라집니다. 특정 전송 방식을 선택해야 Path나 Host를 입력할 수 있고, TLS 관련 옵션을 켜야 서버 이름을 확인할 수 있는 경우도 있습니다. 표는 주요 확인 항목을 정리한 것으로, 모든 프로토콜에 같은 양식을 사용한다는 뜻은 아닙니다. 실제 선택 가능한 항목은 앱에 표시되는 내용을 확인하세요.

Shadowsocks, VMess, VLESS에는 무엇을 입력해야 하나요?

Shadowsocks는 비밀번호만 있으면 되나요? 그렇지 않습니다. 최소한 Address, Port, 암호화 방식을 함께 확인해야 합니다. Password가 같아도 암호화 방식이 다르면 정상적으로 통신할 수 없습니다. 보유한 연결 정보에 추가 전송 방식이나 난독화 설정이 있다면 원래 정보에 맞게 입력하세요. 주소와 비밀번호만 남겨서는 안 됩니다.

• Shadowsocks: 암호화 방식 이름을 정확히 대조하세요. 이름이 비슷하다고 같은 항목으로 취급하면 안 됩니다. Address에는 호스트 이름이나 IP만 입력하고 Port에는 해당 숫자를 입력하세요. 전체 공유 링크를 Address에 넣지 마세요.
• VMess: 핵심 인증 정보는 UUID이며, 암호화 옵션과 전송 방식도 확인해야 합니다. 원본 설정에 AlterID 등의 호환성 매개변수가 있다면 원래 값을 유지하세요. 튜토리얼에 맞춰 일괄 변경하지 마세요.
• VLESS: VMess와 마찬가지로 UUID를 사용하지만, VMess의 다른 표기가 아닙니다. VLESS 자체는 페이로드를 암호화하지 않으므로 서버 요구사항에 맞는 보안 계층을 설정해야 합니다. VMess의 암호화 옵션을 그대로 적용하지 마세요.

UUID가 맞는데도 웹 페이지가 열리지 않는 이유는 무엇인가요? 인증은 여러 설정 중 하나일 뿐입니다. 서버가 WebSocket을 사용하는데 클라이언트에서 다른 전송 방식을 선택하면 핸드셰이크가 예상대로 완료되지 않을 수 있습니다. 선택한 전송 방식을 확인한 다음 Path와 Host를 대조하세요. Path의 슬래시와 경로 내용을 임의로 지우거나 바꾸면 안 되며, Host가 반드시 Address와 같은 것도 아닙니다.

Trojan과 Hysteria2의 TLS 설정은 어떻게 확인하나요?

Trojan은 Password만 입력하면 되나요? 서버 주소와 포트, TLS 설정도 확인해야 합니다. Trojan은 보통 TLS를 통해 연결하므로 인증 비밀번호가 맞더라도 인증서 검증을 대신할 수는 없습니다. Address에 IP를 입력했는데 인증서가 특정 도메인에 발급되어 있다면 서비스에서 안내한 서버 이름을 입력하세요. 인증서 검증을 끄는 방법을 일반적인 해결책으로 삼지 마세요.

Hysteria2와 Trojan은 어떻게 다른가요? Hysteria2는 QUIC 기반으로 UDP 통신이 필요합니다. Trojan은 일반적으로 TCP와 TLS를 사용합니다. 둘 다 인증과 인증서 설정이 관련될 수 있지만, 매개변수를 서로 복사해서는 안 됩니다. 현재 네트워크에서 UDP가 제한되거나 포트가 열려 있지 않거나 서버에 연결할 수 없다면 Hysteria2 연결이 시간 초과될 수 있습니다. 그렇다고 인증 비밀번호가 반드시 잘못된 것은 아닙니다.

1. 이름이 비슷한 Hysteria가 아니라 Type이 Hysteria2인지 확인하세요. 두 프로토콜은 그대로 바꿔 쓸 수 있는 버전이 아닙니다.
2. Port가 서버에서 실제로 수신 대기 중인 포트와 일치하는지 확인하세요. 443을 사용하더라도 해당 UDP 통신이 가능한지 확인해야 합니다.
3. 인증 정보, TLS 서버 이름, 인증서 요구사항을 확인하세요. 서버에 난독화 설정이 있다면 해당 유형과 비밀번호도 확인해야 합니다.
4. 대역폭이나 기타 선택 매개변수가 있다면 실제 서비스 설정에 맞춰 입력하세요. 근거 없이 높은 값을 넣어 네트워크 테스트를 대신하지 마세요.

Hysteria2로 바꾸면 반드시 더 빨라지나요? 프로토콜 이름만으로 속도를 판단할 수 없습니다. 서버 부하, 네트워크 왕복 지연 시간, 패킷 손실, UDP 제한 등이 모두 결과에 영향을 줍니다. 비교할 때는 대상 웹사이트, 기기, 네트워크 조건을 동일하게 유지하세요. 먼저 연결이 실제로 성공했는지 확인한 뒤 페이지가 완전히 로드되는 시간을 살펴보세요. 한 번 측정한 지연 시간만으로 처리량을 판단하기는 어렵습니다.

HTTP, SOCKS5, WireGuard는 어떻게 구분하나요?

HTTP와 SOCKS5에도 UUID를 입력해야 하나요? 일반적으로 필요하지 않습니다. 보통 Address, Port, 그리고 서버에서 요구하는 경우 사용자 이름과 비밀번호를 입력합니다. 서버에서 계정 인증을 사용하지 않는다면 임의로 자격 증명을 추가하지 마세요. TLS로 보호되는 프록시 연결이 필요한 경우에는 이에 맞는 Type이나 보안 설정도 선택해야 합니다.

WireGuard는 왜 주소와 비밀번호만 입력해서는 안 되나요? WireGuard는 키로 인증하며 터널 내부의 주소와 라우팅도 설정해야 합니다. 로컬 Private Key는 서버에 등록된 클라이언트 공개 키와 짝을 이루어야 하고, 피어 Public Key는 서버를 식별하는 데 사용됩니다. 두 키를 서로 바꾸면 안 됩니다. 인터페이스 주소, Allowed IPs, 엔드포인트는 각각 용도가 다르므로 서버의 공인 IP를 자신의 터널 주소로 입력해서는 안 됩니다.

Add Server부터 연결 테스트까지 어떤 순서로 진행하나요?

직접 입력과 구독 가져오기 중 무엇을 먼저 선택해야 하나요? 완전한 구독 정보가 있다면 구독에 포함된 프로토콜, 전송 방식, 보안 설정을 그대로 유지하는 것이 좋습니다. 서비스에서 개별 연결 정보를 제공했거나 특정 항목을 확인해야 할 때 Add Server에 직접 입력하세요. 아래 절차는 이미 자신의 서비스 정보를 보유한 경우를 전제로 하며, 서비스 제공처를 추천하지 않습니다.

1. 정보 출처 확인

   먼저 보유한 연결 정보에서 프로토콜, 주소, 포트, 인증 정보를 확인하세요. 민감한 항목을 공개 토론 게시판에 붙여 넣지 마세요. 구독 링크만 있다면 이를 개별 서버 주소로 입력하지 마세요.

2. Type 선택

   Home → 오른쪽 위 “+” → Add Server → Type으로 이동해 서버와 같은 프로토콜을 선택하세요. 그런 다음 Address, Port와 해당 인증 정보를 입력합니다.

3. 옵션 입력

   보유한 정보에 맞춰 전송 방식, Host, Path, TLS 등의 옵션을 입력하세요. 선택한 프로토콜에 실제로 필요한 항목만 작성하면 됩니다. 저장한 뒤 Home으로 돌아가 해당 서버를 선택하세요.

4. 연결 확인

   Home에서 Connectivity Test를 실행한 다음 연결 스위치를 켜고 접속 가능한 웹사이트를 방문하세요. 처음 연결할 때는 시스템 안내에 따라 VPN 구성을 허용하세요. 또한 Global Routing이 Direct로 설정되어 있어 프록시 결과를 잘못 판단하는 일이 없도록 확인하세요.

구독 정보는 어디에 입력하나요? Home 오른쪽 위의 “+”를 눌러 Add Server로 이동하고 Type에서 Subscribe를 선택하세요. 자신의 구독 링크를 입력해 저장한 다음 Home으로 돌아가 해당 구독을 업데이트합니다. 업데이트 후 현재 선택된 서버를 다시 확인하세요. 구독 항목을 가져오는 데 성공했더라도 각 연결이 실제 서비스 접속 테스트를 통과했다는 뜻은 아닙니다.

구독을 업데이트하면 모든 오류가 해결되나요? 그렇지 않습니다. 업데이트는 구독 서버가 반환한 내용에 따라 관련 항목을 새로고침할 뿐, 현재 네트워크 차단이나 서버 장애를 해결하지는 않습니다. 구독 항목을 직접 수정했다면 업데이트 후 관련 설정을 다시 확인하세요. Config의 분기 규칙도 별도로 확인해야 합니다. 서버 목록 업데이트를 규칙 동기화로 간주하면 안 됩니다.

프로토콜이 맞는데도 Global Routing이 결과에 영향을 주는 이유는 무엇인가요?

서버를 선택하면 모든 트래픽이 그 서버를 거치나요? 반드시 그렇지는 않습니다. 프로토콜은 서버와 통신하는 방식을 결정하고 Global Routing은 연결에 적용할 라우팅 방식을 결정합니다. 프로토콜 문제를 확인할 때는 테스트 요청이 실제로 프록시 정책을 따르는지 먼저 확인하세요. Direct 상태에서 웹 페이지가 열린다고 해서 서버 설정이 올바르다는 뜻은 아닙니다.

Scene과 On Demand도 프로토콜인가요? 아닙니다. Global Routing의 Scene은 설정한 상황에 따라 라우팅 선택을 처리하며, 실제 동작은 각 Scene 설정에 따라 달라집니다. Settings → On Demand는 연결을 필요에 따라 자동으로 시작할지 제어하지만, 서버에 빠진 인증이나 TLS 설정을 추가하지는 않습니다. 문제를 해결하는 동안 이 설정을 기록해 두어 자동 연결이나 Scene 전환이 테스트 조건을 바꾸지 않도록 하세요.

자주 발생하는 문제: 누락된 항목, 시간 초과, 연결 후 웹 페이지 접속 불가

오류가 발생하면 무엇부터 바꿔야 하나요? 먼저 오류가 발생한 단계를 구분하세요. 양식 저장에 실패했다면 필수 입력값부터 확인합니다. 테스트 시간 초과는 주소, 포트, 네트워크, 서버 상태를 함께 살펴봐야 합니다. 연결 후 일부 웹사이트에 문제가 있다면 DNS와 규칙도 확인하세요. 아래 순서대로 점검하면 프로토콜을 계속 바꾸는 것보다 원인을 찾기 쉽습니다.