Shadowrocket
프로토콜 유형 및 설정값 가이드

서버가 제공하는 프로토콜을 확인한 뒤 Type을 선택하세요

프로토콜 유형은 서버 측 설정과 일치해야 합니다. 같은 주소와 비밀번호를 다른 유형으로 임의 전환할 수는 없습니다. Home의 서버 편집 메뉴나 Add Server에서 Type은 클라이언트가 인증 및 데이터를 구성하는 방식을 결정합니다. 연결이 성립하려면 서버도 같은 형식을 이해해야 합니다. 기존 구독에는 대개 필요한 설정이 이미 포함되어 있으므로 가져온 뒤에는 우선 기존 값을 유지하세요. 서버의 실제 설정을 알고 있을 때만 항목을 직접 다시 구성하는 것이 좋습니다. 프로토콜 이름만으로는 모든 설정값을 확인할 수 없습니다.

연결은 여러 계층으로 나누어 이해해야 합니다. 주소와 Port는 연결할 위치를 정하고, 프로토콜 인증은 상대 서버가 요청을 받아들일지 결정합니다. 전송 방식은 데이터를 전달하는 방법을 정하며, TLS는 해당 채널의 신원 확인과 암호화를 담당합니다. Global Routing은 어떤 요청을 이 경로로 보낼지 결정합니다. 같은 VLESS라도 전송 방식은 다를 수 있고, TLS를 사용하는 두 연결도 인증 방식은 다를 수 있습니다. 이 계층들을 혼동하면 실제 원인이 인증서 불일치인데 비밀번호를 바꾸는 식으로 잘못 대응하기 쉽습니다.

프로토콜 7종은 속도 순위표가 아닙니다

프로토콜의 역사와 배경은 설계 목표를 보여줄 뿐, 모든 네트워크에서의 성능을 보장하지 않습니다. Shadowsocks는 간결한 프록시 전달을 지향하고, VMess는 자체 인증 및 데이터 보호 설계를 포함합니다. VLESS는 보호 기능을 외부 계층에 더 많이 맡기며, Trojan은 TLS 채널을 통해 프록시 요청을 전달합니다. HTTP와 SOCKS5는 범용 프록시 인터페이스이고, WireGuard는 IP 계층 터널을 처리합니다. Hysteria2는 QUIC 기반 전송을 사용합니다. 각 프로토콜이 해결하는 문제는 서로 다르므로 이름만 보고 오래된 순서나 최신 순서로 판단할 수 없습니다.

속도는 대개 서버의 외부망, 왕복 시간, 혼잡도와 무선 신호의 영향을 먼저 받으며, 프로토콜 처리 오버헤드는 그다음 요인입니다. 웹페이지를 여는 작업은 DNS 조회, 핸드셰이크, 여러 짧은 요청으로 이루어질 수 있지만, 지속 다운로드는 처리량의 영향을 더 크게 받습니다. 두 작업의 결과가 다를 수도 있습니다. iPhone에서는 셀룰러 신호, 저전력 상태, 백그라운드 전환도 고려해야 합니다. 한 번의 속도 측정에서 나온 최고값을 일상적인 사용 경험으로 간주하지 마세요. 비교할 때는 기기, 네트워크, 서버 조건과 작업을 동일하게 유지하고 조정 가능한 변수 하나만 바꾸세요.

실제 사용 패턴으로 배터리 소모와 호환성을 판단하세요

배터리 소모는 실제 전송량, 연결 유지 방식, 무선 모듈의 작동 시간에 따라 달라집니다. 특정 프로토콜에 영구적으로 따라붙는 특성이 아닙니다. TLS 연결을 자주 설정하면 순간적인 부하가 늘 수 있고, keepalive 패킷을 계속 보내면 네트워크가 더 자주 깨어날 수 있습니다. 패킷 손실 후 재전송도 배터리를 더 소모합니다. 장시간 동영상 시청, 간헐적인 메시지 전송, 대기 상태는 각각 따로 살펴보세요. 기기 온도가 올라가면 프로토콜 구현의 문제라고 단정하기 전에 Data의 트래픽 변화와 백그라운드 작업을 확인하세요.

TCP와 UDP 지원 여부도 각각 확인해야 합니다. 웹페이지가 열린다는 것은 해당 경로의 요청이 성공했다는 뜻일 뿐, 음성 통화나 다른 UDP 트래픽도 전달된다는 뜻은 아닙니다. 일부 프로토콜은 UDP를 지원하지만 서버, 현재 전송 방식 또는 상위 네트워크에서 허용하지 않을 수 있습니다. 반대로 UDP를 사용해 데이터를 전달하는 프로토콜도 앱의 TCP 요청을 중계할 수 있습니다. ‘앱 트래픽의 유형’과 ‘외부 연결의 유형’은 서로 다른 개념입니다. UDP라는 문구 하나만 보고 앱의 모든 동작을 판단하지 마세요.

첫 단계에서는 세 가지를 확인하면 됩니다. 서버가 실제로 무엇을 제공하는지, 현재 네트워크에서 무엇을 허용하는지, 어떤 작업을 처리해야 하는지입니다. 그런 다음 인증 정보가 완전한지, 인증서를 올바르게 검증할 수 있는지, 연결 실패의 원인을 쉽게 찾을 수 있는지 살펴보세요. 현재 사용할 수 있는 유형이 하나뿐이라면 서버에서 지원하지 않는 설정을 찾기보다 해당 유형을 올바르게 구성하는 것이 우선입니다. 공유 형식을 먼저 알아보려면 공유 링크와 구독 링크의 차이를 읽은 뒤 해당 프로토콜 장을 참고하세요.

UUID가 비슷해 보여도 연결 방식까지 같은 것은 아닙니다

VMess는 사용자 인증과 자체 데이터 보호 메커니즘을 포함하도록 설계되었습니다. VLESS는 더 간결한 신원 확인 구조를 사용하고 TLS 같은 외부 방식에 채널 보호를 더 많이 맡깁니다. 둘 다 UUID를 사용할 수 있지만 서버에서 처리하는 방식은 다릅니다. Type을 VMess에서 VLESS로 바꾸고 나머지 항목을 그대로 둔다고 전환이 완료되는 것은 아닙니다. 기존 공유 정보에 지정된 유형을 사용하세요. 서버에 해당 연결 지점이 모두 구성되어 있어야 클라이언트에서 각각 항목을 만들어 비교할 수 있습니다.

UUID는 신원 식별자이지 서버 주소나 구독 링크의 임의 쿼리 매개변수가 아닙니다. 복사할 때 공백, 줄바꿈, 따옴표가 섞이지 않았는지 확인하고 전체 형식을 유지하세요. VMess에는 보안 옵션이나 이전 버전과의 호환 항목이 포함될 수도 있습니다. 모든 서버에서 같은 숫자를 입력해야 한다고 오래된 안내만 보고 판단하지 말고 서버 정보를 따르세요. VLESS의 인증 구조가 간결하다고 외부 보호 계층을 생략해도 된다는 뜻은 아닙니다. TLS가 필요한 연결 지점에서 TLS를 끄면 정상적으로 연결되지 않는 경우가 많습니다.

전송 옵션은 한 묶음으로 확인해야 합니다

TCP, WebSocket 등의 전송 방식은 프록시 데이터를 전달하는 방법을 설명하며 VMess나 VLESS 자체의 신원 인증을 대신하지 않습니다. 같은 주소에 서로 다른 연결 지점이 있을 수 있습니다. 한쪽은 WebSocket을 요구하고 다른 쪽은 일반 TCP 연결만 허용할 수 있습니다. 전송 방식을 잘못 선택해도 네트워크 계층에서는 포트에 연결할 수 있는 것처럼 보일 수 있지만 이후 데이터는 올바르게 처리되지 않습니다. 서버를 추가할 때 전송 유형과 Host, Path 등의 관련 항목을 함께 확인하고 상단 옵션 하나만 바꾸지 마세요.

WebSocket의 Path는 서버가 요청을 받는 경로로, 보통 앞의 슬래시와 대소문자까지 정확히 일치해야 합니다. 임의의 웹사이트 디렉터리가 아닙니다. Host는 관련 요청의 호스트 정보를 나타내고, SNI는 TLS 핸드셰이크에 사용됩니다. 때로는 두 값이 같아도 역할은 다릅니다. Address는 실제 연결 지점을 가리키고 Host와 SNI는 설정에서 요구하는 이름을 가리킬 수 있으므로 값이 서로 다르다고 임의로 통일하지 마세요. 기존 정보를 바탕으로 각각 확인해야 합니다.

TLS 인증서는 연결 상대의 신원을 확인하는 데 사용됩니다. ‘연결되기만 하면 된다’는 이유로 인증서 검증을 끄지 마세요. 인증서 도메인과 예상 이름이 다르거나 인증서 체인이 불완전하거나 기기 시간이 크게 어긋나면 핸드셰이크가 실패할 수 있습니다. 검증을 건너뛰기보다 SNI, 인증서, 시간을 먼저 확인하세요. 다른 핸드셰이크 방식이나 특정 설정 조합이 필요한 연결 지점이라면 가져온 설정을 그대로 유지하세요. 화면에 특정 옵션이 보인다고 모든 서버가 이를 지원하는 것은 아닙니다.

성능을 비교할 때 전송 오버헤드도 고려하세요

캡슐화와 핸드셰이크가 추가되면 첫 요청을 처리하는 데 더 많은 작업이 필요합니다. 실제 체감 여부는 연결 재사용, 왕복 시간, 사용 패턴에 따라 달라집니다. 기존 연결을 재사용하는 연속 요청에서는 최초 설정 비용이 분산될 수 있지만, 짧은 연결을 반복해서 만들면 핸드셰이크 시간이 더 두드러집니다. 안정적인 네트워크에서 다운로드 속도를 비교한 결과만으로 신호가 약한 환경의 성능을 예측할 수는 없습니다. iPhone의 일상적인 사용에는 백그라운드 복귀와 네트워크 전환도 포함되므로 이런 상황을 살펴본 뒤 현재 환경에 맞는 조합인지 판단하세요.

‘서버 테스트는 응답하는데 웹페이지가 열리지 않는’ 경우에는 포트 연결 가능 여부와 전체 요청 성공 여부를 구분하세요. 먼저 Global Routing에서 대상 요청이 해당 항목으로 전달되는지 확인한 뒤 UUID와 Type, TLS 및 전송 설정을 점검하세요. 브라우저에서 인증서 오류가 표시되면 오류가 프록시 연결 지점에서 발생했는지 최종 웹사이트에서 발생했는지 확인해야 합니다. 두 인증서는 서로 다릅니다. ‘연결할 수 없음’이라고만 기록하기보다 구체적인 오류와 발생 단계를 남기면 수정할 항목을 찾기 쉽습니다.

여러 프로토콜 연결 지점을 사용할 수 있다면 설정 정보가 완전하고 인증서를 정상적으로 검증할 수 있는 조합을 먼저 선택한 다음 실제 사용 경험을 비교하세요. VLESS 구조가 간결하다고 반드시 배터리를 덜 쓴다고 단정하지 말고, VMess에 자체 보호 기능이 있다고 외부 설정을 무시하지도 마세요. 프로토콜 이름을 빠르게 확인하려면 지원 프로토콜 1분 요약을 먼저 읽고, 이 장에서 항목 간 의존성과 오류가 발생하는 범위를 확인하세요.

프록시 대상만 지정하는 대신 IP 패킷을 전달합니다

WireGuard는 간결한 IP 계층 암호화 터널을 중심으로 설계되었습니다. 공개 키로 상대를 식별하고 UDP로 데이터를 전달합니다. 대상 주소를 제출하는 앱 프록시와 달리 클라이언트와 서버는 터널 내부의 주소 할당 방식과 대상 트래픽을 올바른 상대에게 전달하는 방법도 알아야 합니다. Shadowrocket에서 사용할 때에도 외부 연결은 앱 전체의 트래픽 처리와 라우팅 방식에 영향을 받습니다. 터널 설정의 의미를 Global Routing 모드와 완전히 같은 것으로 간주해서는 안 됩니다.

문제를 진단할 때는 키 관계부터 확인하세요. 클라이언트의 Private Key는 비밀로 유지해야 하며, 이에 대응하는 공개 키를 서버에 등록해야 합니다. 클라이언트의 Peer Public Key에는 서버 상대편의 공개 키를 입력해야 합니다. 두 값을 거꾸로 입력하거나, 복사가 일부 누락되거나, 오래된 공개 키를 사용하면 핸드셰이크가 성립하지 않을 수 있습니다. 설정에 사전 공유 키가 있다면 양쪽 값도 일치해야 합니다. 서버 공개 키를 클라이언트 Private Key 항목에 넣지 마세요. 연결 문제를 해결하려고 실제 개인 키를 피드백용 스크린샷이나 공개 기록에 노출해서도 안 됩니다.

Endpoint, Address, Allowed IPs를 혼동하지 마세요

Endpoint는 외부 네트워크에서 서버에 연결할 위치로, 보통 도메인이나 IP와 UDP 포트로 구성됩니다. Address는 터널 내부에서 사용하는 주소이지 현재 Wi-Fi의 로컬 네트워크 주소나 서버의 공인 IP가 아닙니다. 기존 설정에 지정된 주소와 프리픽스는 요구 사항에 따라 유지하세요. 비어 보이는 사설 IP로 임의 변경하면 서버 라우팅이나 주소 할당과 충돌할 수 있습니다. 핸드셰이크 성공은 키와 연결 지점이 기본적으로 작동한다는 뜻일 뿐, 내부 주소가 올바르다는 뜻은 아닙니다.

Allowed IPs는 상대와 연결되는 대상 주소 범위를 지정하며 관련 라우팅 판단에도 사용됩니다. 앱 계층의 도메인 규칙은 아닙니다. 범위가 빠지면 핸드셰이크는 정상이어도 업무 데이터가 예상한 상대에게 전달되지 않을 수 있습니다. 범위가 넓다고 해서 Shadowrocket의 모든 요청이 Config의 선택을 무시한다고 단정할 수도 없습니다. 서버 항목의 터널 설정과 앱 수준의 정책을 따로 확인하고 실제 대상에 요청해 보세요. IPv6를 사용하는 경우 터널 주소, 대상 범위, 서버 전달 기능이 모두 IPv6를 지원하는지도 확인해야 합니다.

DNS는 별도로 설정해야 합니다. 터널에서 특정 IP에는 접근할 수 있지만 도메인에는 접근할 수 없다면 WireGuard 암호화가 아니라 조회 서버에 연결할 수 없는 문제일 수 있습니다. 기존 설정의 DNS 주소가 터널을 통해서만 접근 가능하다면 관련 요청이 허용되도록 경로와 규칙을 구성해야 합니다. 문제를 진단할 때 IP 주소 접근과 도메인 접근을 먼저 구분한 뒤 DNS 결과를 확인하세요. 조회 실패를 해결하려고 키를 바꾸지 말고, 핸드셰이크가 된다고 라우팅 문제를 배제하지도 마세요.

경로에 맞춰 MTU와 keepalive를 조정하세요

캡슐화는 추가 공간을 사용하며 MTU는 관련 패킷의 최대 크기를 제한합니다. 설정이 너무 크면 일부 경로에서 큰 요청이 멈추거나 일부 웹페이지가 끝까지 로드되지 않거나 지속 전송에 문제가 생길 수 있습니다. 작은 요청은 계속 성공할 수도 있습니다. 너무 작게 설정하면 실제 전송 효율이 떨어질 수 있습니다. 패킷 크기와 관련된 근거가 있을 때만 신중하게 조정하세요. 매번 기존 값을 기록하고 같은 작업으로 비교해야 합니다. 다른 네트워크에서 사용한 값을 모든 기기에 적용할 고정 답처럼 가져오지 마세요.

Persistent Keepalive는 필요할 때 네트워크 매핑을 유지하는 기능이지 처리량을 높이는 가속 옵션이 아닙니다. 셀룰러 네트워크나 일부 라우터 환경에서는 응답 경로를 유지하려고 주기적으로 트래픽을 보낼 필요가 있을 수 있습니다. 하지만 너무 잦은 keepalive는 무선 모듈을 더 자주 깨웁니다. 유휴 상태 이후 연결이 복구되지 않는 문제가 있는지 확인해 설정을 결정하고, 기본값으로 간격을 아주 짧게 지정하지 마세요. 화면을 끄거나 네트워크를 전환한 뒤의 iPhone 동작은 전면에서 계속 다운로드할 때와 나누어 살펴보세요.

WireGuard는 터널 설정 정보가 완전하고 IP 계층에서 접근 범위를 명확하게 지정해야 하는 환경에 적합합니다. 구조가 간결해도 서버 전달, 방화벽, 주소 설계가 불필요해지는 것은 아닙니다. Endpoint와 공개 키 하나만 알고 있다면 전체 설정을 다시 구성하기에 정보가 부족한 경우가 많으므로 기존 설정 출처에서 누락된 값을 확인하세요. 문제를 공유할 때는 오류가 발생한 단계, 네트워크 유형, 대상 범위를 기록하되 키와 내부 접근 정보는 통제된 환경에 보관하세요.

가져오기에 성공해도 내용이 인식되었다는 뜻일 뿐입니다

Shadowrocket이 구독이나 공유 링크를 받아들였다고 서버가 현재 사용 가능하거나 모든 항목이 기존 연결 지점에 맞는 것은 아닙니다. 가져온 뒤 Type, Address, Port, 신원 인증 항목, 전송 설정을 먼저 확인하고 서버를 선택해 테스트하세요. 기존 구독은 보유한 설정 출처에서 업데이트 정보를 가져와야 하며 업데이트가 수동 변경 사항을 덮어쓸 수 있다는 점에 유의하세요. 장기간 유지할 로컬 변경 사항이 있다면 어떤 항목을 구독에서 관리하는지 먼저 확인하세요. 그래야 다음 업데이트 때 앱이 설정을 임의로 바꿨다고 오해하지 않습니다.

공유 링크와 Subscribe 구독은 서로 다른 역할을 합니다. 공유 링크는 보통 단일 항목을 설명하고, 구독은 여러 항목을 반환해 계속 업데이트할 수 있습니다. 두 형식은 인코딩이나 구조도 다를 수 있습니다. QR 코드는 내용을 전달하는 또 다른 방법일 뿐, 잘못된 설정을 올바르게 바꾸지는 않습니다. Scan QR Code로 가져온 뒤에도 결과를 확인해야 하며, 특히 특수 문자가 포함된 인증 정보, 경로, 추가 설정을 주의 깊게 살펴보세요. 구독 주소 자체에 접근 정보가 포함될 수도 있으므로 공개 스크린샷, 기록, 공유 가능한 문제 설명에 노출하지 마세요.

먼저 모드로 경로를 확인하고 규칙으로 세부 라우팅을 조정하세요

Global Routing의 Config, Proxy, Direct는 각각 구성 규칙 적용, 프록시 경로, 직접 연결을 나타냅니다. Config는 현재 활성화된 구성 규칙에 따라 요청을 처리하고, Proxy는 주로 요청을 프록시 경로로 보내며, Direct는 직접 연결합니다. 이 설정은 요청이 향하는 경로를 정할 뿐 서버 프로토콜의 인증 방식을 바꾸지 않습니다. 특정 서버를 점검할 때는 명확한 프록시 모드에서 먼저 검증한 다음 Config로 돌아와 규칙을 확인하세요. 테스트 후에는 일상적인 사용에 적합한 모드로 되돌리세요.

규칙은 보통 순서대로 확인되며 앞에 있는 구체적인 조건이 뒤의 넓은 조건보다 먼저 적용될 수 있습니다. DOMAIN-SUFFIX는 도메인 접미사를, IP-CIDR은 IPv4 주소 범위를 처리합니다. FINAL은 앞선 규칙에 일치하는 항목이 없을 때 적용되는 최종 정책입니다. 규칙으로 PROXY 또는 DIRECT 경로를 정할 수 있지만 잘못된 Password, UUID, 인증서를 고칠 수는 없습니다. 도메인이 직접 연결에서는 정상이고 Config에서는 실패한다면 먼저 어떤 정책에 일치했는지 확인한 다음 프록시 연결 지점과 대상 서비스 중 어디서 실패했는지 판단하세요.

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

다음은 규칙 적용 순서를 설명하기 위한 .conf 예시일 뿐, 완전한 일상용 구성은 아닙니다. example.com은 설명용 도메인이며 사설 네트워크 범위는 주소 규칙의 예시입니다. GEOIP 결과는 사용 중인 데이터와 실제 대상 주소에 따라 달라집니다. 이 예시는 올바른 [Rule] 구역의 맥락에서 해석해야 하며 Add Server의 인증 항목에 붙여 넣어서는 안 됩니다. 구역 간의 더 자세한 관계는 구성 파일의 General, Rule, Host, URL Rewrite 설명을 참고하세요.

DNS와 On Demand는 프로토콜 인증과 별개입니다

DNS는 도메인을 조회하는 방법을 결정하고 규칙은 요청의 경로를 결정합니다. 둘은 서로 영향을 줄 수 있지만 서버의 Type과 같은 설정은 아닙니다. 도메인이 여러 주소를 반환하면 주소마다 연결 가능 여부가 다를 수 있습니다. 프록시 프로토콜 이름만 바꿔서는 잘못된 DNS 조회 결과를 해결할 수 없습니다. IPv6도 별도로 고려해야 합니다. 기기에 IPv6 주소가 할당되었다고 기존 서버가 모든 IPv6 대상에 데이터를 전달할 수 있는 것은 아닙니다. 실제 주소 유형과 요청 경로를 살펴본 뒤 DNS, 라우팅, 서버 기능 중 무엇을 조정해야 할지 판단하세요.

On Demand는 조건에 따라 연결을 시작하는 방식을 제어합니다. VMess를 VLESS로 바꾸거나 Config의 규칙을 대신하는 기능은 아닙니다. 활성화 후 네트워크가 바뀔 때 자동 연결이 시작된다면 먼저 트리거 조건을 확인하세요. 연결은 되었지만 일부 대상만 실패한다면 규칙, DNS, 프로토콜 설정을 다시 점검해야 합니다. ‘언제 연결할지’와 ‘연결 후 어떻게 라우팅할지’를 나누어 기록하면 특정 웹사이트 문제를 해결하려고 자동 연결 설정을 반복해서 바꾸는 일을 줄일 수 있습니다.

수동으로 변경하기 전에 복구 가능한 설정을 보관하고 공개하면 안 되는 민감 정보가 포함되어 있는지 확인하세요. 앱의 Data로 트래픽 발생 여부를 살펴볼 수 있고, 연결 로그를 사용할 수 있다면 정책 적용과 오류 단계를 확인하는 데 도움이 됩니다. 하지만 트래픽이 늘었다고 요청이 최종적으로 성공한 것은 아닙니다. 가장 효과적인 확인 순서는 항목 완전성, 프로토콜 일치, 외부 연결 가능 여부, 인증 성공, 규칙 적용, 대상 응답입니다. 각 단계를 확인한 뒤 다음 단계로 넘어가고 여러 계층을 동시에 변경하지 마세요.