Shadowrocket 프로토콜 기술 가이드

01 / 선택 기준

프로토콜, 전송 방식, 라우팅을 구분하세요

프로토콜 유형은 먼저 호환성을 결정하고, 성능은 그다음에 고려해야 합니다. 서버가 Trojan을 사용한다면 클라이언트도 Trojan을 선택해야 합니다. 유형을 Hysteria2로 바꾼다고 같은 포트에서 다른 프로토콜 연결을 자동으로 받아들이지는 않습니다. 구독을 가져오면 대개 유형, 주소, 포트, 인증 정보가 함께 설정됩니다. 직접 편집할 때는 서버 제공 정보에 따라야 합니다. 사용할 수 있는 정보가 한 세트뿐이라면 최신처럼 보이는 이름을 목록에서 찾기보다 해당 정보를 정확히 반영하는 것이 우선입니다.

연결은 최소 네 가지 계층의 조건으로 구성됩니다

첫째는 주소에 도달할 수 있는지 여부입니다. 도메인 이름 확인, 대상 포트, 현재 네트워크에서 해당 트래픽을 허용하는지 등이 포함됩니다. 둘째는 TCP, UDP 기반 QUIC, TCP 위의 WebSocket 같은 전송 방식입니다. 셋째는 비밀번호, UUID, TLS 인증서, 키 등의 프로토콜 인증 및 암호화 조건입니다. 넷째는 애플리케이션의 대상과 라우팅 정책입니다. 앞 단계가 실패하면 뒷 단계는 대개 실행되지 않습니다. 따라서 규칙이 제대로 적용된다고 해서 서버 핸드셰이크까지 성공했다는 뜻은 아닙니다.

각 계층은 함께 구성될 수 있지만 임의로 서로 바꿀 수는 없습니다. 일부 VMess 또는 VLESS 구성에는 TLS와 WebSocket이 추가되며, 일반적인 Trojan 구성은 TLS를 사용하고 Hysteria2는 QUIC을 기반으로 합니다. 가져온 설정에 Type, TLS, Host, Path가 함께 있다고 해서 네 가지 프로토콜 중 하나를 선택해야 하는 것은 아닙니다. 한 연결에 필요한 여러 조건을 모두 충족해야 한다는 의미입니다. 이름이 같은 필드라도 뜻이 다를 수 있으므로 해당 프로토콜의 맥락에서 확인하세요.

속도, 배터리, 개인정보 보호는 서로 다른 지표입니다

속도에는 첫 연결까지 걸리는 시간, 소규모 요청 응답 시간, 지속 처리량 등이 포함됩니다. 대용량 파일은 빠르게 다운로드하더라도 핸드셰이크, 도메인 확인 또는 우회 경로 때문에 웹페이지 첫 화면은 늦게 표시될 수 있습니다. 배터리 소모에는 무선 신호 상태, 재전송, 백그라운드 연결 유지, 기기 온도도 영향을 줍니다. 한 번의 Connectivity Test 결과로 하루 종일의 사용 경험을 판단하거나 프로토콜 이름만으로 고정된 배터리 소모 순위를 매길 수는 없습니다. 비교할 때는 서버 지역, 네트워크, 테스트 작업을 최대한 동일하게 유지하세요.

암호화가 적용되는 범위도 따로 이해해야 합니다. 클라이언트와 프록시 서버 사이의 보호가 프록시 서버와 모든 대상 웹사이트 사이의 연결까지 자동으로 암호화한다는 뜻은 아닙니다. 웹사이트 자체의 HTTPS도 여전히 중요합니다. 서버가 확인할 수 있는 연결 정보는 프로토콜, 대상 트래픽, DNS 경로에 따라 달라집니다. 이 문서에서는 올바른 설정과 해석 가능한 성능을 다루며, 특정 프로토콜이 모든 상황에서 개인정보를 보장한다고 설명하지 않습니다.

Shadowrocket에서 되돌릴 수 있는 기준 설정을 유지하세요

수정하기 전에 구독 내 항목, 현재 Type, 주요 설정을 기록하고 Config를 백업하세요. 구독 항목은 업데이트 과정에서 다시 생성될 수 있으므로 직접 수정한 설정이 덮어써지는지 확인해야 합니다. 테스트용 복사본은 일상적으로 사용하는 항목과 구분하세요. 로그나 스크린샷을 공유할 때는 비밀번호, UUID, 개인 키, 구독 주소를 가리고, 문제 해결에 필요한 필드명과 오류 단계, 일부 정보를 처리한 호스트 정보만 남기세요. 정상 작동이 확인된 기준 설정을 먼저 마련해야 이후 비교가 가능합니다.

02 / 비밀번호 및 암호화 방식

Shadowsocks: 간결한 설정 절차

Shadowsocks는 클라이언트와 서버 사이에 보호된 중계 연결을 만드는 경량 암호화 프록시로 설계되었으며, 완전한 가상 네트워크 관리는 담당하지 않습니다. 일반적으로 주소, 포트, 비밀번호, 암호화 방식이 필요해 설정 절차가 비교적 간단합니다. 여기서 ‘경량’은 구조를 설명하는 말이지 모든 네트워크에서 더 빠르다는 뜻도, 모든 Shadowsocks 구성이 서로 호환된다는 뜻도 아닙니다. 암호화 방식, 확장 기능, UDP 지원 여부가 양쪽에서 일치해야 합니다.

Method와 Password를 함께 확인하세요

Method는 데이터 암호화 및 인증 방식을 결정하는 항목이지, 취향에 따라 바꾸는 성능 설정이 아닙니다. 서버가 특정 AEAD 방식을 사용한다면 클라이언트도 같은 방식과 비밀번호를 설정해야 합니다. AEAD는 암호화와 무결성 검증을 함께 제공하므로 데이터가 변경되거나 키가 일치하지 않으면 연결이 실패할 수 있습니다. 이때 알기 쉬운 ‘비밀번호 오류’ 화면이 나타나지 않을 수도 있습니다. 핸드셰이크 중단을 네트워크 속도 탓으로만 돌리면 가장 기본적인 설정 확인을 놓칠 수 있습니다.

암호화 방식에 따라 필요한 키 자료가 다를 수 있습니다. 일반 비밀번호에서 키를 파생하는 방식도 있고, 특정 길이와 인코딩 형식의 키를 요구하는 방식도 있으므로 Password를 임의로 바꿔 쓸 수 있는 짧은 문구로 취급하면 안 됩니다. 복사할 때 줄바꿈, 전각 문자, 앞뒤 공백이 들어가지 않도록 확인하세요. 가져오기 링크에 인코딩된 데이터가 있으면 클라이언트에서 처리하도록 하고, 눈에 보이는 문자열을 직접 다시 조합하지 마세요. 구독을 문제없이 읽어 들였더라도 서버 설정이 변경되지 않았는지 확인해야 합니다.

TCP가 된다고 UDP까지 되는 것은 아닙니다

Shadowsocks의 TCP 및 UDP 전달은 서로 다른 데이터 경로를 사용합니다. 웹페이지가 열린다는 것은 해당 TCP 요청이 처리되었다는 뜻일 뿐입니다. 음성 통화, 게임, 일부 DNS 요청은 UDP 전달 조건이 충족되지 않아 실패할 수 있습니다. 노드의 UDP 지원 여부, 클라이언트 관련 설정, 서버의 수신 대기 상태, 네트워크 허용 여부를 함께 확인하세요. 현재 작업에서 UDP를 사용하지 않았다면 그 테스트만으로 UDP 지원 여부를 판단할 수 없습니다.

‘애플리케이션이 UDP를 사용한다’는 것과 ‘프로토콜이 UDP로 서버에 연결된다’는 것도 구분해야 합니다. 일부 프록시 프로토콜은 애플리케이션 데이터를 다른 전송 방식으로 전달할 수 있으므로 둘은 일대일로 대응하지 않습니다. Shadowsocks 문제를 해결할 때는 웹페이지 접속 실패인지, UDP 서비스 실패인지, 모든 트래픽이 실패하는지 구체적으로 기록하세요. ‘노드가 안 된다’고만 적으면 서로 다른 문제가 뒤섞여 원인을 찾기 어려워집니다.

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

수동 입력 시 확인할 설정이 적다는 것은 설정 절차가 비교적 단순하다는 뜻입니다. 그렇더라도 모바일 기기의 사용 경험은 서버 부하와 무선 연결 상태에 영향을 받습니다. 기기가 해당 알고리즘에 적합한 하드웨어를 갖췄다면 암호화에 드는 비용이 낮을 수 있지만, 일상적인 배터리 소모에는 지속적인 전송, 약한 신호, 재전송이 더 큰 영향을 주는 경우가 많습니다. CPU 알고리즘만 따지면서 같은 장소에서의 셀룰러 신호와 Wi-Fi 차이를 간과하지 마세요.

서버가 지원하는 Shadowsocks 설정이 명확하고 일반적인 TCP 앱을 안정적으로 사용하는 것이 목적이라면, 이를 기준 설정으로 삼을 수 있습니다. 오랫동안 연결을 사용하지 않은 뒤 첫 요청만 실패한다면 연결이 정리되었는지, 도메인 확인 결과가 바뀌었는지, 서버 상태에 문제가 있는지 구분하세요. 바로 Method를 바꾸지는 마세요. 배포 환경에서 추가 기능이 필요하다면 현재 클라이언트에 해당 설정 항목이 있는지 확인하세요. 항목이 없으면 본인의 서비스 제공자에게 문의하고, 다른 프로토콜의 Host나 Path를 그대로 가져오지 마세요.

03 / 인증과 전송 방식 구분

VMess / VLESS: 유형이 비슷해도 서로 바꿔 쓸 수 없습니다

VMess는 사용자 인증, 프록시 요청, 데이터 보호를 하나의 프로토콜 체계로 구성하고 여러 전송 방식을 지원합니다. VLESS는 프로토콜 계층을 더 간결하게 설계하고, 연결 보호는 외부 보안 계층이나 해당 배포 방식에 더 많이 맡깁니다. 둘 다 사용자 식별에 UUID를 사용하는 경우가 많아 Type만 바꾸면 서로 전환할 수 있다고 생각하기 쉽습니다. 하지만 서버 수신 유형과 함께 사용하는 전송 방식이 일치해야 하며, UUID가 같아도 프로토콜이 다르면 해결되지 않습니다.

UUID는 서버 주소나 전송 설정이 아닙니다

UUID는 사용자를 식별하는 인증 정보이므로 끝까지 정확히 복사해야 하며, 길다는 이유로 일부를 지우거나 바꾸면 안 됩니다. Address와 Port는 연결 지점을 지정하고, UUID는 사용할 사용자 신원을 지정합니다. TLS, WebSocket 등의 설정은 해당 요청을 어떤 방식으로 전달할지 결정합니다. 문제 해결 시 이 항목들을 나누어 기록하면 UUID를 계속 다시 붙여 넣으면서 실제 연결 포트를 확인하지 않는 상황을 피할 수 있습니다.

VMess 인증 메커니즘은 시간의 영향을 받으므로 기기 시간이 크게 어긋나면 연결 문제가 생길 수 있습니다. 관련 고급 설정을 임의로 바꾸기보다 먼저 시스템에서 시간 자동 설정을 켜고 시간대를 확인하세요. 구독에 추가 필드가 포함되어 있으면 서버의 현재 설정에 맞춰 유지해야 합니다. 과거 튜토리얼의 기본값을 복사하면 가져오기는 되지만 연결은 실패할 수 있습니다. VLESS도 인증이 생략되는 모드가 아닙니다. 인증은 여전히 필요하며 프로토콜 구성 방식이 다를 뿐입니다.

WebSocket의 Host와 Path가 중요한 이유

서버가 WebSocket으로 요청을 받는 경우 Path는 접속 경로 일치에 사용되는 경우가 많고, Host는 HTTP 호스트 라우팅에 사용될 수 있습니다. Path의 대소문자, 앞의 슬래시, 경로 내용은 서버 설정과 일치해야 합니다. Host에 임의의 웹사이트 도메인을 넣는다고 속도가 빨라지는 것도 아닙니다. 서버가 WebSocket을 사용하지 않는데 이를 켜면 정상적인 연결이 호환되지 않는 요청으로 바뀔 수 있습니다.

TLS의 Server Name은 일반적으로 서버 이름 표시와 인증서 이름 확인에 사용되며 WebSocket의 Host와 같다고 단정할 수 없습니다. 여러 배포 환경에서 두 값이 같더라도 담당하는 계층은 다릅니다. Address는 IP 주소일 수 있지만 Server Name은 인증서에 해당하는 도메인일 수 있습니다. 둘 다 같은 도메인을 사용하기도 합니다. 서버에서 명시한 조합대로 입력하고, 값이 중복돼 보인다는 이유로 항목을 삭제하지 마세요.

속도와 배터리는 실제 조합을 기준으로 평가하세요

‘VMess 속도’는 단일한 고정값이 아닙니다. 같은 프로토콜이라도 직접 TCP를 사용하는지, WebSocket을 사용하는지, 추가 중계가 있는지에 따라 핸드셰이크 횟수와 경로가 달라질 수 있습니다. 첫 접속은 느리지만 연결 후 다운로드는 정상이라면 암호화 알고리즘이 처리량을 낮춘다고 바로 결론 내리기보다 DNS, TLS, 전송 진입점을 확인하는 것이 좋습니다. 추가 캡슐화는 바이트와 처리 작업을 늘릴 수 있지만 실제 네트워크에서 항상 가장 큰 병목이 되는 것은 아닙니다.

VLESS의 프로토콜 계층이 간결하다고 해서 배터리를 더 적게 쓴다고 보장할 수는 없습니다. 서버가 더 멀리 있거나 무선 네트워크에서 재전송이 많다면 프로토콜 처리량 절감은 연결 비용에 상쇄될 수 있습니다. 둘을 비교할 때는 서버 조건과 앱 작업을 최대한 비슷하게 맞추고 첫 요청, 연속 접속, 백그라운드 복귀를 각각 기록하세요. 연결 전후 한 번씩 측정한 결과만으로 하루 종일의 사용을 판단할 수 없습니다.

가져온 뒤 우선 확인할 항목

Home에서 해당 항목의 편집 화면을 열고 Type, Address, Port, UUID 순으로 확인한 다음 전송 방식, TLS, Host, Path 및 서버에서 요구하는 항목을 살펴보세요. 한 번에 하나씩 바꾸고 매번 새 연결을 만들어야 이전 세션이 결과에 영향을 주지 않습니다. 같은 구독의 여러 항목에서 인증 오류가 발생한다면 구독 업데이트 여부와 기기 시간을 먼저 확인하세요. 특정 접속 지점만 실패한다면 그 지점에만 적용되는 경로와 인증서 설정을 우선 점검합니다.

04 / 인증서 및 사용자 인증

Trojan: TLS 조건을 빠짐없이 확인하세요

일반적인 Trojan 구성은 TLS 연결로 프록시 요청을 전달하고 비밀번호로 사용자를 식별합니다. 검증된 TLS 메커니즘을 사용해 클라이언트와 서버 사이의 보호된 연결을 설정하므로 인증서, 이름, 시간도 연결 조건에 포함됩니다. 설정 화면에는 주소, 포트, 비밀번호만 보일 수 있지만 TLS를 무시해도 된다는 뜻은 아닙니다. ‘비밀번호가 맞는데도 연결되지 않는’ 문제 중 상당수는 서버가 비밀번호를 확인하기도 전에 발생합니다.

Address, Server Name, 인증서를 이해하기

Address는 서버를 찾는 데 사용되고, Server Name은 일반적으로 TLS의 서버 이름 표시와 인증서 확인에 영향을 줍니다. 서버는 이름에 따라 해당 인증서와 사이트 진입점을 선택할 수 있습니다. 클라이언트는 받은 인증서가 신뢰할 수 있는지, 유효 기간 내인지, 대상 이름을 포함하는지 확인해야 합니다. Address를 IP로 바꾸면서 올바른 Server Name을 유지하지 않으면 서버에는 연결되더라도 인증에 실패할 수 있습니다.

인증서 도메인 불일치, 불완전한 인증서 체인, 잘못된 기기 시간은 모두 TLS 핸드셰이크 오류로 나타날 수 있습니다. 문제 해결 시 먼저 오류가 발생한 단계를 확인하세요. TLS가 완료되지 않았다면 Password를 반복해서 재설정하지 마세요. TLS는 통과했지만 인증이 거부된 경우 비밀번호, 계정 상태, 서버 수신 유형을 확인합니다. 오류 메시지가 충분하지 않다면 같은 항목을 정상 작동이 확인된 네트워크에서 다시 테스트해 네트워크 경로 차이인지 고정된 설정 오류인지 살펴보세요.

검증 건너뛰기를 일반적인 해결 방법으로 사용하지 마세요

인증서 검증은 서버 신원을 확인하는 절차입니다. 검증을 건너뛰면 오류가 일시적으로 사라질 수 있지만 확인 조건도 함께 없어지므로 원래 설정이 해결됐다는 증거가 되지 않습니다. 배포 환경에서 특정 신뢰 자료를 요구한다면 서버에서 제공한 신뢰할 수 있는 안내에 따라 설정하세요. 연결 버튼을 성공으로 표시하려고 이름이나 인증서 오류를 계속 무시해서는 안 됩니다. 오류 내용을 기록하고 서버 인증서 설정을 확인하는 편이 검사를 우회하는 것보다 문제 진단에 도움이 됩니다.

연결 재사용 및 네트워크 전환의 영향

TLS 핸드셰이크에는 비용이 들지만 이미 설정된 세션과 첫 연결은 구분해야 합니다. 브라우저와 앱은 일부 연결을 재사용하고 시스템은 도메인 확인 결과를 캐시할 수 있어 두 번째 페이지가 더 빠르게 열리곤 합니다. 그렇다고 특정 프로토콜에 특별한 가속 기능이 있다고 볼 수는 없습니다. 비교하려면 새 세션으로 시작하는 경우와 연속 접속을 따로 기록하고, 새로 연결한 세션과 미리 연결을 준비한 세션을 비교하지 마세요.

iPhone이 Wi-Fi에서 셀룰러 네트워크로 전환되면 원본 주소와 기존 연결 상태가 바뀝니다. TCP 기반 세션은 대개 다시 연결해야 하므로 페이지가 잠시 멈췄다가 복구되는 것은 정상일 수 있습니다. On Demand는 연결을 언제 시작할지에 영향을 주지만, 기존 TCP 세션이 네트워크 전환 후에도 그대로 유지되도록 하지는 않습니다. 복구되지 않는 현상이 계속되면 시스템 네트워크 권한, 현재 노드, 앱의 재시도 여부를 확인하세요.

사용 조건 및 실제 고려 사항

기존 서버 설정에 TLS 이름, 유효한 인증서, 비밀번호가 명확히 제공된다면 Trojan은 확인 절차가 비교적 분명해 일반적인 웹 및 앱 트래픽을 위한 선택지로 고려할 수 있습니다. TLS를 사용한다고 다른 방식보다 본질적으로 빠른 것도 아니며, 핸드셰이크가 있다는 이유만으로 배터리를 더 많이 쓰는 것도 아닙니다. 약한 신호에서의 반복적인 재연결, 서버 혼잡, 백그라운드 연결 유지는 한 번의 핸드셰이크보다 실제 소모에 더 큰 영향을 줄 수 있습니다.

일부 앱에서만 문제가 발생한다면 프로토콜을 바로 바꾸기보다 앱의 요구 사항을 나누어 확인하세요. 일부 앱은 UDP가 필요하고, 일부는 다른 DNS 결과에 의존하며, 어떤 요청은 Rule에 따라 DIRECT로 전달됩니다. 먼저 해당 요청이 실제로 Trojan 항목을 거치는지 확인한 뒤 서버가 해당 서비스를 지원하는지 살펴보세요. 연결 시간 초과의 일반적인 점검 순서는 지연 시간 테스트, 프로토콜 설정, 시스템 시간 점검에서 확인할 수 있습니다.

05 / 범용 프록시 인터페이스

HTTP / SOCKS5: 전달 기능과 암호화 범위

HTTP 프록시는 애플리케이션 계층의 중계 요구에서 시작되었으며 브라우저와 조직 네트워크에서 흔히 사용됩니다. SOCKS5는 더 범용적인 프록시 협상 및 전달 방식을 제공합니다. 두 방식의 장점은 인터페이스가 명확하고 지원 소프트웨어가 많다는 것이지, 기본적으로 완전한 암호화를 제공한다는 뜻은 아닙니다. 선택하기 전에 클라이언트와 프록시 사이에 TLS 또는 신뢰할 수 있는 네트워크 보호가 있는지, 인증 방식은 무엇인지, UDP 전달이 필요한지 확인하세요. 사용자 이름과 비밀번호만으로는 이러한 사항을 알 수 없습니다.

HTTP CONNECT가 프록시 연결 암호화를 뜻하지는 않습니다

HTTP 프록시는 일반 HTTP 요청을 받을 수 있고, CONNECT를 통해 지정한 대상과의 터널을 만들 수도 있습니다. HTTPS 웹사이트에 접속할 때 웹사이트 TLS는 보통 해당 터널 안에서 설정되지만, 클라이언트와 프록시 사이의 협상 암호화 여부는 별개의 조건입니다. 대상 웹사이트가 HTTPS를 사용한다고 해서 모든 연결 방식에서 프록시 인증 정보가 같은 수준으로 보호되는 것은 아닙니다. 웹사이트 TLS와 프록시 접속 시 사용하는 TLS를 구분하세요.

서버에서 TLS로 보호되는 HTTP 프록시 접속점을 명시적으로 제공한다면 주소, 포트, 인증서 이름, 인증 정보를 그에 맞게 설정해야 합니다. 웹사이트 주소가 HTTPS로 시작한다는 이유만으로 관련 옵션을 선택하지 마세요. 반대로 일반 HTTP 프록시에 클라이언트에서 임의로 TLS를 켠다고 자동으로 보안 연결로 전환되지 않습니다. 양쪽 설정이 다르면 핸드셰이크 실패나 연결 종료가 발생할 수 있습니다.

SOCKS5 인증, DNS, UDP

SOCKS5는 인증 방식을 협상하고 도메인 이름이나 IP 주소로 대상을 지정할 수 있습니다. 도메인을 로컬에서 확인할지 프록시에서 처리할지에 따라 결과와 오류 지점이 달라집니다. 다만 실제 경로는 Shadowrocket의 DNS 설정과 라우팅 동작에도 영향을 받으므로 프로토콜 이름만 확인해서는 충분하지 않습니다. 문제 해결 시 요청에 도메인과 IP 중 무엇이 포함되는지, 로그에 표시된 DNS 확인 및 전달 순서가 어떤지 살펴보세요.

SOCKS5 표준에는 UDP ASSOCIATE가 포함되지만 모든 서버, 계정, 네트워크에서 UDP 전달을 사용할 수 있는 것은 아닙니다. 제어 연결이 설정되더라도 이후 UDP 포트가 현재 네트워크에서 연결 가능하다는 보장은 없습니다. 일반적인 HTTP CONNECT는 보통 TCP 터널에 사용되므로 범용 UDP 기능으로 간주해서는 안 됩니다. 음성 및 실시간 서비스는 실제 서버 기능을 확인해야 하며, ‘프록시 지원’이라는 말만으로 지원 범위를 추정하지 마세요.

모바일 기기에서의 사용 판단

이미 조직 네트워크에서 HTTP 또는 SOCKS5 접속 정보를 제공받았다면 관리 지침에 따라 설정하세요. 프로토콜 이름이 다르다는 이유만으로 직접 바꾸면 안 됩니다. 모바일 네트워크는 자주 전환되고 조직 접속점은 특정 네트워크에서만 허용될 수 있습니다. 사무실 Wi-Fi에서는 되지만 셀룰러 네트워크에서는 안 된다고 해서 클라이언트 비밀번호를 잘못 입력했다고 단정할 수 없습니다. 접속 허용 범위, 주소 확인, 인증 조건을 점검한 다음 프로토콜 처리 비용을 비교하세요.

이 인터페이스는 협상 과정이 비교적 단순할 수 있지만 실제 속도는 서버와 대상 사이의 연결에도 좌우됩니다. 프록시 접속점이 기기 가까이에 있어도 먼 출구를 거쳐야 한다면 응답 시간이 길어질 수 있습니다. 배터리도 ‘프로토콜이 추가 암호화를 하지 않으니 반드시 절약된다’고 결론 내릴 수 없습니다. 연결이 반복해서 끊겨 재시도하면 기기가 더 자주 깨어나며, 잘못된 연결 유지 설정은 연산량 감소 효과를 상쇄할 수 있습니다.

인증이 실패하면 서버에서 요구하는 인증 방식, 사용자 이름 형식, 비밀번호, 계정 권한을 차례로 확인하세요. 도메인 대상만 실패하고 IP 대상은 정상이라면 DNS 경로를 살펴보세요. UDP 서비스만 실패한다면 전달 기능과 네트워크 포트를 확인하세요. 이 세 가지 상황을 각각 기록하면 Global Routing을 자주 바꾸는 것보다 원인을 찾기 쉽습니다.

06 / 3계층 터널

WireGuard: 키, 주소, 라우팅을 함께 확인하세요

WireGuard는 간결한 구조의 3계층 암호화 터널을 만들도록 설계되었습니다. 피어 공개 키로 상대를 식별하고 UDP를 통해 IP 데이터를 전달합니다. 요청 단위로 전달하는 애플리케이션 프록시와는 사용 방식이 다르므로 터널 주소, 피어, 라우팅 범위를 이해해야 합니다. Shadowrocket에서 사용할 때는 WireGuard 피어 설정과 클라이언트 자체 Rule도 구분해야 합니다. 두 설정은 서로 다른 계층에서 작동하며 어느 한쪽이 다른 쪽을 대체하지 않습니다.

Private Key와 Public Key의 방향

Private Key는 현재 피어의 키이므로 안전하게 보관해야 합니다. Public Key는 상대 피어가 현재 피어를 식별할 수 있도록 제공할 수 있습니다. 클라이언트 설정의 상대 Public Key는 서버를 가리켜야 하고, 서버는 클라이언트의 Public Key를 알고 있어야 합니다. 양쪽 공개 키를 바꿔 입력하거나 개인 키를 변경한 뒤 해당 공개 키를 동기화하지 않으면 핸드셰이크가 설정되지 않습니다. 키 문자열은 일반 비밀번호가 아니므로 길이가 비슷하다는 이유로 서로 바꾸면 안 됩니다.

설정에 Preshared Key가 있다면 양쪽에서 함께 사용하는 별도의 인증 정보이므로 양쪽 값이 일치해야 합니다. Endpoint는 원격에서 접속할 주소와 포트이며 터널 내부 주소가 아닙니다. 인터페이스 Address는 기기가 터널 안에서 사용할 주소이므로 Endpoint를 그대로 복사해서도 안 됩니다. 서버에서 피어별로 허용 주소를 제한할 수 있으므로 ‘핸드셰이크는 성공했지만 데이터가 통하지 않는’ 경우에도 주소 할당을 확인해야 합니다.

Allowed IPs와 Rule의 역할은 무엇인가요?

WireGuard에서 Allowed IPs는 피어 선택과 수신 출처 제한에 관여하며, 일반 프록시의 도메인 규칙과는 의미가 다릅니다. 어떤 트래픽을 터널로 전달할지는 클라이언트 통합 방식에도 달려 있으므로 전체 네트워크 대역이 보인다고 해서 Shadowrocket의 모든 요청이 반드시 WireGuard를 거친다고 볼 수 없습니다. 먼저 Global Routing과 Rule에서 어떤 정책을 선택했는지 확인한 다음, WireGuard에 전달된 트래픽이 피어 설정에 맞는지 살펴보세요.

터널로 내부 네트워크에 접속해야 한다면 해당 네트워크 대역이 현재 Wi-Fi의 로컬 주소와 겹치지 않는지 확인하세요. 집과 원격 네트워크에서 같은 사설 주소 대역을 사용하면 라우팅 판단이 모호해질 수 있습니다. 실제 네트워크 구성에 따라 조정하고, 모든 로컬 네트워크를 원격으로 보내지 마세요. 그러면 LAN 기기 접속이나 로컬 DNS 동작이 바뀔 수 있습니다.

Keepalive 및 모바일 네트워크에서의 배터리 고려 사항

Persistent Keepalive는 NAT 매핑을 유지하는 데 쓰이며 다운로드 속도를 높이는 스위치가 아닙니다. 외부에서 먼저 접속해야 하거나 네트워크가 유휴 매핑을 빠르게 정리하는 경우 도움이 될 수 있습니다. 하지만 Keepalive를 자주 보내면 무선 모듈이 더 자주 동작할 수 있습니다. 주로 앱을 전면에서 사용할 때는 근거 없이 Keepalive 주기를 지나치게 짧게 설정하지 마세요. 먼저 유휴 상태에서 다시 연결할 때 실제 문제가 있는지 확인하세요.

WireGuard는 유효한 인증 데이터를 바탕으로 피어 주소를 갱신할 수 있어 일정 범위의 주소 변경에 대응하지만, 모든 상위 애플리케이션 세션이 네트워크를 전환해도 끊김 없이 유지된다는 뜻은 아닙니다. Wi-Fi와 셀룰러 네트워크 사이를 전환한 뒤 새 UDP 경로에 연결할 수 있는지, NAT 매핑이 갱신되는지, 앱이 다시 요청하는지가 복구에 영향을 줍니다. 먼저 핸드셰이크와 송수신 상태를 확인한 뒤 터널 계층과 앱 계층 중 어디에서 멈췄는지 판단하세요.

MTU는 클수록 좋은 것이 아닙니다

터널 캡슐화에는 추가 바이트가 필요하며 실제 경로에서 허용되는 패킷 크기가 로컬 인터페이스의 최대값보다 작을 수 있습니다. MTU가 맞지 않으면 작은 요청은 정상인데 큰 응답은 멈추거나 일부 웹사이트가 계속 로딩될 수 있습니다. 서버 부하와 패킷 손실을 먼저 확인한 다음 배포 지침에 따라 변경 내용을 기록하며 조정하세요. 한 번에 하나의 값만 바꾸고 같은 작업으로 다시 테스트하세요. 다른 네트워크의 값을 그대로 복사하지 말고 대용량 파일이 느려지는 모든 현상을 MTU 문제로 돌리지 마세요.

완전한 WireGuard 설정이 있고 명확한 터널 네트워크 대역이나 지속 연결이 필요한 경우 원래 설정을 기준으로 연결할 수 있습니다. 일반 프록시 구독 정보만 있다면 키, 인터페이스 주소, 라우팅을 임의로 추정할 수 없습니다. 선택은 서버의 실제 기능과 작업 방식에 따라야 하며, ‘3계층 터널’이 애플리케이션 프록시보다 무조건 더 앞선 방식이라는 뜻은 아닙니다.

07 / QUIC 및 혼잡 제어

Hysteria2: 먼저 UDP 경로를 확인하세요

Hysteria2는 QUIC 기반으로 프록시 트래픽을 전달하며 패킷 손실이나 긴 왕복 시간 등의 조건에서 연결 성능을 고려합니다. QUIC은 UDP 위에서 실행되며 TLS 기반 보안 핸드셰이크와 다중 스트림 전송을 통합합니다. 이 설계는 단일 TCP 바이트 스트림과 다른 처리 방식을 제공하지만 실제 이점은 네트워크 조건에 따라 달라집니다. 현재 네트워크에서 해당 UDP 트래픽을 허용하지 않는다면 혼잡 제어만으로 기본 연결 문제를 해결할 수 없습니다.

다중 스트림은 어떤 대기 시간을 줄이나요?

단일 TCP 연결에서 앞쪽 데이터가 손실되면 이를 다시 채우기 전까지 뒤의 바이트도 순서대로 전달되지 않습니다. QUIC은 서로 다른 스트림의 데이터가 비교적 독립적으로 전달되도록 해 스트림 간 순서 대기를 줄일 수 있습니다. 하지만 같은 스트림 안에서는 여전히 신뢰성 있는 전송이 필요하고 여러 스트림은 기본 네트워크 용량을 공유합니다. ‘다중 스트림’이 패킷 손실의 영향을 없애거나 모든 웹페이지를 더 빠르게 만든다고 이해하면 안 됩니다.

QUIC에는 암호화, 혼잡 제어, 패킷 처리도 필요합니다. 모바일 기기의 연산 및 깨우기 비용은 구현과 작업에 따라 달라집니다. 신호가 약해 재전송이 많으면 배터리 소모가 늘 수 있고, 일부 고속 작업은 더 빨리 끝나 지속 전송 시간이 짧아질 수도 있습니다. 따라서 짧은 요청, 장시간 다운로드, 대기 후 복구를 각각 비교하세요. 한 번의 다운로드 최고 속도만으로 하루 종일 배터리가 절약된다고 결론 내리지 마세요.

인증, TLS, 혼동 설정을 각각 확인하세요

Hysteria2 항목에는 보통 서버 주소, 포트, 인증 정보, TLS 관련 조건이 포함됩니다. Server Name은 서버 인증서 및 접속점 설정과 일치해야 하며 비밀번호나 인증 문자열은 원문 그대로 유지해야 합니다. 배포 환경에서 혼동 설정을 추가로 사용하는 경우 클라이언트와 서버의 유형 및 비밀번호도 일치해야 합니다. 혼동 기능은 모든 서버에서 임의로 켤 수 있는 부가 기능이 아닙니다. 양쪽 설정이 다르면 통신에 직접 문제가 생깁니다.

프로토콜 버전도 일치해야 합니다. 이름이 비슷한 다른 버전이라고 해서 인증 형식과 핸드셰이크까지 같지는 않으므로 표시 이름만 바꿔 변환할 수 없습니다. 서버에서 제공한 가져오기 정보를 사용하고 가져온 뒤 Type이 Hysteria2인지 확인하세요. 구독을 해석한 뒤 익숙하지 않은 필드가 표시되더라도 설정을 ‘깔끔하게’ 보이도록 삭제하지 마세요. 먼저 필드의 용도와 클라이언트 지원 여부를 확인해야 합니다.

대역폭 설정은 구매한 속도가 아닙니다

설정에 업로드, 다운로드, 혼잡 제어 관련 항목이 노출된다면 먼저 필드의 실제 단위와 역할을 확인하세요. 일부 설정은 알고리즘에 예상 대역폭을 전달하기 위한 것으로 물리적인 용량을 늘리지 않습니다. 값을 너무 높게 설정하면 연결이 감당할 수 있는 수준을 넘는 전송으로 대기열, 패킷 손실, 다른 앱의 성능 저하가 발생할 수 있습니다. 너무 낮게 설정하면 처리량이 제한될 수 있습니다. 서버 제한과 현재 네트워크 병목도 여전히 영향을 줍니다.

모바일 네트워크의 사용 가능 대역폭은 신호, 위치, 혼잡도에 따라 달라지므로 고정 광대역에 적합한 설정이 셀룰러 환경에도 맞는 것은 아닙니다. 다운로드는 빠른데 웹페이지 응답이 느려진다면 값을 계속 높이기보다 대역폭을 지속적으로 모두 사용하고 있는지 확인하세요. 실시간 응답이 중요한 작업에서는 최고 처리량보다 안정적인 대기 시간이 더 중요할 수 있습니다. 속도 측정 화면의 한 가지 결과가 아니라 실제 작업에 맞춰 프로토콜을 선택하세요.

실패 시 경로와 인증을 구분하세요

같은 기기가 특정 Wi-Fi에서 연결되지 않다가 셀룰러 네트워크로 바꾼 직후 정상 작동한다면 UDP 경로와 네트워크 정책을 먼저 확인하세요. 두 네트워크에서 동일한 핸드셰이크 단계에 실패한다면 유형, 인증, 인증서, 시스템 시간을 확인해야 합니다. 연결은 되지만 대용량 전송에 문제가 있다면 패킷 손실, 서버 부하, 패킷 크기를 살펴보세요. 증상과 변경 내용을 기록해야 Hysteria2가 현재 환경에 적합한지 판단할 수 있으며, 우연히 한 번 성공한 것을 안정적인 연결로 오인하지 않게 됩니다.

08 / 실측 및 판단

같은 작업으로 비교하고 계층별로 문제를 해결하세요

프로토콜 선택은 같은 기기에서 실제 작업을 반복했을 때 나타나는 결과를 기준으로 해야 합니다. 후보 항목의 설정이 정확하고 서버가 정상인지 확인한 다음 웹페이지 첫 화면, 연속 접속, 장시간 전송, 유휴 상태 후 복구를 각각 테스트하세요. 각 테스트에서 프로토콜이나 노드 중 주요 조건 하나만 바꾸고 네트워크, 신호, 테스트 작업을 기록하세요. 지역과 부하가 다른 서버를 비교해 특정 프로토콜이 본질적으로 더 빠르다고 증명할 수는 없습니다.

Global Routing과 프로토콜 유형을 따로 설정하세요

Global Routing의 Config, Proxy, Direct는 요청의 경로를 결정하며 서버 프로토콜을 바꾸지 않습니다. Config는 현재 구성의 규칙에 따라 트래픽을 분기하고, Proxy는 해당 트래픽을 프록시 정책으로 전달하며, Direct는 직접 연결합니다. 일시적으로 Proxy를 선택해 비교하면 일부 규칙의 영향을 제외하는 데 도움이 될 수 있습니다. 하지만 모든 시스템 트래픽, 모든 로컬 네트워크 예외, 모든 DNS 동작이 일괄 변경된다는 뜻은 아니므로 실제 설정과 로그를 함께 확인하세요.

다음은 단독으로 보는 Rule 문법 예시이며 기존 파일을 그대로 대체할 수 있는 완전한 설정이 아닙니다. 규칙은 위에서 아래 순서로 적용되고 FINAL은 앞선 규칙에 일치하지 않은 요청을 처리합니다. 여기서 PROXY는 프록시 정책, DIRECT는 직접 연결을 뜻합니다. 수정하기 전에 Config를 백업하고 현재 구성에서 해당 정책을 사용할 수 있는지 확인하세요.

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

규칙 일치 여부는 DNS와 관련이 있습니다. IP 유형 규칙에는 대상 IP 정보가 필요하고 도메인 규칙은 요청에 일치시킬 도메인이 남아 있어야 합니다. 로그에서 요청이 DIRECT로 전달된 것으로 나타나면 먼저 Rule 순서를 확인하세요. 이를 프록시 프로토콜 성능 판단의 근거로 삼으면 안 됩니다. 일치 대상과 규칙 순서는 규칙 키워드 시작 가이드에서 더 자세히 확인할 수 있습니다.

네 가지 유형의 테스트 결과를 기록하세요

첫째, 연결이 설정되는지와 실패 단계를 기록합니다. 둘째, 같은 소규모 요청의 응답이 안정적인지 기록합니다. 셋째, 장시간 전송 중 눈에 띄는 변동이 있는지 기록합니다. 넷째, 화면 잠금, 잠금 해제, 네트워크 전환 후 복구 여부를 기록합니다. Connectivity Test는 빠르게 단서를 찾는 데 쓸 수 있지만 테스트 대상과 방식은 모든 앱 사용을 그대로 반영하지 않습니다. 가끔 지연 시간이 낮게 나와도 연속 요청 실패를 상쇄할 수 없으며, 한 번의 시간 초과만으로 서버를 영구적으로 사용할 수 없다고 판단하기도 어렵습니다.

배터리를 비교할 때는 화면 밝기, 신호, 온도, 앱, 전송량을 비슷하게 유지하고 충분히 긴 시간 동안 관찰하세요. 시스템 배터리 통계는 일부 사용량을 전면 앱이나 네트워크 관련 프로세스에 포함할 수 있으므로 Shadowrocket의 비율만 확인해서는 안 됩니다. 기기가 뜨거워지면 대용량 파일의 지속 전송과 약한 신호를 먼저 확인하세요. 안정적인 테스트 조건이 없다면 프로토콜별 배터리 소모 순위를 정밀하게 매기지 마세요.

실패 단계에 따라 범위를 좁히세요

연결이 완전히 시간 초과되면 주소, 포트, 네트워크 연결 가능 여부, TCP / UDP 조건을 먼저 확인하세요. TLS 오류가 나타나면 이름, 인증서, 시스템 시간을 확인합니다. 인증이 거부되면 비밀번호, UUID, 키 방향을 점검하세요. 연결 후 일부 앱만 실패한다면 DNS, Rule, UDP 지원 여부, 대상 서비스를 확인합니다. 매번 한 항목만 변경하고 다시 연결해 같은 작업을 반복하세요. 개선되지 않으면 기준 설정으로 되돌려 오류가 누적되지 않도록 합니다.

일상적인 웹 사용에서는 기존 설정의 완전성과 안정성을 먼저 확인하세요. UDP가 필요한 앱은 종단 간 지원 여부를 점검하고, 내부 네트워크 작업은 터널 주소와 라우팅을 확인하세요. 대용량 전송 작업에서는 지속적인 성능을 비교하면 됩니다. 원인을 찾지 못했다면 민감한 정보를 가린 증상 기록과 함께 FAQ를 확인하세요. 작업 절차를 처음부터 다시 따라가야 한다면 시작 가이드로 돌아가세요. 계층별 점검 대신 프로토콜을 계속 바꾸지 마세요.