Shadowrocket
프로토콜 기술 참고 및 설정 가이드

프로토콜 선택은 서버 설정에 따라 달라집니다

프로토콜은 클라이언트와 서버가 연결을 설정하고, 신원을 확인하며, 데이터를 주고받는 방식을 정합니다. 단독으로 바꿔 끼울 수 있는 외형 옵션이 아닙니다. 서버가 Shadowsocks를 받도록 설정되어 있다면 주소, 포트, 비밀번호가 같아 보여도 클라이언트에서 Trojan을 선택했을 때 올바르게 통신할 수 없습니다. 따라서 이름을 비교하기 전에 서버에서 제공한 전체 설정 정보를 확인하고 프로토콜 유형, 인증 항목, 전송 방식, TLS 사용 여부를 파악해야 합니다. 구독에는 보통 이런 정보가 포함되므로 수동으로 수정하기 전에 원본을 보관하세요.

여기서 말하는 속도는 기기와 서버 사이의 경로, 서버 부하, 대상 사이트의 응답, 클라이언트 처리 비용이 모두 반영된 실제 접속 결과입니다. 프로토콜에 따라 핸드셰이크 횟수, 캡슐화 오버헤드, 패킷 손실 후 복구 방식은 달라질 수 있지만, 사용 가능한 네트워크 경로를 대신 만들어 주지는 않습니다. 한 번의 Connectivity Test 결과를 웹페이지 로딩 속도로 간주하지 마세요. 테스트 대상과 실제 접속 대상이 다를 수 있으며, 짧은 연결 테스트로는 지속 전송 중의 혼잡이나 변동을 파악하기 어렵습니다.

프로토콜·전송·암호화의 차이

프로토콜은 데이터 형식과 인증 방식을 정하고, 전송 계층은 바이트나 패킷을 전달하며, 암호화 계층은 전송 내용을 보호합니다. 조합에 따라 TCP 또는 UDP를 사용할 수 있습니다. WebSocket은 선택 가능한 전송 방식이며 TLS는 보안 계층입니다. 하나의 서버 설정에 프로토콜명, 전송 방식, 인증서 도메인이 함께 표시될 수 있지만 각각 다른 계층을 설명합니다. VLESS 또는 VMess라는 정보만으로는 설정을 재구성하기에 부족하므로 해당 전송 방식과 보안 설정도 확인해야 합니다.

규칙은 별도의 논리 흐름에서 동작합니다. 먼저 요청에 적용할 정책을 판단한 뒤 선택된 서버를 통해 해당 프로토콜로 연결합니다. DOMAIN-SUFFIX는 서버의 인증 방식을 바꾸지 않으며 FINAL도 잘못된 TLS 이름을 수정하지 않습니다. 접속에 실패하면 먼저 요청에 예상한 정책이 적용되었는지 확인한 다음 프로토콜 연결이 성립했는지 점검하세요. 두 단계를 혼동하면 실제로는 DIRECT가 적용됐는데 비밀번호를 계속 바꾸거나, 인증이 계속 실패하는데 규칙만 반복해서 수정할 수 있습니다.

모바일에서는 최고 속도뿐 아니라 지속 사용 비용도 확인하세요

iPhone과 iPad의 배터리 소모는 암호화·복호화 연산만으로 결정되지 않습니다. 무선 네트워크의 반복적인 활성화, 약한 신호에서의 재전송, 짧은 간격의 핸드셰이크, 백그라운드 연결 유지도 배터리 사용량을 늘릴 수 있습니다. 같은 프로토콜이라도 안정적인 Wi-Fi와 신호가 변하는 셀룰러 네트워크에서 동작이 다를 수 있습니다. 비교할 때는 기기, 네트워크, 작업, 테스트 시간을 동일하게 맞추고 발열, 로딩 대기 시간, 재연결 횟수도 기록하세요. 프로토콜 이름만으로 고정적인 배터리 효율 순위를 매길 수는 없습니다.

Shadowrocket에서 표시되는 설정 항목은 선택한 유형과 관련 옵션에 따라 달라집니다. 이 문서는 각 항목의 역할을 설명하며, 모든 프로토콜의 선택 항목을 필수값으로 간주하지 않습니다. 실제 설정은 앱의 현재 화면과 서버 안내를 대조해 입력하세요. 편집 화면에 없는 확장 항목을 이름이나 비밀번호에 억지로 넣지 마세요. 처음 사용하는 경우 튜토리얼에 따라 기본 연결을 완료한 뒤 필요한 전송 설정을 하나씩 추가하고, 변경할 때마다 변수 하나만 바꾸세요.

이후 내용을 확인할 때는 다음 순서를 기준으로 삼을 수 있습니다. 서버에서 실제로 제공하는 설정을 파악하고, 인증 정보를 확인한 뒤, 전송 및 보안 계층을 점검하고, 마지막으로 실제 작업을 테스트하세요. 주소와 포트만 있고 프로토콜 안내가 없다면 먼저 필요한 정보를 보완해야 합니다. 프로토콜을 추측하거나 보안 옵션을 임의로 바꾸면 새로운 실패 증상만 생길 뿐, 재현 가능한 진단 결과를 얻기 어렵습니다.

설계 특성: 프록시 데이터를 간결하게 처리

Shadowsocks는 비교적 간결한 방식으로 프록시 트래픽을 전달하고, 대상 주소와 앱 데이터를 양측이 약속한 암호화 구조에 담습니다. 완전한 네트워크 터널처럼 가상 네트워크 대역이나 라우팅 주소를 먼저 이해해야 하는 방식은 아닙니다. 일반적인 수동 설정은 서버 주소, 포트, 암호화 방식, 비밀번호를 중심으로 구성됩니다. 이 간결함은 기본 설정을 이해하기 쉽게 하지만, 서로 다른 암호화 방식이나 프로토콜 세대, 확장 기능이 호환된다는 뜻은 아닙니다.

초기의 스트림 암호 방식에서 인증 암호 방식으로 발전하면서 달라진 핵심은 수신 측에서 데이터를 복원하는 것뿐 아니라 무결성도 확인할 수 있는지 여부입니다. AEAD는 암호화와 인증을 결합하므로 클라이언트와 서버가 구체적인 방식과 키 자료에 합의해야 합니다. 이름이 비슷해 보여도 정확히 대조하세요. 키 길이나 알고리즘 계열만으로 호환성을 추측할 수 없습니다. 서로 다른 키 형식을 요구하는 설정에 다른 유형의 임의 텍스트 비밀번호를 재사용해서도 안 됩니다.

주소·방식·비밀번호의 대응 관계

서버 주소는 도메인 또는 IP로 지정하며 외부 연결의 진입점 역할을 합니다. 포트는 해당 진입점의 서비스를 지정합니다. 암호화 방식은 데이터 처리 형식을 정하고, 비밀번호 또는 지정된 형식의 키는 인증과 암호화에 필요한 자료를 만듭니다. 이 항목들은 한 묶음으로 확인해야 합니다. 포트가 맞아도 방식이 다르면 하위 연결은 성립할 수 있지만 이후 데이터가 상대 측에서 거부될 수 있습니다. 따라서 포트에 연결할 수 있다는 사실과 프로토콜 인증에 성공했다는 사실은 서로 다른 근거입니다.

Subscribe에서 가져온 뒤에는 서버 편집 화면에서 유형이 실제로 Shadowsocks인지 확인하고, 암호화 방식과 비밀번호가 온전히 입력되었는지 대조하세요. 일부 공유 정보는 인코딩되어 있어 복사 중 끝부분이 잘리거나 줄바꿈이 섞이거나 불필요하게 디코딩되면 실제 내용이 달라질 수 있습니다. 구독을 다시 가져온 뒤 정상 작동하고 수동으로 수정한 항목만 실패한다면 필드 차이를 비교하세요. 수동 변경 사항을 구독의 다른 서버 설정에 덮어쓰지 마세요.

확장 매개변수는 서버에서 명시적으로 지원해야 합니다. 일부 설정에는 플러그인이나 추가 캡슐화 정보가 포함되지만, 모든 Shadowsocks 연결의 기본 항목은 아닙니다. 기본 프로토콜을 사용할 수 있다고 임의의 추가 전송 방식도 쓸 수 있는 것은 아닙니다. 반대로 서버에서 확장을 요구한다면 기본 네 항목만으로는 부족합니다. 알 수 없는 확장이 있으면 이름, 관련 옵션, 필수 매개변수를 확인하세요. TLS를 켜거나 흔히 사용하는 포트로 바꾸는 것으로 대체할 수 없습니다.

TCP와 UDP는 각각 따로 확인하세요

웹페이지가 열리는 것은 해당 앱 접속 경로가 동작한다는 뜻일 뿐, UDP 전달까지 정상이라는 의미는 아닙니다. 클라이언트 옵션, 서버 설정, 중간 네트워크가 모두 UDP에 영향을 줄 수 있습니다. 보유한 서비스에서 UDP를 지원한다면 실제 UDP가 필요한 작업으로 테스트하고 로그에서 해당 요청에 적용된 정책도 확인하세요. 웹페이지는 정상인데 특정 실시간 작업이 실패한다면 프로토콜을 바꾸기 전에 해당 트래픽과 전달 방식이 지원되는지 확인하세요.

모바일 기기에서 Shadowsocks의 실제 처리 비용은 암호화 구현, 데이터량, 네트워크 상태에 따라 달라집니다. 캡슐화가 적으면 추가 오버헤드를 줄이는 데 도움이 될 수 있지만, 신호가 약할 때 반복되는 재전송과 대기 시간이 암호화 연산의 차이보다 훨씬 클 수 있습니다. 두 설정을 비교할 때는 동일한 작업으로 지속 처리량과 응답 안정성을 관찰하세요. 작은 데이터 패킷을 한 번 테스트하는 것만으로 장시간 더 빠르거나 백그라운드 사용 시 배터리가 덜 소모된다고 판단할 수 없습니다.

보유한 서비스가 완전한 Shadowsocks 설정을 명시적으로 제공하고 필요한 작업이 지원되는 전달 방식과 일치한다면 선택할 수 있습니다. 인증서 신원 확인, 특정 전송 방식 또는 네트워크 계층 주소 관리가 필요하다면 서버의 실제 기능을 기준으로 다른 장을 확인하세요. Shadowsocks 설정에 대응하지 않는 필드를 추가하지 마세요. 설정이 완료되면 원본 정보를 보관하고, 이후 문제가 생기면 네트워크 환경과 설정 변경 사항부터 비교하세요.

설정 항목이 비슷해도 같은 프로토콜은 아닙니다

VMess는 자체 프로토콜 구조에서 사용자 인증과 프록시 데이터 전달을 처리합니다. 일반적으로 UUID로 사용자를 식별하고 관련 보안 매개변수도 사용합니다. VLESS는 프로토콜 자체의 일부 처리를 줄이고 전송 보안은 외부 계층에 더 많이 맡기도록 설계되었습니다. 두 프로토콜은 서버 주소, UUID, 전송 항목이 비슷할 수 있지만 메시지 형식과 서버 측 처리 방식은 다릅니다. 편집 화면에서 유형을 VMess에서 VLESS로 바꾸는 것만으로 올바른 변환이 되지는 않습니다.

이 차이를 이해하면 “설정값이 다 같은데 왜 연결되지 않지?”라는 상황을 판단하는 데 도움이 됩니다. UUID는 인증 정보의 일부일 뿐 모든 프로토콜에서 공통으로 쓸 수 있는 로그인 정보가 아닙니다. 서버는 해당 진입점에 같은 유형을 설정하고 적절한 전송 및 보안 계층 조합도 받아야 합니다. 기존 구독에 서로 다른 유형의 항목이 있다면 각각 별도의 연결 정보로 취급하세요. 한 항목의 비밀번호, 포트, 전송 설정을 다른 항목과 조합하지 마세요.

접속 주소와 서비스 이름을 구분하세요

서버 주소는 먼저 연결할 대상을 지정하고, TLS의 서비스 이름은 신원 확인과 핸드셰이크에 사용됩니다. WebSocket의 Host와 Path는 해당 애플리케이션 계층 요청에 관여합니다. 이 값들은 같을 수도 있고 서버 배포 구조에 따라 다를 수도 있습니다. 특히 주소가 IP여도 인증서는 도메인용으로 발급될 수 있습니다. 서버 안내에 따라 필요한 이름을 입력하세요. 인증서 이름을 IP로 단순히 바꾸거나 Path를 도메인의 일부로 취급해서는 안 됩니다.

WebSocket Path는 보통 슬래시로 시작하며 서버가 허용하는 경로와 일치해야 합니다. 대소문자, 끝의 슬래시, 불필요한 공백도 요청 수락 여부에 영향을 줄 수 있습니다. Host는 메모용 이름이 아니므로 알아보기 쉬운 제목을 입력해 대체할 수 없습니다. 수동으로 입력할 때 주소, 포트, UUID, 전송 방식, TLS 이름, Host, Path를 항목별로 정리한 뒤 앱에서 제공하는 설정에 하나씩 대응하세요.

VMess 설정에는 보안 방식 등의 매개변수가 포함될 수 있으며, 오래된 자료의 일부 항목은 현재 서비스에 적용되지 않을 수 있습니다. VLESS의 확장 기능과 전송 조합도 클라이언트와 서버 양쪽에서 지원해야 합니다. 예전 안내서의 기본값을 기존 설정에 그대로 입력하지 말고, 대응하는 항목이 보이지 않으면 대체 설정을 추측하지 마세요. 구독에서 가져온 전체 설정을 우선 보존하고, 필요한 경우 서비스 제공자에게 현재 사용해야 하는 항목을 확인하세요.

핸드셰이크 단계는 짧은 작업의 체감에 영향을 줍니다

TCP, TLS, WebSocket을 조합하면 보통 각 계층의 연결을 차례로 설정해야 합니다. 데이터가 적은 짧은 작업에서는 이후 전송보다 연결 대기 시간이 더 두드러질 수 있습니다. 이미 연결이 안정적으로 유지되는 경우에는 체감이 다를 수 있습니다. 따라서 지속 접속에서 안정적인 조합이 셀룰러 네트워크에서 자주 재연결할 때도 적합하다고 단정할 수 없습니다. 처음 열기, 연속 접속, 네트워크 전환 후 복구를 각각 비교하세요.

VMess 인증 방식에는 시간 요소가 관련되어 있어 기기 시간이 크게 어긋나면 인증 문제가 발생할 수 있습니다. 먼저 시스템의 날짜와 시간 설정을 확인한 뒤 프로토콜 항목을 점검하세요. VLESS 연결 실패에 같은 원인을 바로 적용해서는 안 됩니다. 네트워크 전환 후 기존 연결을 계속 사용할 수 있는지는 하위 전송 방식에 따라 달라집니다. TCP 연결은 경로가 바뀐 뒤 다시 설정해야 하는 경우가 많습니다. 프로토콜 이름이 비슷하다고 모든 조합의 복구 동작까지 같을 것으로 기대하지 마세요.

두 프로토콜 중 하나를 선택할 때는 VMess와 VLESS라는 이름만 비교하지 말고 보유한 서비스의 전체 설정 조합을 기준으로 삼으세요. 명확한 오류 없이 연결에 실패하면 진입점 접속, TLS 핸드셰이크, 전송 요청, 인증 순으로 확인할 수 있습니다. 각 단계에서 판단 근거를 기록하세요. 여러 항목을 한꺼번에 바꾼 뒤 우연히 복구되면 실제 원인을 알기 어렵습니다.

보안 계층은 연결 구조의 일부입니다

Trojan은 프록시 요청과 비밀번호 인증을 TLS 연결 안에서 처리하고, 성숙한 TLS 메커니즘을 이용해 클라이언트와 서버 사이의 통신을 보호하도록 설계되었습니다. 따라서 Trojan을 이해하려면 비밀번호뿐 아니라 서버 인증서, 서비스 이름, 핸드셰이크 과정도 확인해야 합니다. 외부 보안 연결이 완료되지 않으면 일반적으로 앱 계층의 인증도 진행되지 않습니다. 이때 비밀번호를 반복해서 바꿔도 인증서 만료, 이름 불일치, 핸드셰이크 협상 실패는 해결되지 않습니다.

이 TLS 연결은 프록시 서버까지의 구간을 보호합니다. 대상 웹사이트가 HTTPS를 사용한다면 앱과 대상 웹사이트 사이에는 별도의 보안 연결이 형성됩니다. 두 연결은 서로 다른 인증서를 사용하므로 혼동하지 마세요. 서버 연결은 성공했는데 특정 웹사이트에서 인증서 오류가 발생하면 어떤 계층에서 오류가 났는지 구분해야 합니다. 오류 메시지에 TLS라는 글자가 있다는 이유만으로 Trojan 서버 이름을 바꾸면 원래 올바르던 설정까지 망가질 수 있습니다.

접속 주소·SNI·인증서의 역할

주소는 클라이언트가 연결할 위치를 지정하고 SNI는 핸드셰이크 중 필요한 서비스를 나타내며 인증서는 서비스 신원을 검증하는 데 사용됩니다. 단순한 배포에서는 세 항목이 같은 도메인을 사용할 수 있지만, 진입점 구성에 따라 서로 다를 수도 있습니다. 서버 안내에 맞춰 각각 입력하고 인증서에 예상 서비스 이름이 포함되어 있는지 확인하세요. 진입점이 IP라고 해서 인증서에도 반드시 해당 IP가 있어야 하는 것은 아닙니다. 지정된 TLS 이름을 먼저 확인하세요.

비밀번호는 서버 설정과 정확히 일치해야 합니다. 앞뒤 공백, 줄바꿈, 문자 변경으로 인증이 실패할 수 있습니다. 포트는 서비스 진입점만 지정하므로 흔히 쓰는 포트라고 해서 Trojan이 실행 중이거나 인증서 설정이 올바르다는 뜻은 아닙니다. 서버에서 추가 전송 캡슐화를 허용한다면 관련 항목도 확인해야 합니다. 서버가 명시적으로 요구하지 않는 한 일반 Trojan 설정에 다른 전송 방식의 Path나 Host를 임의로 추가하지 마세요.

ALPN과 같은 일부 고급 항목은 애플리케이션 프로토콜을 협상하거나 핸드셰이크 세부 사항을 조정합니다. 양측이 이후 처리 방식에 합의하기 위한 설정이지, 범용 속도 향상 옵션은 아닙니다. 관련 안내가 없다면 가져온 설정을 그대로 유지하세요. 다른 곳에서 본 값을 복사하면 외부 연결은 성립해도 잘못된 서비스로 연결되거나 서버가 후속 처리를 거부할 수 있습니다. 진단할 때는 정상 작동이 확인된 조합으로 되돌린 다음 차이를 하나씩 확인하세요.

원인별 인증서 문제 점검

인증서 이름이 일치하지 않으면 주소와 TLS 이름을 혼동했는지 확인하고 서버가 예상한 인증서를 실제로 제공하는지 점검하세요. 유효기간 오류가 표시되면 기기 시간을 확인한 뒤 서버 인증서를 갱신해야 하는지 살펴보세요. 신뢰 체인 문제가 발생하면 서버 설정에 필요한 인증서 체인을 추가하거나 기존의 신뢰 방식을 확인해야 합니다. 인증서 검증을 끄면 신원 확인 근거가 사라지므로 연결 복구를 위한 일반적인 방법으로 사용하지 마세요.

iOS에서 TLS의 연산 및 핸드셰이크 비용은 전체 사용 경험의 일부일 뿐입니다. 안정적인 연결로 요청을 많이 처리하면 연결 설정 비용을 분산할 수 있지만, 모바일 네트워크가 자주 끊기면 핸드셰이크를 반복하면서 대기 시간과 무선 활동이 늘어납니다. 따라서 Trojan을 일률적으로 “배터리를 더 많이 소모한다”거나 “더 빠르다”고 평가할 수 없습니다. 같은 네트워크에서 실제 작업을 비교하고 첫 연결 시간과 연결 후 전송 성능을 구분하세요.

보유한 서비스가 Trojan을 명시적으로 제공하고 인증서 이름과 인증 정보가 모두 갖춰져 있다면 사용할 수 있습니다. 같은 서비스에서 여러 진입점을 제공한다면 인증서 정보가 명확하고 현재 네트워크에서 접속할 수 있는 항목부터 확인하세요. 특정 대상 하나만 실패한다면 TLS 설정을 바로 다시 만들지 말고 규칙과 DNS부터 확인하세요. 모든 대상에서 실패하고 로그가 핸드셰이크 문제를 가리킬 때 이 장의 순서에 따라 점검하면 됩니다. 이름 확인 문제는 DNS 설정 및 이름 확인 문제 해결을 참고하세요.

두 가지 범용 프록시의 요청 전달 방식

HTTP 프록시는 웹 요청을 한곳에서 전달해야 하는 요구에서 출발했으며 HTTP 방식으로 프록시 요청을 받습니다. 터널 연결이 필요할 때는 보통 CONNECT를 사용합니다. SOCKS5는 특정 웹 리소스 유형에 의존하지 않고 대상 주소와 연결 요청을 중심으로 동작합니다. 두 방식은 역사적으로 초점을 둔 영역이 다르지만 서버가 해당 프로토콜을 실제로 지원해야 합니다. 주소와 포트만 있다고 임의로 하나를 골라 시도하지 마세요.

HTTP 프록시, TLS로 연결하는 HTTP 프록시, HTTP 프록시를 통해 HTTPS 사이트에 접속하는 것은 서로 다른 개념입니다. 마지막 경우 대상 사이트의 HTTPS가 클라이언트와 프록시 진입점 사이의 모든 통신까지 자동으로 보호하지는 않습니다. SOCKS5 자체도 암호화 터널을 의미하지 않습니다. 보안 범위를 판단할 때는 외부 연결이 보호되는지, 업무 데이터가 자체적인 종단 간 보안 프로토콜을 사용하는지 구분해야 합니다.

계정 인증과 전송 보호를 따로 확인하세요

두 유형 모두 주소, 포트, 사용자 이름, 비밀번호 항목을 사용할 수 있지만 인증 사용 여부와 지원 방식은 서버 설정에 따라 달라집니다. 사용자 이름이 비어 있다고 반드시 익명 서비스인 것은 아니며, 임의의 문자를 입력한다고 서버가 요청을 받아들이는 것도 아닙니다. 보유한 정보에 인증이 필요한 프록시 주소만 적혀 있다면 프로토콜 안내에 따라 항목을 나누세요. 사용자 이름을 주소란에 남기거나 포트를 비밀번호 일부로 오해하지 마세요.

SOCKS5의 사용자 이름 및 비밀번호 인증은 전체 데이터 암호화를 제공하지 않습니다. 외부 연결을 보호해야 한다면 이름이 비슷한 옵션을 찾는 대신 서비스에서 실제로 보안 기능을 제공하는지 확인하세요. HTTP 프록시도 마찬가지입니다. 대상 사이트의 인증서가 정상이라는 사실은 해당 대상 연결의 관련 검증이 통과했다는 뜻일 뿐, 프록시 진입점의 신원과 전송 보안까지 확인해 주지는 않습니다.

프록시가 대상을 전달할 때 도메인을 로컬에서 확인하는지 프록시 측에서 확인하는지에 따라 결과와 문제 해결 방향이 달라집니다. 클라이언트가 도메인을 프록시에 전달할 수도 있고, 설정이나 요청 형식에 따라 먼저 IP를 얻을 수도 있습니다. 도메인으로 접속하면 실패하지만 알고 있는 주소로는 정상인 경우 DNS 경로와 로그에 표시된 대상 형식을 확인하세요. 계정 인증 문제라고 바로 판단하지 마세요. 두 테스트는 실제로 서로 다른 이름 확인 경로를 사용할 수 있습니다.

프로토콜 이름만으로 UDP 지원 여부를 판단할 수 없습니다

SOCKS5 표준에는 UDP 관련 메커니즘이 포함되어 있지만 실제 사용 가능 여부는 클라이언트 구현, 서버 기능, 네트워크 연결성에 따라 달라집니다. HTTP CONNECT는 주로 TCP 터널로 사용되므로 모든 UDP 작업이 해당 진입점을 통과할 수 있다고 단정할 수 없습니다. 보유한 서비스에서 실시간 음성·영상 등 UDP 요청이 필요한 작업을 주로 한다면 해당 설정의 지원 여부를 명확하게 확인하세요. 브라우저에서 웹페이지가 열린다는 이유만으로 전체 기능이 검증된 것은 아닙니다.

iPhone이나 iPad에서 이 프로토콜의 성능도 연결 경로에 따라 달라집니다. 단순한 진입점이 특정 네트워크에서 직접적으로 동작할 수도 있지만, 원격 처리, 연결 수 제한, 인증 정책으로 인해 대기 시간이 생길 수도 있습니다. 오래된 프로토콜이라고 반드시 느린 것은 아니며, 설정 항목이 적다고 반드시 배터리를 덜 쓰는 것도 아닙니다. 실패 후 재시도가 잦으면 추가 무선 활동으로 간단한 설정도 배터리를 크게 소모할 수 있습니다.

보유한 HTTP 또는 SOCKS5 서비스 정보가 명확하거나 기존 네트워크의 프록시 진입점을 사용해야 하는 경우에 적합합니다. 먼저 신뢰 범위를 확인한 뒤 필요한 작업과 이름 확인 방식을 테스트하세요. 기기와 원격 진입점 사이의 데이터를 보호하려는 경우 이 두 이름만 선택하는 것으로 완전한 구성이 되지는 않습니다. 진입점의 보안 계층을 확인할 수 없다면 브라우저 주소 표시줄의 보안 표시를 근거로 전체 경로를 추측하지 말고 서비스 안내를 보완하세요.

요청 프록시에서 네트워크 패킷 터널로

WireGuard는 간결한 프로토콜 구조로 네트워크 계층 터널을 만들고, 공개 키로 상대를 식별하며 UDP를 통해 암호화된 패킷을 전달하도록 설계되었습니다. 앞서 살펴본 대상별 프록시 요청 방식과 달리 연결할 위치뿐 아니라 로컬 터널 주소, 상대 키, 해당 경로로 보낼 수 있는 주소 범위도 설정해야 합니다. 단순히 “비밀번호만 입력하는 또 다른 서버 유형”으로 이해하면 필수 항목을 놓치기 쉽습니다.

WireGuard는 고정된 최신 암호화 조합을 사용하므로 사용자가 알고리즘 메뉴에서 직접 선택할 필요가 적습니다. 알고리즘 조합 설정은 간단해지지만 키, 주소, 라우팅 관계가 올바른지 확인하는 중요성은 더 커집니다. 프로토콜 구조가 간결하다고 네트워크 설정까지 생략할 수 있는 것은 아닙니다. 키가 정확해도 터널 주소나 허용 범위가 맞지 않으면 핸드셰이크는 성립하지만 업무 데이터가 돌아오지 않을 수 있습니다.

로컬 개인 키와 상대 공개 키는 서로 바꿔 쓸 수 없습니다

개인 키는 로컬 신원을 증명하므로 안전하게 보관해야 합니다. 공개 키는 상대를 식별하는 데 사용됩니다. 클라이언트 설정에 필요한 상대 공개 키는 서버에서 실제 사용하는 개인 키와 대응해야 하며, 서버도 클라이언트의 공개 키를 알아야 합니다. 양쪽에서 임의로 한 쌍씩 입력한다고 연결되는 것은 아닙니다. 사전 공유 키를 사용하는 경우에도 양쪽 값이 일치해야 합니다. 공개 키와 개인 키를 각각 보관하고 서로 대신 사용하지 마세요.

Endpoint는 외부 서버 주소와 포트를 지정하고 터널 Address는 터널에 들어간 뒤의 로컬 주소를 지정합니다. 두 값은 서로 다른 네트워크 계층에 해당합니다. Endpoint에는 공용 네트워크에서 접속할 수 있는 도메인을 사용할 수 있고 터널 주소는 지정된 내부 네트워크 대역에 속할 수 있습니다. Endpoint의 IP를 터널 주소에 입력해서는 올바른 설정이 되지 않는 경우가 많습니다. 보유한 정보를 가져올 때 주소 뒤의 접두사 길이를 유지하고 IPv4와 IPv6 항목을 구분하세요. IP처럼 보이는 부분만 남기지 마세요.

AllowedIPs는 주소 범위를 상대와 연결하며 완전한 설정에서는 라우팅과 허용할 발신 범위 모두에 관여합니다. Shadowrocket에는 자체 규칙 정책도 있으므로 서버 측 터널 설정과 클라이언트 분할 라우팅은 서로 다른 두 계층임을 이해해야 합니다. “모든 요청을 터널로 보내기 위해” 주소 범위를 무조건 넓히지 마세요. 특히 로컬 네트워크나 여러 내부 네트워크에 접속할 때는 원래 네트워크 설계에 따라 필요한 대상 범위를 확인해야 합니다.

연결 유지 및 MTU는 각각 적용 범위가 있는 설정입니다

PersistentKeepalive는 필요한 경우 중간 장비의 매핑을 유지해 일정 시간 유휴 상태인 뒤 상대가 연결해야 하는 상황을 도울 수 있습니다. 하지만 간격을 짧게 할수록 항상 더 안정적인 것은 아닙니다. 주기가 짧으면 정기 패킷이 늘어나 모바일 네트워크에서 무선 활동이 증가할 수 있습니다. 필요한지와 어떤 값을 쓸지는 네트워크 환경 및 기존 설정에 따라 결정하세요. 사용자가 직접 접속 중인데 가끔 재연결되는 문제라면 먼저 실제 유휴 상태와 매핑 동작부터 확인하세요.

MTU는 한 번에 전달되는 데이터 크기의 한계를 나타냅니다. 터널 캡슐화가 추가되면 사용할 수 있는 공간이 달라집니다. 경로에서 큰 패킷을 제대로 처리하지 못하면 작은 요청은 성공하지만 큰 페이지나 파일이 멈출 수 있습니다. 이런 증상만으로 MTU가 원인이라고 단정하지 말고 패킷 손실과 대상 응답도 확인하세요. 조정이 필요한 경우 기존 값을 보관하고 같은 네트워크와 대상에서 한 번에 하나씩 검증하세요. DNS, 규칙, 키를 동시에 바꾸지 마세요.

iOS에서 WireGuard의 UDP 전달과 Endpoint 갱신 방식은 일부 네트워크 변화를 처리할 수 있지만, 네트워크 전환 중 연결이 항상 유지된다고 보장하지는 않습니다. 현재 네트워크가 UDP를 제한하거나 매핑, 라우팅, 반환 경로에 문제가 있으면 사용에 영향을 줍니다. 완전하고 정상 작동하는 터널 정보를 보유한 경우에 적합하며, 특히 지정된 내부 네트워크 대역에 접속할 때 유용합니다. 간결한 프로토콜 설계만으로 항상 더 빠르거나 배터리를 덜 쓴다고 추론하지 마세요.

변동이 큰 네트워크 경로를 고려한 설계

Hysteria2는 QUIC을 기반으로 전송을 구성하고 UDP를 하위 전달 방식으로 사용하며, 관련 인증 및 혼잡 제어 메커니즘으로 프록시 트래픽을 처리합니다. 지연 시간이 길거나 패킷 손실과 처리량 변동이 큰 경로를 고려한 설계지만 모든 네트워크에서 성능을 보장하지는 않습니다. 먼저 현재 네트워크에서 필요한 UDP 통신이 가능한지 확인하세요. 외부 패킷이 서버에 정상적으로 도달하지 못하면 대역폭이나 인증 항목을 바꿔도 해결되지 않습니다.

QUIC은 하나의 연결에서 여러 스트림을 구성할 수 있어 일부 상황에서 패킷 손실로 인한 스트림 간 전달 지연을 줄일 수 있습니다. 그러나 모든 스트림은 실제 경로의 용량을 공유하므로 혼잡과 무선 신호의 제약은 사라지지 않습니다. Hysteria2도 앱 트래픽을 자체 프로토콜 구조에 담아 전달하므로 QUIC의 특정 기능 하나만으로 모든 작업이 반드시 빨라진다고 볼 수 없습니다. 순간적인 최대 처리량뿐 아니라 실제 작업 완료 시간도 확인하세요.

인증·TLS·추가 설정은 각각 입력하세요

기본 설정에는 서버 주소, 포트, 인증 정보, 서비스에서 요구하는 TLS 설정이 필요합니다. 인증 정보는 보유한 안내에 나온 값과 정확히 대응해야 합니다. 텍스트 형태라는 이유만으로 다른 프로토콜의 비밀번호와 혼용하지 마세요. 인증서 이름 확인 방법은 앞서 설명한 것과 같습니다. 진입점 주소와 TLS 서비스 이름이 다를 수 있으므로 인증서에 예상한 신원이 포함되는지 확인하고 검증을 유지하세요.

일부 서비스는 추가 난독화 설정도 제공하며 유형과 비밀번호가 양쪽에서 일치해야 합니다. 이 값은 사용자 인증과 다른 항목이므로 두 비밀번호를 합치거나 클라이언트에서만 켜면 서버가 자동으로 인식할 것이라고 기대하지 마세요. 구독에 해당 항목이 없다면 필수 성능 설정으로 간주하지 마세요. 알 수 없는 확장이 있으면 현재 앱에서 해당 기능을 지원하는지 먼저 확인한 뒤 이 연결 정보를 사용할지 결정하세요.

대역폭 설정은 속도 제한을 해제하는 버튼으로 오해하기 쉽습니다. 관련 모드에서 전송 방식이나 혼잡 제어에 사용될 수 있으며, 입력값은 기대하는 최고 속도가 아니라 경로가 실제로 처리할 수 있는 수준을 반영해야 합니다. 지나치게 높게 추정하면 실제 용량을 초과해 전송하면서 대기열, 패킷 손실, 다른 작업의 응답 저하가 발생할 수 있습니다. 너무 낮게 잡으면 처리량이 제한될 수 있습니다. 입력 여부와 단위는 앱 화면 및 서버 안내에 따라 각각 확인하세요.

속도와 응답 지연을 함께 확인하세요

같은 기기에서 대용량 파일의 전송 속도가 높을 때 다른 페이지의 응답은 오히려 느려질 수 있습니다. 대개 대기열과 대역폭 경쟁이 관련되어 있습니다. Hysteria2를 평가할 때 최고 속도 결과 하나만 기록하지 말고 지속 다운로드와 가벼운 요청을 함께 관찰하세요. 설정을 바꾼 뒤 최고 속도는 높아졌지만 페이지가 더 자주 멈춘다면 이전 설정으로 되돌리고 현재 네트워크에 적합한 완만한 값과 비교하세요.

모바일 네트워크의 신호 변화는 사용 가능한 전송률에 영향을 미치므로 고정된 대역폭 추정값이 항상 정확하기 어렵습니다. Wi-Fi에서 얻은 수치를 셀룰러 네트워크에 그대로 적용하지 말고, 한가한 시간에 한 테스트를 하루 전체의 네트워크 상태를 대표하는 결과로 여기지 마세요. 반복 재시도, 장시간 고속 전송, 무선 활동은 발열과 배터리 소모를 늘릴 수 있습니다. 장시간 백그라운드 연결이 필요하다면 실제 사용 주기에 맞춰 관찰하고 한 번의 고속 결과만으로 장기 설정을 결정하지 마세요.

보유한 서비스에서 Hysteria2를 명시적으로 제공하고 현재 네트워크가 UDP 트래픽을 안정적으로 전달할 수 있어야 사용할 수 있습니다. 이 조건을 만족하지 않는 네트워크라면 보유한 서비스가 제공하는 다른 사용 가능한 설정을 테스트하세요. 대역폭 값을 계속 높이지 마세요. 선택 결과는 “이 네트워크와 작업에서는 더 적합하다”로 표현해야 하며, 한 번의 사용 경험을 프로토콜의 고정 순위로 일반화해서는 안 됩니다.

프로토콜 이름을 순위로 매기지 말고 필요한 기능으로 추리세요

실제 선택을 시작할 때는 작업 조건부터 정리하세요. 보유한 서비스가 어떤 유형을 지원하는지, 현재 네트워크에서 TCP와 UDP를 사용할 수 있는지, 내부 네트워크에 접속해야 하는지, 주요 작업이 짧은 페이지 접속인지 지속 전송인지 실시간 상호작용인지 확인합니다. 유명한 프로토콜보다 완전한 설정 정보와 안정적인 접속 가능성이 우선입니다. 사용할 수 있는 설정이 하나뿐이라면 먼저 그 설정을 충분히 검증하세요. 여러 항목이 있다면 동일한 조건에서 비교하고 특정 이름을 쓰려고 매개변수를 조합할 필요는 없습니다.

일반적인 웹 접속에는 설정 항목이 완전하고 핸드셰이크가 안정적인 기존 연결을 먼저 사용하고 첫 페이지와 연속 접속의 응답을 확인하세요. 지정된 내부 주소에 접속해야 한다면 WireGuard 등 기존 터널 설정의 주소와 라우팅을 확인합니다. UDP 작업이 필요하면 프로토콜, 서버, 경로가 모두 지원하는지 점검하세요. 지속 전송에서는 처리량뿐 아니라 다른 요청의 대기 시간과 기기 발열도 관찰하고 한 번의 최고 속도를 종합 평가로 간주하지 마세요.

프로토콜을 바꾸기 전에 Global Routing을 확인하세요

Global Routing에는 Config, Proxy, Direct라는 세 가지 모드가 있습니다. Config는 현재 구성의 규칙에 따라 정책을 선택하고, Proxy는 해당 트래픽을 프록시 방식으로 처리하며, Direct는 직접 연결합니다. Proxy를 사용하면 일부 규칙의 영향을 비교하는 데 도움이 되지만 이것만으로 진단이 끝나는 것은 아닙니다. 각 요청의 실제 동작은 로그에서 확인하세요. 테스트가 끝나면 평소 사용하는 모드로 복원해 임시 문제 해결 설정이 장기 규칙으로 남지 않게 하세요.

아래 내용은 규칙 문법과 적용 순서만 보여 주는 예시이며 완전한 구성이나 서버 정보는 포함하지 않습니다. 규칙은 위에서 아래로 적용되고, 앞에서 일치하지 않은 요청은 마지막의 FINAL이 처리합니다. 예시의 PROXY는 실제 구성에서 사용 가능한 정책에 연결해야 합니다. 설정 구간은 .conf 구조 안내를, 적용 순서는 사용자 지정 규칙과 FINAL을 참고하세요.

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

한 번에 하나의 문제 계층만 확인하세요

전혀 연결되지 않으면 먼저 현재 네트워크를 사용할 수 있는지 확인한 다음 서버 주소, 포트, 프로토콜 유형을 점검하세요. 이어서 오류가 TLS, 인증, 시간 초과 중 무엇을 가리키는지 확인합니다. 연결은 되었지만 웹페이지가 열리지 않으면 DNS와 대상 요청에 적용된 정책을 살펴보세요. 일부 작업만 실패하면 UDP가 필요한지, 다른 대상을 사용하는지, 대용량 패킷이나 동시 작업이 문제를 일으키는지 확인합니다. DNS 변경, 인증서 검증 해제, 규칙 수정, 서버 설정 재작성을 한꺼번에 하지 마세요.

간단한 테스트 기록에 네트워크 유형, 선택한 설정, Global Routing 모드, 대상 작업, 오류 발생 단계를 적어 두세요. Wi-Fi와 셀룰러 네트워크를 바꿔 테스트할 때는 다른 설정을 그대로 유지하세요. 프로토콜을 비교할 때도 가능한 한 대상과 작업을 동일하게 맞추세요. 배터리 소모는 충분한 일반 사용 시간 동안 관찰하고 화면 밝기, 백그라운드 작업, 신호 세기도 함께 고려하세요. 짧은 시간의 배터리 잔량 변화만으로 특정 프로토콜이 본질적으로 더 많은 전력을 쓴다고 판단할 수 없습니다.

로그나 스크린샷을 정리해 공유하기 전에 구독 주소, 인증 비밀번호, 개인 키, 설정 전체를 복원할 수 있는 정보를 삭제하세요. 관련 시간대, 대상 유형, 오류 설명만 남기고 전체 설정을 외부에 공유하지 마세요. 구독 업데이트 후 차이가 생기면 유형, 주소, 전송, 인증 항목부터 비교하고 모든 로컬 설정을 바로 덮어쓰지 마세요. 앱 구매 복원은 별도의 절차입니다. 구매 항목 복원 안내를 확인하세요. 프로토콜 설정을 다시 만들어 해결하는 문제가 아닙니다.

마지막으로 결과를 반복 가능한 절차로 정리하세요. 작동하는 설정을 확인하고 원본 정보를 보관한 뒤 평소 사용하는 규칙으로 되돌리고 실제 작업을 테스트합니다. 문제가 계속되면 연결은 됐지만 인터넷이 안 될 때의 점검 순서 또는 자주 묻는 질문을 확인하세요. 가져오기 절차를 다시 진행하려면 빠른 시작 튜토리얼로 돌아가세요. 프로토콜 선택은 정보가 정확하고, 경로에 접속할 수 있으며, 정책이 예상대로 적용되고, 실제 작업 검증이 완료되어야 마무리됩니다.