Shadowrocket 프로토콜 가이드

프로토콜 선택의 네 가지 단계

프로토콜·전송·암호화·라우팅 구분하기

Shadowrocket에서 프로토콜을 선택한다는 것은 기존 서버와 클라이언트가 통신하는 방식을 정하는 일이지, 연결 속도 등급을 고르는 일이 아닙니다. 연결에는 최소 네 가지 단계가 관여합니다. 프로토콜은 요청과 인증 형식을 정하고, 전송 방식은 데이터를 상대편까지 전달하며, 암호화는 전송 중인 데이터를 보호하고, 라우팅은 어떤 요청이 해당 연결을 이용할지 결정합니다. 서로 연관은 있지만 서로 대체할 수는 없습니다. 올바른 프로토콜 유형을 선택한 뒤에도 서버 주소, 포트, 인증 정보, 전송 설정을 하나씩 일치시켜야 합니다. 이름이 같다는 사실만으로 양쪽이 통신할 수 있는 것은 아닙니다.

예를 들어 VLESS는 요청 및 인증 형식이고, WebSocket은 데이터를 전달하는 방식이며, TLS는 해당 연결의 암호화와 신원 확인을 담당합니다. DOMAIN-SUFFIX는 도메인에 적용할 프록시 정책을 결정합니다. 하나의 프로토콜에 여러 전송 방식을 조합할 수 있고, 하나의 전송 방식이 서로 다른 프로토콜을 전달할 수도 있습니다. 서버에서 제공한 설정 전체를 하나의 단위로 다뤄야 합니다. 한 설정의 인증 정보와 다른 설정의 전송 방식을 섞어서는 안 됩니다. 가져온 뒤 항목 이름이 다르면 각 이름이 어느 단계에 해당하는지 먼저 확인하세요.

비교하려는 사용 목적을 명확히 하기

웹 탐색은 짧은 요청을 여러 번 보내는 경우가 많아 최초 연결 시간, 도메인 조회, 연결 재사용이 체감 속도에 영향을 줍니다. 대용량 파일 전송에서는 지속 처리량, 혼잡 제어, 서버의 외부 회선 제한이 더 잘 드러납니다. 음성 통화나 인터랙티브 앱은 왕복 지연의 변동, 패킷 손실, UDP 사용 가능 여부가 중요합니다. 따라서 ‘웹페이지가 빨리 열린다’와 ‘전송 속도가 빠르다’는 서로 다른 결과입니다. 한 번의 다운로드 결과를 모든 앱에 적용하면 이후 문제 해결 방향을 잘못 잡을 수 있습니다. 먼저 목적을 정한 뒤 그 목적에 맞는 테스트를 선택하세요.

iPhone과 iPad에서는 사용 시간대와 네트워크 조건도 함께 기록하세요. 한곳에서 사용하는 Wi-Fi와 이동 중인 셀룰러 네트워크는 주소 변경, 무선 재전송, 백그라운드 작업 처리 방식이 다를 수 있습니다. 프로토콜의 캡슐화, 암호화, 연결 유지 기능은 추가 부하를 만들지만 화면 밝기, 무선 신호 세기, 전송량도 배터리에 큰 영향을 줍니다. 이런 요소를 통제하지 않은 비교는 특정 상황의 경험만 보여줄 뿐, 프로토콜별 배터리 소모 순위를 정할 근거가 되지 않습니다. 이름이 더 최신이라는 이유만으로 배터리를 더 적게 쓴다고 판단할 수도 없습니다.

되돌릴 수 있는 선택 순서 세우기

프로토콜 선택은 우선 보유한 서버의 기능에 따라 달라집니다. 완전한 설정이 하나뿐이라면 제공된 정보에 맞는 유형을 선택하고, 비교를 위해 프로토콜을 바꾸지 마세요. 사용할 수 있는 설정이 여러 개라면 먼저 각 설정으로 독립적으로 연결되는지 확인한 다음, 같은 목적을 대상으로 최초 접속, 재접속, 지속 사용을 비교합니다. 원래 설정을 복사해 보관하고, 매번 변수 하나만 바꾸며 당시의 네트워크를 기록하세요. 변경으로 개선되지 않더라도 확인된 기준 상태로 돌아갈 수 있어야 합니다. 여러 항목을 연달아 바꿔 비교 기준을 잃지 마세요.

마지막으로 유지 관리 부담도 고려하세요. 설정 항목이 많은 연결은 더 자세한 정보를 보관해야 하며, 인증서·도메인·전송 경로마다 변경 주기가 다를 수 있습니다. 잠시 더 빠르더라도 출처가 명확하지 않은 설정은 장기적으로 적합하지 않을 수 있습니다. 정보가 충분하고 현재 목적에 맞으며 확인하기 쉬운 기존 설정을 우선 선택하세요. 이 가이드는 차이와 적용 범위를 설명하기 위한 것이며 서버 설정을 대신하지 않습니다. 특정 프로토콜이 모든 네트워크에서 유일한 정답이라고 제시하지도 않습니다.

Shadowsocks, HTTP, SOCKS5

Shadowsocks: 간결한 암호화 프록시

Shadowsocks는 비교적 간단한 프로토콜로 프록시 트래픽을 전달하고, 합의된 암호화 방식과 키 정보를 사용해 양쪽 간 통신을 처리합니다. 여러 단계의 전송 설정을 함께 입력하는 복잡한 조합이 필요하지 않은 경우가 많지만, 모든 설정을 서로 바꿔 쓸 수 있다는 뜻은 아닙니다. 암호화 방식마다 필요한 키 정보와 메시지 처리 방식이 다르고, 서버가 지원하는 범위도 다를 수 있습니다. 기존 정보의 암호화 방식이 클라이언트에서 선택 가능한 항목과 일치하는지 먼저 확인한 뒤 서버, 포트, 인증 정보를 점검하세요.

비밀번호와 암호화 방식은 한 쌍으로 확인해야 합니다. 일반 텍스트 비밀번호를 사용하는 설정도 있고, 키의 인코딩이나 길이에 특정 조건이 있는 방식도 있습니다. 인코딩된 값을 일반 비밀번호로 취급하거나 ‘더 강해 보인다’는 이유만으로 암호화 방식을 바꾸면 인증에 실패할 수 있습니다. 구독에서 가져온 설정은 가져온 값을 그대로 유지하세요. 직접 추가할 때는 제공된 정보를 하나씩 입력하고, 안내되지 않은 항목을 임의로 추가하지 마세요. 별도의 전송 방식이 포함된 설정이라면 관련 항목도 확인해야 합니다. 서버가 기본값으로 이를 허용한다고 가정하지 마세요.

iOS에서 사용할 때 캡슐화 단계가 적으면 추가 처리 부담을 줄일 수 있지만, 실제 속도는 서버 리소스, 회선 품질, 대상 사이트의 제한에도 영향을 받습니다. 최신 기기에서는 암호화 성능만이 병목이 아닐 수 있으므로 특정 알고리즘 이름을 배터리 소모량과 동일시해서는 안 됩니다. 지속 전송 중에만 기기가 뜨거워진다면 비슷한 전송량에서 비교하세요. 대기 중에도 배터리가 눈에 띄게 줄어든다면 암호화 방식을 바꾸기보다 재연결, 네트워크 신호, 연결 유지 동작을 확인하세요. 설정값 오류는 오래 기다린다고 저절로 해결되지 않습니다.

HTTP: 프록시 연결과 대상 연결 구분하기

HTTP 프록시는 웹 요청을 전달하기 위해 발전했으며, 일반 HTTP 요청을 전달하거나 CONNECT를 사용해 대상과 터널을 만들 수 있습니다. 여기서는 두 구간을 구분해야 합니다. 기기에서 프록시 서버까지의 연결과 프록시 서버에서 대상 사이트까지의 연결입니다. 대상 사이트가 HTTPS를 사용한다고 해서 기기와 HTTP 프록시 사이도 TLS를 사용한다는 뜻은 아닙니다. 서버에서 암호화된 프록시 접속을 제공한다면 해당 정보에 맞춰 연결 방식을 설정하세요. 대상 주소가 HTTPS로 시작한다는 이유만으로 전체 경로의 특성을 판단할 수는 없습니다.

HTTP 프록시의 일반적인 항목은 주소, 포트, 선택 사항인 사용자 이름과 비밀번호입니다. 인증 방식은 서버 설정에 따라 다르며, 인증 정보를 비워 둔 경우와 잘못 입력한 경우에도 결과가 다를 수 있습니다. CONNECT로 특정 대상 포트에 연결할 수 있는지는 서버 정책에 달려 있습니다. 일반 웹사이트는 열리지만 특정 서비스에 연결할 수 없더라도 클라이언트의 프로토콜 구현 문제라고 단정할 수 없습니다. 먼저 연결이 허용된 것으로 확인된 대상을 사용하고, 해당 서비스가 실제로 사용하는 포트와 전송 유형을 확인하세요. 권한 제한을 속도 문제로 오해하지 않도록 주의합니다.

SOCKS5: 범용 전달 기능에 암호화가 포함되는 것은 아닙니다

SOCKS5는 다양한 연결을 전달하기 위한 프로토콜로, 인증 협상, 연결 요청, UDP 연결 등의 기능을 정의합니다. 프로토콜 자체가 일반적인 연결 암호화를 보장하지는 않습니다. 사용자 이름과 비밀번호가 있다고 해서 데이터가 암호화된 채널로 전송된다는 뜻도 아닙니다. 신뢰할 수 있는 기존 네트워크 환경이나 별도로 제공되는 보안 전송 방식과 함께 사용할 수 있습니다. 선택하기 전에 서버의 접근 범위와 보호 방식을 확인하세요. 입력 항목 수만으로 SOCKS5와 암호화 기능이 있는 프로토콜을 동일하게 비교해서는 안 됩니다.

SOCKS5에서 UDP를 사용하려면 양쪽의 구현, 서버의 허용 여부, 중간 네트워크의 연결 가능성이 모두 충족되어야 합니다. TCP 연결이 성공해도 UDP 연결까지 정상이라는 뜻은 아닙니다. 웹은 정상인데 실시간 서비스가 실패한다면 해당 경로를 별도로 확인하세요. 도메인을 어느 쪽에서 조회하는지도 결과와 접속 방식에 영향을 줄 수 있으므로 서버 주소만 확인해서는 부족합니다. 기존 설정을 관리할 때는 인증, 이름 조회, UDP 관련 원래 정보를 보관하고 실제 필요에 따라 하나씩 확인하세요. 무작정 설정을 바꾸는 것보다 문제를 찾기 쉽습니다.

VMess와 VLESS의 설계 차이

VMess: 인증 정보와 프로토콜 처리를 함께 확인하기

VMess는 사용자 인증과 프로토콜 단계의 데이터 처리 기능을 포함하며, 일반적으로 UUID로 사용자 정보를 식별합니다. 다른 전송 방식과 조합하는 경우가 많아 하나의 설정에 UUID, 프로토콜 보안 옵션, 전송 유형, 외부 TLS 항목이 함께 포함될 수 있습니다. UUID가 있다고 해서 연결 설정이 모두 끝난 것은 아닙니다. 주소와 포트는 연결 대상을 정하고, 인증은 서버가 접속을 허용할지 결정하며, 외부 설정은 실제 서비스까지 요청을 전달하는 방식을 정합니다. 어느 한 단계라도 일치하지 않으면 연결 시간이 초과되거나 연결이 끊길 수 있습니다.

직접 확인할 때는 UUID가 완전한지 먼저 살펴보세요. 복사 과정에서 공백이나 줄바꿈이 섞이거나 문자가 빠지지 않았는지 특히 주의합니다. 다음으로 서버가 요구하는 보안 옵션을 확인하고, 마지막으로 전송 관련 항목을 살펴보세요. 과거에 만들어진 설정에는 추가 항목이 있을 수 있으므로 다른 설정의 값을 그대로 적용하지 말고 현재 사용 중인 서버의 명확한 안내를 따르세요. 인증 단계가 시간과 관련된 경우 기기의 시간이 크게 어긋나 있어도 연결에 영향을 줄 수 있습니다. 시간을 정확하게 설정한 뒤 인증 정보를 갱신해야 하는지 확인하세요.

VLESS: 간결한 프로토콜이라고 보안 계층이 불필요한 것은 아닙니다

VLESS는 간결한 인증 및 요청 캡슐화를 중시하며 일반적으로 UUID를 사용합니다. 프로토콜 자체에서 범용 데이터 암호화를 제공하는 것을 주된 설계 목표로 삼지는 않습니다. 실제 구성에서는 사용 중인 보안 및 전송 방식을 함께 고려해야 합니다. ‘설정 항목이 적다’는 이유로 원격 서버의 신원을 확인하지 않아도 된다는 뜻은 아닙니다. UUID는 인증 정보이지 인증서 검증을 대신하는 자격 증명이 아닙니다. 전송 방식, TLS 설정, 서버에서 지정한 다른 항목도 모두 완전한 연결 설정의 일부이므로 함께 보관해야 합니다.

기존 설정에 특정 흐름 처리 옵션이 포함될 수도 있습니다. 이 항목은 서버의 처리 방식과 사용 가능한 전송에 따라 달라지며, 속도를 높이는 범용 스위치가 아닙니다. 정보에 명시되지 않았다면 온라인의 다른 설정을 참고해 임의로 채워 넣지 마세요. 안내된 항목이 있는데 현재 클라이언트의 선택 항목과 일치하지 않는 경우에도 이름이 비슷한 값으로 바꾸지 마세요. 조합을 반복해서 시도해 잘못된 가정을 세우기보다 앱의 기능과 서버 조건을 먼저 확인한 뒤 적용 여부를 판단하는 편이 안전합니다.

WebSocket 등 전송 방식은 관련 항목을 함께 맞춰야 합니다

WebSocket에서는 요청 경로와 Host를 주로 확인합니다. 경로가 서버의 요청 분기에 사용될 수 있으므로 대소문자, 앞쪽 슬래시, 기타 구성 요소에도 의미가 있을 수 있어 임의로 삭제해서는 안 됩니다. Host는 해당 요청의 라우팅에 사용됩니다. 실제 네트워크 연결 주소나 TLS의 Server Name과 반드시 같지는 않습니다. 서버가 요청을 여러 단계로 구분한다면 각 값은 서로 다른 역할을 할 수 있습니다. 모든 도메인을 하나의 주소로 통일하면 올바른 조합이 깨질 수 있습니다.

다른 전송 방식을 사용한다면 해당 방식의 설정 항목을 기준으로 확인하세요. 예를 들어 서비스 이름이 포함된 경우, 이름과 경로가 모두 텍스트라는 이유만으로 서로 바꿔 쓸 수는 없습니다. 외부 연결은 성립했는데 요청이 계속 실패한다면 요청이 진입점에는 도달했지만 올바른 백엔드로 전달되지 않았을 수 있습니다. 이때는 UUID를 새로 만들기보다 전송 설정과 서버의 요청 분기 조건을 함께 확인하세요. 잘못된 경로는 인증 정보를 바꿔도 해결되지 않으며, 그 반대도 마찬가지입니다.

iPhone에서 실제 부담을 비교하는 방법

VMess와 VLESS의 체감 차이는 함께 사용하는 전송 방식과 서버를 고려해야 합니다. TLS 핸드셰이크, 연결 재사용, 추가 캡슐화, 서버 부하가 프로토콜 형식 자체보다 최초 접속에 더 큰 영향을 줄 수 있습니다. 하나는 단순한 연결을 사용하고 다른 하나는 추가 중계 단계를 거친다면 속도 차이를 프로토콜 이름만으로 설명할 수 없습니다. 비교할 때는 네트워크, 대상, 전송 조건, 테스트 시간을 가능한 한 비슷하게 맞추고 최초 연결과 후속 요청을 따로 기록하세요.

장기간 사용한다면 처음 연결할 때의 결과만 기록하지 말고 네트워크 전환 후 복구도 확인해야 합니다. Wi-Fi에서 셀룰러 네트워크로 바뀌면 기존 연결을 다시 설정해야 할 수 있으며, 구체적인 동작은 전송 방식과 시스템 처리의 영향을 함께 받습니다. 전환할 때만 실패한다면 연결을 끊었다가 다시 연결했을 때 복구되는지 먼저 확인하고, 모든 서비스가 영향을 받는지도 기록하세요. 이를 통해 연결 유지 문제와 고정된 설정 오류를 구분하고, 재현 가능한 네트워크 상황을 프로토콜의 영구적인 문제로 오해하지 않을 수 있습니다.

Trojan 및 TLS 설정 확인

Trojan의 외부 보안 연결

Trojan은 프록시 요청과 인증을 TLS 연결 내부에서 처리하며, 검증된 보안 전송 방식을 사용해 트래픽을 전달하도록 설계되었습니다. 사용자 입장에서는 비밀번호, 서버 주소, TLS 신원 확인이 모두 충족되어야 합니다. 셋 중 하나를 선택하는 방식이 아닙니다. 비밀번호가 올바르더라도 서버 이름이 맞지 않거나 신뢰할 수 없는 인증서를 받았거나 포트가 잘못되면 정상적으로 연결할 수 없습니다. 외부 연결부터 내부 인증까지 순서대로 문제를 확인하세요.

TLS는 데이터를 암호화할 뿐 아니라 인증서 체인과 이름 일치를 통해 원격 서버의 신원을 확인하는 데도 사용됩니다. 핸드셰이크 단계에서 실패하면 정상적인 서비스 데이터가 전달되기 전에 연결이 중단됩니다. 따라서 ‘웹페이지가 열리지 않는다’는 결과만으로 비밀번호 오류라고 판단할 수 없습니다. 먼저 네트워크에서 접속 지점에 도달할 수 있는지 확인한 뒤 인증서 조건을 점검하세요. 보안 연결이 성립한 다음에 내부 인증과 대상 요청을 확인하면 여러 항목을 동시에 바꾸는 불필요한 작업을 줄일 수 있습니다.

연결 주소, Server Name, Host

서버 주소는 ‘어디에 네트워크 연결을 만들지’를 나타내고, Server Name은 TLS 핸드셰이크의 서버 이름 표시와 관련 신원 확인에 사용됩니다. 구체적인 항목 이름은 현재 화면을 기준으로 확인하세요. 기존 설정에서는 한 네트워크 주소로 접속하면서 이름 확인에는 별도로 제공된 도메인을 사용할 수 있습니다. 겉으로 보기에 다르다는 이유로 이를 임의로 수정해서는 안 됩니다. Server Name을 연결 주소로 바꾸면 인증서 이름과 일치하지 않을 수 있습니다. 주소만 바꾸고 서버 진입점은 확인하지 않으면 전혀 다른 서비스에 연결될 수도 있습니다.

Host는 해당 애플리케이션 요청에서 사용되며 Server Name과 역할이 다릅니다. 이 항목을 포함하는 전송 방식을 실제로 사용할 때만 안내에 따라 입력하세요. 해당 항목이 없는 연결에 임의로 의미를 추가해서는 안 됩니다. 여러 도메인이 함께 제공된 설정은 각 값이 어느 단계에 속하는지 기록하세요. 문제를 해결하기 쉬운 정보는 단순히 ‘서버 도메인’ 하나만 보관하는 것이 아닙니다. 연결 주소, TLS 이름, 요청 라우팅에 각각 어떤 값을 쓰는지, 어떤 항목이 기본값인지 명확히 기록해야 합니다.

인증서 오류를 검증 생략으로 해결하지 마세요

인증서 문제는 세 가지 기준으로 확인할 수 있습니다. 기기의 시간이 정확한지, 설정의 이름이 인증서 적용 범위와 일치하는지, 서버가 완전하고 신뢰할 수 있는 인증서 체인을 제공하는지 살펴보세요. 인증서 만료, 체인 누락, 이름 불일치는 서로 다른 문제이므로 해결 방법도 다릅니다. 클라이언트에서 확인할 수 있는 것은 로컬 설정과 시간입니다. 서버 인증서 배포 문제는 기존 서비스의 관리자가 해결해야 합니다. 비밀번호를 계속 바꿔도 인증서 체인은 수정되지 않으며, 오류 원인을 확인하는 작업을 대신할 수 없습니다.

인증서 검증을 건너뛰면 신원 확인 조건이 달라지므로 일상적인 문제 해결의 기본 단계로 사용해서는 안 됩니다. 검증을 끈 뒤에만 연결된다면 기존 신원 확인 단계에 문제가 있었다는 뜻일 뿐, 해당 서버가 신뢰할 수 있다는 증거는 아닙니다. 원래 설정을 보관하고 어떤 항목이 일치하지 않는지 확인한 뒤 정상적인 검증을 다시 적용하세요. 기존 서비스에 별도의 신뢰 정보가 필요한 경우에도 해당 정보의 출처와 적용 범위를 먼저 확인해야 합니다. 다른 연결에서 복사한 인증서 설정을 현재 설정에 임의로 적용하지 마세요.

TLS 부하와 장시간 연결

TLS 연결을 설정할 때는 추가 왕복 통신과 계산이 필요하지만 이후 요청에서는 연결을 재사용할 수 있습니다. 실제 영향은 앱의 동작과 네트워크 조건에 따라 달라집니다. 소량의 데이터를 자주 전송하며 연결을 끊고 다시 만드는 경우와 대용량 데이터를 전송하며 연결을 오래 유지하는 경우는 최초 접속 시간만으로 직접 비교할 수 없습니다. 신호가 약하면 재시도가 핸드셰이크 부하를 키워 배터리 변화가 프로토콜의 고정된 특성처럼 보일 수 있습니다. 테스트에서는 최초 연결, 연속 접속, 유휴 상태 후 복구를 구분해 어느 단계에서 차이가 발생하는지 확인하세요.

Trojan 설정에서 TLS 연결이 정상이라고 해서 UDP까지 사용할 수 있는 것은 아닙니다. 서버 지원 여부와 실제 서비스 동작을 함께 확인하세요. 웹은 정상인데 실시간 서비스에 문제가 있다면 먼저 라우팅을 확인하고 UDP 경로를 별도로 점검하세요. 인증서, 도메인, 전송에 관한 점검 방법은 TLS를 사용하는 다른 프로토콜에도 적용되지만, 그렇다고 서로 다른 프로토콜의 비밀번호나 요청 형식을 바꿔 쓸 수 있는 것은 아닙니다. 공통 단계에는 같은 점검 방법을 적용하되, 각 프로토콜의 내부 설정은 일치시켜야 합니다.

WireGuard의 키와 라우팅

요청 기반 프록시와 비교할 때의 차이

WireGuard는 IP 계층 터널을 만들도록 설계되었으며, 공개 키 방식으로 상대편을 식별하고 UDP를 통해 암호화된 데이터를 전달합니다. 대상 요청에 따라 프록시 연결을 만드는 프로토콜과는 확인 및 설정 단계가 완전히 같지 않습니다. Shadowrocket에서 사용할 때는 클라이언트가 트래픽을 해당 연결로 전달하는 방식과 원격 측에서 받은 데이터를 전달하는 방식도 함께 고려해야 합니다. 터널이 연결되었다고 해서 대상 라우팅, 이름 조회, 응답 경로까지 올바른 것은 아닙니다. 실제 서비스가 작동하는지 추가로 확인하세요.

WireGuard는 비교적 명확한 암호화 조합과 간결한 프로토콜 상태를 사용해 사용자가 알고리즘 조합을 직접 구성할 여지를 줄입니다. 그렇다고 모든 항목을 비워 둘 수 있는 것은 아닙니다. 로컬 주소, 키, 원격 접속 지점, 허용 주소 범위는 각각 다른 역할을 합니다. 서버는 현재 클라이언트의 공개 키를 인식하고 그에 맞는 네트워크 조건을 설정해야 합니다. 설정의 개인 키를 바꾸면서 원격 측 정보를 갱신하지 않으면 기존 신원 관계가 대개 유효하지 않게 됩니다.

Private Key, Public Key, Endpoint

Private Key는 로컬 신원을 증명하는 비밀 정보이므로 신뢰할 수 있는 설정 저장소에서만 사용해야 합니다. Public Key는 상대편을 식별하는 데 사용되며 같은 방식으로 비밀로 취급되지는 않습니다. 원격 Public Key를 입력할 때는 로컬 공개 키를 복사하는 것이 아니라 안내에 명시된 상대편의 공개 키를 사용하세요. 설정에 추가 사전 공유 키가 포함될 수도 있습니다. 이는 별도의 보안 정보이지 임의의 메모가 아닙니다. 이름에 모두 Key가 들어간다고 해서 서로 바꾸거나 하나를 삭제해 간단히 설정할 수 있다고 생각해서는 안 됩니다.

Endpoint는 원격 접속 주소와 포트를 나타내며, 터널 내부에서 사용하는 로컬 주소와는 다릅니다. 전자는 현재 네트워크에서 서버를 찾는 데 사용하고, 후자는 터널 내부의 데이터 통신에 사용합니다. 주소의 접두사 길이에도 명확한 네트워크 의미가 있으므로 장식 문자처럼 보고 제거해서는 안 됩니다. 가져온 뒤 설정이 불완전하다는 메시지가 표시되면 원본 정보를 다시 확인하세요. 기기의 현재 Wi-Fi 주소로 대신 입력하지 마세요. 실제 네트워크 주소와 터널 주소는 서로 다른 단계이므로 혼용하면 문제 해결이 더 어려워집니다.

Allowed IPs, DNS, MTU

WireGuard에서 Allowed IPs는 상대편이 받을 수 있는 대상 범위와 수신 출처 확인에 관련됩니다. 클라이언트에서 어떤 옵션을 제공하고 자체 라우팅과 어떻게 연동하는지는 현재 화면과 기존 설정을 기준으로 확인하세요. 이를 Shadowrocket 규칙 목록의 다른 표기 방식처럼 임의로 수정해서는 안 됩니다. 특정 내부 네트워크만 허용하는 터널을 선택했다고 해서 완전한 인터넷 접속이 자동으로 제공되는 것도 아닙니다. 원격 측의 전달, 외부 출구, 응답 라우팅이 해당 대상을 지원하는지 확인해야 합니다.

DNS는 이름을 주소로 바꾸고, 터널 라우팅은 변환된 주소까지 도달하는 방법을 정합니다. 두 항목을 따로 확인하세요. 알고 있는 주소로는 접속되지만 도메인으로 접속되지 않는다면 먼저 이름 조회 경로를 살펴볼 수 있습니다. 도메인이 정상적으로 조회되지만 연결되지 않는다면 대상 범위와 원격 전달을 확인하세요. MTU는 캡슐화 이후 패킷 크기에 영향을 줍니다. 너무 크면 작은 요청은 성공하지만 큰 응답이 멈추는 현상이 나타날 수 있습니다. 그렇다고 일반적인 값으로 임의 변경하지 말고 기존 값을 보관하세요. 증상을 확인한 뒤 서버 안내에 따라 변수 하나만 바꿔 테스트합니다.

모바일 네트워크에서 연결 유지와 복구

연결 유지는 특정 환경에서 네트워크 매핑을 유지하는 데 사용되며, 주기가 짧을수록 좋은 것은 아닙니다. 유휴 상태 이후에도 들어오는 데이터를 받아야 하는 환경에서는 도움이 될 수 있지만 주기적인 통신과 무선 기기 활성화를 늘립니다. 필요한지와 설정 방법은 서버의 역할, 네트워크 매핑 유지 시간, 실제 서비스 요구 사항을 고려해 정해야 합니다. 화면에서 계속 활성 상태로 보이게 하려고 설정하지 마세요. 사용자가 요청을 보내는 일반적인 상황에서 연결 유지 간격을 짧게 하는 것은 모든 서비스의 속도를 높이는 범용 방법이 아닙니다.

WireGuard의 상대편 식별 방식은 조건이 맞으면 접속 주소가 바뀌는 경우를 처리할 수 있지만, 네트워크 전환 후 복구 여부는 시스템, 서버, 현재 UDP 연결 가능성에 영향을 받습니다. 연결이 계속 유지된다고 보장할 수는 없습니다. 테스트에는 유휴 상태 이후의 첫 요청과 네트워크 전환 후 실제 요청을 포함하고, 대상 트래픽이 실제로 터널을 통과하는지 확인하세요. 문제 기록을 공유할 때는 Private Key, 추가 사전 공유 키, 내부 네트워크 정보를 숨기고 필요한 증상, 항목 이름, 오류 유형만 남기세요. 전체 설정을 공유해 편리하게 문제를 해결하려고 해서는 안 됩니다.

Hysteria2의 네트워크 사용 조건

패킷 손실과 혼잡 문제를 바탕으로 설계 이해하기

Hysteria2는 QUIC 기반으로 프록시 통신을 구성합니다. QUIC는 UDP 위에서 동작하며 보안 핸드셰이크, 스트림 관리, 혼잡 제어 등의 기능을 포함합니다. 설계 목표 중 하나는 품질이 서로 다른 네트워크 경로에 맞춰 전송 동작을 조정하는 것입니다. 그렇다고 물리적인 네트워크 한계가 사라지는 것은 아닙니다. 무선 신호가 약하거나 서버의 외부 회선이 부족하거나 중간 네트워크가 해당 UDP 트래픽을 허용하지 않으면 연결 실패나 처리량 저하가 발생할 수 있습니다. 현재 네트워크에서 전송 조건이 충족되는지 먼저 확인한 뒤 성능을 살펴보세요.

QUIC의 다중 스트림 방식은 전송 계층의 순차 전달로 인해 스트림 간에 발생할 수 있는 일부 대기 현상을 줄일 수 있습니다. 하지만 회선 대역폭, 혼잡, 공유 서버 리소스는 여전히 공통 제약입니다. 어떤 요청이든 더 이상 기다릴 필요가 없다거나 게임과 음성 통화의 지연이 반드시 낮아진다고 이해해서는 안 됩니다. 인터랙티브 서비스는 대기열과 패킷 손실에 민감하고, 지속 전송은 안정적인 처리량이 중요합니다. 같은 설정이 한 항목을 개선하면서 다른 항목에는 영향을 주지 않을 수도 있으므로 테스트 결과를 구분해 기록하세요.

인증, 이름, 난독화 설정

설정할 때는 서버 주소, 포트, 인증 정보를 먼저 확인한 뒤 TLS 이름과 인증서 검증을 점검하세요. 인증 문자열은 완전한 상태로 유지해야 하며 메모처럼 보인다고 일부를 잘라서는 안 됩니다. TLS를 사용하는 다른 연결과 마찬가지로 실제 연결 주소와 신원 확인에 사용하는 이름은 서로 다른 역할을 할 수 있으므로 제공된 정보를 기준으로 입력하세요. 클라이언트에서 보안 연결이 아직 성립하지 않았다면 인증 정보가 만료됐다고 판단하기 전에 외부 접속 가능 여부와 이름 일치를 확인하세요.

일부 서버는 추가 난독화 설정을 제공하며, 서버에서 같은 방식과 값을 명시적으로 사용하는 경우에만 활성화해야 합니다. 난독화는 신원 인증을 대신하지 않으며 속도를 높이는 별도 스위치도 아닙니다. 클라이언트와 서버 중 한쪽만 활성화했거나 비밀번호가 다르면 정상적인 프로토콜 처리 단계에 들어가기 전에 데이터가 인식되지 않을 수 있습니다. 가져온 설정의 값은 그대로 유지하세요. 직접 수정하기 전에 복사본을 저장하고, 현재 정보에 값을 보충하려고 다른 설정의 비슷해 보이는 옵션을 가져오지 마세요.

대역폭 값은 조건일 뿐 속도를 보장하지 않습니다

기존 설정에 업로드 및 다운로드 대역폭 항목이 있다면 먼저 방향과 단위를 구분하고 혼잡 제어 동작에 어떤 영향을 줄 수 있는지 이해하세요. 실제 회선 성능보다 훨씬 높은 값을 입력해도 사용 가능한 대역폭이 늘어나지 않습니다. 오히려 대기열, 패킷 손실, 다른 서비스와의 자원 경합을 일으킬 수 있습니다. 모바일 네트워크의 성능은 위치와 시간에 따라 바뀌므로 고정된 예상값이 항상 적절한 것은 아닙니다. 서버 권장값이나 클라이언트의 합리적인 기본값을 먼저 유지하고 지속적인 테스트를 통해 조정이 필요한지 확인하세요.

웹페이지는 처음에 정상적으로 열리지만 대용량 전송에서 변동이 크다면 네트워크별 결과를 비교하고 다른 서비스에도 영향이 있는지 확인하세요. 전송을 시작한 뒤 음성 통화가 끊긴다면 회선 혼잡이나 자원 경합 때문일 수 있으며 인증 또는 TLS 설정 문제라고 단정할 수 없습니다. 테스트 중 동시에 사용하는 작업을 줄이고 다른 대용량 전송을 잠시 중단한 뒤 같은 대상을 다시 확인하면 부하가 주원인인지 판단하는 데 도움이 됩니다. 아직 확인하지 못한 병목을 가리기 위해 대역폭 값을 반복해서 높이지 마세요.

UDP 연결 가능성과 배터리 사용의 한계

어떤 네트워크에서 웹사이트에 접속할 수 있다고 해서 필요한 UDP 포트까지 연결할 수 있다는 뜻은 아닙니다. Hysteria2가 한 네트워크에서는 작동하고 다른 네트워크에서는 실패한다면 설정을 유지한 채 하위 네트워크의 연결 가능성에 차이가 있는지 먼저 확인하세요. 비밀번호를 반복해서 바꾸면 올바른 설정을 망가뜨릴 수 있으며 전송 경로가 제한된 문제는 해결할 수 없습니다. 사용할 수 있는 다른 완전한 설정이 있다면 같은 네트워크에서 교차 확인할 수 있지만, 결과는 해당 네트워크 조건에 한정해야 합니다. 모든 상황에서의 프로토콜 우열로 확대 해석하지 마세요.

iPhone에서는 높은 처리량으로 짧은 시간에 더 많은 데이터를 처리할 수 있지만 무선 통신과 프로세서의 부하가 커질 수도 있습니다. 사용 시간, 총 전송량, 유휴 상태 이후 재연결 동작 모두 배터리 결과에 영향을 주므로 화면에 표시되는 순간 속도만으로 판단해서는 안 됩니다. 네트워크를 바꾼 뒤에는 연결 스위치만 보지 말고 서비스가 복구되었는지 다시 확인하세요. 연결 실패가 반복된다면 테스트 강도를 낮추고 현상을 기록한 다음 확인된 설정으로 돌아가 전송 조건, 설정값, 서버 조건을 하나씩 확인하세요.

설정값 확인 및 규칙 분기

가져오기에 성공했다고 서버 연결까지 확인된 것은 아닙니다

Subscribe를 통해 기존 구독을 가져오면 클라이언트가 해당 정보를 읽고 해석할 수 있다는 점은 확인됩니다. 그렇다고 각 연결이 모두 인증을 통과하거나 같은 기능을 제공한다는 뜻은 아닙니다. 가져온 뒤 대상 설정의 유형, 주소, 포트, 필요한 전송 항목이 제공된 설명과 일치하는지 확인하세요. 이름은 설정을 구분하기 위한 라벨일 뿐 프로토콜 유형을 판단하는 근거가 아닙니다. 라벨에는 특정 프로토콜이라고 표시되어 있는데 실제 유형이 다르면 라벨만 보고 추측해 변경하지 말고 원본 정보를 확인하세요.

QR 코드와 공유 텍스트도 설정 정보를 전달하는 방식이므로 인코딩, 이스케이프, 항목 매핑에 따라 가져오기 결과가 달라질 수 있습니다. 복사할 때 일부 문자가 빠졌거나 설명까지 함께 선택했거나 내용이 불완전하게 인식되면 오류가 발생할 수 있습니다. 직접 입력하기 전에 원본 정보가 완전한지 먼저 확인하세요. 구독을 업데이트하면 로컬에서 변경한 값이 덮어써질 수도 있습니다. 테스트를 위해 설정을 바꾸기 전에 별도 복사본과 출처를 기록해 임시 수정 사항을 이후 업데이트에서도 유지된다고 오해하지 않도록 하세요.

Global Routing에서 규칙 사용 여부 결정

Global Routing의 Config, Proxy, Direct는 각각 설정에 따른 처리, 프록시 처리, 직접 연결에 해당하는 전체 동작 방식입니다. 평소 사이트별로 트래픽을 나눌 때는 Config를 사용하고 현재 활성화된 설정 파일을 확인하세요. Proxy는 영향 범위를 이해한 상태에서 프록시 경로를 확인하는 데 사용할 수 있지만 규칙 전체를 점검하는 일을 대신하지 않습니다. Direct는 프록시 프로토콜이 정상 작동한다는 근거가 될 수 없습니다. 동작 방식, 현재 서버, 현재 설정은 서로 다른 상태이므로 각각 기록해야 합니다.

규칙은 보통 위에서 아래로 확인하며 앞쪽 규칙에 먼저 일치하면 뒤의 더 구체적인 규칙은 실행되지 않을 수 있습니다. DOMAIN은 전체 도메인과 일치하고, DOMAIN-SUFFIX는 해당 도메인과 하위 도메인에 일치하며, DOMAIN-KEYWORD는 도메인의 키워드를 기준으로 일치합니다. IP-CIDR은 IP 주소 범위에 적용되고 GEOIP는 해당 주소의 지리적 분류에 따라 처리합니다. FINAL은 앞선 규칙과 일치하지 않은 경우를 처리합니다. 규칙마다 대상이 다르므로 도메인이나 주소를 사용한다는 이유만으로 서로 바꿔서는 안 됩니다. 이름 조회 조건도 일부 주소 기반 규칙의 판단에 영향을 줄 수 있습니다.

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

이 예시는 규칙 순서를 보여줄 뿐 서버 정보가 포함되어 있지 않으며, 그 자체로 연결을 만들 수 있는 완전한 설정도 아닙니다. 더 넓은 DOMAIN-SUFFIX 규칙에 먼저 일치하지 않도록 구체적인 REJECT를 앞에 배치합니다. PROXY는 현재 사용할 수 있는 프록시 연결을 기준으로 해석해야 하며, FINAL,DIRECT는 다른 규칙과 일치하지 않는 요청을 직접 연결한다는 뜻입니다. 예시 도메인은 문법 설명을 위한 것입니다. 기존 설정에서 사용자 지정 정책 이름을 사용한다면 해당 이름의 정의를 확인하세요. 낯선 이름을 모두 PROXY로 바꾸면 안 됩니다.

실제 연결 기록으로 판단 마무리하기

하나의 서비스가 페이지, 정적 리소스, 인증, 실시간 통신 등 여러 도메인에 요청을 보낼 수 있습니다. 메인 페이지가 열려도 모든 요청이 같은 정책에 적용됐다고 볼 수 없으며, 구성 요소 하나의 실패만으로 프로토콜 전체가 작동하지 않는다고 판단할 수도 없습니다. 확인할 때는 실제 연결의 대상과 적용된 정책을 살펴보고 규칙 불일치, 연결 실패, 대상 서버의 응답 오류를 구분하세요. 특정 리소스를 고치려고 모든 규칙을 삭제하지 마세요. 그러면 기존 설정의 목적을 잃고 실제로 효과가 있었던 변경 사항도 파악하기 어려워집니다.

규칙 대상의 의미를 더 알아보려면 규칙 키워드 설명을 참고하세요. 지정한 사이트에만 프록시를 적용하는 방법은 특정 사이트에 규칙을 적용하는 방법에서 확인할 수 있습니다. REJECT를 사용한다면 REJECT 적용 범위도 살펴보세요. 프로토콜은 연결 방법을 정하고 규칙은 연결을 사용할 시점을 정합니다. 각각을 먼저 확인한 뒤 함께 사용해야 문제 해결 기록을 정확히 해석할 수 있습니다.

속도·배터리·문제 원인 확인

같은 조건의 테스트 기록부터 만들기

설정을 비교할 때는 기기, 네트워크, 대상, Global Routing을 고정하고 눈에 띄는 다른 대용량 작업을 중단하세요. 가능하면 비슷한 시간대에 테스트합니다. 매번 최초 연결, 반복 접속, 지속 전송 결과를 따로 기록하고 한데 섞지 마세요. Connectivity Test는 연결 가능성을 확인하는 데 도움이 되지만 테스트 대상과 연결 방식이 실제 서비스와 다를 수 있습니다. 단일 테스트 결과로 실제 서비스가 정상이라고 판단할 수는 없습니다. 테스트가 끝나면 원래 라우팅 방식으로 되돌려 임시 설정이 일상적인 연결에 영향을 주지 않도록 하세요.

배터리를 비교할 때는 사용 시간과 총 전송량을 비슷하게 맞추고 화면, 신호, 백그라운드 활동을 통제하세요. 시스템 배터리 화면은 시스템의 집계 기준에 따른 앱 활동을 보여주는 것이며 프로토콜의 전력 사용량을 별도로 측정한 결과가 아닙니다. 짧은 테스트는 시작 작업, 캐시, 무선 상태의 영향을 받기 쉽습니다. 기기가 계속 뜨거워진다면 고부하 테스트를 중단하고 대량 전송이나 반복 재연결이 있는지 확인하세요. 원인을 파악하기 전에 동시 작업을 늘리면 비교 조건이 더 불안정해집니다.

설정을 무작위로 바꾸지 말고 실패 단계에 따라 확인하기

연결을 전혀 만들 수 없다면 현재 네트워크가 정상인지, 접속 주소와 포트가 맞는지 확인한 다음 프로토콜 유형을 점검하세요. UDP를 사용하는 연결은 해당 경로에 접속할 수 있는지도 별도로 확인해야 합니다. TLS 연결이라면 이름, 기기의 시간, 인증서 조건을 확인하세요. 외부 연결은 성립했지만 인증이 거부되면 그때 비밀번호, UUID, 키를 확인합니다. 한 번에 한 항목만 바꾸고 원래 값을 보관하세요. 개선되지 않으면 즉시 되돌려 원래 맞았던 항목까지 새 문제로 만들지 않도록 합니다.

연결 상태가 정상인데 서비스가 작동하지 않으면 실제 트래픽이 예상한 규칙을 따르는지 먼저 확인한 다음 이름 조회, 대상 연결, 서비스 응답을 구분하세요. 알려진 IP 주소로는 접속되지만 도메인으로는 실패한다면 DNS를 먼저 확인할 수 있습니다. 특정 대상만 실패한다면 대상 자체나 서버의 접속 조건을 점검하세요. 큰 응답만 멈춘다면 MTU, 패킷 손실, 회선 품질을 추가로 살펴볼 수 있습니다. 이는 문제 해결을 위한 단서이지 증상만으로 내릴 수 있는 확정적인 결론은 아닙니다. 다른 가능성을 제외하려면 다음 단계의 확인이 필요합니다.

네트워크를 바꾸거나 유휴 상태로 둔 뒤에만 실패한다면 발생 조건, 대기 시간, 재연결 이후의 변화를 기록하세요. 수동으로 다시 연결했을 때 복구된다면 고정 설정은 적어도 한 번 정상 작동한 것이므로 모든 인증 정보를 다시 입력하기보다 연결 복구, 네트워크 매핑, 서버의 세션 처리 방식을 살펴보세요. On Demand는 설정에 따라 연결 동작에 영향을 주므로 함께 기록해야 하지만, 잘못된 인증이나 서버 기능 누락을 해결해주지는 않습니다. 먼저 수동 연결에서 재현 가능한 결과를 얻은 다음 필요 시 연결 조건을 조정하세요.

사용 사례에 따라 선택 범위 좁히기

일반적인 웹 탐색에는 설정이 안정적이고 항목이 명확하며 최초 접속과 재접속 결과가 일관된 기존 연결을 우선 고려할 수 있습니다. 실시간 통신이 필요하다면 UDP 사용 가능 여부와 지연 변동을 먼저 확인하세요. 접근이 제한된 내부 네트워크에서는 라우팅 범위, 주소 충돌, DNS를 점검합니다. 대용량 작업을 지속한다면 처리량의 안정성과 다른 서비스에 미치는 영향을 살펴보세요. 이는 테스트 순서에 관한 안내이지 프로토콜 순위가 아닙니다. 서버에서 실제 지원하는 기능만 해당 사용 사례의 비교 대상이 될 수 있습니다.

유지 관리 기록에는 프로토콜 유형, 외부 전송 방식, 사용 네트워크, Global Routing, 실패한 대상 유형, 재현 단계가 포함되어야 합니다. 기존 서비스 관리자에게 공유하기 전에 구독 주소, 인증 정보, 개인 키 및 기타 민감한 값을 숨기세요. 스크린샷에도 문제 해결에 필요한 부분만 남기세요. 처음 연결할 때 시스템 권한 안내가 표시되면 VPN 구성 추가 안내를 참고하세요. 자주 쓰는 항목의 의미는 용어집에서 확인하고 전체 조작 순서는 빠른 시작 가이드를 참고하세요.