Shadowrocket 프로토콜 선택 및 설정 참고

01 / SELECTION

프로토콜 선택: 먼저 서버 유형을 확인한 다음 전송 조건 비교하기

프로토콜, 전송, 보안, 라우팅을 구분해 이해하기

Shadowrocket에서 프로토콜 유형을 선택한다는 것은 클라이언트가 서버와 어떤 형식으로 통신할지 지정하는 것입니다. 서로 바꿔 쓸 수 있는 속도 설정을 고르는 것이 아닙니다. 서버에서 Shadowsocks를 제공하면 해당 Shadowsocks 유형과 인증 정보가 필요합니다. 서버가 Trojan을 제공한다면 유형만 VLESS로 바꿔 계속 사용할 수 없습니다. 주소와 포트가 같다는 사실은 연결 대상이 같다는 뜻일 뿐, 서버가 동일한 핸드셰이크, 인증, 데이터 캡슐화 방식을 지원한다는 의미는 아닙니다. 프로토콜 선택의 첫 번째 기준은 보유한 정보에 명시된 유형입니다.

정상적인 연결에는 보통 네 계층의 정보가 필요합니다. 첫째, 주소와 포트는 데이터를 보낼 위치를 지정합니다. 둘째, 프로토콜과 인증 정보는 서버가 요청을 수락할지 결정합니다. 셋째, TLS, WebSocket, UDP 같은 전송 및 보안 설정이 있습니다. 마지막으로 로컬 라우팅에서 어떤 요청을 해당 연결로 보낼지 정합니다. 일부 프로토콜은 여러 계층을 결합하고, 일부는 다양한 조합을 지원합니다. 문제를 진단할 때는 계층별로 확인해야 합니다. 그렇지 않으면 DNS 오류를 비밀번호 오류로 오인하거나, 규칙 미일치를 프로토콜 비호환으로 착각하기 쉽습니다.

속도와 배터리 소모에는 정해진 순위가 없습니다

실제 속도는 접속 네트워크, 왕복 지연 시간, 패킷 손실, 서버 부하, 출구 대역폭, 대상 서비스의 영향을 함께 받습니다. 캡슐화 계층이 늘면 데이터 크기와 처리량이 증가할 수 있지만, 모든 환경에서 더 느려지는 것은 아닙니다. 현재 네트워크에 적합한 전송 방식이라면 재전송 감소 효과가 캡슐화 비용보다 클 수 있습니다. 반대로 같은 서버에서 두 프로토콜 간 차이보다 서로 다른 서버 간 차이가 훨씬 클 수도 있습니다. 따라서 이 가이드에서는 프로토콜 이름만으로 고정된 속도 순위를 제시하지 않습니다.

iPhone과 iPad의 배터리 소모도 사용 방식에 따라 살펴봐야 합니다. 대용량 데이터를 계속 전송하면 무선 연결과 암·복호화, 앱 처리 능력을 함께 사용합니다. 간헐적인 요청은 연결 횟수, 백그라운드 연결 유지, 네트워크 깨우기의 영향을 받기 쉽습니다. 자동 속도 측정을 자주 실행하거나 업데이트 간격을 짧게 설정하고 연결을 반복해서 다시 시도하면 프로토콜 자체의 차이를 파악하기 어려워질 수 있습니다. 비교할 때는 기기, 네트워크, 서버, 대상을 동일하게 유지하고 화면 밝기와 다른 백그라운드 작업도 고려하세요. 배터리가 한 번 줄었다고 특정 프로토콜 탓으로 단정할 수는 없습니다.

재현 가능한 비교 방법 만들기

정상 작동이 확인된 설정을 기준값으로 저장한 뒤 항목을 하나씩 조정하세요. 같은 대상으로 첫 접속, 재접속, 지속 전송, 절전 모드 해제 후 연결을 각각 확인하고, 매번 DNS와 프로토콜, 서버를 동시에 바꾸지 마세요. Connectivity Test는 연결 상태를 확인하는 한 가지 수단이지만, 결과만으로 모든 서비스가 정상 작동한다고 볼 수는 없습니다. 웹 탐색, 동영상 재생, 실시간 음성은 전송 요구 사항이 다르므로 숫자 하나만 비교하지 말고 실제 사용할 서비스를 테스트하세요.

보유한 정보에 프로토콜이 하나만 명시되어 있다면 해당 정보를 빠짐없이 가져와 검증하세요. 이름만 보고 다른 유형을 찾는 방식은 적절하지 않습니다. 프로토콜을 바꾸려면 새 프로토콜에 맞는 전체 설정을 서버 측에서 받아야 합니다. 구독을 가져온 뒤 목록이 비어 있는 문제는 프로토콜 선택과 별개이므로 구독 가져오기 후 목록이 비어 있을 때 확인할 사항을 참고하세요. 이후 내용은 편집 가능한 서버 기록이 하나 이상 있다는 전제하에 설명합니다. 표시되는 인터페이스 필드는 현재 앱에서 제공하는 옵션을 기준으로 확인하세요.

03 / VMESS · VLESS

VMess 및 VLESS: 비슷한 ID 필드가 있어도 같은 프로토콜은 아닙니다

설계 차이와 유형별 범위

VMess는 전용 프록시 프로토콜에서 인증과 데이터 처리를 구성하며, 설정에는 보통 UUID와 보안·전송 관련 매개변수가 포함됩니다. VLESS는 더 간결한 프로토콜 계층을 사용하며 자체적으로 콘텐츠를 암호화하지 않습니다. 따라서 전체 연결을 이해하려면 보안 전송 방식도 함께 살펴봐야 합니다. 두 프로토콜 모두 UUID를 사용할 수 있고 여러 외부 전송 방식과 조합될 수 있으므로, 링크에 ID 필드가 있다는 사실만으로 유형을 판단할 수 없습니다. 원본 구독 정보나 서버에 명시된 유형을 기준으로 삼으세요. 같은 UUID를 여러 프로토콜에서 공통으로 사용할 수 있는 연결 자격 증명으로 간주해서는 안 됩니다.

VLESS가 간결하다고 해서 전체 연결이 반드시 리소스를 덜 사용하거나 보안 계층을 생략해도 되는 것은 아닙니다. TLS, WebSocket 또는 다른 전송 방식을 함께 사용하면 실제 데이터 오버헤드와 핸드셰이크 절차는 전체 조합에 따라 달라집니다. VMess의 동작도 프로토콜 이름 하나가 아니라 서버 설정과 네트워크 조건의 영향을 받습니다. 프로토콜, 전송, 보안 계층을 각각 기록한 뒤 호환성과 사용 환경을 비교하세요. 한 계층만 떼어 비교하면 실제 동작과 다른 결론에 이를 수 있습니다.

UUID, 전송 유형, 경로

UUID는 서버에서 허용하는 사용자 ID를 식별합니다. 복사할 때는 모든 문자와 구분 형식을 그대로 유지하고, 별칭으로 대신하지 마세요. 별칭은 기록을 구별하기 위한 이름일 뿐 프로토콜 인증에 사용되지 않습니다. VMess의 일부 설정은 프로토콜 구현과 과거 구성 형식에 따라 다르므로 온라인의 단일 스크린샷만 보고 일괄 변경하지 마세요. 인증 과정에서 시간이 영향을 주는 프로토콜은 기기 시간이 크게 어긋나면 연결이 실패할 수 있습니다. 먼저 시스템 날짜와 시간이 올바른지 확인한 뒤 서버가 ID를 거부하는지 살펴보세요.

전송 필드는 프로토콜 데이터를 전달하는 방식을 지정합니다. WebSocket을 사용할 때 Path는 핸드셰이크 요청 경로이며 Host는 HTTP 계층의 호스트 정보와 관련이 있습니다. 둘 다 서버 별칭이 아니며 전체 URL을 임의로 나눠 입력해서도 안 됩니다. 경로 앞의 슬래시, 대소문자, 쿼리 문자열을 유지해야 하는지 서버 정보를 기준으로 확인하세요. 다른 전송 유형을 선택하면 필드 구성이 달라질 수 있습니다. WebSocket 매개변수를 다른 전송 유형에 그대로 입력하지 마세요. 화면에 보이지 않는 필드를 이름이 비슷한 다른 필드로 대신할 수도 없습니다.

TLS 이름 및 기타 확장 매개변수

연결 주소는 서버를 찾는 데 사용하고, TLS의 Server Name은 핸드셰이크에서 이름을 전달하며 인증서 이름 검증에도 관련됩니다. 두 값은 같을 수도 있고 서버 정보에 따라 다를 수도 있습니다. Host는 또 다른 계층에 속하므로 모두 도메인처럼 보인다고 해서 서로 덮어쓰면 안 됩니다. 보안 확장이나 특수 핸드셰이크 매개변수가 포함되어 있다면 현재 앱이 해당 조합을 지원하는지 확인하세요. 입력 필드가 있다는 사실만으로 임의의 조합이 서버와 호환된다는 의미는 아닙니다.

기존 설정의 Flow 같은 선택 매개변수는 특정 프로토콜 조합에만 적용되며, 범용 속도 향상 옵션이 아닙니다. 서버에서 명시적으로 요구하고 클라이언트가 호환 옵션을 제공할 때만 활성화하세요. 원본 정보를 확인하는 대신 여러 보안 매개변수를 반복해서 바꾸지 마세요. 핸드셰이크 조건이 동시에 달라져 원인을 파악하기 어려워집니다. 구독에서 가져온 기록은 원본을 보존한 뒤 별도의 테스트 복사본을 만들어 확인하면 가져온 정보가 불완전한지, 편집 이후 연결이 달라졌는지 구분하기 쉽습니다.

모바일 네트워크에서 비교하는 방법

iPhone이나 iPad에서 두 유형의 연결을 평가할 때는 첫 핸드셰이크와 연결 후 데이터 전송을 구분하세요. 여러 계층의 핸드셰이크는 왕복 지연 시간에 민감한 짧은 요청에 영향을 줄 수 있습니다. 장시간 전송은 대역폭과 혼잡의 영향을 더 많이 받을 수 있습니다. 네트워크가 바뀐 뒤 기존 연결이 끊기고 앱이 다시 연결되면 잠시 대기할 수도 있습니다. 특정 전송 방식만 복구가 느리다면 화면 잠금 해제 후인지, Wi-Fi 전환 후인지, 일반적인 연속 사용 중인지 기록하세요. 이를 VMess와 VLESS의 전반적인 차이라고 바로 단정해서는 안 됩니다.

실패가 발생하면 주소와 포트, 프로토콜과 UUID, 외부 전송, 보안 계층, 대상 접근 순서로 하나씩 확인하세요. 연결 기록에서 요청이 해당 서버를 선택하지 않은 것으로 보인다면 Global Routing과 현재 설정을 먼저 확인합니다. 일반적인 문제는 문제 해결에서 더 살펴볼 수 있습니다. 라우팅을 확인하기 전에 ID 필드를 반복해서 변경하지 마세요.

05 / HTTP · SOCKS5

HTTP 및 SOCKS5: 프록시 연결 지점을 확인하고 보호 범위를 점검하세요

두 가지 범용 프록시 인터페이스의 기본 개념

HTTP 프록시는 HTTP 요청을 전달하는 방식에서 발전했습니다. 웹 요청은 프록시 형식으로 전달할 수 있으며 HTTPS 등의 경우 CONNECT 요청으로 대상까지의 터널을 만들기도 합니다. SOCKS5는 대상 주소, 포트, 연결 요청을 지정하는 보다 범용적인 프록시 세션 협상 방식을 제공합니다. 둘 다 프록시 연결 지점에서 사용하는 프로토콜 규약일 뿐, 기본적으로 같은 암호화 보호, 인증 방식, UDP 기능을 제공한다는 뜻은 아닙니다. 서버에 HTTP라고 명시되어 있다면 주소가 같다는 이유만으로 SOCKS5를 선택할 수 없습니다.

여기서는 대상 웹사이트가 HTTPS를 사용하는 것과 클라이언트에서 프록시 연결 지점까지 TLS를 사용하는 것을 구분해야 합니다. HTTPS 웹사이트의 콘텐츠는 보통 대상 웹사이트까지 보호되지만, TLS를 사용하지 않는 HTTP 프록시와 클라이언트 사이의 연결은 프록시 협상 정보와 일부 인증 정보의 보호 범위가 암호화된 프록시 연결과 다릅니다. 대상 웹사이트가 보안 연결을 사용한다고 해서 외부 프록시 경로의 모든 구간도 같은 방식으로 보호되는 것은 아닙니다. 보호 범위는 브라우저 주소창이나 서버 별칭의 단어 하나만 보지 말고 연결 구간별로 확인하세요.

주소, 포트 및 인증 방식

HTTP와 SOCKS5의 기본 정보에는 보통 서버 주소와 포트, 필요할 경우 Username 및 Password가 포함됩니다. 인증이 필요한지는 서버가 결정합니다. 정보를 비워 두면 연결될 것이라고 가정하거나 다른 프로토콜의 UUID를 사용자 이름으로 입력해 호환될 것으로 기대하지 마세요. 인증 실패와 네트워크 연결 불가 현상은 비슷할 수 있으므로 연결 오류와 보유한 정보를 함께 확인해야 합니다. 직접 입력할 때 계정에 도메인이나 다른 접두사가 포함되어 있다면 서버에서 제공한 전체 형식을 그대로 사용하세요.

프록시 연결 지점에서 TLS를 요구한다면 해당 보안 설정을 선택하고 인증서 이름을 확인하세요. 포트 번호만으로 연결 지점이 평문인지 암호화되었는지, CONNECT를 지원하는지 판단할 수 없습니다. 일부 서버는 접근 가능한 대상, 대상 포트, 인증 방식을 제한합니다. 프록시 연결 지점에 접속했더라도 이후 요청은 거부될 수 있습니다. 특정 대상 포트에 연결되지 않으면 접근 권한과 서버 정책을 확인하세요. 로컬 DNS를 반복해서 변경하거나 모든 HTTP 프록시가 웹페이지에만 접근할 수 있다고 오해하지 마세요.

도메인 조회 및 UDP 사용 조건

SOCKS5는 대상 주소를 도메인 이름으로 전달할 수 있지만, 실제 요청에서 도메인 조회를 프록시 측에 맡기는지는 클라이언트 처리 방식, DNS 정책, 대상 정보가 이미 IP로 변환되었는지에 따라 달라집니다. SOCKS5를 선택했다고 모든 DNS 요청이 원격에서 처리된다고 볼 수는 없습니다. HTTP 프록시도 요청에서 대상 호스트 이름을 받을 수 있지만 앱에서 발생하는 다른 DNS 조회는 별도로 확인해야 합니다. 도메인 문제를 해결하려면 서버 유형만 확인하지 말고 실제 연결 대상과 DNS 결과를 살펴보세요.

SOCKS5 규격에 UDP ASSOCIATE가 포함되어 있다고 해서 모든 서버, 네트워크, 클라이언트 조합이 UDP 전달을 지원하는 것은 아닙니다. 협상 과정에는 제어 연결과 전달 주소가 포함될 수 있으며 네트워크가 그 일부를 제한할 수 있습니다. TCP 서비스는 정상인데 UDP 서비스만 실패한다면 서버에서 기능을 활성화했는지, 반환된 주소에 접근 가능한지, 같은 기록을 선택하는 규칙이 적용되는지 각각 확인하세요. 웹페이지 테스트 결과만으로 음성 통화, 게임, 그 밖의 UDP 서비스를 판단해서는 안 됩니다.

사용 환경 및 모바일 기기에서의 확인

이 두 유형의 연결 지점은 조직에서 제공하는 프록시, 권한이 있는 네트워크 접속, 범용 프록시 프로토콜을 명시적으로 제공하는 환경에서 흔히 사용됩니다. 매개변수가 적다고 장기간 사용하기에 더 적합하다고 여기지 말고 관리 주체가 안내한 유형과 보안 요구 사항에 따라 설정하세요. iPhone과 iPad에서도 연결 안정성은 네트워크 전환, 인증 유효 기간, 서버 제한의 영향을 받습니다. 프록시에서 인증 실패가 반복되면 자격 증명 상태와 접근 권한 범위를 먼저 확인하세요. 계속 다시 연결하는 것으로 확인 절차를 대신하지 마세요.

업무에 지속적인 저지연 연결이나 UDP가 필요하다면 연결 지점이 해당 기능을 실제로 제공하는지 먼저 확인하세요. 권한이 부여된 특정 리소스에 접근하는 것이 목적이라면 대상 라우팅과 인증 범위를 더 주의 깊게 살펴봐야 합니다. 프로토콜 선택은 기존 연결 조건에 맞추는 것이지 서버에 없는 기능을 만들어 내는 방법이 아닙니다. 기록을 저장할 때 별칭에 용도와 네트워크 조건을 적을 수 있지만 비밀번호는 포함하지 마세요. 여러 연결 지점 사이에서 용도를 구분하면서 목록 스크린샷에 인증 정보가 노출되는 일을 막을 수 있습니다.

07 / HYSTERIA2

Hysteria2: QUIC 기반 전송은 UDP 사용 가능 여부부터 확인해야 합니다

설계 목적 및 네트워크 전제 조건

Hysteria2는 QUIC 기반으로 프록시 전송을 구성하며 복잡한 네트워크 환경에서의 데이터 전달과 혼잡 처리를 고려합니다. QUIC은 UDP 위에서 동작하고 TLS를 사용해 보안 핸드셰이크를 수행합니다. 하나의 연결에서 여러 데이터 스트림을 구성할 수 있으며, 각 스트림의 처리는 단일 TCP 바이트 스트림과 다릅니다. 하지만 연결을 공유하므로 전체 대역폭, 혼잡, 서버 리소스의 제한을 받습니다. 여러 스트림을 지원한다고 특정 요청이 다른 트래픽의 영향을 전혀 받지 않는 것은 아니며, 프로토콜 이름만으로 실제 처리량을 예측할 수도 없습니다.

사용 전에 가장 먼저 확인할 조건은 UDP 경로가 작동하는지입니다. 일부 네트워크에서는 웹페이지가 정상적으로 열리더라도 UDP 연결 지점이 제한되거나 다르게 처리될 수 있습니다. 따라서 TCP 기반 기록이 정상이라고 Hysteria2 연결 지점도 정상이어야 하는 것은 아닙니다. 실패하면 도메인 조회, 포트, UDP 연결 가능 여부를 확인한 뒤 인증과 TLS를 살펴보세요. 하위 네트워크 경로가 작동하지 않는다면 대역폭 값을 바꾸거나 연결 유지를 추가해도 누락된 조건을 보완할 수 없습니다.

인증, TLS 및 난독화 설정

기존 Hysteria2 정보에는 보통 서버 주소, 포트, 인증 정보, TLS 관련 설정이 포함됩니다. 인증 필드는 서버 요구 사항에 맞춰 빠짐없이 입력하세요. 다른 프로토콜의 비밀번호를 그대로 사용하지 마세요. TLS 이름과 인증서 확인 원칙은 앞서 설명한 내용과 같습니다. 연결 대상, Server Name, 인증서에 포함된 이름이 올바르게 맞아야 합니다. 하위 전송이 UDP를 사용하더라도 인증서 시간, 이름, 신뢰 체인은 여전히 중요합니다. 핸드셰이크 실패를 모두 UDP 제한 탓으로 돌리지 마세요.

서버에서 난독화를 활성화했다면 클라이언트에도 해당 유형과 비밀번호 같은 설정이 필요합니다. 난독화, 인증, TLS는 서로 다른 계층에서 각기 다른 역할을 하므로 하나가 맞다고 나머지를 무시해서는 안 됩니다. 난독화를 사용하지 않는 연결 지점에 알 수 없는 설정을 추가하지 마세요. 가져온 기록은 정상 작동하지만 직접 다시 만든 기록이 실패한다면 필드를 하나씩 비교하세요. 특히 간략한 안내에서 빠지기 쉬운 선택 설정을 확인해야 합니다.

대역폭 필드는 속도 측정 결과가 아닙니다

일부 설정에는 업로드 및 다운로드 대역폭 필드가 있으며 특정 혼잡 제어 방식의 동작에 영향을 줄 수 있습니다. 필드에 입력한 값은 클라이언트가 실시간으로 측정한 속도도, 서버가 지속적으로 제공한다고 보장한 처리량도 아닙니다. 서버 정책과 협상 방식에 따라 값이 적용되지 않을 수도 있습니다. 값을 크게 입력한다고 실제 대역폭이 늘어나지는 않습니다. 입력할 때 앱에서 사용하는 단위를 확인하고 초당 바이트와 초당 비트를 혼동하거나 다운로드 용량을 업로드 항목에 입력하지 마세요.

설정값이 실제 접속 성능보다 지나치게 높으면 해당 모드에서 대기열, 패킷 손실, 불안정한 연결이 생길 수 있습니다. 너무 낮으면 이용 가능한 전송 성능을 제한할 수도 있습니다. 실제 네트워크 조건과 서버 안내를 기준으로 설정하고 원래 값을 기준값으로 보관하세요. 테스트할 때는 다운로드 지속성, 대화형 요청의 대기 시간, 다른 앱의 대기열 영향을 함께 살펴보세요. 짧은 순간 속도가 높게 나온 것만으로 설정이 적절하다고 볼 수 없으며, 안정성을 충분히 관찰하는 과정을 대신할 수도 없습니다.

iPhone 및 iPad에서 리소스 사용량 확인

QUIC 프로토콜 처리와 암호화, 데이터 송수신은 모두 기기 리소스를 사용합니다. 배터리 소모는 구현 방식, 트래픽, 패킷 손실, 무선 신호 강도에 따라 달라지므로 모든 기기에 적용되는 고정된 결론은 없습니다. 대용량 트래픽을 테스트하면 앱 처리와 무선 전송이 동시에 활발해집니다. 기기가 뜨거워졌다는 사실만으로 설정 오류를 입증할 수는 없습니다. 같은 양의 데이터를 처리할 때의 지속적인 동작, 백그라운드 재연결 반복 여부, 신호가 약하거나 화면 잠금 해제 후 복구할 때의 이상 여부를 확인하는 편이 더 유용합니다.

특정 Wi-Fi 네트워크에서만 실패한다면 사용 권한이 있는 다른 네트워크에서 경로 차이를 확인하세요. 모든 네트워크에서 실패하면 원래 인증 정보, TLS, 서버 상태를 점검합니다. 연결은 되지만 대용량 전송이 멈춘다면 다른 프로토콜로 바로 바꾸지 말고 경로의 패킷 손실, 패킷 크기, 대역폭 설정, 원격 리소스를 확인하세요. 서버가 새 프로토콜을 실제로 제공해야 전환이 의미가 있습니다. 단순히 “작동하지 않음”이라고 기록하는 것보다 실패 단계와 짧은 오류 메시지를 남겨두는 편이 원인 파악에 도움이 됩니다.

테스트가 끝나면 반복 속도 측정과 불필요한 지속 전송을 중단하고 일상 설정으로 되돌린 뒤 배터리 상태를 살펴보세요. 구독을 업데이트한 뒤에만 문제가 발생한다면 먼저 기록의 설정이 어떻게 달라졌는지 비교해 서버 변경과 로컬 네트워크 변화를 구분하세요. 기존 구독에서 가져온 설정은 이후 업데이트에서 수동 수정이 덮어써질 수도 있습니다. 테스트 복사본과 구독 기록의 관계를 명확히 관리해 같은 문제가 업데이트 후 반복되지 않도록 하세요.