Shadowrocket
프로토콜 선택 및 설정 항목 안내

01 / 프로토콜·전송·규칙 구분하기

서버와 같은 프로토콜 유형 선택

Add Server에서 유형을 선택하는 것은 클라이언트와 서버가 주고받을 데이터 형식을 지정하는 일입니다. Shadowsocks, VMess, VLESS, Trojan 등의 이름은 인증 방식과 데이터 구성의 차이를 나타내며, 임의로 바꿔 쓸 수 있는 속도 설정이 아닙니다. 기존 정보에 VLESS라고 적혀 있다면 다른 프로토콜이 더 간단해 보인다는 이유로 Trojan을 선택할 수 없습니다. 연결하려면 서버와 클라이언트의 프로토콜, 인증 정보, 전송 방식이 서로 일치해야 합니다.

설정을 이해할 때는 연결을 네 계층으로 나눠 살펴보면 좋습니다. 가장 아래는 기기에서 서버까지의 네트워크 연결 가능 여부이고, 그 위에는 TCP, UDP 또는 이를 기반으로 하는 전송 방식이 있습니다. 다음은 프로토콜 인증과 선택적 TLS이며, 마지막은 요청이 대상 서비스에 도달하는 단계입니다. Config의 규칙은 요청별 정책을 결정할 뿐 서버 비밀번호를 바로잡아 주지는 않습니다. 계층을 나눠 확인해야 인증 오류가 났을 때 DNS를 계속 바꾸거나, 규칙이 잘못 적용될 때마다 프로토콜을 교체하는 일을 피할 수 있습니다.

주소·인증 정보·전송 설정을 따로 확인

서버 주소는 연결할 지점을 찾고, 포트는 해당 지점에서 서비스를 구분합니다. 주소는 도메인 또는 IP일 수 있으며, 도메인을 입력하면 별도의 이름 해석 과정이 추가됩니다. 인증 항목은 연결에 필요한 권한을 확인하는 정보로 Password, UUID 또는 키 형태일 수 있습니다. 전송 항목은 WebSocket의 Path나 HTTP Host처럼 요청을 서버로 전달하는 방식을 지정합니다. 주소와 인증 정보가 올바르더라도 전송 경로가 맞지 않으면 핸드셰이크가 중단될 수 있습니다.

구독을 가져오면 보통 이러한 항목이 서버 설정에 함께 저장됩니다. 따라서 처음 문제를 확인할 때는 가져온 원래 값을 유지하고, 사용자가 보유한 정보와 항목별로 비교하세요. 의미를 모르는 항목을 먼저 지우거나 다른 서버 설정의 값을 현재 항목에 섞지 마세요. 추가 전송 항목이 화면에 표시되지 않는 것은 해당 조합에 필요하지 않거나 선택한 유형과 관련이 있을 수 있습니다. 무관한 예시를 그대로 복사하기보다 현재 앱 화면과 기존 설정을 기준으로 확인하세요.

속도와 배터리 사용량은 같은 조건에서 비교

iOS에서는 프로토콜 처리에 프로세서 자원이 들지만, 무선 신호, 재전송, 화면 밝기와 백그라운드 활동도 큰 영향을 줍니다. 핸드셰이크가 짧다고 대용량 파일이 더 빠르다고 단정할 수 없고, 대역폭을 빠르게 채우는 프로토콜이 장시간 저부하 대기에도 적합하다고 볼 수도 없습니다. 짧은 연결에서는 핸드셰이크와 이름 확인에 드는 비용이 두드러지고, 지속 다운로드에서는 대역폭, 혼잡 제어 및 서버 부하가 더 큰 영향을 줍니다. 성능을 평가하기 전에 어떤 작업을 측정하는지부터 정하세요.

프로토콜 선택으로 서버가 연결된 네트워크의 기본 조건이 바뀌지는 않습니다. 같은 프로토콜도 접속 지점에 따라 지연 시간과 처리량이 크게 달라질 수 있고, 서로 다른 프로토콜도 같은 혼잡 구간을 이용하면 함께 느려질 수 있습니다. 비교할 때는 기기, 네트워크, 대상 리소스와 측정 시간을 동일하게 맞추고, 다른 대용량 작업은 중지하세요. 연결 성공 여부, 첫 요청까지 걸린 시간, 지속 전송의 안정성을 기록합니다. 한 번 측정한 순위를 언제나 적용되는 결론으로 받아들이지 마세요.

02 / Shadowsocks: 암호화 방식과 비밀번호 확인

프록시 전송에 맞춘 연결 구조

Shadowsocks는 비교적 간단한 방식으로 프록시 트래픽을 전달하고, 클라이언트와 서버 사이에 인증 및 암호화 처리를 더하도록 설계되었습니다. 전체 가상 네트워크 구성을 이해하지 않아도 서버 주소, 포트, 암호화 방식과 비밀번호를 중심으로 설정할 수 있습니다. 항목이 적으면 확인이 쉬울 수 있지만, 어떤 조합이든 유효하다는 뜻은 아닙니다. 암호화 방식도 프로토콜 호환성을 구성하는 요소입니다.

기존 설정에서 흔히 볼 수 있는 암호화 방식은 이름에 알고리즘, 작동 방식 또는 키 길이가 표시됩니다. 휴대폰 모델에 따라 더 빠를 것 같은 항목을 고르는 것이 아니라 서버 설정과 정확히 일치시켜야 합니다. 방식에 따라 비밀번호 처리 및 메시지 형식이 다를 수 있으며, 클라이언트에 항목을 저장할 수 있다고 해서 서버가 이를 받아들인다는 보장은 없습니다. 서로 다른 인증 정보 형식을 요구하는 변형 프로토콜이라면 일반 비밀번호를 임의로 입력하지 말고 기존 설정을 그대로 따르세요.

핵심 항목 네 가지를 하나씩 점검

서버 주소에는 실제 접속 주소를 입력하세요. 공유 링크 전체를 주소 칸에 붙여 넣지 마세요. 포트는 서버에서 안내한 숫자를 입력하고, 복사 과정에서 공백, 콜론 또는 설명 문구가 섞이지 않았는지 확인하세요. Password는 대소문자와 기호를 그대로 유지해야 합니다. 메신저에서 복사할 때 줄바꿈이 들어가지 않았는지도 확인하세요. Method는 암호화 방식을 지정하는 항목이므로 문자를 정확히 대조해야 합니다. 공유 링크만 받은 경우에는 먼저 가이드에 따라 가져온 뒤 변환된 설정을 확인하는 편이 직접 분해하는 것보다 인코딩 문자를 빠뜨릴 가능성이 적습니다.

일부 구성에는 추가 플러그인이나 전송 관련 설정이 포함됩니다. 이는 장식용 옵션이 아니라 연결 경로의 일부입니다. 서버가 추가 캡슐화를 요구하는데 클라이언트에 해당 설정이 없으면 같은 형식으로 통신할 수 없습니다. 반대로 일반 접속 지점에 임의로 추가 설정을 넣어서도 안 됩니다. 용도를 확인할 수 없다면 본인이 이용하는 서비스 제공자에게 문의하세요. 인터넷에서 찾은 “공통값”으로 기존 설정을 덮어쓰거나, 호환성을 확인하는 대신 검사를 끄지 마세요.

TCP가 된다고 UDP도 되는 것은 아님

Shadowsocks는 TCP 및 UDP 전송을 지원할 수 있지만, 실제 사용 가능 여부는 서버, 네트워크 경로와 클라이언트 설정에 따라 달라집니다. 웹페이지가 열렸다는 것은 해당 시점의 요청 경로가 작동했다는 뜻일 뿐, UDP가 필요한 앱도 정상 작동한다는 의미는 아닙니다. 웹은 되는데 실시간 앱이 실패한다면 암호화 방식을 바로 바꾸지 말고 앱이 실제로 사용하는 전송 방식부터 확인한 뒤 서버가 해당 기능을 제공하는지 살펴보세요.

UDP 패킷에는 크기 제한이 있어 추가 캡슐화로 사용할 수 있는 페이로드 공간이 줄어들 수 있습니다. 작은 패킷은 정상이지만 큰 패킷이나 지속적인 트래픽에서 문제가 생긴다면 경로 MTU, 패킷 손실과 단편화 가능성을 확인하세요. 이 경우 Password를 반복해서 바꿔도 대개 해결되지 않습니다. 인증 문제라면 특정 패킷 크기에서만 일관되게 문제가 발생하지 않기 때문입니다. 모든 대상에서 문제가 생기는지, 특정 작업에서만 생기는지 기록하고 같은 서버에 간단한 요청을 보내 비교해 원인 범위를 좁히세요.

iOS에서 처리 부하 살펴보기

기기와 구현이 잘 맞는 환경에서는 최신 인증 암호화 방식으로 많은 트래픽을 효율적으로 처리할 수 있지만, 실제 성능은 서버 처리 능력과 네트워크 대역폭의 영향을 받습니다. 처리량이 높은 상태로 오래 지속되면 암호화, 데이터 송수신과 무선 통신으로 기기 온도가 올라갈 수 있습니다. 대기 중에는 실제 트래픽이 발생하는지 확인해야 합니다. 설정 항목이 적다는 이유만으로 항상 배터리를 가장 적게 쓴다고 결론 내릴 수 없으며, 기기 발열을 특정 알고리즘 탓으로만 돌릴 수도 없습니다.

문제를 확인할 때는 먼저 원래 설정을 보존한 뒤 주소, 포트, Method 및 Password를 하나씩 확인하세요. Connectivity Test와 실제 대상 요청을 각각 실행해 검증합니다. 모든 요청이 실패하면 접속 주소와 인증 정보를 먼저 살피고, 특정 앱에서만 문제가 생기면 UDP, DNS 및 규칙 경로를 확인하세요. 프로토콜 전반의 문제 위치를 파악할 때는 프로토콜 유형 개요도 참고하세요. 실제 입력값은 보유한 서버 정보를 기준으로 해야 합니다.

03 / VMess와 VLESS: ID 외에 전송 설정도 확인

설정 모양이 비슷해도 같은 프로토콜은 아님

VMess와 VLESS는 모두 UUID 형식의 ID를 사용하고 여러 전송 방식과 조합할 수 있어 처음 보면 헷갈릴 수 있습니다. VMess는 사용자 인증과 프로토콜 내부의 데이터 보호 방식을 함께 구성합니다. VLESS는 프로토콜 자체의 처리를 간소화하고, 데이터 보호는 호환되는 보안 전송 조합에 맡기는 데 중점을 둡니다. 메시지 형식과 인증 절차가 서로 다르므로 UUID 형식이 같다고 유형만 바꿔 연결할 수 있는 것은 아닙니다.

UUID는 사용자 ID를 나타내는 값이지 서버 도메인이나 표시 이름이 아닙니다. 복사할 때 전체 형식을 유지하고 문자를 빠뜨리거나 눈에 보이지 않는 공백을 넣지 마세요. 일부 설정에는 인증 방식 또는 호환성과 관련된 항목이 추가로 포함됩니다. 오래된 안내만 보고 채우지 마세요. VMess의 일부 과거 설정은 현재의 모든 구성에 필요한 것이 아닙니다. 기존 정보와 화면이 일치하지 않으면 값을 임의로 만들어 넣기보다 설정 출처와 현재 지원되는 조합을 먼저 확인하세요.

전송 방식에 따라 서버의 연결 처리 방법이 달라짐

같은 프로토콜도 서로 다른 전송 방식으로 사용할 수 있습니다. TCP를 직접 사용하는 조합에는 보통 WebSocket 경로가 없습니다. WebSocket을 사용하면 Path와 Host에 따라 요청이 전달되는 백엔드가 달라질 수 있으며, 다른 전송 방식에는 별도의 서비스 식별 정보가 필요할 수 있습니다. 이런 항목은 전송을 맞추기 위한 설정이지 UUID를 대체하는 비밀번호가 아닙니다. 주소와 UUID만 입력하고 전송 항목을 빠뜨리는 것은 설정을 가져오는 과정이 불완전할 때 자주 발생하는 실패 원인입니다.

Path는 맨 앞 슬래시, 대소문자와 기존 쿼리 문자열을 그대로 유지하세요. 사용자에게 보여 주는 메모처럼 다루면 안 됩니다. Host와 서버 주소는 서로 다를 수 있습니다. Host는 애플리케이션 계층 라우팅에 사용될 수 있고, 서버 주소는 네트워크 연결을 설정합니다. TLS도 사용한다면 보안 핸드셰이크용 Server Name 또는 SNI가 별도로 있을 수 있습니다. 세 값이 같은 경우도 있지만 역할은 서로 다르므로 서버 IP로 전부 바꾸지 말고 각 설정에 지정된 값을 입력하세요.

VLESS의 간소화가 보안 계층 생략을 뜻하지는 않음

VLESS를 설명할 때는 “프로토콜 자체가 특정 암호화를 제공하지 않는다”는 것과 “연결 전체가 보호되지 않는다”는 것을 구분해야 합니다. 실제 보안 수준은 함께 사용하는 보안 전송 및 인증 방식에 따라 달라집니다. 프로토콜 이름만으로 보안 여부를 판단하거나 화면의 특정 항목에 암호화되지 않는다고 표시되어 있다는 이유로 TLS를 임의로 끄지 마세요. 서버가 특정 보안 조합을 요구한다면 관련 설정을 모두 유지하고, 안내가 부족하다면 연결 전에 정보를 확인하세요.

일부 설정에는 Flow와 같은 추가 항목이 있습니다. 이는 특정 작동 방식을 지정하므로 어디서나 켜도 되는 성능 옵션이 아닙니다. 잘못 입력하면 인증 후 연결이 끊기거나 서버가 요청을 거부할 수 있습니다. 기존 공유 정보를 기준으로 삼고 Shadowrocket의 현재 화면에서 해당 조합을 설정할 수 있는지 확인하세요. 화면에 해당 기능이 없다면 메모에 값을 넣는 방식으로 구현할 수 없습니다. 서버에서 호환되는 다른 접속 지점을 제공하는지 확인하세요.

핸드셰이크·기기 시간·모바일 네트워크 전환

시간 검증을 사용하는 인증 절차는 기기 시각의 오차에 영향을 받을 수 있습니다. 접속 지점은 연결되지만 인증이 계속 실패한다면 시스템 날짜와 시간이 올바른지 확인하세요. 그렇다고 모든 실패를 시간 문제로 설명해서는 안 됩니다. TLS와 추가 전송을 함께 사용하는 경우 첫 요청에 여러 단계의 핸드셰이크가 포함될 수 있습니다. 연결이 지속된 뒤에는 이 고정 비용이 분산되므로 웹페이지 첫 로딩과 대용량 파일 속도에서 서로 다른 순위가 나올 수 있습니다.

iOS에서 Wi-Fi와 셀룰러 네트워크를 전환하면 기존 연결을 다시 설정해야 할 수 있습니다. 전환 후 새 요청이 성공하는지 살펴보세요. 진행 중인 모든 다운로드가 끊김 없이 이어져야 한다고 기대할 필요는 없습니다. VMess와 VLESS를 비교할 때는 전송 방식과 서버 조건을 최대한 동일하게 맞추세요. 그렇지 않으면 차이가 WebSocket, TLS 또는 접속 지점 부하에서 비롯되었을 수 있습니다. VLESS 설정을 더 자세히 확인하려면 먼저 현재 설정을 저장하고, 수정이 필요한 항목 하나만 변경하세요.

04 / Trojan: TLS 내부의 비밀번호 인증 이해하기

TLS는 보안 연결을, 비밀번호는 사용 권한을 담당

Trojan은 검증된 TLS 연결을 통해 프록시 프로토콜을 전달하고, 그 연결 내부에서 인증과 요청 전달을 처리하도록 설계되었습니다. 두 가지 검사를 구분해서 이해해야 합니다. 먼저 클라이언트는 신뢰할 수 있는 TLS 서비스에 연결하고 있는지 확인해야 합니다. 다음으로 서비스는 클라이언트가 제출한 비밀번호가 유효한지 확인합니다. 인증서가 올바르다는 것은 보안 핸드셰이크의 검증 조건이 충족되었다는 뜻이지, 프록시 비밀번호까지 승인되었다는 뜻은 아닙니다. 두 검사는 서로 대체할 수 없습니다.

일부 오류는 모두 “서버 연결” 단계에서 발생한 것처럼 보이지만 실제 원인은 서로 다를 수 있습니다. 서버 주소나 포트가 틀리면 TCP 연결부터 성립하지 않을 수 있습니다. Server Name이 일치하지 않으면 인증서 검증이 실패할 수 있고, Password가 잘못되면 TLS 연결이 설정된 뒤 거부될 수 있습니다. 실패한 단계를 기준으로 해당 항목을 점검하세요. 모든 연결 중단을 비밀번호 오류로 단정하거나 도메인 설정 문제를 감추기 위해 인증서 검증을 끄지 마세요.

연결 주소와 인증서 이름은 다를 수 있음

Address는 네트워크 연결을 보낼 위치를 지정하고, Server Name 또는 SNI는 TLS 핸드셰이크에서 서버 이름을 전달합니다. IP로 연결하더라도 서버 인증서는 도메인용으로 발급되었을 수 있으므로 기존 설정에 별도의 이름이 필요할 수 있습니다. 인증서에는 유효 기간, 발급 체인 및 이름 범위도 관련됩니다. 브라우저에서 특정 웹사이트가 열린다고 해서 프록시 접속 지점에 같은 포트, 인증서와 라우팅 설정이 사용된다고 볼 수는 없습니다.

서버가 여러 서비스를 함께 운영하면 SNI에 따라 사용할 인증서나 백엔드가 달라질 수 있습니다. 흔히 쓰이는 웹사이트 도메인으로 임의 변경해도 대개 문제가 해결되지 않으며, 오히려 관계없는 서비스로 요청이 전달될 수 있습니다. 올바른 값은 기존 설정에서 확인하세요. 이전에는 잘 작동하다 갑자기 인증서 오류가 발생한다면 기기 시간, 서버 인증서 상태와 접속 지점 변경 여부를 확인하고 오류 내용을 보존한 뒤 이용 중인 서비스 제공자에게 문의하세요.

추가 전송 설정도 빠짐없이 일치시켜야 함

Trojan 설정에 최소한의 항목만 있는 것은 아닙니다. 일부 서버는 TLS처럼 보이는 연결 외에도 특정 전송 방식과 경로를 요구합니다. 다른 Trojan 설정의 항목을 가져와 합치지 말고 기존 정보를 기준으로 확인하세요. 구독을 가져왔다면 앱이 유형과 전송 설정을 빠짐없이 인식했는지 먼저 살펴보세요. 직접 입력할 때는 주소, 포트, 비밀번호, 보안 계층 이름과 명시된 추가 설정을 각각 기록하세요.

비밀번호는 대소문자를 구분하는 인증 정보입니다. 복사할 때 공백, 줄바꿈 또는 기호 변환이 생기면 인증이 실패할 수 있습니다. 구독을 가져올 때 쓰는 토큰을 Trojan 비밀번호로 사용하거나 항목 메모를 사용자 이름으로 사용하지 마세요. 구독 주소와 서버 인증 정보는 서로 다른 항목입니다. 구독 주소는 설정을 가져오는 데 쓰고, 인증 정보는 실제 연결에 사용합니다. 구독 업데이트 성공은 설정 내용을 가져올 수 있다는 뜻일 뿐, 그 안의 모든 서버에 현재 연결할 수 있다는 뜻은 아닙니다.

iOS 속도와 배터리 사용량은 실제 사용 방식에 따라 달라짐

TLS는 모바일 시스템에서 널리 사용되는 기반 기술이지만, 안정적으로 검증되었다고 해서 비용이 없는 것은 아닙니다. 처음 보안 연결을 설정할 때 핸드셰이크가 필요하므로 짧은 연결을 자주 만들면 대기 시간이 더 두드러질 수 있습니다. 지속 전송에서는 네트워크, 암호화 처리와 서버의 전달 능력이 처리량에 더 큰 영향을 줍니다. 추가 전송을 함께 사용하면 캡슐화와 연결 관리 비용도 고려해야 합니다. Trojan이 다른 프로토콜보다 항상 빠르거나 느리다고 단정할 수 없습니다.

배터리 사용량은 실제 사용 시간 전체를 기준으로 살펴보세요. 짧은 다운로드는 순간 소비 전력이 높더라도 빨리 끝날 수 있습니다. 반면 연결을 계속 재시도하면 처리량이 낮아도 네트워크가 반복해서 활성화될 수 있습니다. 대기 중 배터리 소모가 크다면 백그라운드에서 요청하는 앱이 있는지, 연결을 계속 재시도하는지, 네트워크 전환이 잦은지 확인한 뒤 On Demand의 작동 조건도 살펴보세요. 프로토콜 이름만으로 백그라운드 활동의 원인을 판단할 수 없으며 비밀번호 변경으로 재시도 동작을 해결할 수도 없습니다.

문제 해결은 현재 접속 지점에 연결한 뒤 원래 접속할 수 있었던 일반 대상에 요청하고, 마지막으로 실제 사용 서비스를 테스트하는 순서로 진행하면 좋습니다. 연결 단계에서 실패하면 주소, TLS와 인증을 확인하세요. 특정 대상에서만 실패하면 DNS, 규칙과 대상 응답을 살펴보세요. “연결은 켜졌는데 웹페이지가 열리지 않는” 문제를 순서대로 확인하려면 연결을 켠 뒤 확인할 네 단계도 참고하세요. TLS 설정만 반복해서 바꾸는 일을 피할 수 있습니다.

05 / HTTP와 SOCKS5: 프록시 인터페이스는 암호화 연결과 다름

애플리케이션 계층 프록시의 역할로 차이 이해하기

HTTP 프록시는 애플리케이션 계층에서 요청을 전달하기 위한 방식으로, 일반 HTTP 요청을 처리하고 CONNECT를 사용해 대상 연결을 위한 바이트 스트림을 설정할 수도 있습니다. SOCKS5는 더 범용적인 방식으로 대상 주소와 연결 명령을 표현하며, 전달되는 데이터가 모두 웹 프로토콜일 필요는 없습니다. 두 방식은 프록시 인터페이스를 나타내므로 이름만으로 클라이언트와 프록시 서버 사이의 통신이 암호화된다고 판단해서는 안 됩니다. 별도의 보안 계층이 있는지 확인해야 합니다.

이는 대상 웹사이트가 HTTPS를 사용하는지와는 별개의 문제입니다. 대상 웹사이트의 HTTPS는 기기와 대상 사이의 해당 애플리케이션 데이터를 보호할 수 있지만, 프록시 접속 지점은 연결 대상 등의 정보를 확인할 수 있습니다. 프록시 자체에 대한 인증과 전송에도 별도의 보안 경계가 있습니다. TLS가 포함된 HTTP 프록시 조합을 선택하면 인증서와 서버 이름을 확인하세요. 기존 정보가 일반 프록시를 지정한다면 클라이언트에서 TLS를 임의로 켜도 서버가 자동으로 맞춰 주지 않습니다.

사용자 이름·비밀번호와 서버 접근 범위

HTTP와 SOCKS5는 사용자 이름과 비밀번호를 사용할 수 있으며, 서버 접근 제어로 사용 가능 여부를 정할 수도 있습니다. 기존 정보를 그대로 입력하고, 항목을 비워 두면 반드시 접속된다고 생각하지 마세요. 특정 네트워크에서만 접근을 허용하는 프록시는 셀룰러 네트워크로 바꾼 뒤에는 연결을 거부할 수 있습니다. 네트워크 전환 후 접속에 실패하면 Shadowrocket 설정이 손상되었다고 단정하지 말고 서버의 접근 범위와 인증 정보를 함께 확인하세요.

화면에서 전체 URL 입력을 명시적으로 요구하지 않는 한 서버 주소에 불필요한 프로토콜 접두어나 경로를 넣지 마세요. 포트도 대상 웹사이트 주소를 보고 추측하지 않아야 합니다. 회사 또는 개인이 관리하는 네트워크 환경의 정보를 사용하는 경우 해당 프록시가 어떤 대상과 용도로의 접근을 허용하는지도 확인하세요. 특정 앱이나 네트워크 구역에서만 쓸 수 있는 접속 지점도 있습니다. 한 번 인증되었다고 모든 인터넷 대상에 요청을 전달할 수 있다고 가정하지 마세요.

도메인을 어느 쪽에서 확인하는지에 따라 결과가 달라짐

요청이 프록시에 도달하기 전에 클라이언트가 대상 도메인을 IP로 확인할 수도 있고, 도메인 확인을 프록시에 맡길 수도 있습니다. 두 방식에 따라 이름 확인 위치, 오류 양상과 도메인 기반 규칙의 적용 결과가 달라집니다. SOCKS5가 도메인 주소를 지원한다고 해서 모든 요청이 반드시 서버에서 확인된다고 볼 수는 없습니다. Shadowrocket의 DNS 및 라우팅 설정, 앱의 요청 방식과 실제 구현이 모두 영향을 줄 수 있습니다. 문제를 확인할 때는 도메인 요청과 이미 알고 있는 주소로의 요청을 각각 살펴보세요.

마찬가지로 웹이 된다고 실시간 통신도 된다는 뜻은 아닙니다. 일반적인 HTTP CONNECT는 주로 TCP 연결에 사용됩니다. SOCKS5에는 UDP ASSOCIATE가 있지만 서버, 클라이언트 설정과 중간 네트워크가 모두 이를 지원해야 합니다. 실제 작업에 UDP가 필요하다면 먼저 접속 지점이 해당 기능을 명확히 제공하는지 확인하세요. 지원되지 않는 경우 대상 포트 하나를 바꿔서 해결할 수 없으며, 기존 서버에서 호환되는 연결 방식을 제공해야 합니다.

사용 사례와 iOS 동작

사용 중인 회사 네트워크에서 제공하는 HTTP 프록시나 개인 환경의 SOCKS5 접속 정보가 있다면, 다른 프로토콜로 억지로 바꾸기보다 해당 유형을 선택하는 편이 적절합니다. 장점은 이름이 더 범용적으로 들린다는 데 있는 것이 아니라 기존 서비스 인터페이스와 맞는다는 데 있습니다. 신뢰할 수 있는 로컬 네트워크에서만 사용할 수 있는 접속 지점이라면 네트워크 범위도 설정의 일부로 고려하세요. 연결 환경이 바뀌면 인증 보호, 네트워크 연결 가능 여부와 접근 허용 범위를 다시 확인해야 합니다.

프로토콜 내부의 처리가 적다고 전체 배터리 소모도 줄어드는 것은 아닙니다. 별도의 암호화가 없는 연결은 특정 계산을 줄일 수 있지만, 대상 자체의 TLS, 네트워크 재전송과 앱 요청 빈도는 그대로입니다. 프록시 서버가 느리게 처리하면 기기가 무선 연결을 더 오래 유지할 수 있습니다. 비교할 때는 성공률, 요청 대기 시간과 작업 완료 시간을 함께 기록하세요. 한 번의 지연 시간 측정만 보고 일반 프록시가 모든 상황에 적합하다고 결론 내리지 마세요.

일부 대상에만 접근할 수 없다면 프록시의 접근 정책과 대상 포트 제한을 먼저 확인한 뒤 로컬 규칙을 살펴보세요. 인증이 거부되면 사용자 이름, 비밀번호와 접속 네트워크 범위를 확인하세요. 핸드셰이크는 성공했지만 대상 응답이 지연되면 이름 확인과 서버에서 대상까지의 경로를 점검하세요. 이처럼 계층별로 확인하는 편이 유형을 계속 바꾸는 것보다 효과적이며, 이용 중인 서비스 제공자에게 “안 돼요”라는 말만 전하는 대신 문제를 구체적으로 설명할 수 있습니다.

06 / WireGuard: 키·Peer·주소 라우팅

네트워크 계층 터널을 구성하는 프로토콜

WireGuard는 네트워크 계층 터널, 간결한 암호화 구성과 공개 키를 통한 상대 식별을 중심으로 설계되었습니다. 프록시 비밀번호 하나를 입력하는 유형과 달리 로컬 인터페이스 주소, 상대방 ID, 접속 지점과 터널에 전달할 주소 범위를 함께 이해해야 하는 경우가 많습니다. 설정 항목이 더 많은 것은 모든 항목이 인증에 쓰이기 때문이 아닙니다. 일부는 ID를 나타내고 다른 항목은 네트워크 패킷을 올바른 경로로 보내는 방법을 지정하므로 역할을 구분해야 합니다.

Private Key는 현재 클라이언트의 개인 키이고, Public Key는 해당 ID를 나타냅니다. Peer의 Public Key는 원격 피어를 가리킵니다. 클라이언트의 공개 키를 원격 공개 키 칸에 입력하면 양쪽의 ID 관계가 맞지 않습니다. 설정 정보에 Preshared Key가 포함되어 있다면 이는 추가 공유 키이며, 공개 키와 개인 키의 조합을 대체하지 않습니다. 실제 키를 공개 스크린샷, 문서 또는 로그에 올리지 마세요. 다른 사람에게 문제를 설명할 때도 키를 먼저 삭제해야 합니다.

Endpoint와 인터페이스 Address의 역할

Endpoint는 원격 접속 지점이며 보통 주소와 포트로 구성됩니다. 인터페이스 Address는 터널 내부에서 현재 장치에 할당하는 주소로, 접두사 길이가 포함될 수 있습니다. 원격 서버의 공인 주소가 아닙니다. 가져온 설정은 서버에서 지정한 값을 그대로 유지하고, 홈 네트워크 주소와 비슷하게 보이도록 임의로 바꾸지 마세요. 주소 충돌, 접두사 오류 또는 서버가 로컬 주소를 받아들이지 않는 경우 핸드셰이크는 성공해도 실제 통신이 되지 않을 수 있습니다.

Allowed IPs는 피어와 주소 접두사를 연결하며 어떤 대상의 트래픽을 해당 피어로 전달할지에도 영향을 줍니다. 접근 가능한 웹사이트 목록이나 단순한 메모가 아닙니다. 주소 범위 전체를 입력하는 것과 일부 로컬 네트워크만 입력하는 것은 의미가 크게 다릅니다. 또한 Shadowrocket의 상위 정책이 요청을 이 서버로 전달하는지도 고려해야 합니다. 터널 내부의 라우팅 범위와 앱 규칙의 트래픽 분기는 별도의 제약이므로 서로 대체할 수 없습니다.

핸드셰이크 성공 후 실제 트래픽 경로도 확인

핸드셰이크는 양측의 키 교환이 완료되었다는 뜻일 뿐 주소 할당, 전달 경로와 DNS가 올바르다는 보장은 아닙니다. 핸드셰이크는 확인되지만 웹페이지가 열리지 않으면 터널 주소, Allowed IPs, 원격 전달 및 DNS 설정을 점검하세요. 핸드셰이크 자체가 되지 않는다면 Endpoint, 공개 키 조합과 UDP 연결 가능 여부를 먼저 확인하세요. 두 경우를 구분하면 라우팅 문제 때문에 키를 반복해서 다시 만들고 클라이언트와 서버의 설정이 어긋나는 일을 피할 수 있습니다.

MTU는 터널에서 패킷 하나가 가질 수 있는 크기에 영향을 줍니다. 하위 네트워크가 감당할 수 있는 패킷 크기에서 터널 오버헤드를 빼야 합니다. 값을 너무 크게 설정하면 작은 요청은 되지만 큰 응답은 멈출 수 있습니다. 재현 가능한 증상을 기준으로 한 번에 이 항목 하나만 조정하세요. 임의의 작은 숫자를 어디서나 통하는 최적화 값으로 사용하지 마세요. 특정 네트워크에서만 문제가 생긴다면 전체 WireGuard 설정이 잘못되었다고 판단하기보다 하위 경로의 차이도 고려해야 합니다.

연결 유지·로밍·배터리 사용량

WireGuard는 UDP를 사용하며 네트워크 주소가 바뀐 뒤 상대 접속 지점을 갱신하는 메커니즘이 있지만, 실제 복구는 모바일 시스템의 작업 스케줄링, NAT 상태와 네트워크 조건에 따라 달라집니다. 일부 설정은 매핑 유지를 위해 Persistent Keepalive를 사용합니다. 연결 유지 신호는 자주 보낼수록 좋은 것이 아닙니다. 간격이 지나치게 짧으면 대기 중 무선 통신이 늘고, 너무 길면 특정 네트워크에서 필요한 매핑이 유지되지 않을 수 있습니다. 기존 설정의 요구 사항을 보존하고 확인된 문제를 기준으로 조정하세요.

iOS에서는 장시간 연속 트래픽과 장시간 대기가 서로 다른 부하입니다. 전자는 처리량, 발열과 패킷 손실 복구를, 후자는 백그라운드 트래픽이나 연결 유지 신호가 계속 발생하는지를 확인해야 합니다. 네트워크 계층 터널의 구조가 간단하다고 모든 상황에서 배터리를 적게 쓰는 것은 아닙니다. 실제 설정은 WireGuard 설정 항목별 해설과 함께 확인할 수 있습니다. 프록시 비밀번호만 있고 키와 주소 정보가 없다면 이를 바탕으로 사용할 수 있는 WireGuard 설정을 임의로 만들 수 없습니다.

07 / Hysteria2: UDP 경로와 혼잡 제어

QUIC 기반 전송 구조

Hysteria2는 QUIC 기반 프록시 전송을 사용합니다. QUIC는 UDP 위에서 동작하고 TLS를 통해 보안 핸드셰이크를 수행합니다. 높은 지연 시간이나 패킷 손실 환경에서의 전송 성능에 초점을 둔 설계이지만, 모든 네트워크에서 더 빠르다는 보장은 없습니다. 사용 중인 네트워크에서 UDP를 제한하거나 UDP 경로의 품질이 나쁘다면 설계상의 장점도 네트워크 연결 가능성이라는 전제를 바꿀 수 없습니다. 연결 자체가 설정되지 않을 수도 있습니다.

QUIC를 이해할 때는 전송 계층 내부의 다중 스트림과 하위 링크 자원을 구분해야 합니다. 독립적인 스트림은 특정 스트림 간의 대기 문제를 줄일 수 있지만, 모든 스트림이 무선 링크, 경로 용량과 혼잡 상태를 공유합니다. 패킷이 손실되면 해당 스트림의 데이터도 복구가 필요할 수 있습니다. “다중화”가 대역폭을 자동으로 두 배로 늘리거나 모든 요청이 서로 영향을 받지 않는다는 뜻은 아닙니다. 최종 사용 경험은 서버 처리, 대상 응답과 네트워크 대기열에도 영향을 받습니다.

인증과 인증서 설정을 각각 유지

Hysteria2 설정은 서버 주소, 포트와 인증 정보가 일치해야 합니다. 사용하는 보안 계층의 이름과 인증서 검증도 기존 설정에 따라 입력하세요. Password 또는 해당 인증 항목은 TLS 인증서를 대체하지 않습니다. 서버가 도메인 접속을 사용하더라도 Server Name이 설정 요구 사항과 일치하는지 확인하세요. IP로 연결하지만 인증서가 도메인용이라면 이름 항목이 특히 중요합니다. 모든 칸의 값을 같게 만들려고 비우지 마세요.

일부 구성에는 추가 난독화 설정이 제공됩니다. 이는 양측이 합의한 설정의 일부이므로 서버에서 명확히 요구할 때만 켜고 유형과 인증 정보가 맞는지 확인하세요. 난독화 비밀번호를 임의로 입력해도 호환성이 높아지지 않습니다. 인증 단계에 도달하기 전에 패킷을 올바르게 해석하지 못할 수 있습니다. 구독을 가져온 뒤에는 추가 항목이 모두 들어왔는지 먼저 확인하고 네트워크 품질 문제인지 판단하세요.

대역폭 설정은 속도 배율이 아님

업로드와 다운로드 대역폭 항목은 해당 전송 정책에 참고값을 제공하며, 입력한 숫자만큼 회선 용량을 높여 주지 않습니다. 실제 성능보다 훨씬 높은 값을 입력하면 전송 동작이 회선 용량에 맞지 않아 대기열, 패킷 손실이 생기거나 같은 네트워크의 다른 작업에 영향을 줄 수 있습니다. 너무 낮은 값은 사용 가능한 처리량을 제한할 수 있습니다. 초당 바이트와 초당 비트를 혼동해 수치가 크게 달라지지 않도록 단위도 확인하세요.

모든 서버 설정이 클라이언트에서 제공한 대역폭 정보를 같은 방식으로 사용하는 것은 아닙니다. 구체적인 혼잡 제어 동작은 양측이 지원하는 설정과 함께 확인해야 합니다. 가장 안전한 시작점은 기존 설정과 서버 안내이며, 다른 기기에서 이른바 최적값으로 쓰인 숫자를 그대로 적용하는 것이 아닙니다. 조정하려면 안정적인 네트워크에서 기준값을 먼저 측정한 뒤 단일 작업 다운로드, 업로드와 웹 응답을 각각 살펴보세요. 한 번의 최고 속도만 좇아 다른 요청의 대기 시간을 무시하지 마세요.

모바일 네트워크에서 적합성 확인하기

셀룰러 네트워크의 가용 용량과 지연 시간은 신호 및 기지국 부하에 따라 달라질 수 있습니다. 한 시점에 측정한 대역폭이 이후 사용 시간 내내 유지된다고 볼 수 없습니다. 엘리베이터, 이동 중인 교통수단이나 신호가 약한 곳에서 반복 측정하면 무선 환경의 변화가 프로토콜 비교에 섞입니다. 먼저 위치와 신호가 안정적인 곳에서 기본 연결을 확인한 뒤 실제 이동 중 복구 상태를 관찰하세요. 설정 오류와 네트워크 변동으로 인한 일시적인 실패를 구분할 수 있습니다.

높은 처리량, 암호화 처리, 재전송과 무선 통신은 모두 기기의 전력 사용량을 높일 수 있습니다. Hysteria2는 일부 경로에서 작업 완료 시간을 줄일 수 있지만, 다른 경로에서는 패킷 손실이 이어져 오버헤드가 늘 수 있습니다. 따라서 배터리를 아끼는 프로토콜 또는 많이 소모하는 프로토콜이라고 일괄적으로 규정할 수 없습니다. 호환되는 접속 지점이 여러 개라면 같은 작업의 완료 시간, 안정성과 실제 배터리 변화를 함께 기록하세요. 접속 지점이 하나뿐이라면 설정을 먼저 정확히 확인하고, 프로토콜 이름만 보고 전체 구성을 바꾸지 않아도 됩니다.

08 / 사용 사례에 맞게 선택하고 규칙과 실제 측정으로 확인

기존 조건부터 확인하고 설계 차이를 비교

가장 먼저 확인할 기준은 서버가 실제로 제공하는 접속 지점입니다. 기존 구독에 프로토콜이 하나만 포함되어 있다면 유형을 임의로 바꾸지 말고 설정을 빠짐없이 가져왔는지, 인증이 올바른지, 대상에 연결할 수 있는지 먼저 확인하세요. 사용할 수 있는 접속 지점이 여러 개일 때만 작업에 따라 비교하면 됩니다. 웹 요청이 잦다면 DNS 확인과 첫 응답 시간을, 지속 다운로드라면 처리량과 안정성을, 실시간 앱이라면 UDP 지원과 지연 시간 변동을, 개인 내부 네트워크에 접근해야 한다면 주소 라우팅이 정확한지를 살펴보세요.

명시적인 TLS 및 전송 설정이 필요한 접속 지점은 정보가 완전한지, 유지 관리 중 항목을 명확히 확인할 수 있는지 우선 고려하세요. 네트워크 계층 터널은 키, 주소와 라우팅 범위가 모두 제공되어야 합니다. UDP 기반 전송은 현재 네트워크가 UDP를 허용하고 안정적으로 전달하는지 확인해야 합니다. 항목이 적거나 이름이 최신이라는 이유만으로 프로토콜을 선택하지 마세요. 기존 서비스를 정확히 설정할 수 있고 문제가 생겼을 때 계층별로 원인을 찾을 수 있는지도 실제 사용 가능성을 좌우합니다.

Global Routing을 바꿔도 프로토콜 유형은 바뀌지 않음

Global Routing에는 Config, Proxy, Direct가 있습니다. 이는 각각 화면에 표시되는 Config, Proxy, Direct 용어에 해당합니다. Config는 현재 설정의 규칙에 따라 정책을 결정하고, Proxy는 해당 트래픽을 프록시 정책으로 전달하며, Direct는 직접 연결 경로를 사용합니다. 이 옵션을 바꾸면 라우팅 결정이 달라질 뿐 서버 프로토콜은 바뀌지 않습니다. 현재 요청이 선택한 서버로 전달되지 않는다면 해당 요청으로 프로토콜 속도를 비교하는 것은 의미가 없습니다. 먼저 경로를 확인하세요.

아래 예시는 규칙 적용 순서를 설명합니다. Shadowrocket 설정에서 해당 규칙 영역에 넣고 프록시 정책이 사용 가능한 서버를 가리키는지 확인하세요. 완전한 설정이 아니며 서버 인증 정보도 포함하지 않습니다. DOMAIN-SUFFIX는 지정한 도메인 접미사를 먼저 일치시키고, GEOIP는 지역 주소 데이터베이스 조건에 맞는 대상을 처리하며, FINAL은 나머지 요청에 적용할 정책을 지정합니다. 지역 규칙이 필요한지는 사용자의 실제 접속 요구 사항에 따라 판단해야 하며, 예시를 그대로 복사해서는 안 됩니다.

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

규칙은 보통 순서대로 적용하므로 더 구체적인 조건을 적절한 위치에 배치해야 합니다. FINAL은 나머지 연결을 처리해야 합니다. IP 규칙과 도메인 규칙은 입력 조건이 다르며 DNS 확인 결과도 규칙 판단에 영향을 줄 수 있습니다. 특정 대상이 DIRECT로 연결된다고 해서 선택한 프록시 프로토콜에 문제가 있다는 뜻은 아닙니다. 대상이 PROXY를 사용한 뒤 실패했다고 규칙 문법이 틀렸다고 단정할 수도 없습니다. 자세한 설정 방법은 설정 안내를, 첫 연결 절차는 빠른 시작 가이드를 참고하세요.

반복할 수 있는 검증 기록 만들기

검증을 시작할 때 Home에서 대상 서버를 선택한 뒤 Global Routing을 확인하고 연결을 켠 다음 Connectivity Test를 실행하세요. 이어 실제 사용 대상에 접속해 봅니다. 테스트 도구의 결과는 실행한 점검 항목만 보여 주며 모든 프로토콜 기능, 대상 또는 규칙 경로를 보장하지 않습니다. 네트워크 유형, 선택한 서버, 대상과 실패 단계를 기록하세요. 구독 링크, 비밀번호 또는 키는 공개하지 말고 이용 중인 서비스 제공자에게 문의할 때도 민감한 정보를 먼저 삭제하세요.

전혀 연결할 수 없다면 주소 확인, 포트와 전송, TLS 또는 프로토콜 인증 순서로 확인하세요. 연결은 되지만 일부 대상에서 실패하면 DNS, 규칙 적용, UDP와 대상 서비스를 점검합니다. 성능을 측정할 때는 한 번에 변수 하나만 바꾸고 서버, 전송과 라우팅을 동시에 바꾸지 마세요. 배터리 사용량을 비교할 때도 관찰 시간과 화면 사용 방식을 동일하게 유지하고, 기기 온도와 백그라운드 작업이 안정된 뒤 측정을 시작해야 합니다. 서로 다른 부하에서 얻은 두 결과를 그대로 비교할 수 없습니다.

마지막으로 프로토콜 선택과 클라이언트 다운로드는 별도로 확인하세요. iPhone / iPad용은 App Store에서 $2.99 일회성 결제이며, Mac(Apple 실리콘 및 Intel), Windows, Android, Linux 버전은 무료입니다. 다운로드 및 설치 관련 문의는 다운로드 가이드와 자주 묻는 질문에서 확인하세요. 이 사이트는 Shadowrocket의 공식 사이트 및 매뉴얼입니다. 노드나 구독을 제공·판매·추천하지 않습니다. 기존 항목의 화면 용어를 이해하려면 영문 인터페이스 용어 안내를, 연결 순서를 확인하려면 첫 연결 단계별 안내를 참고한 뒤 이 페이지에서 해당 프로토콜의 기술적 범위를 확인하세요.