Shadowrocket 프로토콜 가이드
설정값, 속도와 배터리 소모 비교

01 / CONNECTION LAYERS

연결 계층: 프로토콜, 전송 방식, 규칙의 역할

먼저 서로 다른 네 가지 문제를 구분하세요

Shadowrocket에서 프로토콜 유형을 선택하는 것은 클라이언트가 서버와 어떤 형식으로 통신할지 정하는 일입니다. Shadowsocks, VMess, VLESS, Trojan 등의 유형은 인증과 데이터 캡슐화의 일부 방식을 규정합니다. TCP, UDP, WebSocket은 데이터 전송 방식을 다룹니다. TLS는 인증된 암호화 채널을 설정하고, 규칙은 어떤 요청을 해당 채널로 보낼지 결정합니다. 여러 계층을 조합할 수는 있지만 서로 대체할 수는 없습니다. 유형 이름만 바꿔도 원격 서버가 해당 서비스로 자동 전환되지는 않습니다.

예를 들어 기존 설정에 서버 주소, 포트, UUID, WebSocket 경로, TLS 서버 이름이 함께 있다면 이는 서로 독립적인 다섯 가지 프로토콜이 아니라 여러 계층에 걸친 하나의 연결 설정입니다. 클라이언트가 서버를 찾고, 지정된 방식으로 전송을 설정한 뒤 필요한 보안 핸드셰이크와 인증을 완료하고, 마지막으로 대상 요청을 전달합니다. 어느 한 계층이라도 설정이 맞지 않으면 같은 ‘연결 실패’로 나타날 수 있습니다. 따라서 문제를 진단하기 전에 설정 구성을 기록하고, 오류 메시지만 보고 유형을 임의로 바꾸지 마세요.

속도와 배터리 소모는 프로토콜 이름만으로 판단할 수 없습니다

웹페이지를 여는 과정에는 도메인 조회, 연결 설정, 핸드셰이크, 데이터 전송, 앱 처리가 포함됩니다. 짧은 요청은 왕복 시간과 핸드셰이크의 영향을 더 크게 받고, 장시간 다운로드는 가용 대역폭, 패킷 손실, 서버 부하에 더 좌우됩니다. 다운로드 처리량이 높은 설정이 여러 개의 작은 페이지를 열 때도 빠르다는 뜻은 아닙니다. 한 번의 테스트에서 수치가 낮게 나와도 현재 기기에 해당 프로토콜이 맞지 않는다고 단정할 수 없습니다. 같은 대상과 비슷한 시간대, 동일한 네트워크에서 반복 비교하고 최고 기록뿐 아니라 실패 횟수도 남기세요.

iPhone과 iPad에서는 무선 네트워크 상태도 배터리 소모에 큰 영향을 줍니다. 신호가 약해 반복 재전송이 발생하거나, 연결이 끊긴 뒤 계속 재연결하거나, 백그라운드 작업이 자주 깨어나면 암호화 알고리즘보다 영향이 더 클 수 있습니다. Wi-Fi와 셀룰러 네트워크를 전환한 뒤에는 기존 연결을 복구해야 할 수 있습니다. 전송 방식에 따라 복구 방법은 다르지만, 일정한 배터리 절감률을 제시할 수는 없습니다. 먼저 연결을 안정화한 뒤 같은 시간 동안 사용하며 배터리 소모와 발열을 비교하세요. 항상 배터리를 가장 적게 쓰는 프로토콜을 찾으려 하지는 마세요.

사용 가능한 조건부터 선택하세요

실제 선택 순서는 다음과 같습니다. 먼저 기존 서버에서 제공하는 유형을 확인하고, 해당 전송 방식을 현재 네트워크에서 사용할 수 있는지 점검한 다음, 사용 경험을 비교하세요. 서버에서 확인된 설정을 하나만 제공한다면 직접 다른 유형으로 바꾸기보다 전체 설정을 그대로 가져오는 편이 더 안전합니다. 여러 설정을 제공하는 경우 원래 항목을 보존하고 각각 알아보기 쉬운 이름을 붙이세요. 테스트할 때는 한 번에 변수 하나만 바꾸세요. 서버 주소와 인증 정보가 서로 다른 두 항목은 프로토콜 차이만 비교하는 엄밀한 실험이 아닙니다.

이후 장을 읽을 때는 ‘프로토콜이 지원하는 기능’과 ‘현재 서버에서 활성화된 기능’을 구분해야 합니다. 프로토콜 설계상 선택 가능한 기능도 양쪽 구현과 설정이 모두 지원해야 작동합니다. 구독에는 기본값이 생략되거나 공유 형식의 약칭이 쓰일 수 있습니다. 알 수 없는 항목은 설정을 제공한 곳의 안내를 확인하세요. 알 수 없는 값을 임의로 삭제한 뒤 추측을 이어 가지 말고, 인증 정보가 포함된 전체 설정을 공개 페이지에 올리지 마세요. 조작 순서는 빠른 시작 안내에서, 오류 유형은 자주 묻는 질문에서 확인하세요.

02 / SHADOWSOCKS

Shadowsocks: 암호화 방식과 비밀번호를 함께 확인하세요

간결한 프록시 캡슐화에 초점을 둔 설계

Shadowsocks는 클라이언트와 서버 사이에서 프록시 트래픽을 비교적 간결한 방식으로 전달하도록 설계되었습니다. 완전한 네트워크 터널처럼 먼저 기기에 가상 주소와 라우팅 관계를 설정하기보다는 대상 연결을 캡슐화하는 방식에 가깝습니다. 따라서 설정에서 핵심 항목은 대개 서버, 포트, 암호화 방식, 비밀번호이며, 터널 네트워크 대역이 아닙니다. 사용 성능은 서버 구현, 네트워크 품질, 실제 적용 방식에 따라 달라지므로 설정이 간단하다는 이유만으로 속도를 예측할 수는 없습니다.

최근 구성에서 흔히 사용하는 인증 암호화 방식은 수신 측이 데이터를 복호화하는 동시에 변조나 키 불일치를 감지하도록 합니다. 방식마다 키 자료, 데이터 구성, 양측 구현에 대한 요구 사항이 다르며, 이름이 비슷해도 호환된다는 뜻은 아닙니다. 서버가 요구하는 방식을 클라이언트에서도 동일하게 선택하세요. 이름이 최신처럼 보인다는 이유로 기존 설정을 바로 바꾸지 마세요. 방식을 바꾸면 기존 비밀번호가 해당 방식의 형식 요건에 맞는지도 다시 확인해야 합니다.

핵심 설정값 네 가지를 확인하는 순서

먼저 서버 주소에 불필요한 공백, 프로토콜 접두사, 경로가 들어 있지 않은지 확인하세요. 주소 입력란에는 일반적으로 도메인이나 주소만 입력하고 포트는 별도로 지정합니다. 공유 문자열 전체를 주소 입력란에 붙여 넣는 것은 가져오기를 대신할 수 없습니다. 다음으로 해당 서비스에 지정된 포트인지 확인하세요. 같은 서버에서도 프로토콜에 따라 포트가 다를 수 있습니다. 마지막으로 암호화 방식과 비밀번호를 확인하세요. 비밀번호의 대소문자와 끝부분 문자를 그대로 유지하고, 특수해 보이는 기호를 복사 과정에서 삭제하지 마세요.

일부 최신 방식은 키 형식에 특별한 제약이 있어 일반적으로 기억하는 비밀번호와 인코딩된 키를 같은 입력값으로 취급할 수 없습니다. 서버 정보에 여러 키나 추가 인증 자료가 포함되어 있다면 제공자의 안내에 따라 가져오고 임의로 이어 붙이지 마세요. 기존 구독에서 유형을 올바르게 인식한다면 설정 항목 간 관계를 그대로 유지하세요. 직접 추가할 때는 먼저 필수 값만 입력해 연결을 확인한 다음 선택 항목을 살펴보세요. 확인되지 않은 설정을 여러 개 동시에 추가하지 않는 것이 좋습니다.

UDP 사용 조건도 별도로 확인하세요. 일부 앱은 UDP 요청을 보내지만 서버의 처리 여부, 현재 경로에서 UDP가 허용되는지, 클라이언트가 어떻게 전달하는지 모두 지원되어야 합니다. 웹페이지가 열린다고 해서 일부 TCP 요청만 성공했을 수 있으며, 음성 통화나 실시간 상호작용 등 UDP를 사용하는 기능까지 정상이라고 단정할 수 없습니다. 반대로 특정 실시간 앱에 문제가 있어도 비밀번호 오류라고 단정하지 마세요. 인증 실패와 특정 트래픽 유형의 실패를 구분하면 진단 범위를 좁힐 수 있습니다.

iOS에서 실제 성능 확인하기

iOS에서 지속 전송 중 발생하는 암호화 비용은 프로세서 성능, 방식의 구현, 트래픽 규모에 따라 달라집니다. 일반적인 웹페이지 탐색에서는 연결 설정과 무선 네트워크의 전력 소모가 더 두드러질 수 있고, 대용량 파일 전송에서는 암호화 처리와 지속적인 무선 통신의 영향을 관찰하기 쉽습니다. 테스트할 때는 짧은 페이지 방문, 지속 전송, 화면을 잠근 뒤의 연결 복구를 따로 기록하세요. 다운로드 한 번만 테스트하지 마세요. 기기가 뜨거워지면 백업, 미디어 처리, 앱 업데이트가 동시에 진행 중인지 먼저 확인해 모든 부하를 프록시 프로토콜 탓으로 돌리지 않도록 하세요.

연결할 수 없다면 먼저 원래 설정 전체를 복구하고 시스템 시간과 네트워크가 정상인지 확인한 다음, 같은 설정으로 다른 네트워크에서 다시 테스트하세요. 모든 요청이 실패한다면 주소, 포트, 방식, 비밀번호를 중점적으로 확인하세요. 일부 대상만 실패한다면 규칙, DNS 조회, 대상 서버를 점검하세요. 암호화 방식을 계속 바꾸며 운에 맡기지 말고, 테스트 중 만든 임시 사본을 정식 구독 목록에 섞지 마세요. 직접 추가한 항목에는 알아보기 쉬운 메모를 붙이면 나중에 기본 서버를 잘못 선택하는 일을 줄일 수 있습니다.

기존 서버가 일치하는 Shadowsocks 설정을 명확히 제공하고 테스트 결과가 실제 사용 목적에 맞는다면 Shadowsocks를 선택할 수 있습니다. 설정 항목이 간결해 하나씩 확인하기는 쉽지만, 필수 항목을 생략해도 된다는 뜻은 아닙니다. 설정에 플러그인이나 추가 캡슐화가 필요한데 현재 화면에서 지원하지 않는다면 먼저 지원 여부를 확인하세요. 누락된 항목을 중요하지 않은 설명으로 넘기지 마세요. 프로토콜 이름만 기억하기보다 재현 가능한 유효 설정을 보관하는 것이 중요합니다.

03 / VMESS & VLESS

VMess와 VLESS: 인증, 암호화, 전송을 구분해 이해하기

유형만 바꿔 두 프로토콜을 서로 전환할 수는 없습니다

VMess와 VLESS는 전송 옵션이 여러 계층으로 구성된 설정에 자주 등장하지만, 같은 프로토콜의 표시 이름만 다른 것이 아닙니다. VMess는 프로토콜 계층에서 인증과 데이터 보호 관련 기능을 설계에 포함합니다. VLESS는 프로토콜 계층을 더 간결하게 구성하며, 별도로 설정한 보안 전송과 함께 사용하는 경우가 많습니다. 둘 다 UUID 형식의 식별자를 사용하는 일이 많아 유형만 바꾸면 전환된다고 오해하기 쉽습니다. 하지만 UUID가 같아 보여도 서버에서 해당 프로토콜을 실행하고 동일한 전송 조합을 받아들여야 합니다.

UUID는 구조화된 식별자이지 서버 주소도, 웹사이트 인증서를 확인하는 이름도 아닙니다. 확인할 때는 값이 완전한지, 공백이 섞이지 않았는지, 현재 서버에 해당하는 값인지 점검하세요. 여러 설정의 UUID, 포트, 경로를 서로 섞지 마세요. VMess 인증에는 시간 조건도 관련될 수 있어 기기 시계가 크게 어긋나면 실패할 수 있습니다. 시스템 시간을 자동으로 설정하세요. 이 방법은 시간 문제를 해결할 뿐 잘못된 식별자나 전송 설정을 보완하지는 않습니다.

전송 설정은 하나의 조합으로 확인하세요

일반적인 설정에서는 프로토콜 외에 TCP나 WebSocket 같은 전송 방식도 지정합니다. WebSocket을 선택할 때 경로는 서버가 요청을 받는 위치와 일치해야 하며, 슬래시, 대소문자, 추가 매개변수가 결과에 영향을 줄 수 있습니다. Host는 보통 애플리케이션 계층의 요청이나 프런트엔드 라우팅에 사용되고, TLS 서버 이름은 보안 핸드셰이크와 신원 확인에 사용됩니다. 두 값은 같을 수도 있고 배포 방식에 따라 다를 수도 있습니다. 서버 주소, Host, TLS 이름은 서로 다른 역할이므로 화면을 깔끔하게 보이게 하려고 억지로 같은 값으로 입력하지 마세요.

하나의 도메인 뒤에 여러 단계의 전달 구성이 있다면, 클라이언트가 프런트엔드 포트에 연결되었다고 해서 요청이 올바른 프로토콜 서비스에 도달한 것은 아닙니다. 잘못된 경로는 일반 웹페이지 응답을 반환할 수 있고, 잘못된 Host는 다른 사이트로 연결될 수 있으며, TLS 이름이 틀리면 더 이른 단계에서 거부될 수 있습니다. 포트에 연결할 수 있다는 것은 첫 번째 단계만 확인한 것입니다. 서버가 ‘온라인’이라는 이유로 설정 문제를 배제하지 말고 주소와 포트, TLS, 전송 경로, 프로토콜 인증 순으로 하나씩 확인하세요.

VLESS 자체를 일반적인 페이로드 암호화를 제공하는 대체 수단으로 간주해서는 안 됩니다. 클라이언트와 서버 사이의 데이터를 보호하려면 실제 설정에서 어떤 보안 계층을 사용하며 어떻게 검증하는지 확인해야 합니다. 일부 설정에는 특정 흐름 제어 또는 핸드셰이크 매개변수도 포함되지만, 이는 범용 가속 스위치가 아닙니다. 양쪽에서 같은 조합을 설정해야 의미가 있습니다. 현재 화면에 특정 항목이 보이지 않는다면 해당 조합의 지원 여부를 먼저 확인하세요. 알 수 없는 값을 메모나 관계없는 입력란에 넣어 대신하지 마세요.

짧은 연결의 오버헤드와 연결 재사용의 한계

iPhone에서는 첫 연결의 체감 속도에 네트워크 왕복 시간, TLS 핸드셰이크, 추가 전송 캡슐화가 함께 영향을 줄 수 있습니다. VMess와 VLESS를 단순히 빠르고 느린 순서로 나누는 것은 신뢰할 만한 기준이 아닙니다. 서버와의 거리, 전송 방식, 연결 재사용 정책에 따라 결과가 달라질 수 있습니다. 연결 재사용은 일부 상황에서 반복 연결 설정 비용을 줄일 수 있지만 여러 요청이 하나의 하위 채널을 공유하게 합니다. 혼잡할 때는 공유가 반드시 더 원활한 것은 아니므로, 모든 선택 옵션을 항상 켜 두기보다 같은 작업을 기준으로 테스트하세요.

배터리를 비교할 때도 조건을 통제해야 합니다. 네트워크 전환 후 특정 설정에서 인증 실패가 계속되면 반복 핸드셰이크로 백그라운드 활동이 늘어날 수 있습니다. 더 가벼워 보이는 프로토콜로 바꾸기보다 경로, 시계, 인증 정보를 바로잡는 편이 효과적입니다. 화면을 잠갔다가 앱을 다시 열었을 때 첫 요청만 느리다면 정상적인 연결 재설정인지 반복 재시도인지 구분하세요. 복구 시간, 수동 전환 필요 여부, 오류 반복 여부를 기록하되 한 번의 현상을 해당 프로토콜의 고정 특성으로 일반화하지 마세요.

완전한 VMess 설정이 이미 있고 안정적으로 작동한다면 다른 유형의 설정이 더 간결해 보인다는 이유만으로 옮길 필요는 없습니다. VLESS를 사용한다면 보안 전송, 인증, 선택적 흐름 제어 설정이 서로 맞는지 확인하세요. 여러 항목을 테스트할 때는 전송 방식과 용도를 메모로 표시하고 서버에서 제공한 프로토콜 설정을 바꾸지 마세요. 기본 항목 선택 및 Connectivity Test 실행 방법은 첫 연결 및 확인 안내를 참고하세요.

04 / TROJAN & TLS

Trojan: TLS 신원 확인과 프로토콜 비밀번호를 따로 점검하세요

널리 쓰이는 TLS 채널로 프록시 요청을 전달하는 방식

Trojan의 주요 설계 특징은 TLS를 통해 암호화와 서버 신원 확인을 제공한 뒤, 해당 채널에서 프로토콜 인증과 요청 전달을 수행하는 것입니다. 따라서 비밀번호 입력란만 볼 것이 아니라 인증서, 서버 이름, 연결 대상의 관계도 이해해야 합니다. TLS는 널리 사용되는 보안 전송 방식이지만, TLS를 사용한다고 해서 모든 TLS 서버가 Trojan 요청을 처리할 수 있는 것은 아닙니다. 올바른 포트에 연결하고 해당 프로토콜을 지원하는 서비스에 맞는 인증 정보를 보내야 합니다.

서버 주소는 클라이언트가 연결할 위치를 정하고, 포트는 어떤 서비스에 접속할지 결정합니다. TLS 서버 이름은 핸드셰이크에서 이름을 알리고 인증서의 신원을 확인하는 데 사용됩니다. 인증서는 확인 대상 이름을 포함해야 하고 유효 기간 내에 있어야 하며, 인증서 체인은 시스템에서 신뢰할 수 있어야 합니다. 주소로 직접 연결하지만 인증서가 도메인용으로 발급된 경우 기존 설정에 따라 올바른 검증 이름을 지정해야 합니다. 같은 기기로 해석된다고 해서 모든 이름의 인증서가 검증되는 것은 아닙니다. 네트워크 위치가 같아도 신원은 같지 않습니다.

핸드셰이크 실패가 비밀번호 오류를 뜻하지는 않습니다

인증은 보통 보안 채널이 설정된 뒤에 이루어집니다. 인증서가 만료되었거나 기기 시간이 틀렸거나 이름이 일치하지 않거나 서버가 완전한 인증서 체인을 제공하지 않으면 비밀번호 확인 단계에 도달하지 못할 수 있습니다. 이때 비밀번호를 반복해서 입력해도 TLS 문제는 해결되지 않습니다. 먼저 시스템 날짜, 도메인 철자, 인증서 관련 안내를 확인한 뒤 기존 서버의 관리자에게 인증서 설정을 확인하세요. 반대로 TLS 연결은 성공했지만 프로토콜 인증이 거부되었다면 비밀번호, 서비스 유형, 서버 측 권한을 중점적으로 확인해야 합니다.

비밀번호는 대소문자와 특수 문자, 앞뒤 위치를 포함해 정확히 복사해야 합니다. 구독 업데이트 후 비밀번호가 변경되었다면 오래된 수동 복사본은 계속 실패할 수 있습니다. 이름이 비슷한 예전 항목이 아니라 구독의 최신 항목을 선택했는지 확인하세요. 비밀번호를 저장할 때 중국어 메모, 따옴표, 줄바꿈을 비밀번호에 포함하지 마세요. 문제 기록에는 ‘비밀번호를 원본과 대조함’이라고 적을 수 있지만, 실제 비밀번호를 공개 스크린샷이나 로그에 넣어서는 안 됩니다.

일부 설정에서는 ALPN이나 기타 TLS 협상 조건을 추가로 지정할 수 있습니다. ALPN은 애플리케이션 계층 프로토콜을 협상하는 기능이지 임의로 선택하는 속도 설정이 아닙니다. 입력 필요 여부와 허용 값은 서버 요구 사항을 따르세요. 입력란을 모두 채워 보이게 하려고 다른 곳의 값을 복사하지 마세요. 구독에 관련 값이 이미 포함되어 있다면 조합을 유지하고, 문제가 있을 때 원본 안내와 항목별로 대조하세요. 모든 보안 옵션을 한꺼번에 지우고 테스트하지 마세요.

iOS에서 핸드셰이크와 연결 복구 확인하기

TLS를 처음 설정할 때는 핸드셰이크 정보를 주고받으므로 네트워크 왕복 시간이 이 과정에 영향을 줍니다. 연결이 지속된 뒤의 처리량은 전송 경로, 혼잡, 서버 부하에도 좌우됩니다. 첫 페이지를 여는 데 걸린 시간을 장기적인 속도와 동일시하지 마세요. 조건이 맞으면 세션 복구로 이후 핸드셰이크 비용이 줄어들 수 있지만, 실제 적용 여부는 구현 방식과 서버 상태에 따라 달라져 매번 재사용된다고 보장할 수 없습니다. 첫 방문과 바로 이어지는 재방문을 따로 관찰해 캐시 효과를 프로토콜 차이로 오해하지 않도록 하세요.

Wi-Fi에서 셀룰러 네트워크로 전환하면 기존 연결을 다시 설정해야 할 수 있습니다. 잠시 기다리는 상황만으로 인증 정보가 잘못되었다고 볼 수는 없습니다. 복구가 매번 오래 걸리고 실패한다면 현재 네트워크에서 서버 포트에 연결되는지와 DNS 결과를 확인하세요. 배터리 측면에서는 이미 안정적으로 유지되는 장시간 연결보다 TLS를 자주 다시 설정하고, 실패 후 연속 재시도하며, 약한 신호에서 데이터를 재전송하는 상황을 더 주의해야 합니다. 먼저 불필요한 재시도를 없앤 다음 일반적인 사용 중 배터리를 비교하고, 특정 핸드셰이크 방식에 고정된 배터리 소모량을 부여하지 마세요.

기존 설정에서 Trojan을 명확히 지정하고 TLS 이름, 인증서, 인증 정보가 모두 갖춰져 있다면 사용할 수 있습니다. 설정 점검은 목적지 확인, 보안 핸드셰이크 검증, 비밀번호와 요청 확인 순으로 진행하면 됩니다. 웹페이지에 여전히 문제가 있는데 연결 테스트가 통과했다면 DNS 조회와 규칙도 확인하세요. TLS를 사용한다고 해서 이후 계층의 점검을 건너뛸 수는 없습니다. 모드 선택은 Global Routing 세 가지 모드 안내도 참고하세요.

05 / HTTP & SOCKS5

HTTP와 SOCKS5: 프록시 인터페이스와 암호화 채널은 다릅니다

두 가지 범용 프록시의 설계 배경

HTTP 프록시는 애플리케이션 계층 프록시 요구에서 출발했습니다. HTTP 요청을 처리하고, CONNECT 메서드로 다른 대상에 바이트 터널을 설정하는 데 자주 사용됩니다. SOCKS5는 더 범용적인 연결 협상 방식을 제공하며, 클라이언트가 프록시에 대상을 알리면 프록시가 후속 통신을 설정합니다. 둘 다 프록시 인터페이스이지만, 인터페이스 자체만으로 클라이언트와 프록시 사이의 통신이 암호화되는지 또는 모든 요청 유형을 지원하는지 알 수는 없습니다. 선택할 때는 전송 보호, 인증 방식, 서버가 제공하는 기능을 함께 확인해야 합니다.

흔한 오해는 대상 웹사이트가 HTTPS를 사용하므로 프록시까지의 모든 구간도 동일한 보호를 받는다고 생각하는 것입니다. 대상 웹사이트의 TLS는 해당 채널의 서비스 데이터를 보호할 수 있지만, 일반 HTTP 프록시의 CONNECT 협상과 프록시 인증은 대상이 HTTPS를 사용한다고 자동으로 같은 수준의 보호를 받지 않습니다. TLS로 프록시에 연결하는 경우 프록시 인증서도 별도로 확인해야 합니다. ‘대상 웹사이트가 HTTPS를 사용한다’와 ‘클라이언트가 암호화된 방식으로 프록시에 연결한다’는 서로 다른 조건입니다.

주소, 인증 정보, DNS 조회 위치

HTTP 또는 SOCKS5 항목을 추가할 때 먼저 서버 유형을 확인한 다음 주소, 포트, 사용자 이름, 비밀번호를 점검하세요. 서버가 사용자 이름 없이 접속을 허용할 수도 있고 반드시 인증을 요구할 수도 있습니다. 입력란을 비워도 되는지는 원래 설정에 따라 달라집니다. 사용자 이름과 비밀번호는 별도 항목이므로 구분자가 포함된 전체 문자열을 한쪽에 통째로 입력하지 마세요. 일부 환경은 접속한 네트워크에 따라 접근을 제한할 수 있습니다. 이 경우 인증 정보가 맞더라도 셀룰러 네트워크에서는 거부될 수 있으니 기존 서버 관리자에게 권한을 확인하세요.

DNS 조회가 어디서 이루어지는지도 사용 결과에 영향을 줍니다. 클라이언트가 도메인을 먼저 주소로 변환해 프록시에 요청할 수도 있고, 프로토콜에 따라 도메인을 프록시에 보내 대신 조회하도록 할 수도 있습니다. 실제 동작은 클라이언트 설정, 프로토콜 기능, 서버 구현에 따라 다릅니다. 특히 접속 위치에 따라 주소를 다르게 제공하는 서비스에서는 두 경로가 서로 다른 결과를 반환할 수 있습니다. ‘도메인은 실패하지만 주소로는 연결되는 것 같다’면 프록시 유형을 바로 바꾸기보다 조회 경로와 결과를 확인하세요. 주소를 직접 사용해 HTTPS를 테스트하면 인증서 이름 문제가 추가될 수 있으므로 완전히 같은 조건의 대체 테스트는 아닙니다.

SOCKS5 프로토콜에는 UDP 연계 방식이 정의되어 있지만 모든 서버에서 제공되는 것은 아니며, 유형 이름만으로 현재 설정의 사용 가능 여부를 확인할 수 없습니다. 서버가 TCP만 처리하거나 관련 방화벽이 UDP 응답을 차단할 수 있습니다. HTTP CONNECT는 보통 TCP 터널을 설정하는 데 사용되며 SOCKS5의 UDP 연계와 같은 기능을 제공한다고 가정해서는 안 됩니다. 실시간 음성·영상이 필요하다면 해당 트래픽을 직접 테스트하세요. 웹페이지 하나가 열린다는 이유만으로 필요한 기능이 모두 충족된다고 판단하지 마세요.

사용 상황 및 iOS 동작

기존 회사 네트워크, 테스트 환경 또는 직접 관리하는 서버에서 범용 프록시 인터페이스를 제공한다면 HTTP와 SOCKS5를 기존 서비스에 연결할 수 있습니다. 선택 기준은 어느 이름이 더 고급인지가 아니라 인터페이스가 일치하는지입니다. 추가 암호화가 없다고 해서 모든 네트워크에서 민감한 인증 정보를 전송해도 된다는 뜻은 아닙니다. 먼저 통신 경로의 범위와 보호 방식을 확인하세요. 네트워크에서 평문으로 전송되는 인증 정보를 일반적인 문제 해결 정보처럼 공개하지 말고, 접근 권한을 모르는 상태에서 인증 정보를 반복 제출하지 마세요.

iOS에서 두 인터페이스의 속도도 프록시까지의 거리, 연결 설정 방식, 대상의 응답에 따라 달라집니다. 프로토콜 캡슐화가 적다고 해서 경로 품질이 나쁜 점을 상쇄하거나 배터리를 더 절약하는 것은 아닙니다. 앱마다 동작이 다르면 먼저 대상, 전송 방식, DNS 조회 경로가 다른지 확인하세요. TCP 테스트는 통과했는데 실시간 기능이 실패하면 UDP 조건을 우선 확인하세요. 인증만 실패하는 경우에 사용자 이름과 비밀번호를 집중 점검하고 관련 없는 설정을 반복해서 바꾸지 마세요.

범용 프록시마다 세 가지를 기록하세요. 프록시까지의 통신 경로가 보호되는지, 어떤 전송을 지원하는지, 도메인을 어느 쪽에서 조회하는지입니다. 세 항목이 명확해야 용도에 적합한지 판단할 수 있습니다. 서버 주소와 포트만 확인되고 나머지 정보가 없다면 설정을 제공한 곳에 문의하세요. 보안 조건을 기본값으로 추측해 채우지 마세요. 이렇게 하면 인터페이스에 연결할 수 있는지와 실제 사용에 적합한지를 구분해 ‘연결은 되지만 예상과 다른’ 상황을 줄일 수 있습니다.

06 / WIREGUARD

WireGuard: 키, 터널 주소, 라우팅 범위를 함께 확인하세요

단일 프록시 요청이 아닌 네트워크 터널 관점에서 이해하기

WireGuard는 암호화 네트워크 터널을 위해 설계되었으며 피어, 공개 키와 개인 키, 라우팅 범위를 사용해 통신 관계를 설정합니다. 대상별로 프록시 요청을 지정하는 프로토콜과 달리 데이터 패킷을 가상 네트워크 경로로 보내는 방식에 가깝습니다. 따라서 설정에 터널 내부 주소, 피어 공개 키, 엔드포인트, 허용 주소 범위가 포함되는 경우가 많습니다. 이 차이를 이해하는 것이 중요합니다. 엔드포인트와 핸드셰이크가 된다고 해서 서비스에 올바른 라우팅이 설정된 것은 아닙니다. 키가 맞더라도 서버의 전달 및 응답 경로 설정을 대신할 수는 없습니다.

각 피어는 자체 개인 키를 보유하고 상대 피어의 공개 키로 상대를 확인합니다. 클라이언트 개인 키는 자신의 설정에 보관하고 서버 공개 키는 서버 설정에서 가져오세요. 두 키를 바꿔 입력하면 안 됩니다. 선택적 사전 공유 키는 기존 키 관계에 추가하는 공유 자료이지 개인 키의 다른 이름이 아닙니다. 서버에 해당 설정이 없다면 클라이언트에만 입력해도 호환성이 높아지지 않으며 인증 불일치가 발생할 수 있습니다. 가져온 뒤 키의 관계를 그대로 유지하고 여러 설정의 키를 임의로 섞지 마세요.

엔드포인트, 주소, AllowedIPs의 역할 차이

엔드포인트는 외부 네트워크에서 피어에 연결할 위치로, 보통 도메인 또는 주소와 포트로 구성됩니다. 터널 내부 주소는 암호화 네트워크에서 사용하는 로컬 식별자와 주소이므로 엔드포인트의 공인 주소를 입력하지 마세요. AllowedIPs는 피어의 주소 범위 제한과 라우팅 선택에 모두 관련되지만, 실제 적용 범위는 앱의 통합 방식에 따라 달라집니다. 임의로 범위를 넓혀도 다른 요청에 영향이 없다고 보장되는 일반적인 허용 목록은 아닙니다.

라우팅 범위를 지나치게 넓히면 원래 터널로 보내지 않아도 되는 트래픽까지 들어갈 수 있고, 너무 좁히면 대상 네트워크 대역으로 가는 경로가 없을 수 있습니다. 서버 측에서도 응답을 클라이언트로 보내는 방법을 알아야 하므로 전달 설정, 내부 네트워크 대역, 접근 제어가 서로 맞아야 합니다. 핸드셰이크는 성공했지만 대상에 접근할 수 없다면 먼저 특정 내부 대역만 실패하는지 모든 서비스가 실패하는지 구분한 뒤 주소 범위와 응답 경로를 확인하세요. 키를 다시 생성하는 것부터 시작하지 마세요.

DNS도 별도로 확인해야 합니다. 터널 내부 주소에 접근할 수 있어도 내부 도메인이 반드시 조회되는 것은 아닙니다. 설정에서 내부 DNS 서버를 지정했다면 그 서버까지 도달할 경로도 필요합니다. 반대로 도메인이 조회되었다고 해서 해당 주소의 서비스 포트에 연결할 수 있다는 뜻은 아닙니다. 문제를 진단할 때 조회 결과와 대상 연결 결과를 각각 기록하고 두 단계를 ‘네트워크 정상’이라는 한마디로 합치지 마세요. IPv6를 사용한다면 주소 계열과 라우팅이 제대로 구성되었는지도 확인하세요.

UDP, 연결 유지 패킷, MTU의 고려 사항

WireGuard는 UDP로 터널 데이터를 전송하므로 현재 네트워크에서 클라이언트와 엔드포인트 간의 데이터 송수신이 허용되어야 합니다. 일정한 조건에서는 엔드포인트 변경에 대응할 수 있지만, 연결 복구는 네트워크 주소 매핑과 서버 접근성에 영향을 받습니다. 일부 환경에서는 NAT 매핑을 유지하기 위해 주기적인 연결 유지 패킷이 필요할 수 있습니다. 이런 패킷은 주기적으로 전송되므로 ‘안정성을 높이기 위해’ 간격을 무조건 줄이지 마세요. iPhone 화면 잠금과 셀룰러 사용 중에는 추가 활성화가 배터리에 영향을 줄 수 있으므로 서버 설정에 필요한 최소한의 동작만 사용하세요.

MTU는 터널에서 처리할 수 있는 데이터 패킷 크기를 정합니다. 캡슐화에도 공간이 필요하므로 경로에서 큰 패킷을 제대로 처리하지 못하면 작은 요청은 정상인데 큰 콘텐츠 전송은 멈출 수 있습니다. 다만 이런 증상은 다른 원인으로도 발생하므로 다운로드가 느리다고 바로 MTU를 바꾸지 마세요. 기존 값을 유지하고 패킷 크기와 관련된 문제인지 먼저 확인한 뒤 서버 및 경로 조건에 맞춰 조정하세요. 여러 기기에서 설정을 공유하더라도 한 기기에서 효과가 있었던 값을 모든 네트워크의 표준으로 간주하지 마세요.

iOS에서 WireGuard를 평가할 때는 지속 전송, 장시간 대기, 네트워크 전환 후 복구를 각각 관찰하세요. 암호화와 핸드셰이크 설계는 간결하지만, 기기의 배터리 소모는 신호 품질과 연결 유지 방식에 더 크게 좌우될 수 있습니다. 주기적인 백그라운드 작업이 없는 테스트와 지속 전송 테스트는 직접 비교할 수 없습니다. 기존 내부 네트워크 대역에 접속하는 용도라면 대역 범위와 DNS 조회를 우선 확인하세요. 일반 요청을 전달하는 용도라면 현재 Shadowrocket 규칙 설정과 어떻게 함께 동작하는지도 이해해야 합니다.

WireGuard는 사용자가 명확한 터널 설정과 접속 대상을 이미 보유한 경우에 선택해야 하며, 한 번의 처리량 결과만으로 결정하지 마세요. 문제 기록에는 엔드포인트 접근 가능 여부, 핸드셰이크 성공 여부, 실패한 주소 범위만 적으면 충분합니다. 개인 키를 공개 자료에 포함하지 마세요. 설정을 다른 기기로 옮길 때는 서버에서 동일한 신원을 사용하는 방식을 허용하는지 확인하세요. 같은 설정을 두 기기에서 동시에 사용하면 재현하기 어려운 연결 변화가 발생할 수 있습니다.

07 / HYSTERIA2

Hysteria2: 처리량보다 먼저 UDP 경로를 확인하세요

QUIC 기반 설계와 불안정한 네트워크의 고려 사항

Hysteria2는 QUIC 기반 전송 프로토콜로, QUIC는 UDP 위에서 동작하며 최신 보안 핸드셰이크 방식을 함께 사용합니다. 일정한 패킷 손실, 지연, 대역폭 조건에서 전송 효율을 유지하면서 프록시 요청을 전달하도록 설계되었습니다. 그렇다고 모든 네트워크에서 더 빠른 것은 아닙니다. UDP 사용 가능 여부, 경로에서 UDP 속도를 제한하는지, 서버 부하와 혼잡 제어 방식에 따라 실제 결과가 달라집니다. 프로토콜을 비교하기 전에 네트워크가 기본 전송 조건을 충족하는지 확인하세요.

QUIC는 하나의 연결에서 여러 스트림을 구성해 전송 계층의 헤드 오브 라인 블로킹 영향을 일부 줄일 수 있지만, 모든 스트림은 실제 경로와 혼잡 제어에 사용할 수 있는 대역폭을 공유합니다. 무선 네트워크에서 패킷 손실이 심하면 어떤 신뢰성 있는 전송 방식이든 손실된 데이터를 복구해야 합니다. 프로토콜이 가용 대역폭을 만들어낼 수는 없습니다. 지속 전송 성능이 좋아도 짧은 요청의 첫 응답까지 항상 빠른 것은 아닙니다. ‘특정 조건에서 성능을 개선할 수 있다’와 ‘모든 조건에서 앞선다’를 구분하고 프로토콜 이름만으로 결론 내리지 마세요.

인증, TLS, 선택적 난독화를 각각 확인하세요

설정을 구성할 때 서버 주소와 포트는 엔드포인트를 찾고, 인증 정보는 사용 권한을 확인하며, TLS 서버 이름과 인증서는 원격 서버의 신원을 검증합니다. 원래 설정에 난독화 유형과 비밀번호가 추가로 필요하다면 양쪽 설정이 일치해야 합니다. 난독화 비밀번호는 인증 비밀번호의 다른 이름이 아니며 인증서 이름 입력란에 넣어서는 안 됩니다. 필수 정보가 하나라도 빠져 있다면 기존 구독이나 서버 안내를 확인하세요. 다른 프로토콜에서 쓰던 설정 관행을 가져와 임의로 조합하지 마세요.

인증서 검증 원칙은 다른 TLS 설정과 같습니다. 이름이 일치하고 인증서가 유효하며 기기 시간이 정확해야 합니다. UDP 연결이 가능하다는 것은 하위 네트워크 조건만 충족했다는 뜻이지 보안 핸드셰이크와 인증까지 성공했다는 뜻은 아닙니다. 네트워크 전환 후 연결이 복구된다면 현재 경로에서 같은 포트의 데이터 왕복이 계속 허용되는지 확인하세요. 모든 네트워크에서 실패한다면 서버 상태와 설정값을 점검하세요. QUIC를 사용한다고 인증서 확인을 건너뛰거나 핸드셰이크 오류를 일반적인 지연으로 취급하지 마세요.

일부 서버에서는 업로드 또는 다운로드 대역폭 정보를 입력해야 합니다. 이런 값은 혼잡 제어와 전송 동작에 영향을 줄 수 있으므로 사용자에게 보여 주는 장식용 숫자가 아니며, 크게 입력한다고 속도가 빨라지는 제한 해제 항목도 아닙니다. 실제 회선 성능과 서버 안내에 따라 단위까지 확인해 입력하세요. 모바일 네트워크의 가용 대역폭은 위치와 신호에 따라 달라집니다. 실제보다 높게 설정하면 대기열, 패킷 손실, 다른 앱과의 대역폭 경쟁이 늘어날 수 있고, 너무 낮게 설정하면 처리량이 제한될 수 있으므로 안정적인 조건에서 신중하게 테스트하세요.

iPhone에서 속도, 발열, 네트워크 전환 후 복구를 따로 테스트하세요

지속 다운로드를 평가할 때는 크기와 출처가 비슷한 콘텐츠를 선택하고 완료 시간과 전송 중단 여부를 기록하세요. 시작 후 몇 초간의 순간 속도만 보면 캐시, 순간적인 전송량, 무선 네트워크 스케줄링의 영향을 받을 수 있습니다. 백그라운드에서 다른 데이터 전송이 진행 중이라면 결과는 해당 설정만의 성능을 나타내지 않습니다. 테스트 뒤에는 일반적인 페이지, 메시지, 미디어 요청도 확인하세요. 실제 사용의 안정성을 희생해 대용량 파일 처리량만 높이지 말고, 한 번 성공한 결과를 장기적인 안정성 보장으로 여기지 마세요.

배터리 측면에서는 처리량이 높으면 전송 시간이 짧아질 수 있지만, 높은 부하가 지속되면 프로세서와 무선 모듈의 활동이 늘어날 수도 있습니다. 최종 결과는 작업 부하에 따라 달라집니다. 네트워크 상태가 좋지 않으면 잦은 재전송과 핸드셰이크 재설정이 배터리 소모에 영향을 줍니다. 같은 작업을 완료하는 데 걸린 시간, 발열, 배터리 변화를 함께 비교하고 단위 시간당 전송한 데이터만 비교하지 마세요. 짧은 시간의 배터리 백분율 변화는 측정 단위가 거칠어 정확한 프로토콜별 소비 전력 결론을 내릴 수 없습니다. 정밀한 측정이 아닌 추세 파악에 활용하세요.

QUIC에는 연결 마이그레이션 관련 설계가 있지만, 실제 복구 결과는 양쪽 구현, 네트워크 주소 매핑, 경로 변화에 영향을 받습니다. Wi-Fi에서 셀룰러 네트워크로 전환해도 연결이 절대 끊기지 않는다고 이해하지 마세요. 통제된 조건에서 한 번 전환하며 기존 작업이 복구되는지와 새 요청이 성공하는지 관찰하세요. 기존 작업만 중단된다면 해당 서비스 자체의 복구 방식을 따로 확인해야 합니다. 네트워크를 짧은 간격으로 여러 번 바꾸면 어느 전환에서 문제가 생겼는지 판단하기 어렵습니다.

Hysteria2를 테스트하려면 기존 서버에서 일치하는 설정을 제공하고 UDP 경로를 사용할 수 있어야 하며, 실제 용도에 맞춰 전송 성능을 비교할 필요가 있어야 합니다. 주로 가벼운 웹페이지를 보는 용도라면 최고 속도보다 안정성과 복구 시간이 더 중요할 수 있습니다. 이미 정상 작동하는 설정을 기준으로 보관하고 항목별로 테스트한 뒤 일상적으로 사용할 설정을 정하세요. 성능처럼 보이는 매개변수라고 해서 측정 근거 없이 여러 값을 동시에 바꾸지 마세요.

08 / VERIFICATION & DIAGNOSIS

실제 적용: 프로토콜 확인부터 규칙 검증까지

언제든 되돌릴 수 있는 기준 설정을 먼저 만드세요

문제 해결을 시작하기 전에 원래 구독 항목이나 직접 추가한 설정을 보존하고, 현재 네트워크, 기본 서버, Global Routing 모드를 기록하세요. 구독이 정상적으로 업데이트되었는지 확인하고 구독의 원래 항목과 예전 수동 항목을 구분하세요. 이름이 같아도 설정값은 다를 수 있습니다. 다음으로 Home에서 테스트할 서버를 선택하고 시스템 안내에 따라 필요한 권한을 승인한 뒤 연결을 테스트하세요. 한 번에 명확한 항목 하나만 선택하면 설정을 바꿨지만 실제로는 다른 서버를 테스트하는 상황을 피할 수 있습니다.

Global Routing의 세 가지 모드는 설정 Config, 프록시 Proxy, 직접 연결 Direct입니다. Config는 현재 설정의 규칙에 따라 요청을 처리하고, Proxy는 해당 트래픽을 선택된 프록시 경로로 보내며, Direct는 직접 연결합니다. 모드에 따라 요청 처리 방식은 달라지지만 서버 프로토콜이 변환되지는 않습니다. 문제를 해결하는 동안 모드를 일시적으로 비교할 수 있지만 테스트 후에는 원래 필요한 모드로 되돌리세요. Direct에서도 실패한다면 프록시 비밀번호를 계속 바꾸기보다 기기 네트워크와 대상 자체를 확인하세요.

가장 먼저 실패한 계층을 찾아보세요

먼저 서버 주소가 올바르게 조회되는지, 현재 네트워크에서 해당 포트에 연결할 수 있는지 확인하세요. 다음으로 TLS 또는 다른 보안 핸드셰이크를 점검하고, 프로토콜 인증을 확인한 뒤 대상 요청과 규칙을 살펴보세요. 가장 먼저 실패한 계층을 우선 해결해야 합니다. 그 이후 계층에 대해서는 아직 확실한 결론을 내릴 수 없습니다. 예를 들어 인증서 핸드셰이크가 성공하지 않았다면 프록시 인증이 유효한지 판단할 수 없습니다. 프록시 인증이 성공해도 특정 내부 네트워크 대역의 응답 경로가 올바르다는 뜻은 아닙니다.

Connectivity Test는 선택한 항목의 특정 연결 결과를 확인하는 데 도움이 되지만 모든 대상, 주소 계열, 앱 동작을 테스트하지는 않습니다. 테스트는 통과했는데 웹페이지에 문제가 있다면 DNS 조회, 대상 인증서, 라우팅을 계속 확인하세요. 테스트가 실패했더라도 실제 서비스에서도 동일하게 실패하는지 확인해 단일 테스트 대상의 문제를 프로토콜 오류로 확대하지 않도록 하세요. 올바른 결론에는 테스트 범위를 밝혀야 하며, 한 번 성공한 결과를 모든 기능이 정상이라는 뜻으로 기록해서는 안 됩니다.

규칙 검증과 프로토콜 검증을 따로 진행하세요

다음 예시는 Shadowrocket 설정 파일의 규칙 구조를 설명하며 서버 정보, 인증 정보, 바로 사용할 수 있는 구독을 포함하지 않습니다. 도메인은 예시 값이므로 실제로 구성하기 전에 용도에 맞게 각 규칙을 확인하세요. 규칙은 순서대로 적용되며 앞쪽 규칙에 일치하는 항목은 뒤쪽 처리에 영향을 줍니다. 마지막의 FINAL은 앞선 규칙에 일치하지 않은 요청을 처리합니다. 여기서 PROXY와 DIRECT는 처리 동작이며 서버 프로토콜 이름이나 연결을 다른 프로토콜로 변환하는 명령이 아닙니다.

[Rule]
DOMAIN-SUFFIX,example.com,PROXY
DOMAIN-KEYWORD,example,PROXY
GEOIP,CN,DIRECT
FINAL,PROXY

Proxy 모드에서는 대상에 접속되지만 Config 모드에서는 실패한다면 해당 대상에 어떤 규칙이 적용되는지, 예상한 DNS 결과를 얻는지, 설정에서 어떤 프록시 경로를 선택했는지 확인하세요. 바로 프로토콜을 바꾸지 마세요. 두 테스트가 애초에 같은 경로를 사용하지 않았을 수 있습니다. GEOIP는 IP 주소 위치 데이터베이스를 기준으로 일치 여부를 판단하며 특정 도메인에 대한 의도를 정확히 대체하지 못합니다. 도메인 규칙과 주소 규칙이 함께 있다면 특정 키워드가 있는지만 보지 말고 규칙 순서와 DNS 조회 조건을 확인하세요.

마지막으로 용도에 맞춰 선택하세요. 일반 웹페이지는 첫 응답과 안정성, 지속 전송은 완료 시간과 재전송, 실시간 서비스는 UDP 조건과 지연 변동, 내부 네트워크 접근은 라우팅 범위와 DNS 조회가 중요합니다. 기존 서버에서 사용할 수 있는 여러 방법을 제공하는 경우에만 프로토콜 비교가 의미가 있습니다. 모든 네트워크와 용도에 적용되는 고정 순위는 없으며 단기 테스트 결과만으로 특정 프로토콜의 장단점을 영구적으로 단정해서도 안 됩니다.

도움을 요청할 때는 프로토콜 유형, 전송 방식, 문제가 발생한 네트워크, 오류가 발생한 단계, 이미 완료한 개별 테스트를 정리하세요. 비밀번호, UUID, 개인 키, 구독에 포함된 식별 정보는 숨기고 문제 해결에 필요한 설정 구조만 공유하세요. 자주 발생하는 증상은 자주 묻는 질문에서 확인하고, 가져오기부터 연결까지 다시 살펴보려면 사용 안내로 돌아가세요. 모든 유형을 무작정 시험하는 것보다 언제든 되돌릴 수 있고 재현 가능한 유효 설정을 마련하는 편이 더 유용합니다.