Shadowrocket프로토콜 가이드

1. 프로토콜 선택: 설정을 네 단계로 나누어 확인

프로토콜 유형은 서버 설정과 일치해야 합니다

Shadowrocket에서 프로토콜을 고를 때 이름만 보고 가장 빠른 옵션을 선택하는 것은 적절하지 않습니다. 서버가 사용하는 프로토콜과 클라이언트 유형이 일치해야 합니다. 같은 주소와 포트를 사용하더라도 프로토콜 이름만 바꾸면 연결되는 경우는 드뭅니다. 구독에서 유형을 제공했다면 우선 기존 설정을 유지하세요. Add Server로 직접 추가할 때는 서버 주소, 포트, 인증 정보와 서버 측에서 지정한 전송 및 암호화 설정을 먼저 정리합니다. 정보가 부족하다면 옵션을 계속 바꾸기보다 기존 서비스의 설정 안내를 확인하는 편이 효과적입니다.

설정을 네 단계로 나누어 이해할 수 있습니다. 첫째, 주소와 포트는 연결할 대상을 정합니다. 둘째, 프로토콜과 인증은 양쪽이 신원을 확인하고 요청을 주고받는 방식을 정합니다. 셋째, 전송 방식은 요청을 전달하는 방법을 정합니다. 넷째, TLS 등의 보안 설정은 연결에서 신원을 확인하고 전송을 보호하는 방식을 정합니다. 일부 프로토콜은 여러 단계를 하나로 통합하므로 추가 화면에 모든 항목이 표시되는 것은 아닙니다. 특정 항목이 없다고 기능이 빠진 것은 아니며, 다른 프로토콜의 설정을 그대로 복사해서도 안 됩니다.

속도, 배터리와 보안은 서로 다른 기준입니다

속도는 연결 수립, 첫 응답, 지속 전송의 세 단계로 나누어 볼 수 있습니다. 핸드셰이크 횟수가 적으면 웹페이지를 처음 열 때 대기 시간이 줄어들 수 있고, 적절한 혼잡 제어는 장시간 전송에 도움이 될 수 있습니다. 서버 부하가 낮으면 일반적인 프로토콜도 더 안정적으로 동작할 수 있습니다. 배터리 사용량은 무선 신호, 재전송, 백그라운드 작동과 연결 유지 빈도에도 영향을 받습니다. 프로토콜 이름만으로 고정된 배터리 소모 순서를 예측할 수 없습니다. 신호가 약한 셀룰러 네트워크에서는 반복 연결에 드는 비용이 암호화 알고리즘 간 차이보다 더 크게 나타날 수 있습니다.

인증과 암호화도 구분해야 합니다. 비밀번호나 UUID는 사용자를 식별하는 정보이며, 이것만으로 모든 전송 구간이 암호화되는 것은 아닙니다. TLS가 클라이언트와 서버 사이의 통신을 암호화하더라도 서버와 대상 웹사이트 사이의 모든 연결까지 해당 프로토콜이 보호하는 것은 아닙니다. 웹사이트에 접속할 때는 사이트 자체의 보안 연결도 확인해야 합니다. 실용적인 선택 기준은 모든 보안 특성을 하나의 이름으로 판단하는 것이 아니라 전체 연결 경로에서 각 설정이 적용되는 범위를 확인하는 것입니다.

프로토콜과 트래픽 분기가 각각 해결하는 문제

Global Routing은 트래픽을 규칙에 따라 처리할지 결정하고, 프로토콜은 서버로 전달되는 연결의 전송 방식을 정합니다. Config 모드는 현재 설정에 따라 처리하고, Proxy 모드는 해당 트래픽을 선택한 프록시로 전달하며, Direct 모드는 직접 접속합니다. 이 세 모드를 바꿔도 잘못된 비밀번호나 포트가 수정되지는 않습니다. 프로토콜을 바꿔도 잘못 작성된 DIRECT 또는 REJECT 규칙이 자동으로 바로잡히지 않습니다. 진단할 때는 ‘서버를 경유하는지’와 ‘서버를 경유한 뒤 통신할 수 있는지’를 따로 확인해야 합니다.

문제를 재현할 수 있는 원래 설정을 먼저 저장한 뒤 항목을 하나씩 조정하는 것이 좋습니다. 서버 이름은 식별에 도움이 되지만 실제 프로토콜을 증명하지는 않습니다. 지역 표기도 물리적 거리나 실제 라우팅 경로를 의미하지 않습니다. 가져오기 전후에 이름이 같은 항목의 설정이 달라졌다면 이름이 아니라 각 항목을 비교하세요. 프로토콜 옵션의 구체적인 표시 방식은 현재 앱에서 확인할 수 있는 항목을 기준으로 합니다. 이 페이지는 각 항목의 의미를 설명하며, 특정 서버 조합을 모든 사용자가 기본으로 활성화해야 한다고 안내하지 않습니다.

2. Shadowsocks: 간결한 전달 구조와 암호화 방식

경량 프록시 전송 구조에 중점을 둔 설계

Shadowsocks는 암호화된 프록시 전달을 중심으로 설계되어 대상 주소와 앱 데이터를 서버로 전달합니다. 기기 전체를 연결하는 네트워크 프로토콜이 아니며 기기에 터널 내부 주소를 할당할 필요도 없습니다. 클라이언트에서 주로 확인할 정보는 서버 주소, 포트, 비밀번호와 암호화 방식입니다. 항목이 적으면 직접 입력하기 편하지만 어느 하나도 생략할 수 있다는 뜻은 아닙니다. 특히 암호화 방식은 서버에서 실제로 설정한 값과 일치해야 합니다.

초기의 스트림 암호 방식과 이후의 AEAD 방식은 무결성 보호와 메시지 처리 방식이 다릅니다. AEAD는 데이터 기밀성과 무결성 검사를 함께 처리하므로 이름이 비슷하다는 이유로 이전 방식을 대신 사용할 수 없습니다. 프로토콜 세대에 따라 키 길이, 인코딩과 인증 구조도 다를 수 있습니다. 안내에 특정 형식의 키가 명시되어 있다면 임의로 짧은 일반 비밀번호로 바꾸지 마세요. 클라이언트에서 해당 조합을 인식하지 못한다면 비슷해 보이는 항목을 선택하기보다 양쪽의 지원 여부를 먼저 확인하세요.

Password와 암호화 방식은 함께 확인해야 합니다

Password는 민감한 인증 정보입니다. 복사할 때 앞뒤 공백, 줄바꿈과 전각 문자가 들어가지 않았는지 확인하세요. 암호화 방식은 해당 키 정보를 사용하는 방법을 결정하므로 두 항목 모두 서버 설정과 일치해야 합니다. 입력한 항목이 저장되었다는 것은 양식이 받아들여졌다는 뜻일 뿐, 원격 인증이 성공했다는 의미는 아닙니다. 지연 시간 테스트에 결과가 나와도 웹페이지에 접속할 수 없는 경우 비밀번호가 반드시 맞다고 단정할 수 없습니다. 테스트 경로에 따라 연결 과정의 일부만 확인할 수 있으므로 실제 요청과 앱 내 기록을 함께 살펴보세요.

기존 설정 중에는 추가 전송 확장 항목이 포함된 것도 있습니다. 이런 항목은 서버 구성의 일부이며 일반 설정을 자동으로 빠르게 해주는 스위치가 아닙니다. 다른 항목의 Host, 경로나 확장 옵션을 복사하지 말고, 안내가 없을 때 임의로 활성화하지도 마세요. 기존 구독에서 가져온 항목의 값이 업데이트 후 원래대로 돌아간다면 구독이 해당 항목을 계속 관리하고 있다는 뜻일 수 있습니다. 비교가 필요하면 테스트 항목을 별도로 저장해 수동 변경이 업데이트로 덮여 진단 근거가 사라지지 않게 하세요.

TCP, UDP와 실제 사용 경험

Shadowsocks는 TCP와 UDP 전달을 지원할 수 있지만 두 유형의 트래픽이 정상적으로 통과하는지는 서버 기능과 중간 네트워크 환경에도 달려 있습니다. 웹페이지가 표시된다고 해서 UDP에 의존하는 앱 요청도 정상이라고 볼 수는 없습니다. 반대로 앱에서 소리가 나지 않거나 오래 기다린다고 해서 곧바로 프로토콜 문제라고 단정할 수도 없습니다. 기존 서비스가 어떤 트래픽을 지원한다고 명시했는지 먼저 확인한 뒤 관련 클라이언트 설정을 점검하세요. 확인할 때는 실제 사용 환경에서 소수의 요청을 테스트하고 대용량 트래픽을 계속 발생시키지 않는 것이 좋습니다.

iPhone에서는 간결한 전송 구조 덕분에 일반적인 짧은 연결의 처리 과정이 단순할 수 있지만, 암호화 알고리즘, 기기 하드웨어, 서버 대역폭과 네트워크 패킷 손실이 함께 결과를 결정합니다. ‘구조가 단순하다’는 이유만으로 배터리 소모가 적다고 보장할 수는 없습니다. 장시간 다운로드에서는 화면 상태와 무선 연결이 배터리에 큰 영향을 줄 수 있고, 대기 중에는 연결 유지와 백그라운드 네트워크 활동이 더 중요할 수 있습니다. 기존 항목 두 개를 비교할 때는 같은 네트워크와 콘텐츠를 비슷한 시간대에 사용해 조건 차이를 프로토콜 차이로 오해하지 않도록 하세요.

일반적인 문제 해결 순서는 주소와 포트를 확인한 뒤 암호화 방식과 비밀번호를 하나씩 대조하고, 추가 전송 항목과 UDP 조건을 확인하는 것입니다. 일부 웹사이트만 실패한다면 규칙, DNS와 대상 서버 접근성을 점검하고 항목을 바로 다시 만들지 마세요. 모든 요청이 실패하지만 직접 연결은 정상이라면 실패 시각과 오류 유형을 기록하고 원격 서버의 수신 및 인증 상태를 확인하세요. 서버 테스트 결과와 실제 웹페이지 사용 경험을 구분하려면 지연 시간 테스트와 실제 사용 경험 안내를 참고하세요.

3. VMess와 VLESS: 인증, 전송과 TLS

비슷한 설정 항목이 같은 프로토콜을 뜻하지는 않습니다

VMess는 사용자 인증과 데이터 전송을 하나로 묶어 UUID 등의 정보로 사용자를 식별하고 프로토콜 계층에서 보안 및 데이터 형식을 처리합니다. VLESS는 더 간결한 프로토콜 설계를 채택하고 TLS 같은 외부 계층에 보안 채널의 역할을 더 많이 맡깁니다. 두 프로토콜 모두 UUID, 전송 방식과 TLS 항목이 표시될 수 있어 화면은 비슷해 보이지만, 같은 프로토콜의 표시 이름만 다른 것은 아닙니다. 서버가 둘 중 하나로 설정되어 있다면 클라이언트 유형만 바꿔 모든 설정을 그대로 사용할 수 없습니다.

구성이 간결하다고 모든 상황에서 더 빠른 것은 아니며 보안 설정을 생략해도 된다는 뜻도 아닙니다. VLESS 자체는 VMess와 같은 데이터 암호화 역할을 제공하지 않으므로 실제 보호 수준은 전체 전송 구성에 따라 달라집니다. 기존 서비스 안내를 읽을 때는 프로토콜 이름과 전송 및 보안 설정을 한꺼번에 확인하세요. 예를 들어 ‘VLESS 사용’은 설정의 일부일 뿐입니다. 연결 주소, 인증 정보, 외부 보안 방식과 지정된 전송 항목이 있는지도 확인해야 합니다. 프로토콜 이름만으로 각 항목의 기본값을 추정할 수는 없습니다.

UUID, 시간과 이전 설정 항목

UUID는 인증 식별자이므로 형식과 문자를 그대로 유지해야 하며, 임의로 정하는 메모처럼 취급해서는 안 됩니다. 구독을 가져온 뒤에는 먼저 프로토콜 유형과 식별자가 올바르게 읽혔는지 확인하고 추가 옵션을 살펴보세요. VMess 인증 과정에는 시간 조건이 있으므로 기기 시간이 크게 어긋나면 핸드셰이크가 실패할 수 있습니다. 먼저 시스템 날짜와 시간이 올바른지 확인하세요. 온라인에 있는 오래된 설정 설명을 보고 현재 항목에 이전 설정을 추가하거나 모든 서버가 예전 조합과 호환된다고 가정하지 마세요.

항목에 Encryption 등이 표시되어도 의미는 선택한 프로토콜에 따라 다르므로 한 프로토콜의 값을 다른 프로토콜에 그대로 옮기면 안 됩니다. 클라이언트에서 입력할 수 있다고 해서 원격 서버가 모든 값을 허용한다는 뜻도 아닙니다. 직접 추가하기 전에 ‘명확히 제공된 항목’과 ‘안내에 없는 항목’을 나누어 적고, 안내에 없는 항목은 앱에서 적용하는 기본 상태로 두세요. 필요한 경우 기존 서비스에 문의하세요. 임의로 값을 입력하면 변수가 여러 개 생겨 원인을 찾기 어려워집니다.

WebSocket, gRPC와 인증서 이름

WebSocket은 전송 방식으로, 경로와 요청 Host를 사용하는 경우가 많습니다. gRPC 조합에는 서비스 이름 등의 항목이 포함될 수 있습니다. 경로는 대소문자를 구분하는 경우가 있으며 앞의 슬래시, 끝 문자와 이스케이프 방식도 일치 여부에 영향을 줍니다. 서버 주소는 연결 지점을 찾고, Host는 해당 요청을 처리할 대상을 지정하며, SNI는 TLS 핸드셰이크에서 이름을 전달합니다. 이 값들이 서로 같은 경우도 있고 다른 경우도 있으므로 기존 설정에 따라 입력하세요. 도메인이 해석된다는 이유만으로 모든 이름 항목에 같은 값을 넣어서는 안 됩니다.

TLS 검증을 통과하려면 인증서와 사용 중인 서버 이름이 일치하고 인증서 체인도 정상적으로 검증되어야 합니다. 인증서 오류를 무시하도록 설정하는 것을 일반적인 해결 방법으로 삼지 마세요. 먼저 기기 시간, SNI, 주소 입력과 인증서 유효성을 확인한 뒤 서버 설정을 점검하세요. ALPN은 애플리케이션 계층 프로토콜을 협상하는 항목이므로 실제 전송 구성에 맞는 값을 사용해야 합니다. 이름을 임의로 추가해도 호환성이 높아지지 않으며 오히려 서버 요구 사항과 다른 핸드셰이크 결과가 나올 수 있습니다.

모바일 네트워크에서 전송 계층이 하나 더 추가되면 캡슐화와 핸드셰이크 작업이 늘 수 있지만 실제 영향은 연결 재사용, 서버 처리와 네트워크 품질에 따라 달라집니다. 짧은 요청을 자주 열 때와 대용량 파일을 지속해서 전송할 때 결과가 다를 수 있습니다. 문제를 해결할 때는 올바른 단일 항목으로 안정적인 연결을 먼저 확인한 뒤 기존에 사용 가능한 조합을 비교하세요. ‘연결은 되지만 페이지가 완전히 표시되지 않는’ 경우에는 DNS, 규칙과 대상 연결도 살펴봐야 합니다. UUID만 반복해서 바꾸지 마세요.

4. Trojan: TLS 채널을 통한 프록시 요청 전달

TLS에 보안 채널을 맡기는 방식

Trojan은 TLS 연결 안에서 인증 정보와 프록시 요청을 전달하고, 널리 쓰이는 TLS 기능으로 클라이언트와 서버 사이의 통신을 보호하도록 설계되었습니다. TLS를 사용하는 다른 프로토콜과 서로 바꿔 쓸 수 있는 것은 아닙니다. TLS는 외부 보안 채널일 뿐이며 채널 내부에서는 여전히 Trojan의 인증 및 요청 형식을 따라야 합니다. 서버에 안전한 웹페이지용 포트가 열려 있다고 해서 그 포트를 Trojan 연결 지점으로 사용할 수 있다는 뜻은 아닙니다. 클라이언트의 TLS 핸드셰이크가 완료되었다고 이후 프록시 인증까지 성공한 것도 아닙니다.

일반적인 설정에는 주소, 포트, Password와 서버에 맞는 TLS 이름 정보가 필요합니다. Password는 프로토콜 인증 정보이고 인증서는 연결한 서버의 신원을 확인하므로 서로 다른 역할을 합니다. 비밀번호가 맞아도 인증서 검증이 실패하면 연결이 종료될 수 있으며, 인증서가 올바르더라도 비밀번호가 틀리면 정상적으로 전달되지 않습니다. 이 차이를 알면 오류를 ‘보안 채널이 수립되지 않음’과 ‘채널 수립 후 인증 또는 요청 실패’로 나누어 볼 수 있어 모든 설정을 매번 처음부터 바꾸지 않아도 됩니다.

주소, SNI와 인증서 체인의 관계

주소는 도메인일 수도 있고 명시적으로 제공된 IP 주소일 수도 있습니다. SNI는 TLS 핸드셰이크에서 전달하는 이름으로, 일반적으로 서버가 요구하는 이름을 사용해야 합니다. 주소에 IP를 사용하고 인증서가 도메인에 발급되었다면 이름 검증 조건을 특히 주의해서 확인하세요. ‘이 IP에 연결할 수 있다’고 해서 ‘어떤 SNI든 사용할 수 있다’는 뜻은 아닙니다. 하나의 연결 지점에서 여러 서비스를 제공한다면 이름에 따라 서버 처리 경로가 선택될 수도 있으므로 잘못 입력하면 다른 인증서나 응답이 나올 수 있습니다.

인증서 체인 검증에는 신뢰할 수 있는 발급 경로, 유효기간과 이름 일치 여부가 포함됩니다. 오류가 발생하면 먼저 시스템 시간을 확인하고 주소와 SNI에 불필요한 문자가 없는지 살펴본 뒤 원격 인증서 상태를 확인하세요. 검증을 계속 끄는 것을 일반적인 사용 방법으로 삼지 마세요. 서버 신원 확인이 약해집니다. 기존 서비스가 특수한 인증서 구성을 사용하는 경우 신뢰 설정과 위험 범위를 먼저 확인하고 해당 안내에 따라 처리하세요. 관련 없는 항목의 검증 옵션을 복사해서는 안 됩니다.

핸드셰이크 비용과 모바일 기기에서의 동작

TLS 핸드셰이크는 연결을 수립할 때 협상 작업과 왕복 대기 시간을 추가하지만, Trojan에만 해당하는 비용은 아닙니다. TLS를 사용하는 다른 조합에도 비슷한 과정이 있습니다. 연결 재사용, 세션 복원과 네트워크 왕복 시간에 따라 실제 사용 경험이 달라집니다. 짧은 시간에 여러 웹페이지를 열 때와 같은 연결을 장시간 유지할 때도 결과가 다를 수 있습니다. 따라서 ‘TLS를 쓰면 반드시 느리다’거나 ‘특정 포트는 반드시 배터리를 덜 쓴다’고 단정할 수 없습니다. 같은 네트워크 조건에서 실제 작업을 비교하세요.

iPhone에서 Wi-Fi에서 셀룰러 네트워크로 전환하면 기존 전송 연결을 다시 수립해야 할 수 있습니다. 잠깐 기다린 뒤 복구된다면 우선 상황을 지켜보고 비밀번호가 잘못되었다고 단정하지 마세요. 네트워크를 바꿀 때마다 계속 실패한다면 현재 네트워크의 연결 가능 여부, 도메인 해석 결과와 서버 연결 지점을 각각 확인하세요. 재연결이 잦으면 무선 통신과 처리 비용이 늘어납니다. 고급 항목을 계속 바꾸기보다 안정적인 서버 설정과 연결 동작부터 확인하는 편이 좋습니다.

Trojan에서 UDP를 전달할 수 있는지는 서버 구현, 클라이언트 기능과 실제 설정에 따라 달라지므로 유형 이름만 보고 모든 앱이 정상 동작한다고 판단할 수 없습니다. 웹페이지는 열리지만 특정 실시간 통신이 실패한다면 해당 앱의 네트워크 조건을 기록하고 UDP 및 규칙 경로를 확인하세요. 특정 대상만 실패한다면 연결 스위치를 켰는데 인터넷이 되지 않을 때의 점검 순서를 참고해 모든 문제를 인증서나 프로토콜 유형 탓으로 돌리지 않도록 하세요.

필드가 완전하고 인증서가 정상적으로 설정되어 실제 테스트에서도 안정적인 기존 연결 지점이 있다면 Trojan 설정을 그대로 유지할 수 있습니다. 기존 안내에 비밀번호만 있고 필요한 이름이나 전송 조합이 없다면 먼저 정보를 확인하세요. 특정 프로토콜에 대한 기대만으로 이미 사용할 수 있는 항목을 Trojan으로 바꾸지 마세요. 최종 선택은 한 번의 연결 테스트 수치가 아니라 서버 기능, 사용 목적과 유지 관리 비용을 기준으로 해야 합니다.

5. HTTP와 SOCKS5: 범용 프록시의 적용 범위

프록시 연결과 웹페이지 접속은 서로 다른 계층입니다

HTTP 프록시는 일반적인 애플리케이션 계층 요청 전달을 위해 사용됩니다. 보안 웹사이트에 접속할 때 클라이언트는 CONNECT 요청으로 대상까지 터널을 만든 뒤 웹사이트 자체의 TLS로 웹 통신을 보호할 수 있습니다. 여기에는 서로 다른 두 연결이 있습니다. 기기와 프록시 서버 사이의 연결이 암호화되는지, 그리고 기기와 대상 웹사이트 사이의 내용이 웹사이트의 보안 연결로 보호되는지입니다. 대상 URL이 보안 연결을 사용한다고 해서 기기와 프록시 사이의 모든 요청 및 인증 정보도 같은 방식으로 보호된다는 뜻은 아닙니다.

기존 연결 지점에서 TLS로 프록시 연결을 보호한다고 명시했다면 앱에서 해당 유형과 보안 설정을 사용해야 합니다. 대상 웹사이트가 보안 사이트라는 이유만으로 TLS를 임의로 켜서는 안 됩니다. 일반 HTTP 프록시 포트와 보안 프록시 포트는 다를 수 있으며 인증 조건도 다를 수 있습니다. 서버 주소, 포트, 사용자 이름과 비밀번호를 함께 확인하세요. 인증에 실패하면 자격 증명과 서버 권한을 점검하고, 핸드셰이크에 실패하면 일반 연결 지점을 TLS 연결 지점으로 잘못 사용했는지 먼저 확인하세요.

SOCKS5는 대상 연결 전달에 중점을 둡니다

SOCKS5는 범용 프록시 협상과 대상 주소 전달 방식을 제공하며 웹페이지 내용을 이해할 필요가 없습니다. 여러 인증 방식을 사용할 수 있고 UDP 전달 방식도 정의하지만, 프로토콜 자체가 모든 통신을 자동으로 암호화하지는 않습니다. 사용자 이름과 비밀번호는 인증 정보이지 보안 채널이 이미 수립되었다는 의미가 아닙니다. 기존 서비스에서 추가 보호를 요구한다면 실제 구성에 맞게 확인하세요. Password 입력란이 있다고 해서 연결의 기밀성 수준을 알 수는 없습니다.

SOCKS5에서 UDP를 전달하려면 서버가 이를 지원하고 중간 네트워크에서도 해당 데이터를 전달할 수 있어야 합니다. TCP 연결은 정상인데 UDP 요청은 실패하는 상황이 발생할 수 있습니다. 실시간 데이터나 특정 앱의 트래픽이 필요하다면 기존 서비스가 UDP를 지원한다고 명시했는지 먼저 확인한 뒤 실제 요청을 살펴보세요. 포트를 계속 바꾸며 기능을 추측하지 말고 웹페이지 테스트 한 번에 성공했다고 ‘모든 트래픽이 검증되었다’고 판단하지도 마세요.

도메인 이름을 해석하는 위치가 결과에 영향을 줍니다

프록시 요청에 대상 도메인이 포함될 수도 있고 특정 단계에서 대상 IP로 바뀔 수도 있습니다. 실제 DNS 경로는 앱, Shadowrocket 설정과 서버 처리 방식에 따라 달라집니다. 따라서 범용 프록시가 항상 로컬에서만 또는 원격에서만 DNS를 처리한다고 단정할 수 없습니다. IP 주소로는 접속되는데 도메인으로는 실패한다면 인증 비밀번호만 다시 입력하지 말고 DNS 응답, 규칙 일치 여부와 프록시 요청에 전달되는 주소 형식을 확인하세요.

회사 네트워크나 본인 소유 네트워크의 프록시는 대상 포트, 주소 또는 요청 방식을 제한할 수도 있습니다. 인증 성공은 해당 권한을 얻는 한 단계일 뿐 어떤 대상에나 접속할 수 있다는 의미가 아닙니다. HTTP CONNECT 요청이 거부되면 대상 포트가 허용 범위 밖일 수 있습니다. SOCKS5 요청이 거부되는 경우에도 원격 정책이나 대상 접근성에 원인이 있을 수 있습니다. 오류가 발생한 단계에 따라 책임 범위를 나누어 확인하세요. 연결 지점에 도달할 수 없는 경우, 인증 실패, 대상 거부와 대상 연결 실패는 각각 점검 방향이 다릅니다.

iPhone에서 이 두 유형은 기존 환경에서 해당 프록시를 제공하는 경우에 적합합니다. 설정 항목은 익숙하지만 다른 프로토콜보다 반드시 빠르거나 배터리를 덜 쓰는 것은 아닙니다. 원격 서버의 제한이 많으면 앱이 계속 재시도하면서 대기 시간과 통신 비용이 늘 수 있습니다. 확인할 때는 먼저 허용된 범위의 실제 대상 하나에 접속한 뒤 필요한 앱 유형을 점검하세요. 기존 항목의 외관을 통일하려고 암호화 프로토콜을 HTTP나 SOCKS5로 바꾸지 마세요. 프로토콜 유형이 다르므로 서버 측에 해당 연결 지점이 있어야 사용할 수 있습니다.

6. WireGuard: 키, 터널 주소와 라우팅 범위

프록시 연결에서 네트워크 계층 터널로

WireGuard는 네트워크 계층 터널을 위해 설계되었으며 고정된 최신 암호화 구성과 공개 키 기반 피어 식별 방식을 사용합니다. 개별 프록시 요청을 처리하는 프로토콜과 달리 피어, 터널 주소와 전달이 허용되는 네트워크 범위에 중점을 둡니다. 따라서 설정에는 연결 주소뿐 아니라 로컬 Private Key, 피어 Public Key, 터널 내부 주소와 라우팅 정보도 포함될 수 있습니다. 항목이 많아 보여도 각각을 사용자가 임의로 결정해야 한다는 뜻은 아닙니다. 일반적으로 기존 서버에서 제공한 전체 설정을 기준으로 하나씩 확인해야 합니다.

WireGuard는 주로 UDP로 전송됩니다. 네트워크에서 일반 웹페이지에 접속할 수 있다고 해서 지정된 연결 지점의 UDP 통신까지 허용되는 것은 아닙니다. 특정 포트의 TCP 탐색 결과로 같은 번호의 UDP 연결 지점이 사용 가능한지 확인할 수도 없습니다. 터널 핸드셰이크가 계속 실패하면 웹사이트 규칙을 의심하기보다 주소, 포트, 네트워크 조건과 피어 키를 먼저 확인하세요. 서버 연결 지점이 요청을 받을 수 있는지와 터널 내부의 대상에 접속할 수 있는지는 서로 다른 단계입니다.

Private Key, Public Key와 주소의 역할

Private Key는 로컬 기기의 민감한 신원 정보이므로 공개 토론 공간에 보내거나 피어의 공개 키로 대체하지 마세요. Public Key는 피어를 식별하는 데 사용하며 서버도 연결을 허용할 클라이언트 공개 키를 알고 있어야 합니다. 설정에 사전 공유 키가 포함되어 있다면 양쪽에서 합의한 값을 동일하게 입력하세요. 로컬에서만 사용할 값을 임의로 생성하지 마세요. 키 형식이 입력란 요구 사항에 맞는다는 것은 인코딩이 유효할 수 있다는 뜻일 뿐, 서버가 해당 신원의 접근 권한을 설정했다는 의미는 아닙니다.

터널 내부 주소와 연결 지점 주소는 서로 다릅니다. 연결 지점 주소는 현재 네트워크를 통해 서버를 찾는 데 사용되고, 터널 내부 주소는 터널이 수립된 뒤 네트워크 통신에 사용됩니다. 서버의 공인 주소를 로컬 터널 주소 항목에 입력해도 일반적으로 올바르게 동작하지 않습니다. DNS 주소도 터널 내부에서만 접근할 수 있는지 구분해야 합니다. 설정에서 내부 DNS 서버를 요구하는데 터널이 아직 수립되지 않았다면 도메인 접속 실패는 후속 증상일 수 있습니다. 먼저 모든 DNS 항목을 다른 값으로 바꾸지 마세요.

Allowed IPs, MTU와 연결 유지

Allowed IPs는 피어와 연결된 주소 범위 및 라우팅 선택을 정의하며 일반적인 웹사이트 허용 목록이 아닙니다. 범위가 너무 좁으면 필요한 트래픽이 해당 경로로 전달되지 않을 수 있고, 너무 넓으면 원래 다른 경로를 이용해야 하는 연결에 영향을 줄 수 있습니다. Shadowrocket에서는 현재 Global Routing과 설정의 실제 처리 방식도 함께 고려해야 합니다. 서버의 주소 범위 안내를 앱의 각 트래픽 분기 규칙과 동일한 것으로 보지 마세요. 변경하기 전에 접속하려는 대상이 내부 리소스인지 일반 인터넷 대상인지 먼저 확인하세요.

MTU는 단일 네트워크 패킷에 담을 수 있는 데이터 크기와 관련이 있습니다. 캡슐화 후 사용 가능한 공간이 줄어들며, 특정 경로에서 단편화나 경로 MTU 탐색에 문제가 생기면 작은 요청은 되지만 큰 페이지나 장시간 전송이 멈출 수 있습니다. MTU를 낮추는 것이 문제를 찾는 데 도움이 되기도 하지만 너무 낮추면 패킷과 처리 비용이 늘어납니다. 모두에게 적용되는 ‘최적 수치’는 없습니다. 기존 설정을 기준으로 한 번에 한 항목씩 조금씩 변경하고, 같은 요청에서 실제로 개선되는지 기록하세요.

연결 유지 기능은 일부 네트워크 장비의 매핑 상태를 유지하는 데 도움이 될 수 있지만 주기적으로 데이터를 보내면 통신과 기기 깨우기에 따른 비용도 생깁니다. 셀룰러 네트워크에서 ‘안정성’을 위해 간격을 무조건 줄이지 마세요. 연결이 이미 안정적이라면 백그라운드 통신을 늘릴 이유가 없습니다. 배터리 사용량을 비교할 때는 On Demand 조건에 따라 연결이 반복해서 수립되는지도 확인해야 합니다. WireGuard의 간결한 설계는 구현 복잡도를 낮추는 데 유리하지만 실제 기기 배터리 사용량은 네트워크, 전송량과 연결 유지 빈도에 따라 달라집니다.

피어와 네트워크 범위 설정이 명확한 기존 구성을 보유한 경우, 특히 본인 소유 네트워크 리소스에 접속할 때 적합합니다. 문제를 해결할 때는 먼저 핸드셰이크를 확인하고, 이어서 터널 내부 주소를 테스트한 다음 도메인과 앱 요청을 살펴보세요. 순서가 뒤바뀌면 라우팅이나 이름 해석 문제를 키 오류로 오해할 수 있습니다. 복구를 위해 원래 설정의 사본을 보관하세요. 한 대상 문제를 고치려고 전체 주소 범위를 넓히거나 Private Key가 포함된 화면이나 전체 설정을 공개하지 마세요.

7. Hysteria2: QUIC, 대역폭과 불안정한 네트워크에서의 선택

불안정한 연결 환경을 고려한 전송 설계

Hysteria2는 QUIC 기반 프록시 전송으로, 지연 시간이 높거나 패킷 손실이 있는 환경에서의 데이터 전달을 고려해 설계되었습니다. QUIC는 일반적으로 UDP 위에서 동작하며 보안 연결과 여러 데이터 스트림 기능을 통합합니다. 여기서 두 가지를 구분해야 합니다. 특정 네트워크 문제를 고려해 설계되었다고 모든 네트워크에서 더 빠른 것은 아닙니다. 클라이언트에서 해당 유형을 제공한다고 현재 네트워크가 해당 UDP 연결 지점에 접속할 수 있다는 뜻도 아닙니다. 선택 전에 기존 서버가 실제로 Hysteria2를 제공하는지 확인하세요. 이름이 비슷한 다른 연결 지점과 혼동하지 마세요.

QUIC 기반 전송은 여러 논리적 스트림을 하나의 신뢰성 있는 바이트 스트림에 단순히 겹쳐 보내는 방식에서 발생할 수 있는 일부 문제를 줄여 줍니다. 그래도 데이터는 같은 하위 경로와 사용 가능한 대역폭을 공유합니다. 심한 패킷 손실, 서버 과부하 또는 UDP를 제대로 처리하지 못하는 네트워크에서는 사용 경험이 나빠질 수 있습니다. 다중 스트림 기능이 ‘패킷 손실이 속도에 영향을 주지 않는다’는 뜻은 아닙니다. 대용량 파일 테스트 한 번의 결과를 짧은 요청, 실시간 통신과 백그라운드 동기화에 그대로 적용해서도 안 됩니다.

인증과 TLS 설정을 각각 확인해야 합니다

일반적인 설정에는 연결 주소, 포트, 인증 정보와 TLS 이름 관련 항목이 포함됩니다. 인증은 사용자를 확인하고 TLS는 보안 채널과 서버 신원을 검증하므로 다른 프로토콜과 마찬가지로 각각의 역할을 이해해야 합니다. 인증 오류가 발생하면 기존 서비스에서 제공한 인증 정보를 확인하세요. 인증서나 이름 오류라면 SNI, 시스템 시간과 원격 인증서를 점검하세요. QUIC를 사용한다는 이유로 인증서 검증을 건너뛰거나 이름을 임의로 선택해도 되는 것은 아닙니다.

기존 설정 중에는 특정 위장 설정이나 포트 관련 항목이 필요한 경우가 있으며, 이는 양쪽이 함께 적용해야 하는 조건입니다. 클라이언트에서만 활성화하고 서버에서는 같은 설정을 사용하지 않으면 정상적으로 통신하지 못할 수 있습니다. 가져온 설정은 구독에서 해석한 조합을 우선 유지하세요. 직접 추가할 때는 명확히 제공된 안내에 따라 입력합니다. 안내에 없는 확장 항목을 더 복잡하게 만들 목적으로 추가하지 마세요. 화면에 고급 옵션이 보인다는 것은 설정할 수 있다는 뜻이지 모든 사용자가 활성화해야 한다는 뜻은 아닙니다.

대역폭 항목은 실제 측정 속도가 아닙니다

일부 설정 모드에서는 업로드 및 다운로드 대역폭 정보가 전송 동작 제어에 사용됩니다. 입력값은 해당 항목의 설명, 실제 네트워크 조건과 기존 서비스 요구 사항을 기준으로 이해해야 합니다. 셀룰러 신호 아이콘이 보여 주는 이론상 속도를 그대로 옮기지 마세요. 값을 더 크게 입력해도 연결 용량이 늘어나지 않습니다. 지나치게 높게 추정하면 네트워크에 데이터가 쌓이거나 패킷 손실이 늘어 웹 응답과 다른 앱에 영향을 줄 수 있습니다. 너무 낮게 추정하면 활용할 수 있는 처리량을 제한할 수 있으므로 재현 가능한 작업에서 조금씩 확인하세요.

단위에도 주의하세요. 비트 전송률과 바이트 전송률은 다르며, 인터넷 회선에 표시된 값과 앱의 다운로드 속도를 그대로 비교할 수도 없습니다. 기존 설정이 자동 조정 방식을 사용한다면 단순히 ‘최적화’를 위해 수동 대역폭으로 바꾸지 마세요. 직접 설정해야 한다면 업로드 용량도 고려해야 합니다. 다운로드 중에도 확인 및 제어 데이터가 전송되며, 다른 앱이 업로드를 모두 사용하면 다운로드 성능도 저하될 수 있습니다. 테스트 중에는 관련 없는 대용량 작업을 멈춰 원인을 잘못 판단하지 않도록 하세요.

iPhone에서 신호가 약한 상태로 높은 처리량을 유지하면 무선 통신과 처리 및 재전송이 늘 수 있습니다. 기기 발열이나 배터리 변화가 생겨도 프로토콜 이름만 원인이라고 볼 수 없습니다. 짧은 테스트 결과는 화면 밝기, 충전 상태와 백그라운드 작업의 영향도 받을 수 있습니다. 주로 웹페이지와 메시지를 사용한다면 한 번의 최고 속도보다 안정적인 응답과 네트워크 전환 후 복구를 먼저 비교하세요. 장시간 전송이 주된 용도라면 지속 속도, 대상 서버 제한과 배터리 비용도 살펴봐야 합니다.

연결 시간이 초과되면 현재 네트워크에서 해당 UDP 연결 지점에 접속할 수 있는지 먼저 확인한 뒤 주소, 포트와 인증을 살펴보세요. 연결은 되었지만 일부 콘텐츠가 멈춘다면 대역폭 추정치, 경로 MTU, DNS와 규칙을 확인하세요. 네트워크를 전환하면 실제 경로 조건이 바뀔 수 있으므로 기반 프로토콜에 관련 기능이 있어도 진행 중인 모든 요청이 끊기지 않는다고 보장할 수 없습니다. 연결 수립, 네트워크 전환과 장시간 전송 중 어느 단계에서 실패했는지 기록하고 증상에 따라 다음 단계를 정하세요. 대역폭 수치를 계속 올리지는 마세요.

8. 사용 환경에 맞게 선택하고 단계별로 확인

기존 조건부터 확인해 선택 범위를 좁히세요

사용할 수 있는 연결 지점이 완전한 구성으로 하나뿐이라면 프로토콜을 모두 비교하기보다 올바르게 가져오고 연결되는지 확인하는 것이 우선입니다. 여러 조합을 제공하는 기존 서비스가 있다면 현재 네트워크에서 사용할 수 없는 유형을 먼저 제외한 뒤 실제 작업에 따라 비교하세요. Wi-Fi와 셀룰러 네트워크를 자주 전환한다면 복구 시간과 실패 횟수를 확인하세요. 본인 소유 네트워크 리소스에 접속한다면 주소 범위, DNS와 권한을 확인하고, 짧은 요청이 많은 환경에서는 연결 수립과 첫 응답을, 장시간 전송 환경에서는 안정적인 처리량을 중점적으로 살펴보세요.

테스트할 때는 가능한 한 같은 기기, 네트워크와 대상 콘텐츠를 사용하고 첫 연결, 재접속과 일정 시간 사용 후의 결과를 각각 살펴보세요. 한 번에 항목 하나나 설정 하나만 바꾸고 프로토콜, DNS와 Global Routing을 동시에 변경하지 마세요. Connectivity Test는 연결 지점 상태를 초기에 확인하는 데 도움이 되지만 테스트 수치가 전체 웹페이지 로딩 시간을 의미하거나 모든 대상에서의 결과를 나타내지는 않습니다. 자세한 내용은 지연 시간, 지역과 프로토콜 유형 선택 안내를 참고하세요.

최소한의 규칙으로 트래픽 경로 확인

현재 Global Routing이 Config라면 규칙 순서가 요청의 최종 경로에 영향을 줍니다. 아래 내용은 문법을 설명하는 예시이며 기존 설정을 그대로 대체할 수 있는 완성된 구성은 아닙니다. example.com은 예시용이며 PROXY가 가리키는 실제 정책은 현재 설정과 일치해야 합니다. 규칙은 일반적으로 순서대로 적용되고 FINAL은 앞선 규칙과 일치하지 않은 요청을 마지막으로 처리합니다. 서버 설정이 정확해도 대상이 먼저 DIRECT 또는 REJECT 규칙과 일치하면 예상과 다른 동작이 나타날 수 있습니다.

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

DOMAIN-SUFFIX는 도메인 접미사로 일치 항목을 찾고, IP-CIDR은 주소 범위를 사용하며, GEOIP는 해당 IP 주소 지리 데이터베이스를 기준으로 판단합니다. 웹사이트에서 사용하는 언어를 기준으로 하는 것은 아닙니다. DNS 결과, 대상이 도메인 형식으로 전달되는지 여부와 앞선 규칙도 최종 일치 결과에 영향을 줄 수 있습니다. 예시의 지역 규칙을 모든 사용자가 선택해야 하는 설정으로 여기지 마세요. 프로토콜을 테스트하려면 대상 트래픽이 어떤 경로를 따라야 하는지 먼저 정하고 기록에 표시된 실제 처리 결과를 확인하세요. 직접 연결 결과를 프로토콜 비교 결과로 오해하지 않도록 주의하세요.

연결 지점부터 대상까지 단계별로 점검

첫째, 기기에서 현재 네트워크가 정상인지 확인한 뒤 연결 지점의 도메인, 주소와 포트를 확인합니다. 둘째, 프로토콜, 인증과 전송 항목을 확인합니다. 셋째, TLS 이름, 인증서와 시간 조건을 점검합니다. 넷째, Global Routing, 규칙과 DNS를 확인합니다. 마지막으로 대상 자체와 원격 접근 권한을 확인합니다. 특정 네트워크에서만 실패한다면 해당 네트워크의 연결 가능 여부와 전송 조건을 우선 비교하세요. 모든 네트워크에서 실패한다면 기기 설정을 각각 바꾸기보다 연결 지점 상태와 공통 설정을 살펴보는 것이 좋습니다.

구독 업데이트 후 항목이 사라지거나 설정이 바뀌었다면 가져오기 및 해석 과정에서 문제가 생겼는지, 기존 항목의 연결 단계에서 문제가 발생했는지 먼저 구분하세요. 목록이 비어 있는 것은 암호화 방식 선택 오류의 일반적인 증거가 아니며 TLS 옵션을 바꿔 해결할 문제도 아닙니다. 구독 가져오기에 실패하거나 목록이 비어 있을 때 확인할 사항을 참고해 링크가 완전한지, 기존 서비스가 정상인지, 업데이트 시점이 적절한지 확인하세요. 구독 주소에는 민감한 정보가 포함될 수 있으므로 문제를 공유할 때 그대로 공개하지 마세요.

복구 가능한 설정과 유효한 기록 보관

테스트할 때 네트워크 유형, 프로토콜 조합, 변경한 항목과 결과를 기록하면 충분하며 전체 인증 정보를 공개할 필요는 없습니다. Private Key, 비밀번호, UUID나 전체 구독 주소가 포함된 화면을 공유하지 마세요. 오류 메시지에 민감한 정보가 들어 있는지도 확인해야 합니다. 효과가 없었던 변경은 바로 되돌려 여러 설정이 겹쳐 남지 않게 하세요. 조작 순서로 돌아가려면 빠른 시작 튜토리얼을, 문제별 안내는 자주 묻는 질문을, 화면 용어와 키워드는 용어집을 참고하세요.

최종 선택 기준은 기존 서버 설정과 일치하고, 현재 네트워크에서 안정적으로 사용할 수 있으며, 필요한 앱 트래픽을 올바르게 처리하고 설정을 명확하게 관리할 수 있는지입니다. 한 번의 테스트에서 더 나은 결과를 얻으려고 인증서 검증을 희생하지 말고, 복잡한 구성을 무조건 업그레이드로 여기지도 마세요. 재현하고 복구할 수 있는 올바른 기본 설정을 먼저 확보한 뒤 구체적인 병목을 조정해야 프로토콜 설계의 차이와 네트워크 환경의 영향을 구분할 수 있습니다.