Shadowrocket 프로토콜 기술 가이드

01 · 프로토콜 선택: 연결의 계층부터 구분하기

사용 중인 서비스가 선택 범위를 결정합니다

Shadowrocket의 Add Server에서 유형을 선택하는 것은 클라이언트가 사용할 통신 형식을 지정하는 일이지, 원격 서버를 해당 프로토콜로 바꾸는 일이 아닙니다. 같은 Address와 Port로 여러 프로토콜에 연결할 수 있는 것은 아닙니다. 서버에서 해당 유형의 접속 지점을 제공해야 유형을 바꾸는 의미가 있습니다. 시작하기 전에 서비스 안내에서 프로토콜 이름, 주소, 포트, 인증 정보, 전송 설정을 확인하세요. Subscribe로 가져온 경우에는 먼저 가져온 설정을 그대로 두세요. 이름이 익숙하다는 이유만으로 인식된 유형을 다른 유형으로 바꾸지 마세요.

프로토콜은 클라이언트와 서버가 인증 정보와 프록시 요청을 주고받는 방식을 주로 규정합니다. 전송 방식은 이 메시지가 어떤 통로를 거치는지 정하고, TLS는 통로를 암호화하고 서버 신원을 확인하는 데 쓰일 수 있습니다. 세 요소는 같은 연결 정보에 함께 나타나는 경우가 많지만 역할은 서로 다릅니다. 예를 들어 VLESS와 WebSocket은 서로 배타적인 프로토콜 선택지가 아닙니다. 전자는 프록시 계층을 설명하고 후자는 외부 전송을 담당할 수 있습니다. 계층을 나눠 보면 UUID가 맞아도 경로나 인증서 문제로 연결이 실패하는 이유를 파악할 수 있습니다.

연결 설정을 항목별로 나눠 확인하기

각 항목은 순서에 따라 영향을 주고받습니다. 주소 확인에 실패했다면 인증 항목을 바꿔도 대개 해결되지 않습니다. 서버가 TLS 핸드셰이크를 마친 뒤 인증을 거부했다면 DNS를 계속 조정해도 비밀번호 오류는 해결되지 않습니다. 마지막에 나타나는 포괄적인 시간 초과 메시지보다 실패와 직접 관련된 첫 로그가 더 유용합니다. 주소 확인, 통로 연결, 서버 인증, 대상 접근 중 어느 단계에서 오류가 발생했는지 기록하면 점검 범위를 크게 좁힐 수 있습니다.

속도와 배터리 소모에는 일률적인 순위가 없습니다

iOS에서 실제 사용 경험은 무선 신호, 왕복 지연 시간, 패킷 손실, 서버 부하, 대상 사이트의 영향을 함께 받습니다. 프로토콜 오버헤드는 여러 요소 중 하나일 뿐입니다. 핸드셰이크 단계가 적은 설계는 짧은 연결이 많은 상황에서 차이가 더 잘 드러날 수 있고, 대용량 파일을 계속 전송할 때는 회선 용량과 혼잡 제어가 더 중요할 수 있습니다. 한 번의 Connectivity Test 결과를 전체 접속 경로의 처리량으로 간주하거나 모든 대상에서의 성능으로 확대 해석하지 마세요.

배터리 소모 역시 프로토콜 이름만으로 판단할 수 없습니다. 암호화 연산에도 리소스가 들지만, 잦은 재연결, 무선 모듈의 지속적인 활성 상태, 지나치게 잦은 keep-alive, 반복적인 재전송이 더 큰 원인일 수도 있습니다. 비교할 때는 기기, 네트워크, 화면 밝기, 작업을 동일하게 유지하고 첫 실행, 지속 전송, 대기 상태를 나눠 관찰하세요. 이런 조건을 통제하지 않았다면 특정 프로토콜이 반드시 배터리를 덜 쓰거나 더 빠르다고 결론 내리기 어렵습니다.

특정 프로토콜을 지원하는 것과 그 프로토콜의 모든 조합을 지원하는 것은 구분해야 합니다. 외부 전송, 인증 확장, 특수 항목을 사용할 수 있는지는 현재 Shadowrocket 화면과 기존 서비스 안내를 기준으로 확인하세요. 안내에 클라이언트에서 찾을 수 없는 항목이 있다면 메모나 다른 입력란에 임의로 넣지 마세요. 먼저 다른 계층의 설정인지 확인하고, 필요한 경우 기존 서비스 제공자에게 문의하세요.

02 · Shadowsocks: 공유 키와 암호화 방식

설계 목표와 연결 구조

Shadowsocks는 암호화된 프록시 연결을 중심으로 설계되었으며, 일반적으로 공유 키를 사용해 통신을 보호합니다. 클라이언트는 앱의 요청을 받아 대상 정보와 데이터를 정해진 형식으로 원격 서버에 전달하고, 서버는 대상에 연결합니다. 이는 완전한 IP 계층 터널과는 다릅니다. 이 프로토콜은 주로 프록시 전달을 처리하며 서버 주소만으로 시스템 전체의 라우팅, 내부 주소 할당, 피어 관계를 모두 표현하지는 않습니다. 설정 항목은 비교적 단순하지만 어떤 요청을 프록시로 보낼지는 클라이언트의 라우팅 정책이 결정합니다.

Shadowsocks를 이해할 때 가장 중요한 점은 암호화 방식을 임의로 조정할 수 있는 보안 강도 슬라이더가 아니라 프로토콜 호환성의 일부로 보는 것입니다. 클라이언트와 서버는 같은 방식, 키 규칙, 메시지 형식을 사용해야 합니다. 이름이 몇 글자만 다른 암호화 방식도 설계가 다를 수 있으므로 이름이 비슷하다고 서로 바꿔 쓰면 안 됩니다. 최신 방식 계열은 키 재료의 인코딩이나 길이에 특정 조건이 있을 수 있으므로 일반 텍스트 비밀번호라면 모두 사용할 수 있다고 가정하지 마세요.

Address, Port, Password, 암호화 방식의 관계

Address에는 기존 서비스가 제공한 호스트 이름이나 IP 주소를 입력하세요. 공유 링크 전체를 주소 입력란에 넣으면 안 됩니다. Port는 서비스에서 해당 프로토콜이 대기 중인 포트이며 웹 주소의 임의의 숫자가 아닙니다. Password는 원본 그대로 정확하게 입력하세요. 복사 과정에서 앞뒤 공백, 줄바꿈, 전각 문장 부호가 들어가지 않았는지 특히 확인하세요. 암호화 방식도 문자 단위로 대조해야 합니다. 화면에 여러 선택지가 있다고 해서 서버 설정 대신 더 최신처럼 보이는 이름을 고르면 안 됩니다.

일반적인 AEAD 방식은 데이터 기밀성과 무결성 검증을 함께 처리하므로, 수신 측에서 검증을 통과하지 못한 메시지를 거부할 수 있습니다. 키나 방식이 일치하지 않으면 연결 종료, 대상의 무응답, 인증 관련 오류처럼 나타날 수 있으며 명확한 '비밀번호 오류' 메시지가 뜨지 않을 수도 있습니다. 따라서 원격 포트에 연결되었다고 해서 설정이 모두 올바른 것은 아닙니다. 클라이언트가 해당 연결로 실제 대상에 접근할 수 있는지 추가로 확인해야 합니다. 공유 링크를 가져온 뒤에도 목록에 이름이 표시되는지만 보지 말고 유형과 항목을 점검하세요.

TCP, UDP, 추가 전송 설정은 서로 다른 항목입니다

웹에서 흔히 쓰이는 TCP 트래픽과 UDP를 사용하는 앱 트래픽은 서로 다른 결과를 보일 수 있습니다. 완전한 경로를 구성하려면 서버, 클라이언트 설정, 중간 네트워크가 모두 해당 전달을 허용해야 합니다. UDP 관련 옵션 하나를 켠다고 해당 기능을 지원하지 않는 원격 서버가 자동으로 지원하게 되는 것은 아닙니다. 반대로 웹페이지 하나가 정상적으로 열려도 UDP 경로가 작동한다고 단정할 수 없습니다. 실제 앱의 요구에 따라 각각 확인하고 모든 실패를 서버 전체의 접속 불가로 묶지 마세요.

일부 연결 정보에는 추가 전송 또는 캡슐화 설정도 포함됩니다. 이는 Shadowsocks의 비밀번호나 암호화 방식과 혼동하면 안 됩니다. 기존 서비스에서 해당 설정을 명시했고 현재 화면에 대응 항목이 있을 때만 안내된 값 그대로 입력하세요. 가져온 링크에서 추가 매개변수가 빠졌다면 원래 설정을 먼저 기록한 뒤 한 번에 한 항목씩 수정하세요. 방식, 포트, 추가 전송을 연달아 바꾸면 어떤 항목이 변화를 일으켰는지 확인하기 어렵습니다.

모바일 기기에서 선택 기준 살펴보기

Shadowsocks는 설정 항목이 비교적 집중되어 있어 '접속 지점, 키, 방식'의 관계를 이해하기 좋습니다. 그렇다고 어떤 네트워크에서나 더 유리하다는 뜻은 아닙니다. 지속 전송 성능은 서버의 외부 회선과 패킷 손실의 영향을 받으며, 짧은 작업은 이름 확인과 연결 설정에도 영향을 받습니다. iPhone이 Wi-Fi에서 셀룰러 네트워크로 전환되면 기존 연결을 다시 설정해야 할 수 있습니다. 복구 속도는 전체 경로에 달려 있으며 프로토콜 이름만으로 판단할 수 없습니다.

문제 해결은 네 단계로 범위를 좁힐 수 있습니다. 먼저 Address가 확인되는지 살펴보고, 다음으로 포트가 현재 접속 지점에 해당하는지 확인한 뒤 방식과 키를 점검하고 마지막으로 TCP와 UDP 작업의 차이를 구분하세요. 연결은 되지만 일부 도메인만 실패한다면 검증과 라우팅 섹션으로 이동해 규칙과 DNS를 확인하세요. 특정 대상 문제를 해결하겠다며 인증에 성공한 프로토콜 설정을 반복해서 바꾸지 마세요.

03 · VMess와 VLESS: 인증, 전송, 보안 계층

설정 항목이 비슷해도 서로 바꿔 쓸 수 있는 것은 아닙니다

VMess와 VLESS는 모두 UUID를 사용자 식별자로 자주 사용하므로 가져온 뒤 주소, 포트, 인증 항목이 비슷하게 보일 수 있습니다. 하지만 서로 다른 통신 형식이므로 유형만 바꾸고 다른 항목을 그대로 두면 안 됩니다. VMess에는 자체 인증 및 데이터 보호 메커니즘이 포함됩니다. VLESS는 기본 설계가 더 간결하고 VMess와 동등한 페이로드 암호화를 자체 제공하지 않으므로 일반적으로 올바르게 구성된 보안 전송과 함께 사용해야 합니다. 두 프로토콜 중 무엇을 쓸지는 우선 기존 서버의 접속 지점에 따라 결정됩니다.

이 설계 차이가 곧바로 성능 차이로 이어지는 것은 아닙니다. VLESS가 프록시 계층의 일부 역할을 줄여도 외부 TLS나 다른 보안 메커니즘에는 별도의 비용이 발생합니다. VMess의 실제 성능 역시 전송, 다중화, 네트워크 상태의 영향을 받습니다. 설정 정보에 'VLESS'만 적혀 있고 외부 보안 설정이 설명되어 있지 않다면 정보가 불완전한 것입니다. 인증 항목이 있다고 해서 통로에 서버 인증과 데이터 암호화가 모두 적용되었다고 오해하지 마세요.

UUID, 시간, 인증 실패

UUID는 구조화된 식별자이므로 문자와 구분 기호를 모두 그대로 보존해야 합니다. 표시 이름, 구독 주소, 다른 비밀번호를 대신 입력하면 안 됩니다. VMess의 인증 설계는 시간과 관련되어 있어 기기의 시계가 크게 어긋나면 연결에 영향을 줄 수 있습니다. 인증에 실패하면 시스템 날짜와 시간이 정확한지 확인하세요. 가져온 설정에 호환성 관련 항목이 있다면 서비스 안내와 현재 클라이언트의 선택지를 기준으로 삼으세요. 오래된 가이드에서 숫자를 복사해 정상적으로 가져온 값을 덮어쓰지 마세요.

UUID가 올바르다고 해서 모든 인증 조건이 충족된 것은 아닙니다. 서버에서 사용자를 비활성화했거나 특정 접속 지점을 제한했거나 연결 정보를 갱신했을 수 있습니다. 구독을 갱신한 뒤에도 연결되지 않으면 이름만 비교하지 말고 새 항목과 이전 항목의 프로토콜 유형, 포트, 전송 설정을 비교하세요. 이름이 같은 두 연결도 서로 다른 설정을 가리킬 수 있으며, 이름이 달라도 같은 접속 지점의 메모만 바뀐 것일 수 있습니다. 판단 기준은 언제나 실제 설정 항목입니다.

WebSocket, Host, 경로, SNI

WebSocket은 프록시 데이터를 전달하는 외부 전송 방식이며 경로는 서버의 라우팅 규칙과 일치해야 합니다. 경로는 앞에 슬래시가 붙는 경우가 많고 대소문자나 다른 문자도 일치 여부에 영향을 줄 수 있습니다. Host는 HTTP 요청의 가상 호스트 선택에 관여할 수 있고, SNI는 TLS 핸드셰이크에서 서버 이름을 알리는 데 사용됩니다. 서로 다른 계층의 항목이므로 한 설정에서 두 값이 같더라도 언제나 같아야 한다고 단정하면 안 됩니다.

Address에 IP를 사용하더라도 서비스 안내에서 도메인 형식의 SNI를 요구할 수 있습니다. 연결 주소와 인증서의 신원은 서로 다르기 때문입니다. 제공된 이름 중 검증에 통과하는 올바른 값을 사용하고 오류를 피하려고 검증을 끄지 마세요. 외부 전송이 아직 성립하지 않았다면 프록시 계층의 UUID를 서버가 확인할 기회조차 없을 수 있습니다. TLS 오류, 경로 오류, 인증 오류를 먼저 구분해야 하는 이유입니다.

이름으로 순위를 매기지 말고 작업별로 확인하기

모바일 네트워크에서 추가 캡슐화는 핸드셰이크와 패킷 오버헤드를 늘리고 연결 복구 방식에도 영향을 줄 수 있지만, 실제 차이는 작업 시간을 고려해 살펴봐야 합니다. 짧은 연결이 많은 페이지, 장시간 유지되는 세션, 지속 다운로드는 각각 중요한 기준이 다릅니다. Wi-Fi에서는 정상인데 셀룰러 네트워크에서 실패한다면 프로토콜 자체를 분석하기 전에 같은 접속 지점의 주소 확인, 외부 전송, 포트 연결 여부부터 확인하세요. Config의 전반적인 사용법은 기능 안내를 참고해 라우팅 선택 문제를 프로토콜 호환성 문제로 오인하지 않도록 하세요.

04 · Trojan: TLS 서버 인증과 비밀번호 인증

통로 보안과 사용자 인증의 역할

Trojan은 TLS 기반 연결을 사용해 보호된 통로에서 프록시 요청과 사용자 인증을 처리합니다. 이때 서버 신원과 사용자 신원을 구분해야 합니다. TLS 인증서는 연결 대상 서버가 무엇인지 클라이언트가 확인하는 데 쓰이고, Password는 사용자의 접근 권한을 서버가 확인하는 데 쓰입니다. 비밀번호가 맞아도 인증서 검증에 실패하면 정상 연결로 볼 수 없습니다. 인증서가 정상이어도 비밀번호가 맞지 않으면 프록시를 사용할 수 없습니다.

이 역할 구분을 보면 TLS는 속도를 높이기 위해 임의로 켜고 끄는 장식이 아닙니다. 일반적인 Trojan 연결에서 문제를 해결하겠다며 TLS를 끄고도 원격 서버가 기존 프로토콜을 알아볼 것이라고 기대하면 안 됩니다. 기존 연결 정보에 특수 전송 설정이 포함되어 있다면 Trojan 연결은 항상 필드 세 개만 필요하다고 가정하지 말고 해당 조합을 모두 점검하세요. 기본 프로토콜과 추가 전송 방식이 함께 일치해야 하며 어느 한 계층의 오류만으로도 요청이 최종 단계에 도달하지 못할 수 있습니다.

Address, Port, Password, SNI 입력 기준

Address는 네트워크 연결이 향하는 곳을 지정하며 서비스에서 제공한 도메인이나 명시된 IP를 사용할 수 있습니다. Port는 해당 Trojan 접속 지점의 포트여야 합니다. TLS를 사용한다고 해서 포트가 특정 고정값일 것이라고 추정하면 안 됩니다. Password는 원본 정보를 그대로 입력하고 복사 과정에서 눈에 보이지 않는 줄바꿈이 들어가지 않았는지 확인하세요. SNI에는 서비스 안내에 지정된 서버 이름을 사용합니다. Address와 같을 수도 있고 Address가 IP일 때 별도로 안내된 도메인일 수도 있습니다.

인증서 검증에는 이름 일치, 유효 기간, 신뢰 체인, 기기 시간 등이 영향을 줍니다. SNI는 임의의 도메인을 입력해 유효한 인증서를 얻는 기능이 아니라 원격 서버에 기대하는 이름을 알리고 이후 검증에 사용할 이름을 지정하는 역할을 합니다. 인증서 이름이 맞지 않으면 먼저 입력 오류, 오래된 서비스 정보, 서버 인증서 설정을 확인하세요. 기기 날짜가 잘못되었다면 시스템 시간을 먼저 바로잡으세요. 검증을 끄면 연결의 보안 속성이 달라지므로 장기적인 해결책으로 삼지 마세요.

연결 실패의 발생 순서 파악하기

Address를 확인할 수 없다면 서버에 도달하기 전 단계에서 문제가 발생한 것입니다. 원격 서버가 연결을 거부하면 먼저 포트와 대기 상태를 살펴보세요. TLS 이름이나 신뢰 관련 오류가 나타나면 서버 인증 계층을 집중적으로 확인하세요. TLS 통로가 성립된 뒤에야 서버가 Trojan 인증과 대상 전달을 처리할 수 있습니다. 이 순서대로 확인하면 인증서 검증 전부터 Password를 반복해서 바꾸거나 방향 없이 여러 설정 조합을 시험하는 일을 줄일 수 있습니다.

통로와 인증이 완료되었는데도 대상 웹사이트가 열리지 않는 경우도 있습니다. 이때는 대상 도메인의 확인, 원격 서버에서 대상까지의 연결, 로컬 요청이 실제로 해당 연결을 선택했는지 살펴보세요. 웹사이트 하나만 실패한다면 Trojan 접속 지점 전체의 문제라고 단정할 수 없습니다. 접근 가능한 다른 대상을 비교용으로 사용하고 요청 기록을 확인해 오류가 어느 단계에서 발생했는지 살펴보세요. Home의 연결 스위치 상태만 확인해서는 안 됩니다.

모바일 네트워크에서의 동작과 사용 기준

TLS 연결에는 핸드셰이크가 필요하므로 왕복 지연 시간이 크거나 연결을 자주 다시 설정할 때 비용이 더 두드러질 수 있습니다. 세션이 유지된 뒤의 실제 전송은 회선 용량, 혼잡, 대상의 응답에 더 크게 좌우됩니다. TLS를 사용한다는 이유만으로 반드시 느리다고 판단할 수 없고, 한 번의 테스트 시간이 짧았다고 이후 작업도 항상 안정적이라고 단정할 수 없습니다. iOS에서 무선 네트워크를 전환하거나 기기가 잠자기 상태에 들어갔다가 깨어나면 기존 연결 상태가 달라질 수 있으므로 복구 과정을 별도로 관찰하세요.

Trojan 설정 정보를 모두 보유한 사용자는 인증서 검증 여부, Address와 SNI의 명확성, 네트워크 전환 후 복구 여부를 중점적으로 확인하세요. 알 수 없는 설정을 덧붙일 필요는 없습니다. 항목별로 다시 확인하려면 Trojan 설정값 입력 안내를 읽어보세요. 사용 가능 여부를 확인한 설정을 보관하고 복사본에서 테스트하세요. 구독을 갱신한 뒤에는 오래된 수동 복사본이 아니라 현재 적용 중인 항목을 확인하고 있는지 점검하세요.

05 · HTTP와 SOCKS5: 범용 프록시의 기능 범위

HTTP 프록시와 HTTPS 웹사이트는 다른 개념입니다

HTTP 프록시는 일반적인 프록시 접속 모델의 하나로, 정해진 방식의 요청을 처리하고 CONNECT 등의 메커니즘으로 대상까지 통로를 만들 수 있습니다. 흔한 오해는 대상 URL이 HTTPS라면 클라이언트와 프록시 서버 사이에도 반드시 TLS가 적용된다는 것입니다. 실제로는 두 구간을 따로 살펴봐야 합니다. 웹사이트의 HTTPS는 주로 클라이언트와 대상 사이트 사이의 앱 데이터를 보호합니다. 프록시 접속 지점 자체에 TLS가 적용되는지는 프록시 유형과 접속 지점 설정에 달려 있으며 대상 URL만으로 추정할 수 없습니다.

CONNECT 이후 대상 콘텐츠가 HTTPS로 보호되더라도 프록시는 어느 대상에 연결할지 알아야 하며 전달 과정에 관여합니다. 따라서 대상 콘텐츠 암호화만으로 프록시 인증 정보와 모든 연결 메타데이터까지 동일하게 보호되는 것은 아닙니다. 기존 서비스에서 암호화된 HTTP 프록시 접속 지점을 제공한다면 안내에 따라 유형과 보안 옵션을 선택하세요. 일반 HTTP 접속 지점을 임의로 다른 유형으로 바꾸고 핸드셰이크 실패를 사용자 이름 오류로 오해하지 마세요.

SOCKS5의 협상, 인증, UDP

SOCKS5는 범용 연결 전달을 위한 프로토콜로, 협상을 통해 인증 방식과 요청 작업을 결정합니다. 대상 주소와 포트를 지정할 수 있고 UDP 연결 기능도 정의하지만 기본 프로토콜 자체에는 TLS와 같은 통로 암호화 기능이 없습니다. 사용자 이름과 비밀번호는 접근 제어에 사용되며 암호화 기능과 같은 의미가 아닙니다. 인증 정보를 입력한 뒤에도 클라이언트와 프록시 사이에 어떤 보호 방식이 적용되는지, 서버에서 어떤 기능을 활성화했는지 확인해야 합니다.

SOCKS5 표준에 UDP 관련 기능이 포함되어 있어도 모든 서비스 접속 지점과 네트워크 경로에서 UDP를 사용할 수 있는 것은 아닙니다. 서버 구현, 접근 정책, 중간 네트워크, 클라이언트의 현재 설정이 모두 결과에 영향을 줍니다. TCP 웹 접속은 되는데 UDP 앱만 실패한다면 실제 서비스에서 UDP를 허용하는지 먼저 확인한 뒤 전달 경로를 점검하세요. 프로토콜 이름이 SOCKS5라는 이유만으로 접속 지점 기능 부족이나 프로토콜 문제 가능성을 배제하면 안 됩니다.

설정 항목이 적어도 정확히 확인해야 합니다

두 유형의 일반적인 설정 항목은 Address, Port이며 서비스에서 요구하는 경우 사용자 이름과 비밀번호도 포함됩니다. 인증 필요 여부는 기존 안내를 따라야 합니다. 사용자 이름을 비워 두는 것과 임의의 이름을 입력하는 것을 같은 것으로 보면 안 됩니다. 인증 정보에 특수 문자가 포함되었다면 신뢰할 수 있는 가져오기 방법을 사용하거나 각 항목을 별도로 입력하세요. 공유 링크를 직접 조합하다 인코딩 문제가 생기지 않도록 주의해야 합니다. 메모 이름은 로컬에서 항목을 구분하는 용도일 뿐 인증 정보를 대신하지 않습니다.

이름 확인과 실제 사용 환경

요청에 도메인이 포함될 수도 있고 로컬에서 확인한 IP가 포함될 수도 있습니다. 이에 따라 이름 확인 위치와 이후 규칙 판단이 달라질 수 있습니다. HTTP 또는 SOCKS5라는 표시만 보고 모든 도메인이 원격에서 확인된다고 단정하지 마세요. 문제를 확인할 때 Shadowrocket의 DNS 설정, 대상 요청 형식, 적용 중인 규칙을 함께 살펴보세요. 같은 대상이 도메인으로는 실패하고 알고 있는 주소로는 연결된다면 사용자 이름이나 포트를 바로 바꾸지 말고 이름 확인 경로를 점검하세요.

이미 구성된 업무용 프록시, 테스트 환경, 명시적으로 제공된 범용 프록시 접속 지점에 연결할 때 이 유형을 사용할 수 있습니다. 다른 프로토콜을 대체하는 범용 수단은 아닙니다. iPhone과 iPad에서의 실제 동작은 인증, 통로 보호, 대상 연결, 시스템 네트워크에 따라 달라집니다. 사용 중 원래 정책으로 되돌려야 할 수 있으므로 변경 전 Global Routing 상태와 Config를 기록하세요. 한 번의 테스트가 이후 모든 앱에 영향을 주지 않도록 주의하세요. 자주 겪는 문제는 문제 해결에서 증상에 따라 확인할 수 있습니다.

06 · WireGuard: 피어, 키, 터널 주소

프록시 요청에서 IP 계층 터널로

WireGuard는 IP 계층 터널을 위해 설계되었으며 공개 키로 피어를 식별하고 UDP로 네트워크 패킷을 캡슐화해 전달합니다. 주소와 비밀번호만 입력하는 프록시 접속 지점과 달리 터널 내부 주소, 피어 신원, 처리할 수 있는 주소 범위도 설정해야 합니다. 이 항목들을 이해해야 설정 정보가 완전한지 판단할 수 있습니다. 원격 IP와 포트만 알아서는 올바른 연결을 만들 수 없습니다. 서버가 클라이언트의 공개 키를 인식하고 해당 주소와 전달 방식을 설정해야 하기 때문입니다.

Shadowrocket에서 WireGuard를 사용할 때는 앱이 트래픽을 처리하는 기능과 원격 프로토콜의 캡슐화를 구분해야 합니다. iOS에 VPN 관련 상태가 표시되는 것은 클라이언트가 시스템 네트워크 처리 권한을 얻었다는 뜻이지, 현재 모든 외부 연결이 WireGuard를 사용한다는 의미가 아닙니다. 선택한 서버 유형, Global Routing, Config를 확인해야 합니다. 시스템 VPN 아이콘만으로 터널 내부 주소와 원격 피어가 정상적으로 통신한다고 판단할 수도 없습니다.

개인 키, 공개 키, 선택적 공유 키

클라이언트 개인 키는 로컬 신원 확인과 키 협상에 사용되므로 자신의 기기와 백업에서 안전하게 보관해야 합니다. 서버 공개 키는 원격 피어를 식별합니다. 두 항목을 바꿔 입력하거나 모든 키 입력란에 같은 값을 넣으면 안 됩니다. 클라이언트 공개 키는 개인 키에 대응해 생성되며 원격 서버는 이 공개 키로 클라이언트를 식별합니다. 클라이언트 개인 키를 바꾸고 서버 설정을 함께 갱신하지 않으면 Endpoint가 그대로여도 기존 인증 관계가 무효가 될 수 있습니다.

일부 서비스는 기존 공개 키 방식에 공유 정보를 추가하기 위해 별도의 사전 공유 키도 제공합니다. 이는 클라이언트 개인 키나 서버 공개 키가 아니므로 안내된 항목에 각각 입력해야 합니다. 실제 키를 공개 스크린샷, 오류 보고서, 글 댓글에 올리지 마세요. 문제를 확인할 때 해당 항목이 있는지 또는 형식이 맞는지 설명할 수는 있지만 원본 값은 공개하면 안 됩니다. 기기를 옮길 때 백업 파일에 민감한 정보가 포함될 수 있으므로 일반 규칙 파일처럼 취급하지 마세요.

Endpoint, 주소 범위, DNS

Endpoint는 원격에서 실제로 연결할 수 있는 주소와 UDP 포트를 지정합니다. 터널 내부 주소는 터널에서 사용하는 네트워크 신원으로, 두 항목은 서로 다른 네트워크 계층에 속합니다. 내부 주소를 공용 접속 지점에 입력하거나 Endpoint를 내부 주소 입력란에 넣으면 연결이 잘못됩니다. 주소 범위 관련 설정은 어떤 대상 주소 또는 피어 주소 관계를 처리할지 지정합니다. 실제 역할은 클라이언트의 라우팅 연동 방식에 따라 달라지므로 Shadowrocket의 도메인 규칙 목록과 단순히 같은 것으로 볼 수 없습니다.

IPv4와 IPv6도 따로 고려해야 합니다. 한 주소 계열의 경로를 설정했다고 다른 주소 계열도 똑같이 연결된다는 뜻은 아닙니다. 도메인이 IPv6 주소를 우선 반환하는데 터널이나 원격 전달에 해당 지원이 없다면 일부 대상만 실패할 수 있습니다. DNS 서버에 연결할 수 있는지도 중요합니다. 내부 DNS 주소를 지정했다면 기존 터널을 통해 실제로 접근되는지 확인하세요. 설정 정보에 DNS가 있다고 해서 이름 확인 경로가 자동으로 정상이라고 단정하면 안 됩니다.

Keep-alive, MTU, 모바일 네트워크 전환

Keep-alive는 중간 장비가 유휴 UDP 상태를 정리하는 환경 등에서 필요에 따라 네트워크 매핑을 유지하는 데 사용됩니다. 간격을 너무 짧게 하면 무선 네트워크를 깨우는 일이 늘 수 있으므로 '항상 온라인' 상태를 유지하려고 임의로 간격을 줄이지 마세요. 필요한지와 적절한 값은 기존 서비스 안내와 실제 네트워크를 기준으로 판단해야 합니다. 모바일 네트워크 전환으로 클라이언트가 보이는 외부 주소가 바뀔 수 있습니다. WireGuard는 인증된 통신 후 피어가 주소 변화에 대응할 수 있도록 설계되었지만, 복구에는 새 경로를 통한 데이터 전달이 필요합니다.

MTU는 한 패킷에 실을 수 있는 데이터 크기에 영향을 줍니다. 너무 크면 특정 경로에서 단편화나 패킷 손실이 생길 수 있고, 너무 작으면 캡슐화 비율과 패킷 수가 늘어납니다. 작은 요청은 정상인데 큰 페이지나 지속 전송이 멈춘다면 경로 MTU를 점검 항목으로 고려할 수 있지만 모든 시간 초과의 원인이라고 단정하면 안 됩니다. 먼저 키와 핸드셰이크를 확인하고 내부 주소, DNS, 대상 전달을 검증한 다음 근거가 있을 때 MTU를 조정하세요. 설정 백업과 기기 변경은 설정 이전 안내를 참고하세요.

07 · Hysteria2: QUIC, UDP 경로, 혼잡 제어

설계 배경과 호환성 범위

Hysteria2는 QUIC 기반 전송을 사용하며 UDP 경로에 의존합니다. 인증과 TLS 관련 메커니즘을 함께 사용해 프록시 통신을 설정합니다. 복잡한 네트워크에서의 데이터 전송과 혼잡 처리를 고려한 설계지만 모든 네트워크에서 속도가 더 빠르다는 뜻은 아닙니다. 먼저 사용 가능한 UDP 경로가 필요합니다. 현재 네트워크에서 원격의 해당 포트에 도달할 수 없다면 대역폭 설정이나 비밀번호를 바꿔도 이 기본 제한을 우회할 수 없습니다.

Hysteria2의 숫자 2는 프로토콜 이름의 일부이며 이 페이지에서 안내하는 Shadowrocket 앱 버전이 아닙니다. 가져오기 전에 서비스에서 실제로 Hysteria2를 제공하는지 확인하세요. 이름이 비슷하다는 이유만으로 유형을 선택하면 안 됩니다. 프로토콜 세대, 전송 형식, 선택 설정에는 호환성 범위가 있을 수 있으므로 같은 주소와 인증 정보를 다른 유형에서도 그대로 사용할 수 있다고 가정하지 마세요. 앱에서 제공하는 추가 설정은 실제 화면과 기존 서비스 안내를 기준으로 확인하세요.

접속 지점, 인증, 인증서를 각각 확인하기

먼저 원격 Address와 UDP 포트를 확인한 다음 인증 정보와 TLS 서버 이름을 확인하세요. 주소는 실제 통신 접속 지점을 가리키고 SNI는 서버 이름을 알리고 인증서를 검증하는 데 쓰입니다. 서비스 설정에 따라 두 항목을 다르게 입력할 수 있지만 임의로 추측해서는 안 됩니다. IP로 연결하면서 도메인 검증이 필요하다면 서비스에서 명시한 도메인을 사용하세요. 정보가 부족하다고 인증서 검증을 끄면 안 됩니다.

일부 연결 정보에는 난독화나 기타 추가 설정이 포함되기도 합니다. 이는 인증 비밀번호를 대신하는 값도 아니고 기본적으로 켜야 하는 범용 옵션도 아닙니다. 서버에서 해당 기능을 설정한 경우에만 클라이언트에도 일치하는 정보를 입력해야 합니다. 항목 누락, 오타, 불필요한 활성화는 인증 단계에 도달하기도 전에 패킷 처리를 막을 수 있습니다. 문제 해결 시 안내와 항목을 하나씩 대조하고 인증, 보안, 추가 설정을 한꺼번에 바꾸며 맞춰 보지 마세요.

대역폭 입력값이 실제 연결 용량을 정하지는 않습니다

현재 설정에 업로드·다운로드 대역폭 또는 혼잡 관련 옵션이 있다면 이는 전송 제어 정보이지 서버 용량에 대한 보장이 아니라는 점을 먼저 이해하세요. 일부 제어 방식은 대역폭 추정치를 참고하고 다른 방식은 구현이 자동으로 판단할 수 있습니다. 실제 적용 조건은 해당 설정 안내를 확인하세요. 큰 숫자를 입력해도 무선 신호, 서버 외부 회선, 대상 사이트의 성능이 향상되지는 않습니다. 오히려 패킷 손실, 대기열, 같은 네트워크의 다른 작업에 대한 간섭이 늘 수 있습니다.

입력할 때 비트와 바이트를 구분하고 화면에서 요구하는 단위를 확인하세요. 가정용 인터넷의 표시 속도는 iPhone의 현재 무선 연결에서 안정적으로 사용할 수 있는 속도와 다르며 셀룰러 업로드 속도와도 다릅니다. 신뢰할 만한 측정값이 없다면 한 번 기록된 짧은 최고 속도를 기준으로 값을 정하지 말고 기존 안내의 권장값이나 명시적으로 지원되는 자동 설정을 유지하세요. 변경 전후를 비교할 때는 순간 최고 속도뿐 아니라 작업 완료 시간, 실패율, 다른 앱에 미치는 영향도 살펴보세요.

패킷 손실, 네트워크 전환, 배터리 확인

QUIC는 UDP에서 연결과 신뢰성 있는 전송을 처리하고 데이터 흐름별 관리 기능을 제공하지만 물리적인 경로에서 발생하는 패킷 손실을 없애지는 못합니다. 네트워크 품질이 떨어지면 재전송과 혼잡 제어가 계속 작동하며 무선 신호가 반복해서 변하면 이전 추정치도 유효하지 않을 수 있습니다. 일부 환경은 UDP를 TCP와 다르게 처리하므로 같은 기기에서 TCP 유형의 접속 지점을 사용할 수 있다고 Hysteria2의 UDP 경로도 반드시 된다고 볼 수 없습니다.

iOS에서는 지속적인 전송과 재전송, 네트워크 활성 상태 유지가 모두 배터리 사용량에 영향을 줄 수 있습니다. 화면, 백그라운드 동기화, 기기 온도의 영향을 가능한 한 줄이고 지속 전송과 유휴 상태를 나눠 관찰하세요. Wi-Fi와 셀룰러 네트워크를 전환한 뒤 QUIC의 일반적인 기능만으로 세션이 반드시 끊김 없이 유지된다고 볼 수 없습니다. 서버와 클라이언트 구현, 새 경로의 상태도 결과에 영향을 줍니다. 주된 작업이 짧은 정보 확인이고 다른 연결이 이미 안정적이라면 프로토콜 이름만 보고 모든 설정을 바꿀 필요는 없습니다.

같은 네트워크와 대상, 비슷한 시간대에 기본 연결을 확인한 뒤 여러 번 작업을 완료해 보세요. UDP 접속 지점만 실패한다면 포트 연결 여부와 경로 정보를 우선 확인하세요. 모든 접속 지점이 실패한다면 기기 네트워크와 대상을 점검하세요. '전송 연결을 설정하지 못함'과 '연결은 되었지만 작업이 느림'을 별개의 문제로 다뤄야 관련 없는 설정을 바꿔 실제 원인을 가리는 일을 피할 수 있습니다.

08 · 프로토콜에서 실제 요청까지: 검증, 규칙, 문제 해결

반복해서 확인할 수 있는 검증 절차부터 만들기

프로토콜 설정을 확인한 뒤 Home으로 돌아가 검증할 연결을 선택하고 Global Routing을 확인하세요. Config 모드에서는 현재 Config의 규칙에 따라 정책이 결정됩니다. Proxy 모드는 관련 트래픽을 선택된 프록시 경로로 처리하며 Direct 모드는 주로 직접 연결에 사용됩니다. 세 가지는 라우팅 모드이지 원격 프로토콜 종류가 아닙니다. Direct에서 웹사이트가 정상적으로 열린다고 해서 방금 입력한 Trojan이나 Shadowsocks에 연결할 수 있다는 뜻은 아닙니다.

테스트 전에 기존 모드와 현재 Config를 기록하고 같은 웹페이지를 열어 콘텐츠가 완전히 로드되는지 확인하는 등 명확한 작업을 선택하세요. Connectivity Test는 연결 상태를 파악하는 단서로 사용할 수 있지만 테스트 방식, 대상, 당시 네트워크의 영향을 받으므로 실제 작업을 대신하지 않습니다. 시스템 연결 스위치가 켜져 있다는 것은 클라이언트가 네트워크 처리를 맡고 있다는 뜻일 뿐 모든 요청이 원격 서버를 통해 성공했다는 뜻은 아닙니다. 올바른 항목 선택, 요청이 예상한 정책을 따르는지, 대상에 실제로 접근할 수 있는지 세 단계 모두 검증하세요.

규칙의 순서에 따라 결과가 달라집니다

Config의 규칙은 위에서 아래로 하나씩 평가하며 처음 일치하는 규칙이 정책을 결정합니다. PROXY는 프록시 정책에 따라 처리하고, DIRECT는 직접 연결하며, REJECT는 요청을 거부합니다. 프로토콜 설정이 완벽해도 대상이 DIRECT에 일치하면 예상한 프록시 경로를 통과하지 않습니다. 먼저 REJECT에 일치하면 아래쪽에 PROXY가 있어도 계속 시도하지 않습니다. 문제를 해결할 때는 실제로 어떤 규칙에 일치했는지 먼저 확인하고 인증을 통과한 연결 정보를 바로 바꾸지 마세요.

아래는 규칙 순서를 설명하는 Shadowrocket .conf 예시이며 서버 정보는 포함하지 않습니다. 예외 도메인은 범위 규칙보다 위에 두고, 사설 주소 범위는 DIRECT로 설정하며, 마지막에는 앞의 어떤 규칙에도 일치하지 않는 요청을 FINAL로 처리합니다. 예시 도메인은 설명용일 뿐 실제 서비스를 나타내지 않습니다. 이 몇 줄을 모든 환경에 맞는 완성된 설정으로 사용하지 마세요.

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

DOMAIN-SUFFIX를 앞에 두면 ads.example.com이 먼저 범위 규칙에 일치해 뒤에 있는 정확한 거부 규칙이 적용되지 않습니다. IP 규칙이 판단에 참여하는지는 요청에 사용할 수 있는 주소 정보와 이름 확인 동작에도 영향을 받습니다. 규칙 문구만 보고 모든 도메인이 특정 주소 범위에 반드시 일치한다고 단정하지 마세요. 더 자세한 규칙 배치 방법은 규칙 순서와 FINAL 안내를 참고하세요. 처음 설정할 때는 빠른 시작 가이드를 따라 진행하세요.

오류가 발생한 계층에 따라 다음 단계 선택하기

한 번에 한 항목씩 바꾸고 수정 전후의 구체적인 결과를 기록하세요. Subscribe를 갱신한 뒤 항목이 달라졌다면 현재 선택한 것이 예상한 접속 지점인지 먼저 확인하세요. 수동으로 복사한 항목은 구독을 갱신해도 함께 바뀌지 않을 수 있습니다. 문제를 보고할 때는 프로토콜 이름, 오류 단계, 네트워크 유형, 민감한 정보를 제거한 설정 항목 구조를 제공할 수 있지만 전체 구독 주소, Password, UUID, 개인 키 등은 삭제해야 합니다. 로그에 접속 대상이 포함될 수도 있으므로 공유 전에 확인하세요.

실제 작업 조건에 맞춰 최종 선택하기

기존 범용 프록시 환경에 연결해야 한다면 HTTP 또는 SOCKS5의 인증, 보호 방식, 필요한 기능을 먼저 확인하세요. Shadowsocks, VMess, VLESS, Trojan 접속 정보를 보유한 경우에는 방식, 전송, TLS 설정이 서로 일치하는지 확인하세요. WireGuard 설정이 있다면 피어, 내부 주소, 허용 범위를 점검하고 Hysteria2 접속 지점이 있다면 UDP 경로와 제어 설정을 우선 확인하세요. 이는 점검 항목이지 성능 순위가 아닙니다.

최종적으로 사용할 연결은 설정 정보가 완전하고, 서버 신원을 예상한 대로 검증하며, 자주 사용하는 작업을 반복해서 완료할 수 있고, 실제 네트워크 전환과 대기 상태에서도 수용할 만하게 작동해야 합니다. 한 번 측정한 숫자를 줄이려고 올바른 인증서 검증을 포기하거나 안정적인 설정을 계속 바꾸지 마세요. 앱 구매, 시스템 호환성, 다시 받는 방법은 App Store 정품 다운로드 가이드에서 확인하세요. 연결 문제와 화면 조작은 문제 해결을 참고하세요. 이 페이지는 판단 기준을 설명하고, 가이드는 그 기준을 처음 설정할 때 실행할 단계로 연결합니다.