Shadowrocket 프로토콜 설명
및 설정값 가이드

1. 프로토콜 선택과 연결 구조

프로토콜을 선택할 때 가장 먼저 확인할 것은 이름이 아니라 서버가 실제로 지원하는 연결 방식입니다. Shadowrocket의 프로토콜 유형은 보유한 구독 정보나 서버 정보와 일치해야 합니다. 같은 주소를 다른 유형으로 바꿔 선택해도 서버에 해당 기능이 생기지는 않습니다. 서버에서 여러 연결 방식을 제공하고 각 방식의 인증 및 전송 설정이 모두 갖춰진 경우에만 비교할 수 있습니다. 가져온 뒤에는 먼저 유형, 주소, 포트를 확인하고, 추가 설정이 필요한지 검토하세요. 속도에 대한 인상만으로 설정을 하나씩 바꾸는 것은 피해야 합니다.

한 번의 접속을 네 단계로 나눠 보기

첫 번째는 로컬 네트워크입니다. 기기가 Wi-Fi 또는 셀룰러 네트워크에 연결되고 서버에 기본적으로 접근할 수 있어야 합니다. 두 번째는 전송 및 보안 계층으로, TCP와 UDP 중 어떤 방식을 사용할지, TLS를 설정할지, WebSocket 같은 전송 방식을 더할지를 결정합니다. 세 번째는 프로토콜 인증 및 데이터 형식으로, 비밀번호·UUID·공개 키 인증 등이 여기에 해당합니다. 네 번째는 클라이언트 라우팅과 대상 접속으로, 요청을 선택한 서버로 보낼지 직접 연결할지 결정합니다. 앞 단계에서 문제가 발생했다면 뒤 단계의 설정을 바꿔도 해결되지 않는 경우가 많습니다.

따라서 ‘응답이 확인됨’과 ‘웹 페이지가 정상적으로 열림’은 같은 의미가 아닙니다. 테스트에 따라 주소 접근 가능 여부, 핸드셰이크 성공 여부 또는 지정 대상의 응답만 확인할 수 있으며, 모든 대상·DNS·UDP·앱 동작까지 검사하는 것은 아닙니다. 반대로 한 번의 테스트가 실패해도 테스트 대상 자체에 접근할 수 없는 것일 수 있습니다. 결과를 해석할 때는 테스트 방식, 현재 네트워크, 선택한 서버, 라우팅 모드를 함께 기록해 서로 다른 조건의 수치를 단순 비교하지 마세요.

속도와 배터리는 동일한 조건에서 비교해야 합니다

프로토콜 오버헤드는 속도를 결정하는 여러 요소 중 하나일 뿐입니다. 서버까지의 거리, 사용 가능한 대역폭, 혼잡, 패킷 손실, 대상 사이트의 제한, 기기의 무선 신호가 암호화 방식의 차이보다 더 큰 영향을 줄 수 있습니다. 같은 네트워크와 비슷한 시간대에 같은 대상을 대상으로 첫 접속, 지속 전송, 유휴 상태에서의 재연결을 각각 살펴봐야 핸드셰이크 비용과 안정적인 전송 속도를 구분할 수 있습니다. 짧은 테스트 한 번의 결과를 지속 속도로 간주하지 말고, 여러 작업을 동시에 실행한 경험을 특정 프로토콜 탓으로 돌리지 마세요.

iPhone과 iPad의 배터리 사용량은 무선 모듈의 작동, 백그라운드 재연결, 신호 품질, 화면 밝기, 실행 중인 작업에도 영향을 받습니다. 핸드셰이크 횟수가 적다고 반드시 배터리를 덜 쓰는 것은 아니며, 연결을 적극적으로 유지한다고 항상 더 많이 소모하는 것도 아닙니다. 실제 영향은 접속 빈도와 네트워크 전환에 따라 달라집니다. 평가할 때는 비슷한 사용 시간을 유지하고 기기 발열과 연결 중단 빈도를 기록하세요. 앱의 데이터 전송과 시스템 백그라운드 작업도 구분해야 합니다. 이 문서에서는 프로토콜 이름만으로 속도나 배터리 효율을 일률적으로 순위 매기지 않습니다.

설정을 정리할 때는 정상 작동이 확인된 기준 설정을 보관하고, 한 번에 변수 하나만 변경하면서 이유를 기록하세요. 인증 정보, 구독 주소, 개인 키는 민감한 정보이므로 공개 스크린샷이나 진단 텍스트에 넣지 마세요. 프로토콜 항목은 현재 앱 화면과 서버 안내를 기준으로 확인해야 합니다. 어떤 옵션이 보이지 않는다면 이름이 비슷한 다른 항목으로 대신하지 마세요. 시스템 요구 사항은 App Store 페이지의 표기를 기준으로 하며, 기기 호환성과 프로토콜 성능은 별개의 문제입니다.

2. Shadowsocks: 공유 키와 암호화 방식

Shadowsocks는 비교적 가벼운 프록시 전달을 목표로 설계되었으며, 통신을 처리할 때 양측이 미리 정한 비밀번호와 암호화 방식을 사용합니다. 인증서 체인으로 서버 신원을 확인하는 TLS 프로토콜은 아니므로 비밀번호와 암호화 방식이 일치해야 연결이 성립합니다. 프록시 프로토콜 자체는 간결하게 유지하고 서버 배포, 계정 관리, 전송 방식 확장은 관련 구현에 맡기는 설계입니다. 사용자는 주소와 비밀번호만 따로 저장하기보다 서버에서 제공한 설정 전체를 보존해야 합니다.

주소, 포트, Password, Method

주소에는 도메인 이름이나 IP 주소를 사용할 수 있습니다. 도메인 이름이 올바르게 확인되는지도 연결 전제 조건입니다. 포트는 서버의 구체적인 접속 지점을 나타내며, 같은 주소라도 포트에 따라 비밀번호나 암호화 방식이 다를 수 있습니다. Password는 한 글자도 빠짐없이 일치해야 합니다. 복사할 때 앞뒤 공백, 줄바꿈, 전각 문자가 섞이지 않았는지 특히 주의하세요. Method는 암호화 데이터를 처리하는 방식을 지정하는 항목이지, 임의로 바꿔 성능을 높이는 설정이 아닙니다. 이름이 비슷하더라도 서로 다른 방식을 대신 사용할 수 없습니다.

초기의 스트림 암호 설계와 이후 AEAD 설계는 무결성 보호, 메시지 처리, 재전송 공격 방지 등에서 차이가 있습니다. AEAD는 기밀성과 인증을 함께 처리하지만, 이름에 특정 알고리즘이 들어 있다고 해서 현재 서버에 반드시 적합하다는 뜻은 아닙니다. 암호화 방식에 따라 키 형식도 다를 수 있으며, 일부 방식에서 요구하는 키 자료는 일반 비밀번호처럼 다룰 수 없습니다. 가져온 설정에 긴 문자열이 있다면 먼저 정해진 형식의 키인지 확인하세요. 임의로 줄이거나 다시 인코딩하거나 기억하기 쉬운 문구로 바꾸지 마세요.

가져오기 링크에는 대개 유형, 암호화 방식, 비밀번호, 주소, 포트가 포함되지만, 링크가 간결해 보여도 정보가 생략된 것은 아닙니다. 먼저 원본 설정 그대로 연결해 기준 상태를 확인하고, 수동으로 살펴볼 필요가 있으면 앱에 표시된 필드를 하나씩 비교하세요. 메모 이름은 로컬에서 항목을 구분하기 위한 이름일 뿐, 프로토콜이나 서버 기능을 증명하지 않습니다. 구독 항목 이름에 네트워크 설명이 포함되어 있더라도 그것만으로 추가 전송 옵션을 켜서는 안 됩니다. 실제 접속 방식은 설정 필드와 서버 안내를 기준으로 확인하세요.

UDP와 추가 전송 방식은 자동으로 호환되지 않습니다

실시간 음성·영상 통신이나 다른 UDP 서비스가 필요하다면 클라이언트 설정, 서버의 전달 기능, 중간 네트워크를 모두 확인해야 합니다. TCP를 사용하는 웹 페이지가 열린다고 UDP 경로까지 작동한다는 뜻은 아닙니다. 설정에 추가 전송 방식이나 난독화 매개변수가 있다면 이 역시 양측이 합의한 구성의 일부입니다. 기본 프로토콜만 일치시키고 이 항목을 빠뜨리면 연결은 되더라도 유효한 데이터가 오가지 않을 수 있습니다. 추가 옵션은 현재 앱의 지원 여부에 맞춰 설정하고, 다른 접속 방식의 매개변수를 섞지 마세요.

Shadowsocks의 실제 리소스 사용량은 방식의 구현, 기기 하드웨어, 데이터 양, 연결 수에 따라 달라집니다. 가벼운 처리 방식은 일부 작업량을 줄일 수 있지만, 신호가 약하거나 패킷 손실이 많은 환경에서는 무선 전송과 재시도 비용이 더 클 수 있습니다. 프로토콜의 영향을 확인하려면 같은 서버에서 사용 가능한 접속 방식끼리 비교하세요. 회선이나 부하가 다른 서버 간의 차이를 알고리즘 차이로 해석하지 마세요. 짧은 다운로드 후 기기가 뜨거워졌다면 무선 통신이나 저장 장치 사용이 주된 원인일 수도 있습니다.

문제 해결 순서는 주소와 포트 확인, Method와 Password 확인, 추가 전송 설정 점검, UDP 및 라우팅 검증으로 정해 두면 좋습니다. 정상 작동하던 구독이 갑자기 실패한다면 여러 옵션을 연달아 바꾸지 말고 먼저 업데이트로 필드가 바뀌었는지, 서버 정보가 여전히 유효한지 확인하세요. 구독을 갱신하기 전에 로컬에서 직접 수정한 내용을 기록해 두세요. 이후 새로 고침 과정에서 설정이 다시 적용될 수 있습니다. 추가 과정을 처음부터 진행해야 한다면 시작하기를 참고하세요. 이 장에서는 필드를 설명하며 전체 설정 절차를 반복하지 않습니다.

3. VMess와 VLESS: 인증, 전송, 보안 계층

VMess와 VLESS는 모두 사용자 식별 정보로 UUID를 사용하는 경우가 많지만, 서로 같은 프로토콜의 전환 옵션은 아닙니다. VMess는 자체 설계에서 인증과 데이터 보호를 처리하는 반면, VLESS는 구조를 더 간결하게 하고 일반적으로 별도의 보안 전송 계층과 함께 사용합니다. 두 프로토콜은 서로 다른 설계 선택을 보여 줍니다. 하나는 프로토콜 내부에서 더 많은 기능을 맡고, 다른 하나는 일부 기능을 바깥 계층에 맡깁니다. UUID를 알고 있다고 두 유형을 바로 바꿔 쓸 수 있는 것은 아닙니다.

UUID 형식이 올바르다는 것만으로는 충분하지 않습니다

UUID의 문자와 구분 기호를 빠짐없이 보존하고, 복사할 때 따옴표·공백·설명 문구가 포함되지 않도록 하세요. 형식이 올바르더라도 계정이 비활성화되었거나 인증 정보가 일치하지 않거나 접속 지점 설정이 다르면 서버가 요청을 거부할 수 있습니다. VMess에서는 기기 시간이 정확한지도 확인하세요. 시간 차이가 크면 인증 과정에 영향을 줄 수 있습니다. 자동 날짜 및 시간 설정은 이 변수를 확인하는 데 도움이 됩니다. 시간이 정상인데도 실패하면 계속 시간을 초기화하지 말고 서버 설정을 확인하세요.

VMess 설정의 암호화 관련 항목은 서버에서 안내한 값으로 입력해야 합니다. 바깥 계층에서 TLS를 사용한다는 이유만으로 내부 설정을 추측해서는 안 됩니다. 오래된 설정에는 추가 항목이 다르게 들어 있을 수 있으므로 가져온 뒤 현재 앱에서 실제로 해석한 결과를 확인하세요. 일부 오래된 항목이 없거나 기본값으로 표시된다면 여러 시기의 설정을 임의로 조합하지 말고 원본 설정과 서버 안내를 확인해야 합니다. 항목 이름만으로 프로토콜의 변화나 서버 설정 차이를 판단할 수 없습니다.

전송 방식은 프로토콜 접속 지점에 도달하는 방법을 결정합니다

같은 프로토콜도 서로 다른 전송 방식으로 전달될 수 있습니다. 직접 TCP 연결, WebSocket 및 기타 지원되는 전송 방식은 연결 경로, 호스트 이름, 서버 처리 방식에서 요구 사항이 다릅니다. WebSocket을 선택하면 Path와 Host 등의 설정이 요청 라우팅에 사용될 수 있으므로 경로의 슬래시, 대소문자, 문자를 정확히 입력해야 합니다. 서버가 중간 프록시를 통해 접속 지점을 배정한다면 같은 주소와 포트로 연결하는 것만으로 올바른 서비스에 도달한다고 보장할 수 없습니다.

TLS의 Server Name은 핸드셰이크에서 서버 이름 표시와 관련 신원 확인에 사용됩니다. 전송 계층의 Host는 상위 요청을 라우팅하는 데 쓰일 수 있습니다. 일부 설정에서는 두 값이 같지만 역할은 다르므로 한 항목에 값이 없다고 다른 항목의 값을 그대로 복사해서는 안 됩니다. 연결 실패 시 인증서 검증을 우선 끄는 것도 피해야 합니다. 도메인 불일치, 인증서 체인 이상, 시스템 시간 오류의 원인을 먼저 찾아야 명확한 오류를 알아채기 어려운 위험으로 바꾸지 않습니다.

VLESS가 간결하다고 바깥쪽 보안을 생략해도 되는 것은 아닙니다

VLESS 자체는 VMess와 같은 데이터 암호화 역할을 맡지 않으므로 실제 보호 수준은 전체 보안 구성에 따라 달라집니다. 기존 설정에서 TLS나 다른 지원 보안 매개변수를 지정했다면 전체 구성을 그대로 유지하세요. 일부 서버는 특정 Flow나 관련 보안 항목도 요구합니다. 이는 단순한 메모가 아니라 양측의 프로토콜 동작에 영향을 주는 값입니다. 사용 가능 여부와 설정 조합은 현재 Shadowrocket 화면 및 기존 설정을 기준으로 확인해야 합니다. 오류를 없애려고 임의로 값을 비워서는 안 됩니다.

iOS에서 첫 접속까지 걸리는 시간에는 DNS 확인, 바깥 연결, 보안 핸드셰이크가 포함될 수 있습니다. 지속 전송 속도는 경로 품질과 혼잡의 영향을 더 많이 받습니다. 보안 계층을 추가하면 처리 부담이 늘 수 있지만 서버에 정상적으로 접속하기 위해 필요한 경우도 있습니다. 유휴 상태 후 접속이 느리고 지속 다운로드는 정상이라면 연결 재생성과 네트워크 전환을 살펴보세요. 처음부터 끝까지 느리다면 경로와 서버 부하를 비교하세요. VMess와 VLESS 중 적합한 유형은 ‘간결함’이나 ‘암호화’ 같은 단일 특징이 아니라 기존 접속 설정을 빠짐없이 맞출 수 있는지로 판단해야 합니다.

4. Trojan, HTTP, SOCKS5: 서로 다른 보안 경계

Trojan은 TLS를 중요한 바깥 계층으로 사용하고 자체 인증 및 전달 형식을 결합합니다. HTTP와 SOCKS5는 보다 일반적인 프록시 사용을 위한 프로토콜로, 프록시 서버에 어떤 대상에 연결할지 전달하는 데 중점을 둡니다. 이 세 유형을 함께 살펴보는 이유는 프록시 기능과 보안 채널의 차이를 이해하기 위해서입니다. 연결을 전달할 수 있다고 해서 클라이언트와 프록시 서버 사이까지 자동으로 암호화되는 것은 아닙니다. 선택할 때는 프록시 유형과 기존 접속 설정에 해당하는 보안 계층이 있는지 모두 확인해야 합니다.

Trojan: 먼저 TLS를 확인한 뒤 Password를 확인하세요

Trojan 설정에는 보통 서버 주소, 포트, Password, TLS 이름 관련 정보가 필요합니다. 연결 주소는 실제 서버에 도달하는 데 쓰이며, Server Name은 TLS 핸드셰이크와 인증서 신원 확인에 사용됩니다. 두 값은 같을 수도 있고 배포 방식에 따라 다를 수도 있습니다. 연결 대상으로 IP 주소를 사용하더라도 인증서가 해당 IP와 일치해야 한다고 단정할 수 없습니다. 기존 설정의 이름 항목을 그대로 유지하세요. 인증에 성공해도 이후 데이터 전달까지 성공한다는 뜻은 아니므로 대상에 접근할 수 있는지도 따로 확인해야 합니다.

인증서 관련 오류는 시스템 시간, 이름 일치 여부, 인증서 체인, 서버 배포 설정 순으로 확인하세요. 인증서 검증을 건너뛰면 서버 신원 확인이 약해지므로 장기적인 문제 해결 방법으로 유지해서는 안 됩니다. 일부 로컬 네트워크에서 먼저 웹 로그인 절차를 완료해야 한다면 프록시를 테스트하기 전에 네트워크 조건을 해결하세요. TLS 오류, 인증 오류, 대상 접속 오류는 서로 다른 단계의 문제입니다. 실제 차이가 모호해지지 않도록 오류 원문을 보관하는 것이 좋습니다.

HTTP: CONNECT는 터널을 만들지만 TLS를 대신하지 않습니다

HTTP 프록시는 프록시 요청을 처리하며, CONNECT를 통해 대상까지 바이트 터널을 만들기도 합니다. 대상 웹사이트가 HTTPS를 사용하는 경우 웹사이트 자체의 TLS는 보통 앱과 대상 사이에서 설정됩니다. 그렇다고 클라이언트와 프록시 사이에서 프록시 핸드셰이크, 인증 정보, 대상 메타데이터까지 자동으로 보호되는 것은 아닙니다. 암호화된 프록시 접속 지점을 사용할 수 있는지는 서버에서 제공하는 방식과 앱의 해당 설정을 확인해야 합니다. 대상 URL이 HTTPS로 시작한다는 이유만으로 판단하지 마세요.

HTTP 프록시의 사용자 이름과 비밀번호는 서버 로그인 정보와 전혀 다를 수 있습니다. 서버에서 프록시 인증용으로 명시한 정보를 사용하세요. 인증에 실패하면 사용자 이름이 필요한지, 특수 문자가 포함되어 있는지, 가져오는 과정에서 값이 올바르게 복원되었는지 먼저 확인하세요. 일부 프록시는 대상 포트, 요청 방식, 계정 사용 범위에 제한을 둘 수 있습니다. 연결은 성공해도 특정 대상이 거부될 수 있습니다. 이때 DNS나 규칙을 계속 바꾸기보다 프록시의 접근 범위를 확인하세요.

SOCKS5: 대상 및 인증 협상, UDP에는 별도 조건이 있습니다

SOCKS5는 연결할 대상을 협상하고 여러 인증 방식을 지원할 수 있습니다. 프로토콜에 UDP 전달 방식이 정의되어 있지만 자체적으로 데이터 암호화를 보장하지는 않습니다. 클라이언트에서 어떤 기능을 지원하더라도 현재 서버에서 활성화되어 있다는 뜻은 아닙니다. 대상을 도메인으로 지정할 때 DNS 확인이 어디서 이루어지는지는 요청을 프록시에 전달하는 방식과 클라이언트 처리 과정에 따라 달라집니다. 따라서 DNS 설정과 함께 확인해야 하며, SOCKS5라는 이름만으로 모든 이름 확인이 원격에서 이루어진다고 추정할 수 없습니다.

SOCKS5에서 UDP를 전달하려면 별도의 연계 절차가 필요한 경우가 많으며, 클라이언트와 서버 및 중간 네트워크에서 관련 트래픽을 허용해야 합니다. 웹 페이지는 열리지만 실시간 서비스가 실패한다면 사용자 이름을 계속 바꾸지 말고 TCP와 UDP를 각각 확인하세요. 사용 중인 일반 프록시가 로컬 또는 제한된 네트워크 안에서만 제공되는 경우, 그 네트워크를 벗어난 뒤에도 주소에 접근할 수 있는지 확인해야 합니다. 주소의 접근 가능 범위는 배포 환경에 따라 정해지며, 클라이언트에 항목을 저장한다고 자동으로 넓어지지 않습니다.

이 접속 유형들을 비교할 때는 먼저 설정 차이를 제외한 다음 핸드셰이크, 연결 재사용, 경로 품질을 살펴보세요. Trojan의 TLS 핸드셰이크는 짧은 연결의 초기 대기 시간에 영향을 줄 수 있고, 일반 프록시는 처리 계층이 적더라도 전체적으로 더 빠르거나 적합하다는 뜻은 아닙니다. iOS에서 간헐적으로 접속할 때는 연결이 안정적으로 복구되는지도 중요합니다. 특정 대상만 실패한다면 대상 자체와 서버의 접근 제한부터 확인하세요. 모든 대상이 실패한다면 주소, 인증, 보안 계층을 다시 살펴보세요.

5. WireGuard: 키를 통한 인증과 네트워크 계층 터널

WireGuard는 개별 요청마다 대상을 협상하는 프록시 프로토콜과 달리 네트워크 계층 터널을 위해 설계되었습니다. 공개 키로 상대를 식별하고 IP 패킷을 전달하며 UDP를 사용합니다. 이에 따라 인증 정보, 터널 주소, 전송할 수 있는 네트워크 범위가 하나의 설정 관계로 연결됩니다. 서버 주소와 비밀번호만으로 설정할 수는 없습니다. 서버가 제공한 전체 설정 자료가 있어야 하며, 어떤 항목이 로컬 기기용이고 어떤 항목이 원격 서버용인지 이해해야 합니다.

PrivateKey와 PublicKey의 방향

PrivateKey는 로컬 신원을 확인하는 비밀 정보이므로 공개하거나 알 수 없는 진단 페이지에 제출하거나 공유 스크린샷에 포함해서는 안 됩니다. 상대방 설정의 PublicKey는 원격 상대를 식별하는 데 사용되며, 서버에도 로컬 PrivateKey에 대응하는 공개 키가 등록되어 있어야 합니다. 로컬 PrivateKey를 바꾸고 서버에서 인정하는 신원 정보를 함께 갱신하지 않으면 설정이 완벽해 보여도 통신할 수 없습니다. 키를 복사할 때는 전체 인코딩을 보존하고 메모나 줄바꿈이 함께 붙지 않도록 하세요.

설정에 PresharedKey가 있다면 양측이 공유하는 추가 인증 자료입니다. 공개 키와 개인 키의 관계를 대신하지 않으며, 사용자가 임의의 문자열을 입력해서는 안 됩니다. 키 항목이 모두 비슷한 문자열처럼 보여도 용도는 서로 다릅니다. 앱에서 입력을 허용한다고 정보가 올바르다는 뜻은 아닙니다. 형식 검사는 표기 형태만 확인할 뿐 원격 서버에 대응 설정이 있는지는 알 수 없습니다. 문제를 해결할 때 키의 연결 관계를 확인할 수는 있지만 PrivateKey 전체를 피드백에 포함하지 마세요.

Address, Endpoint, AllowedIPs

Address는 일반적으로 터널 내부에서 로컬 인터페이스가 사용하는 주소를 가리키며, Endpoint는 기기가 원격 서버에 연결할 때 사용하는 공인 주소와 포트입니다. 두 항목을 서로 바꿔 쓸 수 없습니다. 터널 주소는 서버에 직접 연결하는 접속 지점이 아니며, 원격 공인 주소는 로컬 터널 주소가 아닙니다. 서버에서 특정 주소를 배정했다면 접두사 길이를 포함해 원래 값 그대로 입력하세요. 사용되지 않는 것처럼 보이는 다른 주소로 임의 변경하면 서버 라우팅이나 접근 제어가 깨질 수 있습니다.

WireGuard에서 AllowedIPs는 상대와 IP 범위의 연결에 관여하며, 전송 대상 선택과 수신 출처 확인에도 영향을 줍니다. 단순한 웹사이트 도메인 목록도 아니고 Shadowrocket의 도메인 기반 라우팅 규칙과도 다릅니다. 최종적으로 어떤 트래픽이 해당 항목으로 들어가는지는 클라이언트의 라우팅 처리에도 달려 있습니다. 다른 환경의 전체 라우팅 설정을 그대로 적용하지 말고 터널 허용 범위, 서버의 전달 기능, 현재 Global Routing 설정을 함께 확인하세요.

MTU와 연결 유지 설정은 근거를 바탕으로 조정하세요

MTU는 터널 내부에서 한 번에 전달되는 데이터 패킷의 크기에 영향을 줍니다. 바깥 계층의 캡슐화에도 추가 공간이 필요하며, 경로에서 처리할 수 있는 패킷 크기도 다를 수 있습니다. 값이 맞지 않으면 작은 요청은 성공하지만 큰 전송은 멈출 수 있습니다. 그렇다고 MTU를 낮추는 것이 모든 연결 문제의 해결책은 아닙니다. 먼저 주소, 키, 라우팅 오류를 제외한 뒤 같은 작업을 반복해 변경 전후를 비교하세요. 여러 설정을 한 번에 바꾸면 원인을 파악하기 어렵습니다.

연결 유지 설정은 특정 네트워크 환경에서 매핑을 유지하거나 접근 가능성을 높이는 데 쓰일 수 있습니다. 간격을 지나치게 짧게 설정하면 유휴 상태에서의 데이터 전송과 무선 활동이 늘어납니다. 설정이 필요한지, 어떤 값을 사용할지는 서버 안내와 실제 네트워크 상태를 기준으로 판단하고 고정된 숫자를 그대로 따라 하지 마세요. iOS에서는 앱을 사용 중일 때, 기기가 잠겨 있을 때, 무선 네트워크가 바뀔 때 동작이 달라질 수 있습니다. 핸드셰이크가 확인되더라도 터널을 통해 대상에 접근할 수 있다는 뜻은 아닙니다. 서버 전달 기능, 반환 경로, DNS도 확인해야 합니다. 필드를 더 자세히 읽는 순서는 WireGuard 설정 설명을 참고하세요.

6. Hysteria2: QUIC, UDP와 혼잡 조건

Hysteria2는 QUIC과 UDP를 사용해 프록시 통신을 전달하며, 복잡한 전송 환경에서의 데이터 전달을 고려해 설계되었습니다. QUIC은 UDP 위에서 보안 연결, 신뢰성 있는 전송, 다중화 등의 기능을 구현하므로 ‘UDP 기반’이라고 해서 모든 데이터가 신뢰성 없이 전달되는 것은 아닙니다. TCP 기반 접속과 전송 동작은 다르지만, 실제 결과는 네트워크의 UDP 허용 여부, 경로 혼잡, 서버 리소스, 설정의 적절성에 따라 달라집니다. 프로토콜 이름만으로 속도를 보장할 수는 없습니다.

성능을 따지기 전에 UDP 경로부터 확인하세요

로컬 네트워크에서 웹 페이지가 열린다고 지정한 서버의 UDP 포트에도 연결할 수 있는 것은 아닙니다. 일부 네트워크 환경에서는 UDP를 제한하거나 장시간 또는 대용량 UDP 통신에 다르게 반응할 수 있습니다. 접속 지점에 연결할 수 없다면 먼저 주소, 포트, 네트워크 조건을 확인하고, 필요하면 신뢰할 수 있는 다른 네트워크에서 비교해 보세요. 네트워크를 바꾼 뒤 결과가 크게 달라진다면 인증 문자열이나 인증서 이름보다 경로 문제를 먼저 살펴봐야 합니다.

QUIC의 연결 및 재전송 기능은 일부 패킷 손실과 경로 변화에 대응할 수 있지만, 물리적인 대역폭, 원격 서버의 혼잡, 지속적인 패킷 손실을 없애지는 못합니다. 패킷 손실이 심하면 재시도가 늘어 무선 전송과 기기 처리 부담이 커질 수 있습니다. 앱에서 작업이 더 빨리 끝나더라도 전송 시간과 유휴 활동을 함께 고려해야 배터리 영향을 판단할 수 있습니다. 짧은 메시지 중심의 접속은 첫 핸드셰이크와 기기 깨우기 비용이 더 두드러질 수 있습니다. 장시간 전송에서는 시작 시점의 최대 속도보다 안정적으로 전송되는 구간을 살펴보세요.

인증, TLS 이름, 추가 설정

Hysteria2의 인증 정보는 서버 설정과 일치해야 하며, 비밀번호나 특정 형식의 인증 자료일 수 있습니다. 일반 비밀번호처럼 보인다고 구분 문자를 삭제하지 마세요. TLS 관련 이름도 정확히 확인해야 하며 연결 주소와 인증서 이름은 여전히 역할이 다릅니다. 원본 설정에 특정 보안 또는 추가 매개변수가 있다면 현재 앱이 지원하는지 확인하고 전체 설정을 가져오세요. 이름만 바꿔 서로 다른 세대의 프로토콜 항목을 변환해서는 안 됩니다.

일부 배포 환경에서는 별도의 난독화 매개변수나 추가 설정을 요구합니다. 이런 값은 속도를 높이는 만능 스위치도 아니고 마음대로 생략해도 되는 장식 항목도 아닙니다. 서버에서 요구하는 값이 클라이언트에 없으면 인증 전에 정상적인 통신이 이루어지지 않을 수 있습니다. 설정을 가져온 뒤 원본 자료와 앱에 표시된 값을 하나씩 비교하세요. 특히 특수 문자, 인코딩, 매개변수 이름에 주의해야 합니다. 직접 입력한 값과 구독을 통해 가져온 결과가 다르다면 어떤 과정에서 차이가 생겼는지 먼저 확인한 뒤 사용할 설정을 결정하세요.

대역폭 설정값은 속도를 보장하지 않습니다

현재 설정에 업로드, 다운로드, 혼잡 관련 항목이 있으면 전송 동작이나 대역폭 협상에 영향을 줄 수 있습니다. 서버가 계정에 보장하는 고정 성능을 뜻하지는 않습니다. 업로드와 다운로드의 방향, 측정 단위, 서버 제한을 확인해야 합니다. 값을 계속 높여도 로컬 무선 연결의 물리적 용량이 늘지는 않으며, 오히려 혼잡·패킷 손실·지연이 심해질 수 있습니다. 신뢰할 만한 근거가 없다면 한 번의 속도 테스트에서 나온 순간 최대값을 입력하지 말고 현재 정상 작동하는 설정을 유지하세요.

iPhone의 배터리 사용량을 평가할 때는 먼저 일정한 시간 동안 실제 작업을 수행한 뒤 같은 시간 동안 연결만 유지하는 상태를 관찰하세요. 신호 상태와 네트워크 전환 여부도 기록해야 합니다. 백그라운드 연결 유지, 잦은 재시도, 고강도 전송은 모두 결과에 영향을 줍니다. 서버가 다르면 회선 차이도 함께 영향을 미칩니다. 기기가 뜨거워졌다면 대용량 테스트를 반복하지 말고 기기 상태가 안정될 때까지 기다리세요. 그렇지 않으면 온도와 시스템 작업 관리가 이후 결과에 영향을 줄 수 있습니다.

적합성은 보유한 접속 정보에 따라 판단해야 합니다. 서버에서 Hysteria2를 명시적으로 제공하고 UDP 경로에 접근할 수 있으며 인증 및 TLS 설정이 완전해야 테스트할 수 있습니다. 같은 서버에서 다른 유형도 제공한다면 정상 작동이 확인된 접속 방식을 비교 기준으로 보관할 수 있습니다. 한 번 실패했다고 해당 프로토콜을 항상 사용할 수 없다고 단정하지 마세요. 일부 대상만 비정상이라면 DNS, 규칙, 대상 자체를 더 확인해야 합니다. 접속 단계가 성공했다고 이후 모든 단계까지 확인된 것은 아닙니다.

7. Global Routing, 규칙, DNS의 관계

프로토콜 항목은 서버에 연결하는 방법을 설명하고, Global Routing은 요청이 해당 항목을 사용할지 결정합니다. 두 설정은 서로 다른 계층입니다. 설정/프록시/직접 연결은 인터페이스의 Config / Proxy / Direct에 각각 해당합니다. Config는 현재 설정 규칙에 따라 처리하고, Proxy는 선택한 프록시를 통해 일반적인 요청을 처리하며, Direct는 직접 연결합니다. 실제 접속은 세부 설정, 시스템 처리, 앱 동작의 영향을 받을 수 있으므로 Home의 상태만 보지 말고 실제 요청 기록을 확인하세요.

세 가지 모드로 문제 범위 좁히기

Direct에서는 대상에 접속되지만 Proxy에서 실패한다면 선택한 서버, 프로토콜 인증, 서버에서 대상까지의 경로를 먼저 확인하세요. Proxy에서는 되지만 Config에서 실패한다면 현재 활성화된 설정과 규칙이 일치하는지 살펴보세요. 다른 정책으로 연결되거나 REJECT 규칙에 걸리는지도 확인해야 합니다. 세 모드에서 모두 실패하면 로컬 네트워크, 대상 서비스, DNS부터 점검하세요. 이러한 비교는 문제를 찾기 위한 방법이지, 특정 모드로 모든 요청을 처리하라는 뜻은 아닙니다.

설정 파일이 여러 개라면 현재 적용 중인 파일부터 확인하세요. 활성화되지 않은 파일을 수정해도 사용 중인 규칙은 자동으로 바뀌지 않습니다. 구독에 포함된 서버가 업데이트되더라도 규칙 파일까지 업데이트되는 것은 아닙니다. 문제를 해결하기 전에 선택한 서버, Global Routing, 설정 이름을 기록하면 서로 다른 세 가지 변경 사항을 혼동하지 않을 수 있습니다. 평소 설정으로 되돌릴 때는 테스트용으로 임시 변경한 모드도 필요한 상태로 복구하세요.

규칙 순서와 기본 처리 규칙

규칙은 일반적으로 위에서부터 순서대로 일치 여부를 확인합니다. 앞에 있는 규칙이 해당 요청에 적용되면 뒤의 규칙이 같은 요청을 처리할 기회가 없을 수 있습니다. DOMAIN은 정확한 도메인, DOMAIN-SUFFIX는 도메인과 하위 도메인 범위에 적합합니다. IP-CIDR과 IP-CIDR6은 IP 주소 대역을, GEOIP는 IP 주소 데이터베이스를 기준으로 판단합니다. FINAL은 마지막 기본 처리 규칙입니다. 키워드를 선택할 때는 도메인과 IP 중 무엇을 대상으로 일치시킬지 먼저 정하고, 더 많은 요청을 처리하겠다고 범위를 임의로 넓히지 마세요.

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

이 예시는 규칙의 구조와 순서를 보여 주며 기존 설정을 그대로 대체할 수 있는 완성 파일이 아닙니다. example.com은 설명용 도메인입니다. PROXY와 DIRECT는 트래픽 처리 방향이므로 한국어로 바꾸면 안 됩니다. GEOIP 결과는 IP 주소 데이터베이스와 실제 대상 주소에 따라 달라지며 사이트 운영 주체가 있는 지역과 일치한다고 보장하지 않습니다. FINAL의 동작은 사용 목적에 맞게 정하고 마지막 기본 처리 위치에 둬야 합니다. 이 규칙을 바꾸면 테스트 대상 하나뿐 아니라 앞에서 일치하지 않은 모든 요청이 영향을 받습니다.

DNS는 단독으로 작동하는 ‘속도 향상 스위치’가 아닙니다

DNS는 도메인 이름을 IP 주소로 변환합니다. 어떤 리졸버를 사용할지, 요청이 어떤 경로로 전달되는지, 어떤 주소가 반환되는지에 따라 이후 접속 결과가 달라집니다. 시스템 DNS, 사용자 지정 리졸버, DNS over HTTPS는 각각 필요한 환경이 다릅니다. DoH는 HTTPS로 DNS 통신을 보호하지만 프록시를 통하는지, 리졸버에 접근할 수 있는지, 연결 전에 다른 접속이 필요한지는 설정을 함께 살펴봐야 합니다. DNS 방식을 바꿀 때 모든 항목을 한꺼번에 바꾸지 말고 새 경로를 사용할 수 있는지 확인하세요.

도메인 규칙과 IP 규칙은 서로 다른 단계의 정보에 의존할 수 있습니다. 도메인으로 접속할 때만 실패한다면 IP 주소를 직접 사용하는 테스트로는 경로 일부만 확인할 수 있습니다. 인증서 이름, 상위 계층의 호스트 이름, 대상 서비스에는 여전히 도메인이 필요할 수 있습니다. IPv4와 IPv6의 응답이 다르면 같은 대상도 네트워크에 따라 다르게 작동할 수 있습니다. DNS에서 주소 하나를 받았다고 문제가 해결된 것으로 판단하지 말고 실패한 요청에서 실제 사용한 주소 체계와 규칙 처리 결과를 확인하세요.

DNS를 조정한 뒤에도 기존 연결과 캐시가 이전 결과를 한동안 사용할 수 있습니다. 통제된 조건에서 새로 접속한 다음 요청 기록을 비교하세요. 구독을 새로 고치는 동시에 리졸버와 규칙까지 바꾸면 어떤 변경이 결과에 영향을 줬는지 알기 어렵습니다. DNS 경로 선택을 자세히 알아보려면 시스템 DNS, 사용자 지정 DNS, DoH 안내를 참고하세요. 용어 설명은 개념 빠른 참조에서 확인할 수 있습니다.

8. 상황별 선택과 단계별 문제 해결

프로토콜 선택은 사용 가능한 설정과 실제 작업을 기준으로 판단해야 합니다. 완전한 서버 정보가 한 세트뿐이라면 유형을 바꾸기보다 우선 해당 설정을 정확히 사용하세요. 사용할 수 있는 접속 방식이 여러 개라면 짧은 요청, 지속 전송, 유휴 후 재접속, 네트워크 전환을 같은 조건에서 비교하고 안정적인 기준 설정을 보관하세요. 용도에 따라 적합한 방식은 달라집니다. 큰 파일을 전송할 때는 안정적인 처리량, 간헐적으로 웹을 볼 때는 첫 응답 대기 시간, 실시간 서비스에서는 UDP와 지연 변동 및 지속적인 접속 가능성을 살펴보세요.

상황에 맞는 선택은 제한 조건부터 확인하세요

로컬 네트워크에서 UDP에 접근할 수 있는지 확실하지 않다면 먼저 경로를 확인한 뒤 Hysteria2 또는 WireGuard를 평가하세요. 연결 테스트에 실패했을 때 대역폭 값을 높이거나 연결 유지 간격을 줄여 네트워크 확인을 대신하지 마세요. 기존 설정에서 특정 도메인, 경로, TLS 이름을 사용한다면 VMess, VLESS, Trojan의 모든 설정을 일치시키는 것이 우선입니다. 이미 HTTP 또는 SOCKS5 접속 정보를 보유하고 있다면 접근 가능한 범위, 보안 계층, 접속 제한도 확인해야 합니다.

기기가 Wi-Fi와 셀룰러 네트워크 사이를 자주 전환한다면 두 네트워크에서 각각 테스트하고 전환 후 연결이 복구되는지 확인하세요. 전환으로 잠시 연결이 끊겨도 인증이 만료되었다는 뜻은 아닙니다. 주소 확인, 네트워크 매핑, 기존 연결을 다시 설정해야 할 수 있습니다. 화면이 잠긴 뒤에는 실패하지만 앱을 사용 중일 때는 정상이라면 잠금 시간, 복구 방식, On Demand 조건의 적용 여부를 기록하세요. On Demand 연결 규칙의 작동을 특정 프로토콜이 백그라운드에서 원래 사용할 수 없다는 뜻으로 오해하지 마세요.

연결 실패: 접속 지점에서 대상까지 차례로 확인

첫째, 로컬 네트워크에 정상적으로 연결할 수 있는지 확인하세요. 필요하다면 네트워크 자체에서 요구하는 웹 로그인을 먼저 완료하세요. 둘째, 서버 주소, 포트, 프로토콜 유형을 확인하고 구독이 업데이트되었는지, 항목이 여전히 유효한지 살펴보세요. 셋째, 인증·보안 계층·전송 설정을 확인합니다. Password, UUID, 공개 키 관계, Server Name, Host, Path, 추가 매개변수가 여기에 포함됩니다. 한 번에 검증 가능한 문제 하나만 처리하고 상태를 바꾸려고 여러 설정을 동시에 전환하지 마세요.

넷째, 핸드셰이크·인증·대상 접속 중 어느 단계에서 실패했는지 구분하세요. 앱에 표시된 오류 원문을 보관하고 현재 사용 가능한 기록이나 진단 기능으로 실패 지점을 확인합니다. 다섯째, Global Routing, 규칙, DNS를 확인하고 여러 대상을 비교해 보세요. 특정 대상 하나만 실패하면 서버에서 해당 대상으로 가는 경로, 대상의 제한, DNS 결과를 살펴봐야 합니다. 모든 대상이 실패하면 앞 단계의 공통 계층으로 돌아가세요. 웹사이트 규칙을 하나씩 바꿀 필요는 없습니다.

속도 저하: 반복 가능한 방식으로 테스트하기

테스트 전에 동시에 실행 중인 대용량 작업을 종료하고 같은 대상과 비슷한 작업 길이를 선택하세요. 사용하는 네트워크와 서버도 기록합니다. 먼저 직접 접속과 필요한 프록시 접속을 비교한 다음, 같은 서버에서 사용할 수 있는 접속 방식끼리 비교하세요. Connectivity Test 결과는 해당 테스트 방식과 당시 조건만을 나타내며 다운로드 속도로 바로 환산할 수 없습니다. 속도 한계를 확인하는 테스트를 연속해서 반복하면 발열, 혼잡, 백그라운드 작업이 결과에 섞일 수 있습니다. 적당한 간격을 두면 해석하기 쉬운 결과를 얻을 수 있습니다.

처음 열 때만 느리다면 DNS, 핸드셰이크, 연결 복구를 중점적으로 확인하세요. 시작은 빠르지만 전송 중 속도가 떨어진다면 혼잡, 서버 부하, 기기 온도, 경로 변화를 살펴보세요. 작은 요청은 성공하는데 대용량 전송이 멈출 때는 MTU나 패킷 분할 문제를 추가로 확인할 수 있습니다. 모든 판단은 같은 작업을 반복해 확인해야 합니다. 단계별 점검 방법과 테스트 결과 해석은 속도 저하 단계별 점검을 참고하세요. 한 번 나온 수치만 보고 모든 설정을 삭제하지 마세요.

기준 설정 복원 및 피드백 정리

변경 사항이 많아졌다면 정상 작동이 확인된 설정 사본을 먼저 복원한 다음 필요한 변경을 하나씩 적용하세요. 구독을 업데이트하기 전에 로컬에서 직접 변경한 내용이 덮어써질 수 있는지 확인하세요. 업데이트 후 설정 필드가 바뀐 것을 앱의 임의 오류로 오해해서는 안 됩니다. 문제를 전달할 때는 프로토콜 유형, 네트워크 조건, 실패 단계, 오류 원문, 재현 절차를 제공하면 충분합니다. 구독 전체 주소, Password, UUID, PrivateKey, 계정을 식별할 수 있는 정보는 삭제하세요. 재현을 쉽게 하려고 인증 정보를 공개하지 마세요.

이 매뉴얼은 서버 설정 안내를 대신하지 않으며 프로토콜 이름만으로 품질을 보장하지 않습니다. 앱 구매, 구매 복원, 정품 정보는 정품 확인을 참고하세요. 처음 실행할 때 필요한 시스템 권한은 첫 실행 및 VPN 구성 권한에서 확인할 수 있습니다. 알려진 증상은 질문과 답변에서 찾아보세요. 문제를 해결한 뒤에는 ‘프로토콜을 바꾸니 됐다’는 결론만 남기지 말고 실제로 작동한 설정 관계를 기록하세요. 그래야 다음 업데이트나 네트워크 변경 때도 각 단계별로 다시 확인할 수 있습니다.