Shadowrocket
프로토콜 유형 및 설정값 확인

01 · 선택 전에 네 가지 정보 계층 구분하기

프로토콜 이름은 여러 질문 중 하나에만 답합니다

Shadowrocket의 서버 항목에는 프로토콜 외에도 여러 설정이 포함됩니다. 주소와 포트는 연결 대상 위치를 정하고, Shadowsocks, VMess, VLESS 등의 유형은 양측이 프록시 요청을 주고받는 방식을 정합니다. TCP, WebSocket 등의 전송 방식은 데이터를 전달하는 방법이며, TLS는 암호화와 인증서 검증에 관련됩니다. 규칙과 정책은 별도의 계층으로, 특정 요청을 이 항목으로 보낼지 결정합니다. 네 계층 모두 결과에 영향을 줄 수 있지만 서로 대체할 수는 없습니다.

따라서 주소가 같다고 유형을 임의로 바꿀 수 있는 것은 아닙니다. 포트와 비밀번호가 비슷해 보여도 VLESS를 Trojan으로 바꾸면 서버가 새 요청 형식을 자동으로 이해하지 않습니다. 서버가 해당 연결 지점을 실제로 제공해야 하며, 인증 항목과 전송 방식, 보안 설정도 일치해야 합니다. 여기서 ‘프로토콜 선택’은 이미 보유한 정보에서 서버가 지원한다고 명시된 항목을 고르는 것이지, 한 항목의 유형 이름을 다른 이름으로 바꾸는 것이 아닙니다.

기존 정보에 따라 확인 순서 정하기

기존 구독을 가져온 뒤 Home에서 항목을 확인하고 편집 화면에서 유형과 서버 주소를 살펴보세요. 직접 추가해야 한다면 Add Server에서 서버 안내와 일치하는 유형을 선택합니다. 유형마다 표시되는 항목이 다르며, 항목의 표시 여부와 선택값, 위치는 현재 앱 화면을 기준으로 확인하세요. 안내문에 특정 항목이 언급됐다는 이유만으로 이름이 비슷한 다른 입력란에 값을 넣지 마세요.

주소와 포트, 인증 정보, 전송 방식, 보안 설정, 마지막으로 규칙 순서로 확인하는 것이 좋습니다. 이 순서는 문제 발생 계층과도 맞닿아 있습니다. 주소가 틀리면 대상에 연결되지 않고, 인증 정보가 틀리면 인증에 실패하며, 전송 방식이 일치하지 않으면 요청을 올바르게 해석할 수 없습니다. 인증서 검증이 실패하면 보안 연결이 성립하지 않습니다. 이런 문제는 규칙을 먼저 바꿔도 해결되지 않으며, 오히려 테스트 대상이 불분명해질 수 있습니다.

클라이언트, 서비스, App Store 정보 각각 확인

Shadowrocket은 상용 앱입니다. 이 페이지에서는 주로 iPhone과 iPad를 다룹니다. iPhone과 iPad는 App Store에서 한 번 구매하고, Mac, Windows, Android, Linux는 무료입니다. 클라이언트는 한 번 구매하면 사용할 수 있지만, 이는 회선 요금제가 아닙니다. 구매 대상은 클라이언트 사용 권한이며, 연결하려면 사용자가 기존 구독 또는 서버 정보를 보유해야 합니다. 이 사이트는 노드나 구독을 제공하거나 판매하거나 추천하지 않습니다. 기존 구독의 유효 여부와 서버가 지원하는 프로토콜은 해당 구독의 안내에서 확인하세요. 클라이언트에 표시되는 유형만으로 이를 판단할 수는 없습니다.

iPhone과 iPad는 App Store에서 구매하고, 나머지 플랫폼은 무료입니다. 구매하거나 제품 정보를 확인하려면 정품 다운로드 및 확인 안내를 참고하여 개발자 Shadow Launch Technology Limited, 공식 아이콘, 앱 ID 932747118을 확인하세요. 시스템 요구 사항과 구매 가능 여부는 App Store 페이지의 표시를 기준으로 합니다. 연결 실패와 구매 상태는 서로 다른 문제입니다. 앱이 정상적으로 실행되더라도 서버 정보가 유효하다는 뜻은 아닙니다.

02 · Shadowsocks: 암호화 방식과 인증 정보 맞추기

경량 프록시의 설계 목적을 바탕으로 설정 이해하기

Shadowsocks는 비교적 간결한 프로토콜로 프록시 트래픽을 전달하고, 클라이언트와 서버가 합의한 암호화 방식과 비밀번호로 데이터를 주고받도록 설계되었습니다. 기기 전체를 원격 로컬 네트워크에 직접 연결하는 방식도 아니며, 웹 요청이 반드시 프록시를 거치도록 정하는 것도 아닙니다. Shadowrocket은 현재 Global Routing 상태와 설정 규칙에 따라 요청의 경로를 결정합니다. 프로토콜은 그 경로로 전달된 트래픽을 처리합니다.

따라서 우선 확인할 핵심 항목은 서버 주소, 포트, 암호화 방식, 비밀번호입니다. 설정이 간결하다고 값을 추측해도 되는 것은 아닙니다. 비밀번호가 맞다는 이유만으로 인증 설정이 모두 올바르다고 단정할 수 없습니다. 암호화 방식은 양측이 데이터를 해석하는 규칙입니다. 잘못 선택하면 서버가 연결을 받더라도 내용을 해석하지 못해 비밀번호 오류와 비슷한 증상이 나타날 수 있으며, 재연결만으로 해결되는 경우는 드뭅니다.

Method와 Password를 함께 확인해야 하는 이유

현재는 인증 기능을 포함하고 데이터 변조 여부도 확인하는 암호화 방식이 널리 쓰입니다. 방식마다 키 길이와 파생 방법, 데이터 형식이 다릅니다. 서버에서 제공한 전체 방식을 그대로 입력하고, 이름 일부가 비슷하다고 같은 방식으로 취급하지 마세요. 한 항목의 비밀번호를 다른 항목에 복사해도 서로 바꿔 쓸 수 있다고 가정해서는 안 됩니다. 프로토콜 변형에 따라 인증 정보 형식이 다를 수 있습니다.

최신 Shadowsocks 변형 중에는 임의의 문장형 비밀번호가 아니라 특정 인코딩과 길이를 갖춘 키를 사용하는 경우가 있습니다. 이때 Password 입력란의 문자열은 일반 텍스트처럼 보여도 정해진 형식의 키 자료입니다. 임의로 줄이거나 보충하거나 다시 인코딩하지 마세요. 가져오기는 성공했지만 직접 입력한 항목이 실패한다면 복사 과정에서 마지막 문자가 누락됐는지, 줄바꿈이 포함됐는지, 링크에서 인코딩된 텍스트를 원래 인증 정보로 착각했는지 먼저 확인하세요.

이름만으로 UDP 및 추가 전송 방식을 추측하지 마세요

일부 앱 트래픽은 UDP를 사용합니다. TCP 웹페이지가 열린다고 해서 해당 항목의 경로를 사용할 수 있다는 점만 확인된 것이며, UDP도 작동한다는 뜻은 아닙니다. 서버 측에서 해당 전달을 허용하는지, 현재 네트워크에서 데이터를 전송할 수 있는지, 클라이언트 항목의 관련 설정이 기존 안내와 맞는지도 확인해야 합니다. UDP 문제를 ‘프로토콜 전체가 불안정하다’고 판단하면 서버 제한이나 네트워크 경로의 차이를 놓칠 수 있습니다.

기존 항목에 추가 전송 설정이 포함된 경우에는 각 설정의 용도를 하나씩 확인하세요. Shadowsocks라는 이유만으로 추가 설정이 없다고 단정하지 마세요. 추가 계층은 핵심 프로토콜과 별도로 확인해야 합니다. 비밀번호가 맞아도 추가 계층 설정이 틀리면 실패할 수 있으며, 낯선 설정을 삭제하면 원래 올바르던 연결 지점이 손상될 수 있습니다. 구독에서 가져온 원본 항목을 기준으로 삼는 편이 임의로 설정을 줄이는 것보다 재현하기 쉽습니다.

iPhone에서 적합성을 판단하는 방법

조건이 같다면 캡슐화 계층이 적은 쪽이 처리 부담을 일부 줄일 수 있지만, 속도나 배터리 사용량을 보장하지는 않습니다. 실제 체감에는 암호화 구현, 기기 성능, 서버 부하, 패킷 손실, 왕복 지연 시간 등이 영향을 줍니다. 짧은 웹페이지 테스트는 주로 연결 수립과 소량 데이터 전송을 반영하고, 파일을 계속 전송하는 테스트는 처리량을 보여 줍니다. 두 테스트에서 체감이 다를 수 있으므로 각각 기록하세요.

기존 Shadowsocks 항목으로 일상적인 요청을 안정적으로 처리하고 있다면, 다른 프로토콜 이름이 더 최신이라는 이유만으로 바꿀 필요는 없습니다. 연결은 되지만 특정 앱만 실패한다면 도메인 확인, TCP 및 UDP 경로를 구분하고 해당 앱의 규칙이 다른 정책을 적용하는지 살펴보세요. 모든 요청이 실패하면 전력 관련 설정을 조정하기 전에 주소, 포트, 암호화 방식, 비밀번호부터 확인하세요.

03 · VMess와 VLESS: 인증, 전송, TLS

비슷한 항목이 있어도 프로토콜이 같은 것은 아닙니다

VMess는 인증과 프로토콜 자체의 데이터 보호 방식을 결합하며, 대표적인 인증 항목으로 UUID를 사용합니다. VLESS는 인증과 요청 정보를 더 간결하게 구성하고, 연결 보호를 외부 보안 계층에 더 많이 맡깁니다. 두 프로토콜 모두 여러 전송 방식과 조합될 수 있어 편집 화면에 비슷한 항목이 보일 수 있지만, 유형만 바꿔 서로 변환할 수 있는 형식은 아닙니다. 서버에서 실제로 제공하는 연결 방식에 맞춰 사용해야 합니다.

이러한 설계 차이를 이해하면 ‘항목이 적다’는 사실을 ‘더 안전하다’ 또는 ‘더 빠르다’고 오해하지 않을 수 있습니다. VLESS 자체에는 VMess와 같은 데이터 암호화 기능이 없으므로 배포 환경에서 연결을 보호하는 외부 계층을 확인해야 합니다. VMess에 자체 보안 기능이 있다고 해서 외부 전송 설정을 무시해도 되는 것은 아닙니다. 항목을 평가할 때는 이름만 볼 것이 아니라 프로토콜, 전송, 보안 설정을 하나의 조합으로 살펴보세요.

UUID는 인증 정보이지 표시 이름이 아닙니다

UUID는 원래 값을 한 글자도 바꾸지 않고 사용해야 합니다. 항목 이름은 지역이나 용도를 구분하는 데 쓰이며, 이름을 바꿔도 보통 인증에는 영향이 없습니다. 반면 UUID는 인증에 직접 사용되므로 임의로 바꾸면 서버가 식별하지 못합니다. 복사할 때 하이픈, 앞뒤 공백, 자동 줄바꿈을 확인하세요. 여러 항목이 같은 UUID를 사용한다고 해서 주소, 포트, 다른 설정까지 같다는 뜻은 아니므로 항목별로 모두 확인해야 합니다.

VMess 인증에는 시간 정보도 관련됩니다. 기기 시간이 크게 어긋나면 설정값이 맞아 보여도 인증에 실패할 수 있습니다. UUID를 반복해서 바꾸기보다 먼저 시스템 설정에서 날짜와 시간이 올바른지 확인한 다음 서버 인증 정보를 살펴보세요. 기존 정보에 다른 호환 항목이 포함되어 있다면 서버 안내에 따라 입력하고, 서로 다른 시기의 예제에서 값을 섞어 쓰지 마세요.

WebSocket의 Host·Path와 TLS의 SNI

WebSocket은 해당 연결 위에 프록시 데이터를 전달하며, 일반적으로 Host와 Path를 확인해야 합니다. Path는 서버 라우팅 설정과 일치해야 하므로 첫 슬래시, 대소문자, 끝부분 경로도 중요할 수 있습니다. Host는 관련 요청의 호스트 정보를 나타내며, 서버는 이를 바탕으로 요청을 서로 다른 연결 지점으로 전달할 수 있습니다. 두 값이 틀리면 대상 포트와 연결되더라도 이후 프로토콜 교환이 실패할 수 있습니다.

SNI는 TLS 핸드셰이크에서 사용하는 서버 이름 정보이며, 인증서 검증에서는 예상한 이름과 인증서가 일치하는지 확인합니다. 서버 연결 주소, WebSocket Host, SNI는 일부 환경에서 같지만 서로 다른 환경도 있으므로 세 입력란에 같은 값을 무조건 넣어서는 안 됩니다. IP 주소로 기본 연결을 설정하더라도 안전한 연결을 완료하려면 서버 안내에 나온 도메인이 필요할 수 있습니다.

전체 연결 설정을 기준으로 선택하기

일부 VLESS 조합에는 Flow 또는 특정 보안 설정이 추가로 필요합니다. 서버가 명시적으로 요구하고 현재 클라이언트에도 해당 옵션이 있을 때만 입력하세요. 다른 항목이 정상 작동한다는 이유로 그 값을 모든 VLESS 항목에 복사하지 마세요. 조합마다 제약이 다르며, 빈칸이 올바른 상태일 수도 있습니다. 판단 기준은 항상 현재 서버 연결 지점의 설정 정보입니다.

iOS에서 두 프로토콜을 비교할 때는 먼저 전송과 보안 계층의 차이를 통제하세요. 직접 TCP를 사용하는 항목과 여러 계층으로 캡슐화된 항목을 비교한 결과를 VMess 또는 VLESS만의 차이라고 볼 수는 없습니다. 원본 구독 항목은 작동하지만 직접 만든 항목이 실패한다면 UUID, 전송, Host, Path, TLS, SNI를 하나씩 대조하세요. 모든 설정 조합이 일치해야 처리 부담을 비교하는 의미가 있습니다.

04 · Trojan, HTTP, SOCKS5: 보안 경계

Trojan에서 중요한 TLS

Trojan은 일반적으로 TLS 연결 안에서 프록시 요청을 전달하고 비밀번호 등의 정보로 사용자를 인증하도록 설계됩니다. 검증된 보안 전송 방식을 활용하지만 클라이언트에는 올바른 서버 주소, 포트, 비밀번호, 검증 이름이 필요합니다. 포트에 연결된다는 것은 기본 경로가 있다는 뜻일 뿐입니다. 비밀번호가 맞아도 인증서 이름이 일치하지 않는 문제를 해결할 수는 없습니다. 문제를 해결할 때 핸드셰이크 실패와 인증 실패를 별개로 다루세요.

도메인, SNI, 인증서의 관계가 특히 중요합니다. 인증서에는 예상한 서비스 이름이 포함되어야 하며 유효하고 신뢰할 수 있는 상태여야 합니다. 연결 주소와 검증 이름이 다른 연결 지점이라면 서버 정보에 따라 각각 입력하세요. 인증서 오류가 발생하면 검증을 끄는 방법을 일반적인 해결책으로 사용하지 말고 기기 시간, 이름, 서버 인증서 체인을 먼저 확인하세요. 검증을 끄면 연결 대상의 신원을 확인하는 기능이 약해집니다.

HTTP 프록시를 사용한다고 모든 트래픽이 보호되는 것은 아닙니다

HTTP 프록시는 애플리케이션 계층의 프록시 요구에 따라 요청을 전달하고, CONNECT를 통해 대상과 바이트 통신 채널을 만들기도 합니다. 일반적인 항목에는 주소, 포트, 사용자 이름, 비밀번호가 포함됩니다. 기기와 프록시 서버 사이의 연결, 앱과 대상 사이트 사이의 연결을 구분해야 합니다. 대상 사이트에서 HTTPS를 사용하더라도 기기와 프록시 사이의 인증 정보가 같은 방식으로 보호된다는 뜻은 아닙니다. 외부 연결의 TLS 사용 여부는 별도로 확인하세요.

따라서 기존 안내에 HTTP라고 적혀 있다면 TLS가 적용된 프록시 연결이라고 임의로 가정하지 마세요. 보안 전송이 필요하다고 안내된 경우 일반 프록시 항목만 입력해서도 안 됩니다. 양측이 지원하는 방식이 다르면 핸드셰이크가 일치하지 않을 수 있습니다. 사용자 이름과 비밀번호의 정확성, 프록시의 CONNECT 허용 여부, 대상 포트 제한도 일부 사이트만 작동하는 원인이 될 수 있습니다.

SOCKS5는 범용 협상을 제공하지만 자체 암호화 기능은 없습니다

SOCKS5는 협상을 통해 대상 주소와 연결 요구 사항을 지정하며, 사용자 이름과 비밀번호 인증 및 UDP 관련 기능도 정의합니다. 하지만 전달되는 모든 내용을 자체적으로 암호화하지는 않습니다. 인증과 데이터 기밀성은 서로 다른 기능입니다. 비밀번호를 요구한다고 해서 연결이 암호화됐다고 판단하지 마세요. 실제 보안 경계는 네트워크 환경, 외부 보안 계층, 앱 자체 연결 보호 기능에도 달려 있습니다.

SOCKS5 항목으로 연결할 수 있어도 UDP가 작동한다고 단정할 수 없습니다. 서버가 TCP만 허용할 수 있고, 네트워크가 UDP 연결에 필요한 데이터를 전달하지 못할 수도 있습니다. 도메인이 어디에서 확인되는지도 따로 살펴봐야 합니다. 앱, 클라이언트 설정, 프록시 요청 방식이 실제 경로에 함께 영향을 줍니다. 도메인 연결은 실패하지만 직접 주소 테스트 결과가 다르다면 프록시 비밀번호만 반복해서 바꾸지 말고 DNS와 규칙을 확인하세요.

이름으로 보안 순위를 매기지 말고 기존 환경에 맞춰 선택하기

기존 환경에서 특정 프록시 연결 방식만 제공한다면 먼저 전송 보호와 접근 권한을 확인하고 용도에 맞는지 판단하세요. 클라이언트의 유형 옵션만으로 서버에 TLS 기능을 추가할 수는 없습니다. 인증 실패를 해결하기 위해 HTTP를 SOCKS5로 바꿔서도 안 됩니다. 조직에서 관리하는 연결 지점이라면 접근 범위와 기기 사용 규칙을 따르세요. 용도가 제한된 프록시를 범용 통로로 오해하지 않아야 합니다.

iPhone에서는 이들 유형의 속도 차이가 네트워크 경로에 가려지는 경우가 많습니다. 핸드셰이크 횟수, 연결 재사용, 서버 응답, 무선 네트워크 상태가 프로토콜 해석 부담보다 더 큰 영향을 줄 수 있습니다. 동일한 작업과 비슷한 환경에서 비교하고 각 항목의 보안 설정이 올바른지 먼저 확인하세요. 인증서 검증을 끈 경우에만 작동하는 항목은 성능이 더 좋은 것이 아니라 서버 정보를 수정해야 하는 상태입니다.

05 · WireGuard: 키, 주소, 터널 범위

네트워크 계층 터널로서의 차이 이해하기

WireGuard는 비교적 간결한 프로토콜과 고정된 최신 암호화 조합으로 네트워크 계층 터널을 만드는 것을 목표로 합니다. 프록시 요청에서 대상을 지정하는 프로토콜과 달리 터널 안의 IP 패킷을 처리합니다. 이 차이는 설정 항목에도 드러납니다. 원격 주소뿐 아니라 로컬 터널 주소, 양측 키, 상대편을 통해 전달할 주소 범위도 이해해야 합니다. 일반 프록시의 비밀번호 입력 방식을 그대로 적용할 수 없습니다.

Shadowrocket에서 WireGuard를 사용할 때도 항목 자체의 터널 설정과 클라이언트의 규칙 결정을 구분해야 합니다. 항목은 상대편과 통신하는 방식을 정하고, Global Routing 및 설정은 어떤 요청을 해당 항목으로 보낼지 정합니다. 터널 내부 주소가 표시된다고 기기의 모든 요청이 예상대로 터널을 통과하는 것은 아닙니다. 클라이언트 연결 스위치가 켜져 있다고 원격 서버에서 필요한 대상에 접근하도록 허용했다는 뜻도 아닙니다.

Private Key, Public Key, Endpoint

Private Key는 로컬 인증 정보이므로 안전하게 보관해야 합니다. 상대편의 Public Key는 원격 대상을 식별하는 데 사용됩니다. 두 값은 같은 문자열의 다른 표시 이름이 아니며 서로 바꿔 쓸 수 없습니다. 기존 설정에 Preshared Key가 있다면 이는 양측에 동일하게 설정해야 하는 추가 공유 키입니다. 문제를 확인할 때는 항목의 존재 여부와 일치 여부만 기록하고 전체 키를 공개 스크린샷, 로그 설명, 문의 글에 복사하지 마세요.

Endpoint는 연결 가능한 원격 주소와 포트를 가리키며 터널 내부 주소와는 다릅니다. 설정의 로컬 주소는 터널 내부 통신에 쓰이므로 임의의 사설 주소를 선택해도 되는 것은 아닙니다. 서버는 해당 클라이언트와 주소의 관계를 인식해야 하며, 맞지 않는 주소나 인증 정보를 재사용하면 충돌이 생길 수 있습니다. 새 기기에서 같은 정보를 사용할 수 있는지는 기존 서버의 설정 규칙에 따라 확인하세요.

Allowed IPs와 라우팅은 같은 표가 아닙니다

Allowed IPs는 상대편에서 전달할 수 있는 주소 범위와 관련되며, 터널 내부의 경로 선택 및 출발지 제한을 이해하는 데도 관여합니다. 이는 Shadowrocket의 DOMAIN-SUFFIX 같은 규칙과 다른 계층입니다. 외부 규칙이 특정 요청을 WireGuard로 보내더라도 터널이나 원격 서버에서 해당 주소 범위를 허용하지 않으면 트래픽이 실패할 수 있습니다. 반대로 터널에서 특정 범위를 허용해도 클라이언트가 관련 요청을 모두 해당 터널로 보내는 것은 아닙니다.

기존 내부 리소스에 접근해야 한다면 원격 전달, 대상의 응답 경로, 이름 확인도 살펴봐야 합니다. 터널 핸드셰이크가 성공해도 대상 기기가 데이터를 돌려보낼 경로를 모르면 요청 시간이 초과될 수 있습니다. 도메인만 실패하고 해당 내부 주소는 연결된다면 내부 DNS의 접근 가능 여부와 설정을 먼저 확인하세요. 모든 내부 주소에 접근할 수 없다면 주소 범위, 원격 권한, 라우팅을 확인하세요.

MTU와 Persistent Keepalive의 고려 사항

MTU는 터널 패킷 하나가 전달할 수 있는 크기를 제한합니다. 캡슐화로 데이터가 추가되고 경로에도 별도 제한이 있을 수 있어, 설정이 적절하지 않으면 작은 요청은 성공하지만 큰 전송은 멈출 수 있습니다. 지연이 보인다고 값을 계속 낮추지 말고 패킷 크기와 관련된 문제인지 먼저 확인한 뒤 원래 값을 보관하세요. 값을 조정한 다음에는 같은 대상과 전송 작업으로 다시 테스트하여 일시적인 네트워크 변동을 MTU 수정 효과로 오인하지 않도록 합니다.

Persistent Keepalive는 일부 네트워크 주소 변환 환경에서 연결 매핑을 유지하는 데 쓰이지만, 주기적인 패킷 전송은 무선 활동도 늘립니다. 간격을 짧게 할수록 안정적인 것은 아니며 모든 네트워크에 필요한 것도 아닙니다. 유휴 상태 후 응답 경로가 끊기고 기존 설정에서 조정이 허용된 경우에만 검토하세요. iPhone의 셀룰러 네트워크에서는 기기를 깨우는 데 드는 비용도 함께 살펴야 합니다. 재연결이 한 번 더 빨라졌는지만으로 판단할 수 없습니다.

06 · Hysteria2: UDP 경로와 대역폭 추정

패킷 손실이 있는 경로의 전송 특성에 초점

Hysteria2는 QUIC을 기반으로 프록시 데이터를 전송하며, QUIC은 보통 UDP 위에서 작동합니다. 패킷 손실과 긴 왕복 지연 시간이 있는 경로에서 전송 효율을 유지하는 데 중점을 둡니다. 여기서 ‘손실이 있는’ 경로란 네트워크 상태를 설명하는 것이며 모든 셀룰러 네트워크가 같은 특성을 가진다는 뜻은 아닙니다. 현재 환경에 적합한지는 프로토콜 이름으로 속도를 미리 판단하지 말고 UDP 경로가 작동하는지 확인한 뒤 실제 작업을 테스트해야 합니다.

QUIC은 보안 핸드셰이크와 전송 기능을 결합하고 하나의 연결에서 여러 스트림을 전달할 수 있습니다. 스트림 간에 단일 순서 바이트 스트림에서 발생하는 일부 대기 현상을 줄일 수 있지만, 공유 링크의 혼잡, 무선 패킷 손실, 서버 리소스 제한은 여전히 존재합니다. 실제 대역폭을 늘리거나 원격 응답을 빠르게 만들지는 않습니다. 특정 사이트가 느리다면 DNS, 규칙, 대상 사이트 자체의 문제일 수도 있습니다.

성능 설정 전에 인증과 인증서를 먼저 확인하기

기본 항목에는 서버 주소, 포트, 인증 정보, TLS 관련 설정이 포함되는 경우가 많습니다. 기존 정보의 인증값을 그대로 사용하고, 다른 프로토콜의 UUID나 비밀번호를 모양이 비슷하다는 이유로 바꾸어 넣지 마세요. SNI와 인증서 검증도 올바르게 설정해야 합니다. QUIC이 UDP를 사용한다고 서버 신원 확인을 생략해도 되는 것은 아닙니다. 인증서 오류와 UDP 연결 실패는 다른 증상일 수 있으므로 따로 기록하세요.

기존 서버에서 추가 Obfuscation 방식이나 비밀번호를 요구한다면 클라이언트와 서버의 설정이 일치해야 합니다. 이는 연결 설정에 필요한 항목이지 임의로 켜서 성능을 높이는 스위치가 아닙니다. 명확한 설정이 없으면 추가하지 말고, 기존 설정에 포함되어 있으면 함부로 삭제하지 마세요. 포트 범위나 포트 변경도 원격 서버에서 명시적으로 지원해야 합니다. 한쪽의 숫자만 바꾼다고 새 연결 지점이 만들어지지는 않습니다.

대역폭 항목은 추정값이며 속도를 보장하지 않습니다

일부 전송 모드에서는 사용자가 입력한 업로드·다운로드 대역폭 정보가 전송 제어에 반영됩니다. 클라이언트 기준 방향과 단위를 정확히 확인하세요. 큰 숫자를 입력해도 물리적인 회선 용량이 늘지는 않습니다. 실제 경로와 맞지 않는 전송 속도를 유도해 대기열, 패킷 손실, 속도 변동을 일으킬 수 있습니다. 반대로 값이 너무 작으면 회선을 충분히 활용하지 못할 수 있으므로 현재 모드를 고려해야 합니다.

사용 가능한 대역폭은 네트워크마다 다릅니다. 집의 Wi-Fi에서 얻은 결과를 셀룰러 네트워크에 그대로 적용할 수는 없습니다. 테스트를 시작하기 전에 기존 설정이 제공하는 기준값을 사용하고 업로드, 다운로드, 다른 전송 설정을 한꺼번에 바꾸지 마세요. 현재 화면이나 서버가 자동 추정 방식을 사용한다면 해당 안내를 따르세요. 다른 모드의 필수 입력 요구 사항을 그대로 적용하지 마세요. 큰 숫자를 추구하기보다 설정의 의미를 이해하는 것이 중요합니다.

UDP 경로가 제한된 상황 확인하기

해당 항목을 사용하지 않을 때는 일반 웹페이지가 열리지만 Hysteria2 연결이 계속 실패한다면 현재 네트워크의 UDP 지원 여부, 서버 포트, 원격 서버 상태를 확인해야 할 수 있습니다. 하지만 시간 초과만으로 UDP 제한이라고 단정할 수는 없습니다. 주소 확인, 인증, 보안 설정 오류도 원인일 수 있습니다. 같은 원본 항목을 다른 신뢰할 수 있는 네트워크에서 다시 테스트하면 경로 문제의 범위를 좁힐 수 있습니다.

연결은 되지만 전송 속도가 계속 변한다면 무선 신호 변화, 업로드 회선 포화, 기기 발열을 먼저 살펴보세요. 적극적인 전송 방식은 특정 경로에서 처리량을 개선할 수 있지만 재전송, 무선 활동, 배터리 소모를 늘릴 수도 있습니다. 모바일 기기에서는 작업 완료 시간과 배터리 사용량을 함께 기록하세요. 짧은 시간 동안의 최고 속도만으로 장시간 사용에 적합한지 판단할 수 없습니다.

07 · iOS에서 속도와 배터리 사용량을 나눠 확인하기

‘빠르다’를 세 가지 관찰 가능한 결과로 나누기

페이지를 처음 열 때의 대기 시간, 지속 전송의 처리량, 장시간 연결의 안정성은 서로 다른 지표입니다. 대기 시간에는 DNS 확인, 기본 연결 수립, 프로토콜 핸드셰이크, 보안 핸드셰이크, 대상의 응답이 포함됩니다. 지속 처리량은 병목 대역폭, 혼잡 제어, 서버 부하의 영향을 더 많이 받습니다. 장시간 연결은 네트워크 전환, 유휴 시간 제한, 백그라운드 상태의 영향을 받습니다. 하나의 지연 시간 숫자로 세 가지를 모두 설명할 수는 없습니다.

Connectivity Test 결과는 사용된 테스트 방식과 대상에 따라 달라집니다. 특정 연결 가능 여부나 상대적인 변화를 살펴보는 데는 적합하지만 실제 앱의 전체 경로와 같지는 않습니다. 테스트는 성공했는데 페이지가 계속 실패한다면 DNS, 규칙, 대상 요청을 추가로 확인하세요. 테스트 결과의 활용 방법은 지연 시간 테스트와 실제 로딩 체감 안내를 참고하고, 가장 낮은 숫자만으로 사용 가능 여부를 판단하지 마세요.

프로토콜 비교 시 통제할 변수

가능하면 같은 기기와 네트워크, 비슷한 시간, 같은 대상을 사용해 비교하세요. 두 항목의 원격 위치가 다르거나 회선 및 부하 차이가 크다면 결과는 프로토콜 자체보다 두 전체 경로의 차이를 반영합니다. 조건을 통제할 수 없다면 실제 사용 경험을 기록하되, 결론은 “현재 네트워크에서 이 항목이 보인 결과”로 한정하고 특정 프로토콜이 항상 더 빠르다고 일반화하지 마세요.

테스트할 때마다 변수 하나만 바꾸고 짧은 요청과 지속 작업을 따로 살펴보세요. 첫 테스트는 캐시, 핸드셰이크, 무선 상태의 영향을 받을 수 있으므로 반복 테스트 사이에 간격을 두세요. 대역폭을 계속 최대로 사용하면 기기 온도와 네트워크 혼잡이 변해 결과가 달라질 수 있습니다. 테스트 중 Wi-Fi를 전환하거나 신호가 약한 장소로 이동하거나 다른 대용량 작업을 했다면 해당 테스트는 별도 조건으로 기록하고 결과에 합쳐 비교하지 마세요.

배터리 소모는 데이터 양과 무선 활동 모두에서 발생합니다

암호화와 캡슐화에는 처리 시간이 필요하지만 모바일 기기의 배터리 사용량에는 신호 세기, 무선 통신 깨우기, 재전송, 화면, 백그라운드 작업도 영향을 줍니다. 특정 프로토콜의 처리 부담이 적다고 실제 총소모량도 낮은 것은 아닙니다. 연결에 자주 실패해 재시도하거나 연결 유지 패킷이 무선 모듈을 계속 작동시키면 프로토콜 알고리즘 자체의 차이보다 추가 비용이 커질 수 있습니다. 작업을 완료한 뒤 전체 결과를 확인하세요.

배터리 사용량을 살펴볼 때는 지속적인 영상 재생, 능동 전송, 유휴 상태 유지 상황을 구분하세요. 지속 작업은 같은 작업을 완료하는 데 필요한 시간과 배터리 변화를 비교할 수 있습니다. 유휴 상태에서는 불필요한 정기 테스트, 연결 유지, 재연결이 있는지 살펴보세요. 시스템의 배터리 통계는 일정 시간 동안의 활동을 보여 주는 참고 자료이지 엄밀한 프로토콜 전력 측정이 아닙니다. 짧은 시간 동안 배터리 비율이 그대로여도 추가 소모가 없다는 뜻은 아닙니다.

On Demand와 연결 재사용의 한계

On Demand는 네트워크 조건에 따라 연결을 시작하도록 제어하지만 잘못된 설정값을 서버 프로토콜에 맞춰 자동으로 조정하지는 않습니다. 먼저 수동 연결에서 안정적인 기준 상태를 만든 다음 트리거 조건을 추가해야 프로토콜 연결 실패와 자동 트리거 미작동을 구분할 수 있습니다. 조건을 설정할 때는 On Demand 네트워크 조건 안내를 참고하고 테스트 중 네트워크 변화와 연결 상태를 함께 기록하세요.

연결 재사용은 반복적인 핸드셰이크를 줄일 수 있지만 여러 요청이 한 연결의 혼잡이나 오류 상태를 공유하게 할 수도 있습니다. 사용 여부는 기존 서버의 지원 범위와 현재 화면의 안내에 따라야 합니다. 일부 요청이 멈췄을 때 ‘재사용은 보통 더 빠르다’는 이유만으로 영향을 배제하지 마세요. 원본 항목을 보관하고 동일한 작업에서 변수 하나만 바꿔 비교한 뒤 같은 변화가 반복되는지 확인하세요.

08 · 용도에 따라 선택하고 계층별로 문제 해결하기

용도에 맞는 기존 항목 선택하기

일상적인 웹 탐색에는 짧은 요청의 안정성, 정상적인 이름 확인, 완전한 보안 설정이 중요합니다. 이미 작동하는 항목부터 사용해도 좋습니다. 지속 전송은 첫 테스트 속도보다 안정적인 처리량과 기기 온도를 살펴야 합니다. 기존 내부 네트워크에 접근할 때는 WireGuard의 주소 범위와 응답 경로가 핵심일 수 있습니다. 패킷 손실이 있는 경로에서는 기존 Hysteria2 항목을 검토할 수 있지만 UDP가 작동해야 합니다. 이는 확인 방향이지 프로토콜의 우열을 매기는 기준이 아닙니다.

기존 정보에서 한 가지 프로토콜만 제공한다면 다른 연결 지점을 찾아 비교하기보다 해당 프로토콜을 올바르게 설정하세요. 완전한 항목이 여러 개 제공된다면 각각의 원본 설정을 보관하고 실제 용도에 따라 테스트하세요. 한 항목의 TLS, 다른 항목의 Path, 세 번째 항목의 인증 정보를 합치지 마세요. 서로 다른 설정을 섞어 생긴 실패로는 어떤 프로토콜이 적합한지 판단할 수 없습니다.

Global Routing의 테스트 모드부터 확인하기

Config 모드에서는 설정 파일의 규칙에 따라 정책이 선택됩니다. Proxy 모드는 해당 트래픽을 프록시 경로로 보내고, Direct 모드는 직접 연결 경로로 처리합니다. 모드를 바꾸면 테스트 경로도 달라지므로 매번 현재 선택을 기록해야 합니다. Proxy 모드에서도 항목과 요청 처리 기능의 한계를 벗어날 수 없으며 잘못된 인증 정보를 수정해 주지 않습니다. Direct 모드는 경로 비교에 사용할 수 있지만 모든 요청이 반드시 성공한다는 뜻은 아닙니다.

프로토콜 항목이 정상임을 확인한 다음 Config로 돌아가 규칙 순서를 살펴보세요. 아래는 매칭 방식을 설명하기 위한 .conf 예시이며 모든 환경에 적용되는 설정은 아닙니다. PROXY 정책은 실제 설정에서 올바르게 해석되어야 합니다. 규칙은 보통 순서대로 적용되며 FINAL은 앞선 규칙과 일치하지 않은 요청에 사용됩니다. 도메인 규칙과 IP 규칙은 서로 다른 정보에 의존하며 DNS 확인도 최종 매칭에 영향을 줄 수 있습니다.

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

이 예시에서는 example.com과 하위 도메인을 PROXY로 보내고, 지정된 사설 주소 범위와 GEOIP에 일치하는 주소는 DIRECT로 처리합니다. 모든 환경에서 같은 정책을 사용해야 한다는 뜻은 아니며 GEOIP 결과도 주소와 사용 데이터에 따라 달라집니다. 섹션의 역할과 설정 범위를 이해하려면 .conf 섹션별 역할 안내를 이어서 읽어 보세요. 규칙이 잘못 일치하는 문제를 프로토콜 변경으로 해결하지 마세요.

문제가 발생한 위치에 따라 범위 좁히기

연결이 전혀 되지 않으면 현재 네트워크, 주소 확인, 포트, 서버 상태를 먼저 확인하고 인증 항목을 살펴보세요. 명확한 인증서 문제가 있으면 기기 시간, SNI, 이름, 인증서 체인을 확인합니다. 연결이 성립한 뒤 실패한다면 전송 연결 지점, 대상 접근 권한, 전달 기능을 살펴보세요. 일부 도메인만 이상하다면 모든 항목을 다시 만들기보다 DNS, 규칙 매칭, 대상 상태부터 확인하세요.

웹페이지는 정상이지만 특정 실시간 앱이 실패한다면 TCP와 UDP를 각각 확인하세요. 작은 요청은 성공하지만 대용량 전송이 멈춘다면 MTU, 재전송, 혼잡을 살펴보세요. 유휴 상태 후 연결이 끊긴다면 주소 매핑 시간 초과와 연결 유지 필요성을 확인하세요. 네트워크를 전환한 뒤에만 문제가 발생하면 전환 전후의 주소와 연결 복구 상태를 기록하세요. 각 상황에서 관련 설정만 바꾸고 같은 작업으로 다시 테스트한 다음 다른 자동화 조건을 적용하세요.

인증 정보를 노출하지 않고 결과 기록하기

유용한 문제 해결 기록에는 프로토콜 유형, 전송 방식, 네트워크 조건, 실패 단계, 현재 Global Routing 모드, 반복 가능한 대상 증상이 포함됩니다. Password, UUID, Private Key, 전체 구독 주소는 공개 기록에 포함하지 마세요. 앱 로그나 스크린샷에 이런 정보가 들어갈 수 있으므로 공유 전에 하나씩 확인해야 합니다. 항목 이름만 가리는 것으로는 충분하지 않습니다. 이름은 대개 가장 민감한 정보가 아닙니다.

최종적으로 정리할 내용은 추상적인 속도 순위가 아니라 “어떤 전체 항목이 어떤 작업에 적합하고 어떤 네트워크에서 테스트에 성공했는지”입니다. 처음 설정한다면 가이드 시작으로 돌아가고, 흔한 증상은 문제 해결에서 확인하세요. 앱 구매 및 복원은 App Store 확인 안내를 참고하세요. 구매, 가져오기, 프로토콜 연결, 규칙 매칭을 나누어 살펴보면 다음 문제 해결을 이미 확인한 단계부터 시작할 수 있습니다.