1. 프로토콜 선택: 인증, 전송, 라우팅을 구분하세요
Shadowrocket의 프로토콜 유형은 클라이언트와 서버가 데이터를 주고받는 방식을 결정하지만, 서버의 위치나 출구 대역폭, 서비스 품질을 결정하지는 않습니다. 사용 중인 서버 정보를 기준으로 선택해야 합니다. 서버가 제공하는 유형과 같은 유형을 클라이언트에 설정해야 하며, Add Server에서 옵션만 바꾼다고 연결이 다른 프로토콜로 바뀌지는 않습니다. 구독 링크는 서비스 제공업체에서 받으세요. 가져온 뒤에도 유형, 주소, 인증 정보를 확인해야 합니다. 앱을 한 번 구매하는 것과 회선 요금제는 별개입니다. 앱 구매와 연결 서비스는 각각 따로 관리하며, 앱을 받으려면 App Store 정품 확인 안내를 참조하세요.
연결을 네 가지 계층으로 나눠 보기
첫 번째 계층은 비밀번호, UUID, 키와 같은 인증 정보 및 서버가 요청을 해석하는 방식입니다. 두 번째는 TCP, UDP, WebSocket 또는 QUIC 기반 전송과 같은 전달 방식입니다. 세 번째는 보안 세션으로, 프로토콜 자체 암호화를 사용하거나 TLS 같은 외부 메커니즘에 의존할 수 있습니다. 네 번째는 라우팅으로, 각 요청에 PROXY와 DIRECT 중 어느 경로를 사용할지 결정합니다. 네 계층은 함께 결과에 영향을 주지만 서로 대체할 수 없습니다. Global Routing을 Proxy로 바꾸면 트래픽 경로는 달라지지만 잘못 입력한 비밀번호가 고쳐지지는 않습니다. TLS를 켜도 서버가 지원하지 않는 전송 형식을 자동으로 받아들이지는 않습니다.
프로토콜 이름이 같다고 해서 모든 확장 설정이 동일한 것은 아닙니다. 서버에서 특정 전송 방식, 경로, 인증서 이름 또는 추가 설정을 요구할 수 있고, 클라이언트는 그중 일부 조합만 지원할 수도 있습니다. 따라서 VMess나 VLESS를 확인할 때는 외부 전송 방식도 함께 살펴봐야 합니다. HTTP의 경우 프록시 입구 자체가 TLS로 보호되는지 확인하세요. 화면에 표시되는 설정 항목은 선택한 유형에 따라 달라집니다. 다른 설정 화면의 항목 배치가 아니라 현재 클라이언트에 실제로 표시되는 옵션과 서버 안내를 기준으로 판단하세요.
속도·배터리·안정성은 단일 순위로 판단할 수 없습니다
웹페이지가 열리는 속도에는 보통 DNS 조회, 연결 설정, 인증, 첫 응답, 콘텐츠 전송이 모두 포함됩니다. 장시간 다운로드는 출구 대역폭, 패킷 손실 복구, 서버 부하의 영향을 더 크게 받습니다. 작은 파일을 불러올 때 빠른 구성도 장시간 다운로드에서는 우위가 없을 수 있습니다. iPhone과 iPad의 배터리 사용량은 셀룰러 신호, 화면 밝기, 무선 통신 활성 시간, 백그라운드 재연결에도 영향을 받습니다. 캡슐화 계층이 적다고 반드시 배터리를 덜 쓰는 것은 아니며, 전송량이 많다고 전체 작업의 전력 소모가 적은 것도 아닙니다. 비슷한 조건에서 비교해야 합니다.
네트워크 전환도 별도의 변수입니다. 기기가 Wi-Fi에서 셀룰러 네트워크로 바뀌면 로컬 주소와 경로가 달라질 수 있으며, 기존 세션이 복구되는지는 전송 방식, 서버 동작, 앱의 재시도 방식에 따라 달라집니다. 네트워크를 전환한 뒤 잠시 멈췄다고 곧바로 프로토콜 오류로 판단하지 마세요. 여러 설정을 계속 바꿔 문제를 감추려 해서도 안 됩니다. 재현 가능한 작업 하나를 정하고, 연결 설정 전과 전송 중 어느 단계에서 실패하는지 기록한 다음 점검할 계층을 정하세요.
| 판단 계층 | 확인할 항목 | 대체할 수 없는 항목 |
|---|---|---|
| 인증 | 비밀번호, UUID, 키 및 유효성 | 서버 연결 가능 여부 |
| 전송 | TCP, UDP, 경로 및 외부 캡슐화 | 인증서 신원 확인 |
| 보안 세션 | 암호화 방식, TLS 및 서버 이름 | 규칙 일치 여부 |
| 라우팅 | Global Routing 및 규칙 순서 | 프로토콜 설정 수정 |
이 문서는 클라이언트 유형 선택과 설정 범위만 설명하며 서비스 제공업체를 평가하지 않습니다. 시스템 요구 사항은 App Store 페이지를 기준으로 하며, 지원되는 프로토콜과 설정 항목은 현재 클라이언트에 따라 다릅니다. 출처를 확인할 수 없는 추가 옵션은 이름만 보고 추측하기보다 가져온 값을 유지하는 편이 좋습니다. 서버의 어떤 설정과 연결되는지 파악한 뒤에 수정하세요.
2. Shadowsocks: 경량 프록시와 암호화 방식 확인
Shadowsocks는 비교적 간결한 암호화 프록시 연결을 제공하도록 설계되었습니다. 클라이언트가 목적지 주소와 데이터를 서버에 전달하면 서버가 목적지에 접속합니다. 따라서 양쪽을 완전한 사설 네트워크로 연결하는 네트워크 계층 터널이 아니라 프록시 프로토콜입니다. 기본 설정은 보통 서버 주소, 포트, 암호화 방식, 비밀번호로 구성됩니다. 항목이 적다고 확인을 생략해도 되는 것은 아닙니다. 특히 암호화 방식은 프로토콜 통신의 일부이지 클라이언트가 단독으로 정하는 성능 옵션이 아닙니다. 서버 설정과 일치하지 않으면 시간 초과, 즉시 연결 종료, 인증 실패 등이 발생할 수 있습니다.
암호화 방식과 비밀번호를 함께 확인하세요
최근 Shadowsocks 구성에서는 인증을 포함한 암호화 방식을 사용해 데이터를 복호화하고 변조 여부도 확인하는 경우가 많습니다. 방식마다 키 길이와 파생 규칙이 다를 수 있으며, 일부 방식은 임의의 텍스트 비밀번호가 아니라 정해진 형식의 인코딩 키를 요구합니다. 가져올 때는 방식 이름과 비밀번호를 원문 그대로 유지하세요. 인코딩된 문자열을 다시 디코딩해 붙여 넣거나 끝의 기호를 불필요한 문자로 보고 삭제하지 마세요. 구독을 갱신한 뒤 갑자기 연결이 되지 않는다면 먼저 비밀번호가 바뀌었는지, 유형이 변경되었는지 확인한 다음 네트워크 문제를 살펴보세요.
Add Server에서 직접 입력할 때는 먼저 Shadowsocks를 선택하고 원본 정보를 그대로 입력하세요. 주소 항목에는 호스트 이름이나 IP 주소만 입력하고 포트는 별도 항목에 입력합니다. 공유 링크 전체를 서버 주소로 넣지 마세요. 플러그인이나 추가 캡슐화 정보가 있다면 현재 클라이언트가 해당 옵션을 제공하는지, 가져오기가 제대로 되었는지도 확인하세요. 기본 프로토콜 이름이 같더라도 플러그인 조합이 다르면 서로 연결되지 않을 수 있습니다. 추가 설정을 확인할 수 없다면 여러 옵션을 무작위로 바꾸지 말고 기존 구성 안내를 확인하세요.
TCP와 UDP 지원 여부를 따로 확인하세요
웹페이지는 주로 TCP로 연결되지만 일부 실시간 앱, 음성 서비스 및 기타 기능은 UDP를 사용합니다. Shadowsocks는 TCP와 UDP 전달을 모두 다룰 수 있지만, 서버의 지원 여부와 네트워크 연결 가능성, 클라이언트 처리 방식은 각각 다를 수 있습니다. 웹페이지가 열린다는 사실만으로 UDP 경로까지 정상이라고 볼 수는 없습니다. 반대로 특정 앱 하나가 작동하지 않는다고 프로토콜 문제라고 단정할 수도 없습니다. DNS, 규칙 또는 대상 서비스 자체가 원인일 수 있습니다. 진단할 때는 해당 앱이 실제로 어떤 유형의 트래픽을 사용하는지 확인하고 관련 요청이 프록시로 전달되는지 살펴보세요.
UDP에는 TCP와 같은 연결 상태 개념이 없으며 네트워크 장비가 유휴 상태의 매핑을 빠르게 정리할 수 있습니다. 백그라운드에 오래 둔 뒤 첫 요청은 실패하지만 다시 시도하면 되는 경우, 매핑 만료나 경로 변경이 원인일 수 있습니다. 바로 Keepalive 빈도를 높이지 마세요. 셀룰러 네트워크를 계속 활성 상태로 유지해 배터리 소모가 늘어날 수 있습니다. 먼저 오랫동안 유휴 상태였을 때만 문제가 발생하는지, 특정 네트워크에서만 발생하는지 확인한 뒤 조정 여부를 판단하세요. 전송 중에는 안정적이지만 기기를 다시 사용한 뒤 실패하는 경우와 처음부터 인증되지 않는 경우는 점검 방향이 달라야 합니다.
모바일 기기의 성능 확인
Shadowsocks는 기본 캡슐화가 비교적 간결해 추가 프로토콜 계층의 오버헤드를 줄일 수 있지만, 실제 속도는 암호화 구현, 기기 성능, 서버 출구, 왕복 지연 시간에 따라 달라집니다. 암호화 알고리즘별 성능은 프로세서에 따라 다를 수 있습니다. 이름에 더 큰 숫자가 들어 있다고 더 안전하거나 빠르다고 단정하지 말고, 속도를 위해 서버에서 제공하지 않는 방식으로 바꾸지도 마세요. 배터리 테스트에서는 순간적으로 표시되는 전송량뿐 아니라 같은 작업을 완료하는 데 걸리는 시간, 재연결 횟수, 백그라운드 상태를 확인하세요.
해당 서버 정보가 있고 명확한 주소 및 인증 설정으로 프록시 연결을 만들려는 경우에 적합합니다. 사설 네트워크 간 연결, 양쪽 키를 통한 신원 확인, 완전한 네트워크 계층 라우팅이 필요하다면 Shadowsocks에 기능을 억지로 맞추지 말고 WireGuard를 살펴보세요. 두 프로토콜은 해결하는 문제가 다릅니다. 먼저 연결 모델에 따라 선택한 뒤 성능을 비교하세요. 구독에 포함된 항목이 안정적으로 작동한다면 유형을 통일하려고 다시 편집하기보다 원래 설정을 유지하는 편이 좋습니다.
3. VMess와 VLESS: 신원 정보와 외부 전송을 구분하세요
VMess와 VLESS는 사용자 신원 정보와 외부 전송 설정이 포함된 구성에서 함께 언급되곤 하지만 서로 바꿔 쓸 수는 없습니다. VMess는 사용자 인증, 요청 형식, 암호화 방식을 결합합니다. VLESS는 신원 및 요청을 더 간결하게 표현하며, 일반적으로 전송 보호를 위해 선택한 외부 보안 방식에 의존합니다. VLESS는 VMess의 이름만 바꾼 것이 아니며 모든 네트워크에서 더 빠른 것도 아닙니다. 먼저 서버가 어떤 방식을 제공하는지 확인하고 전체 설정 조합을 살펴보세요. UUID만 복사했다고 구성이 완성되는 것은 아닙니다.
UUID는 신원 정보이지 서버 주소가 아닙니다
UUID는 사용자를 식별하고 서버 주소는 연결 지점을 지정하므로 서로 다른 계층의 정보입니다. 직접 입력할 때는 UUID의 모든 문자와 하이픈을 유지하고 복사 과정에서 공백이나 줄바꿈이 들어가지 않도록 확인하세요. 서버에서 해당 사용자를 삭제했거나 신원 정보가 변경되었는데 구독에 이전 값이 남아 있으면 포트에 연결되더라도 인증은 실패할 수 있습니다. 일부 오래된 구성에는 과거 호환성 설정이 포함될 수도 있습니다. 이 값은 원본 구성에 따라 유지해야 하며, 관련 없는 안내를 따라 일괄 설정해서는 안 됩니다. 모든 구성에 필요한 필수 항목으로 간주하지 마세요.
VMess 인증에는 시간 관련 확인 절차가 포함됩니다. 기기의 날짜나 시간이 크게 틀리면 계속 실패할 수 있습니다. 포트를 반복해서 바꾸기보다 먼저 시스템에서 자동 시간 설정이 올바르게 사용되는지 확인한 다음 다른 설정을 점검하세요. VLESS는 신원 정보와 외부 보안 설정이 다르므로 VMess의 문제 해결 방법을 그대로 적용할 수 없습니다. 공통 점검 원칙은 ‘연결 지점에 접속하지 못함’, ‘외부 세션 실패’, ‘신원 정보 거부’를 구분하는 것입니다. 연결 스위치의 상태만 보지 말고 로그나 연결 기록으로 실패 단계를 확인하세요.
WebSocket, 경로 및 서버 이름
외부 전송에 WebSocket을 사용할 때는 클라이언트와 서버의 전송 유형 및 요청 경로가 일치해야 합니다. 경로의 대소문자, 앞의 슬래시, 추가 매개변수가 일치 여부에 영향을 줄 수 있습니다. 설명처럼 보이는 문자열도 실제 설정값일 수 있습니다. HTTP Host는 요청 단계에서 호스트를 식별하고, TLS 서버 이름은 보안 세션에서 이름을 처리하는 데 사용됩니다. 둘은 같을 수도 있고 배포 방식에 따라 다를 수도 있습니다. 서버 주소가 세 번째 값일 수도 있으므로 세 항목을 모두 연결 지점 주소로 입력해서는 안 됩니다.
TLS를 사용할 때는 인증서가 예상한 서버 이름과 일치하는지 확인해야 합니다. 연결 대상이 IP 주소이고 인증서가 도메인용으로 발급된 경우에도 서버 정보에 지정된 이름을 입력해야 합니다. 인증서 검증을 끄는 것은 이름을 올바르게 설정하는 대안이 아닙니다. 연결 앞에 중계 계층이 있으면 요청이 해당 계층에 먼저 도착한 다음 실제 서비스로 전달될 수 있습니다. 이때 경로나 Host가 맞지 않으면 응답 가능한 연결 지점에 도달하더라도 올바른 서비스로 전달되지 않을 수 있습니다. 비밀번호 오류와 모두 연결 실패처럼 보일 수 있지만 점검 순서는 다릅니다.
캡슐화에 따른 비용과 한계
전송 계층이 추가되면 핸드셰이크, 헤더, 상태 유지에 비용이 발생할 수 있지만, 영향은 연결 재사용 여부, 네트워크 지연 시간, 요청 크기에 따라 달라집니다. 짧은 연결을 자주 만드는 작업은 세션 설정 비용의 영향을 더 쉽게 받으며, 대용량의 지속적인 전송은 서버 처리량의 영향을 더 크게 받을 수 있습니다. VMess와 VLESS를 비교할 때 외부 전송 방식이나 연결 지점이 다르면 측정 차이를 프로토콜 자체의 차이로만 볼 수 없습니다. 서버 위치, 네트워크, 작업, 테스트 시간을 가능한 한 동일하게 유지하고 프로토콜 이름뿐 아니라 전송 조합도 기록하세요.
iOS에서는 적은 수의 프로토콜 헤더보다 잦은 재연결과 실패 재시도, 네트워크 전환이 배터리에 더 큰 영향을 줄 수 있습니다. 항목이 연결된 것으로 표시되지만 요청이 계속 완료되지 않는다면 먼저 신원 정보, 시간, 경로, TLS를 확인하고 지속적인 재시도가 발생하는지 살펴보세요. 서버에서 요구하는 특수 흐름 제어나 확장 설정은 현재 클라이언트가 지원하고 관련 정보가 명확한 경우에만 사용하세요. 구독에서 가져온 항목에 필수 설정이 빠졌다면 비슷한 이름의 항목을 직접 추가하기보다 구독을 새로 고치거나 원본 정보를 확인하는 편이 정확합니다.
4. Trojan, HTTP, SOCKS5: 연결 지점의 기능과 보안 범위
Trojan, HTTP, SOCKS5는 모두 프록시 연결에 사용할 수 있지만 인증 방식, 전송 보호, 목적지 지정 방식은 서로 다릅니다. Trojan은 TLS로 보호되는 연결에서 프록시 요청을 처리하며, 비밀번호로 인증하는 경우가 많습니다. HTTP 프록시는 일반적인 요청 및 터널 방식을 따르고, SOCKS5는 범용 프록시 협상 방식을 제공합니다. 후자의 기본 프로토콜은 클라이언트와 프록시 연결 지점 사이의 암호화를 자동으로 보장하지 않습니다. 따라서 입력하기 전에 서버가 실제로 어떤 유형의 연결 지점을 제공하는지 확인하세요. 최종 목적지에서 보안 웹페이지를 이용한다고 해서 프록시 연결 지점의 보호 방식까지 무시해서는 안 됩니다.
Trojan: TLS를 먼저 확인한 다음 비밀번호를 확인하세요
Trojan 설정에는 일반적으로 서버, 포트, 비밀번호, TLS 관련 항목이 포함됩니다. TLS 세션은 인증 요청보다 먼저 설정되므로 인증서 문제로 인해 비밀번호 확인 단계까지 도달하지 못할 수 있습니다. 주소에 연결되지만 핸드셰이크에 실패한다면 시스템 시간, 인증서 유효성, 서버 이름, 서버 보안 설정을 확인하세요. 인증서와 이름이 올바른데 인증에 실패하는 경우 비밀번호가 완전한지, 변경되었는지, 복사 과정에서 보이지 않는 문자가 들어갔는지 점검하세요. 모든 실패를 비밀번호 오류로 단정하지 말고 인증서 오류를 라우팅 모드 변경으로 해결하려 하지 마세요.
일부 구성은 하나의 연결 지점에서 여러 서비스를 함께 제공하므로 이름과 요청 처리 방식이 특히 중요합니다. 포트에서 응답이 온다는 사실은 해당 주소에 서비스가 있다는 뜻일 뿐, 예상한 프록시 연결 지점이라는 뜻은 아닙니다. 클라이언트에서 Trojan을 선택한 다음 가져온 정보에 추가 전송 설정이 포함되어 있는지, 현재 클라이언트가 해당 조합을 지원하는지 확인하세요. 관련 정보가 없다면 비밀번호에 따옴표나 인코딩, 접두사를 붙이지 마세요. 입력란에는 일반적으로 프로토콜 표기가 포함된 공유 문자열 전체가 아니라 원래 필드값을 입력해야 합니다.
HTTP: 터널과 연결 지점 암호화는 별개입니다
HTTP 프록시는 일반 요청을 전달하거나 CONNECT를 통해 목적지까지 바이트 통신 터널을 만들 수 있습니다. 목적지가 TLS를 사용하면 터널 내부의 목적지 콘텐츠는 암호화된 상태로 유지될 수 있습니다. 그러나 클라이언트가 프록시에 보내는 협상 정보와 프록시 인증이 보호되는지는 프록시 자체에 연결할 때 TLS를 사용하는지에 따라 달라집니다. ‘보안 웹페이지에 접속한다’는 것과 ‘프록시 연결 지점에 안전하게 연결한다’는 것을 혼동하면 인증 정보의 노출 범위를 잘못 판단할 수 있습니다. TLS가 적용된 프록시 연결 지점이라는 정보가 있다면 실제 유형과 보안 옵션에 맞게 설정하세요. 포트만 바꿔서는 해결되지 않습니다.
HTTP 프록시는 명확한 접근 정책이 있는 환경에서 적합할 수 있지만 모든 UDP 트래픽을 처리한다고 가정해서는 안 됩니다. 웹페이지는 정상인데 실시간 앱이 실패한다면 클라이언트 규칙이 아니라 연결 지점이 해당 트래픽을 지원하지 않는 문제일 수 있습니다. 사용자 이름과 비밀번호에 접근 범위, 동시 연결 수, 유효 기간 제한이 있을 수도 있습니다. 인증이 거부되면 계정 상태와 원본 정보를 확인하고, 특정 목적지만 거부된다면 연결 지점 정책과 대상 서비스의 응답을 구분하세요. 어느 경우에도 구독을 반복해서 새로 고치는 것으로 원인 분석을 대신해서는 안 됩니다.
SOCKS5: 범용 협상이 내장 암호화를 뜻하지는 않습니다
SOCKS5는 목적지 주소와 포트를 지정하고 인증 협상 및 UDP 전달 방식을 정의합니다. 하지만 서버에서 인증을 사용하는지, UDP를 허용하는지는 별도로 확인해야 합니다. 기본 사용자 이름과 비밀번호 인증만으로는 콘텐츠가 암호화되지 않으므로 사용 환경에 맞는 보호 조치가 필요합니다. 목적지를 도메인 이름으로 전달하는지 IP 주소로 전달하는지에 따라 DNS를 처리하는 위치도 달라질 수 있습니다. 유형이 SOCKS5라는 이유만으로 모든 도메인 조회가 원격에서 처리된다고 단정하지 마세요. 클라이언트의 DNS 설정, 규칙 요구 사항, 실제 연결 기록을 함께 확인해야 합니다.
이 세 가지 유형을 선택할 때는 막연한 속도 비교보다 사용 중인 서비스의 실제 기능이 중요합니다. Trojan은 보안 세션을 설정하는 데 시간이 들고, HTTP 터널은 연결 지점의 정책에 영향을 받으며, SOCKS5의 UDP는 네트워크 장비에 의해 제한될 수 있습니다. 모바일 기기에서는 짧은 요청, 지속 전송, 유휴 상태 후 복구를 각각 확인하세요. 접근 범위나 보안 요구 사항이 분명하지 않다면 먼저 서비스 제공업체에 각 설정값의 용도를 확인하세요. 검증을 끄거나 비밀번호를 비워 두거나 비슷한 유형으로 바꿔 시험하지 마세요.
| 유형 | 주요 확인 항목 | 혼동하기 쉬운 점 |
|---|---|---|
| Trojan | 비밀번호, TLS, 서버 이름 | 핸드셰이크 성공이 인증 성공을 뜻하지는 않습니다 |
| HTTP | 연결 지점 보호, 인증, CONNECT 지원 | 목적지 암호화가 연결 지점 암호화를 뜻하지는 않습니다 |
| SOCKS5 | 인증, UDP, 도메인 처리 | 기본 프로토콜만으로 통신이 암호화되지는 않습니다 |
5. WireGuard: 키, 터널 주소 및 네트워크 계층 라우팅
WireGuard는 네트워크 계층 터널과 피어 신원을 중심으로 하며, 간결한 프로토콜과 명확한 암호화 조합을 목표로 합니다. 요청별 목적지를 지정하는 프록시 모델과 달리 네트워크 패킷이 터널을 통과합니다. 연결 설정에는 로컬 터널 신원, 상대편 연결 지점, 허용할 주소 범위도 포함되어야 합니다. 따라서 서버 도메인과 비밀번호만으로 WireGuard를 설정할 수 없으며 다른 프로토콜의 비밀번호를 키 항목에 입력해서도 안 됩니다. 사용하기 전에 현재 기기에 맞는 완전한 정보를 받고 서버에 해당 공개 키가 등록되어 있는지 확인하세요.
Private Key와 Public Key의 역할
Private Key는 로컬 신원 정보이므로 비밀로 관리해야 합니다. Public Key는 상대편이 해당 신원을 확인하는 데 사용됩니다. 클라이언트에 입력하는 상대편 공개 키는 서버 정보에서 받아야 하며 기기의 공개 키가 아닙니다. 서버에도 클라이언트 공개 키가 등록되어 있어야 합니다. 양쪽 설정이 일치하지 않으면 UDP 패킷이 도달하더라도 의도한 보안 통신을 할 수 없습니다. 정보에 사전 공유 키가 포함되어 있다면 이는 추가 공동 비밀이며 어느 한쪽의 키 쌍을 대신하지 않습니다. 여러 항목을 같아 보이게 하려고 같은 문자열을 붙여 넣지 마세요.
기기를 바꿀 때는 ‘설정 복원’과 ‘여러 기기에서 같은 신원 정보를 동시에 사용’하는 것을 구분해야 합니다. 두 기기가 같은 신원 정보와 주소를 사용하면 서버에서 관찰되는 접속 지점이 반복해서 바뀌어 연결이 불안정해지거나 트래픽이 다른 기기로 전달될 수 있습니다. 재사용이 가능한지는 서버 구성에 따라 다릅니다. 파일을 가져올 수 있다고 해서 동시 사용도 항상 가능한 것은 아닙니다. 문제를 진단할 때 현재 해당 신원을 사용하는 기기 수를 기록하고 기존 서비스 안내에 따라 기기별 정보를 할당하세요. 클라이언트에서 서버를 반복해서 바꾸는 것보다 원인 파악에 도움이 됩니다.
Endpoint, Address, Allowed IPs
Endpoint는 현재 네트워크를 통해 연결할 상대편 주소와 포트를 뜻하며, Address는 터널 내부의 로컬 주소를 뜻합니다. 둘은 서로 바꿔 쓸 수 없습니다. WireGuard에서 Allowed IPs는 피어에 연결되는 주소 선택 및 수신 검증과 관련됩니다. 클라이언트에 통합될 때는 앱의 라우팅 방식과 함께 이해해야 합니다. 특정 네트워크 대역이 올바르게 포함되지 않으면 터널 핸드셰이크는 정상이어도 목적지에 연결할 수 없습니다. 반대로 범위를 지나치게 넓게 설정하면 원래 로컬에서 접속해야 하는 트래픽까지 적절하지 않은 경로로 전달될 수 있습니다.
사설 네트워크에 접속하려면 반환 경로도 고려해야 합니다. 클라이언트가 보낸 데이터가 상대편에 도달했다고 해서 상대편 뒤의 기기가 클라이언트 터널 주소로 응답하는 방법까지 알고 있는 것은 아닙니다. 서버의 전달 설정, 반환 경로, 접근 정책이 모두 결과에 영향을 줄 수 있습니다. 상대편 자체에는 접속되지만 그 뒤의 네트워크에는 접속되지 않는다면 클라이언트 키를 다시 만들기보다 서버 측 네트워크 구성을 확인하세요. DNS도 별개의 문제입니다. 사설 도메인에는 특정 DNS 서버가 필요할 수 있지만 DNS 서버를 지정했다고 해당 주소로 라우팅할 수 있는 것은 아닙니다.
UDP, MTU, Keepalive의 실제 영향
WireGuard는 UDP를 사용하므로 현재 네트워크에서 해당 UDP 트래픽을 허용하는 것이 기본 조건입니다. 경로의 유효 MTU가 부족하면 작은 요청은 정상이어도 큰 응답이나 일부 서비스가 멈출 수 있습니다. 캡슐화로 패킷 크기가 커지기 때문입니다. 이런 현상이 발생하면 먼저 배포 권장 사항과 경로 조건을 확인한 다음 근거를 바탕으로 조정하세요. 특정 숫자를 모든 네트워크에 적용되는 값으로 간주하지 마세요. 조정 후에는 같은 대용량 파일이나 고정 요청으로 확인하고 원래 값을 보관해 변경이 실제 개선 원인인지 판단하세요.
Persistent Keepalive는 필요한 경우 네트워크 매핑을 유지하는 기능이지, 빈도가 높을수록 안정적인 것은 아닙니다. 모바일 네트워크에서 주기적으로 데이터를 보내면 무선 통신 활성 시간이 늘어날 수 있습니다. 매핑을 유지할 필요가 없다면 과도한 설정은 백그라운드 작업만 늘릴 수 있습니다. WireGuard는 간결한 설계로 프로토콜 비용을 줄이는 데 도움이 되지만, 배터리 소모는 트래픽, 신호, 재연결에 따라 달라집니다. 완전한 피어 정보가 있고 네트워크 계층 주소 관계를 명확히 해야 하는 상황에 적합합니다. 프로토콜 이름만 보고 배터리 소모가 적을 것이라 기대해 선택하지 마세요.
6. Hysteria2: QUIC, 혼잡 제어 및 대역폭 예상치
Hysteria2는 QUIC 기반 프록시 전송을 위한 프로토콜이며, 패킷 손실이나 왕복 지연이 큰 경로에서도 효율적인 전송을 유지하는 데 중점을 둡니다. QUIC은 UDP를 기반으로 하고 그 위에 보안 세션과 신뢰성 있는 전송 등의 기능을 구현하므로 UDP를 그대로 전달하는 방식이 아니며 혼잡 제어가 전혀 필요 없는 것도 아닙니다. 먼저 호환되는 서버 정보가 있어야 하고 현재 네트워크에서 해당 UDP 트래픽을 전달할 수 있어야 합니다. 이름이 비슷한 다른 세대의 프로토콜이 서로 호환된다고 볼 수 없으므로 가져올 때 정확한 유형을 유지하세요.
먼저 UDP와 TLS 조건을 확인하세요
연결 지점, 포트, 인증 정보, TLS 서버 이름이 모두 일치해야 합니다. 네트워크에서 TCP 웹페이지 접속이 가능하다고 같은 위치의 UDP 연결 지점도 사용 가능한 것은 아닙니다. 일부 네트워크는 UDP를 제한하거나 지속 전송을 다르게 처리합니다. 모든 요청이 세션 설정 단계에서 시간 초과된다면 대역폭 값을 바로 바꾸지 말고 UDP 연결 가능 여부와 서버 리스닝 상태부터 확인하세요. 세션에서 인증서 문제가 나타나면 시스템 시간, 서버 이름, 신뢰 체인을 다시 살펴보세요. 속도 설정을 높여 보안 세션 실패를 우회할 수는 없습니다.
서버 정보에 추가 처리 설정이 포함될 수 있으므로 현재 클라이언트가 이를 지원하고 올바르게 가져왔는지 확인해야 합니다. 인증 값은 요청 권한의 일부이므로 웹사이트 로그인 비밀번호나 다른 프로토콜의 비밀번호로 대체할 수 없습니다. 포트가 바뀌는 구성이라면 서버 안내와 클라이언트 기능도 빠짐없이 확인하세요. 특정 포트에 간혹 연결된다고 전체 설정이 올바르다는 뜻은 아닙니다. 정보가 불완전하면 추측을 멈추고 정확한 설정값을 먼저 확인한 다음 성능을 테스트하세요. 그렇지 않으면 매번 여러 불확실한 요인이 동시에 작용합니다.
대역폭 설정값은 실제 속도를 보장하지 않습니다
일부 구성에서는 업로드 및 다운로드 대역폭 예상치를 설정합니다. 이러한 값이 전송 동작이나 혼잡 제어에 반영될 수는 있지만 클라이언트에 입력한 숫자가 실제 회선 용량을 만들어 내지는 않습니다. 실제 사용 가능한 대역폭보다 훨씬 높게 설정하면 대기열이 쌓이고 패킷 손실이 늘어나 같은 네트워크의 다른 서비스에 영향을 줄 수 있습니다. 너무 낮게 설정하면 활용 가능한 처리량이 제한될 수 있습니다. 입력 여부와 해석 방법, 서버 설정과의 조합은 현재 구현과 서비스 안내를 기준으로 확인하세요. 특정 숫자를 그대로 적용하지 마세요.
전송 방향도 구분해야 합니다. 기기에서 데이터를 보내는 방향과 기기로 받는 방향은 다릅니다. 속도 측정 화면에 다운로드 결과가 두드러지게 표시된다고 같은 숫자를 두 항목에 복사하지 마세요. 셀룰러 네트워크의 사용 가능 용량은 위치, 신호, 시간대에 따라 달라집니다. 실험실 환경에서 적합한 예상치가 이동 중에도 적합한 것은 아닙니다. 조정할 때는 보수적인 기준값을 유지하고 작업 완료 시간과 다른 앱에 미치는 영향을 확인한 뒤 조금씩 바꾸세요. 전송량은 늘었지만 상호작용이 크게 느려졌다면 전체 성능이 개선된 것으로 보기 어렵습니다.
패킷 손실 복구의 이점과 리소스 비용
QUIC은 하나의 연결에서 여러 데이터 스트림을 구성해 기존의 순서가 있는 바이트 스트림에서 발생하는 전달 제약을 줄일 수 있습니다. 하지만 모든 스트림이 같은 경로와 혼잡 리소스를 공유합니다. 패킷이 손실되면 해당 데이터는 여전히 복구해야 하며 실제 이점은 작업 유형과 경로 상태에 따라 다릅니다. 일부 네트워크에서는 다른 전송 방식보다 나을 수 있지만, 안정적이고 지연 시간이 짧은 네트워크에서는 차이가 뚜렷하지 않을 수도 있습니다. 한 번의 속도 측정 결과를 모든 상황의 순위로 일반화하면 주요 변수인 서버 설정과 네트워크 조건을 놓치게 됩니다.
iPhone과 iPad에서는 사용자 공간의 프로토콜 처리, 암호화, 지속적인 고속 전송, 패킷 손실 복구에 리소스가 필요합니다. 작업을 더 빨리 끝내면 네트워크 활성 시간이 줄어들 수 있지만, 회선을 계속 높은 부하로 사용하면 발열과 배터리 소모가 늘어날 수도 있습니다. 안정성, 작업 완료 시간, 백그라운드 복구, 기기 상태를 함께 살펴보세요. 오랫동안 대기하며 계속 재시도하는 연결은 배터리 테스트에 적합하지 않습니다. 먼저 연결 가능 여부를 해결하세요. 프로토콜 선택은 실제 작업을 위한 것이지 특정 설정값을 최대로 높이기 위한 것이 아닙니다.
7. 설정 확인: 프로토콜 연결과 규칙 라우팅을 따로 검증하세요
프로토콜 설정은 서버에 연결하는 방법을 결정하고, Global Routing은 트래픽이 해당 연결을 사용하는 방식을 정합니다. 둘을 따로 확인하지 않으면 규칙 문제를 프로토콜 문제로 오해하기 쉽습니다. 먼저 Home에서 현재 선택된 서버를 확인한 다음 Global Routing을 살펴보세요. Config는 설정된 규칙에 따라 처리하고, Proxy는 진단을 위해 트래픽을 하나의 프록시 경로로 보내며, Direct는 직접 연결합니다. 이는 라우팅 선택을 설명하는 것이지 서버의 인증이나 전송 기능을 바꾸지는 않습니다. 자세한 조작 순서는 사용법 안내를, 세 가지 모드 설명은 Global Routing 안내를 참조하세요.
주소, 이름, 인증 정보를 단계별로 확인하세요
서버 주소에는 호스트 이름이나 IP 주소를 입력할 수 있습니다. 호스트 이름을 사용하는 경우 연결 지점의 이름을 먼저 해석해야 합니다. 이 단계에서 실패하면 프로토콜 인증 전에 연결이 중단됩니다. TLS 서버 이름은 보안 세션에서 이름을 확인하는 데 쓰이며 최종 접속 대상 웹사이트의 도메인과 혼동해서는 안 됩니다. 포트에는 해당 서비스가 실제로 수신 중인 값을 입력해야 합니다. 흔히 쓰이는 포트로 바꿔도 서버가 다른 프로토콜을 자동으로 제공하지는 않습니다. 사용자 이름, 비밀번호, UUID, 키는 각각 다른 인증 방식에 속합니다. 빈 값, 인코딩 변경, 앞뒤 공백도 의미를 바꿀 수 있으므로 임의로 해석하지 말고 원본 정보에 따라 확인하세요.
공유 링크 전체를 단일 설정 항목에 입력하지 말고 구독 링크를 서버 주소로 사용하지도 마세요. 구독은 여러 항목을 가져오는 경로이며, 각 항목에 프로토콜과 인증 정보가 포함될 수 있습니다. 구독을 갱신하면 기존 항목이 교체되거나 이름이 바뀌거나 삭제될 수 있으며, 직접 수정한 내용이 다음 새로 고침 때 덮어써질 수도 있습니다. 특정 변경을 장기간 확인하려면 별도의 복사본을 만들고 구분하기 쉬운 이름을 지정하세요. 이름에 비밀번호를 넣지는 마세요. 가져오기 방식의 차이는 구독 가져오기 안내를 참조하세요.
| 설정 항목 | 확인할 사항 | 흔한 오해 |
|---|---|---|
| 서버 및 포트 | 연결 지점 이름 해석, 리스닝 위치 | 주소 입력란에 링크 전체를 넣기 |
| 신원 정보 | 유형, 완전성, 유효성 | 서로 다른 프로토콜에 같은 인증 정보 재사용 |
| TLS 이름 | 인증서 및 서버 구성과 일치하는지 | 최종 접속 웹사이트 이름을 잘못 입력 |
| 전송 설정 | 유형, 경로, Host | 프로토콜 이름만 보고 외부 전송을 무시 |
| 네트워크 계층 설정 | 주소 범위, MTU, 반환 경로 | 핸드셰이크 성공만으로 네트워크 연결이 된다고 판단 |
규칙은 트래픽 경로만 결정하며 서버를 고치지는 않습니다
아래는 규칙 일치 순서를 설명하기 위한 Shadowrocket .conf 규칙 예시입니다. 서버 정의는 포함하지 않으며 기존 설정을 대체할 수 있는 완성 파일도 아닙니다. 도메인 규칙은 지정된 접미사를 먼저 확인하고, 로컬 네트워크 규칙은 해당 주소를 처리하며, FINAL은 나머지 요청에 기본 정책을 적용합니다. 기존 구성에 복사하기 전에 원래 규칙 구조와 기본 정책을 이해해야 합니다. 사설 네트워크 설정을 덮어쓰지 않도록 주의하세요. 여기에는 문법 설명을 위한 예시 도메인만 사용했으며 연결 서비스를 뜻하지 않습니다.
[Rule]
DOMAIN-SUFFIX,example.com,PROXY
IP-CIDR,192.168.0.0/16,DIRECT
FINAL,PROXY규칙은 보통 순서대로 확인합니다. 조건이 지나치게 넓은 규칙이 앞에 있으면 뒤의 구체적인 조건이 적용되지 않을 수 있습니다. DOMAIN-SUFFIX는 도메인 접미사를 기준으로, IP-CIDR은 IP 주소 대역을 기준으로 판단하므로 필요한 정보가 다릅니다. 일부 주소 판정에는 DNS 조회 결과가 영향을 줄 수 있지만 DNS가 성공했다고 프록시 출구에서 목적지에 접속할 수 있다는 뜻은 아닙니다. 문제를 진단할 때는 먼저 명확한 도메인 규칙으로 경로를 확인한 다음 연결 기록에 표시된 실제 목적지 주소를 살펴보세요. 서로 겹치는 테스트 규칙을 한꺼번에 추가하지 마세요.
비교 테스트로 규칙 문제와 프로토콜 문제를 구분하세요
같은 서버가 Proxy 모드에서는 지정한 작업을 완료하지만 Config에서는 실패한다면 프로토콜을 바로 수정하지 말고 규칙 일치 여부, 정책 참조, DNS를 먼저 확인하세요. 두 모드 모두 실패한다면 서버 설정과 연결 경로를 살펴보세요. Direct는 현재 네트워크의 기본 연결을 확인하는 데 사용할 수 있지만, 직접 연결에 성공했다고 프록시 서버에도 연결할 수 있는 것은 아닙니다. 테스트가 끝나면 원래 사용해야 하는 모드로 되돌리세요. 진단 설정이 모든 트래픽 경로를 장기간 바꾸어 이후 관찰 결과가 일상 설정과 달라지지 않도록 해야 합니다.
IPv6를 사용하는 경우 목적지의 DNS 결과, 규칙, 서버 기능이 서로 맞는지도 확인해야 합니다. IPv4만 처리하는 규칙은 IPv6 요청을 포함하지 않을 수 있습니다. 같은 도메인이 네트워크에 따라 다른 주소를 받으면 결과가 무작위처럼 달라질 수도 있습니다. 일부 요청이 실패한다고 DNS 설정을 모두 바꾸지 마세요. 먼저 주소 체계, 적용된 정책, 실패 시간을 기록한 다음 하나씩 확인하세요. 주요 개념은 용어 안내에서 확인해 서로 다른 계층의 용어를 같은 설정으로 오해하지 않도록 하세요.
8. 상황별 선택: 재현 가능한 절차로 결과를 판단하세요
프로토콜을 선택할 때 가장 먼저 고려할 사항은 사용 중인 서버와의 일치 여부이며, 그다음이 작업과 네트워크 조건입니다. 안정적으로 작동하는 설정이 있다면 프로토콜 이름을 좇아 바꿀 필요는 없습니다. 일상적인 웹 및 메시지 이용에서는 첫 응답, 백그라운드 복구, 연결 성공률이 중요합니다. 지속 전송에서는 처리량과 장시간 안정성을 살펴보세요. 사설 네트워크 접속은 주소 관계와 반환 경로를 먼저 확인해야 하고, UDP를 사용하는 서비스는 전체 UDP 경로를 점검해야 합니다. 서버가 호환되는 여러 옵션을 실제로 제공할 때만 같은 조건에서 비교할 의미가 있습니다.
반복 가능한 테스트 기록 만들기
기기, 네트워크, 대상, 테스트 작업을 고정하고 결과에 영향을 주는 다른 실험 설정은 끄세요. 현재 설정의 복사본도 보관합니다. 프로토콜과 외부 전송 방식, Global Routing 모드, 네트워크를 방금 전환했는지, 어느 단계에서 실패했는지 기록하세요. 웹페이지는 같은 대상과 비슷한 콘텐츠로 테스트하고, 지속 전송은 동일한 파일과 시간으로 진행하며 캐시도 고려하세요. 새 연결의 설정 시간을 이미 세션을 재사용하는 요청과 직접 비교할 수는 없습니다. 시간대별 서버 부하 차이를 모두 프로토콜의 차이로 볼 수도 없습니다.
Connectivity Test는 선택한 항목의 연결 가능성이나 테스트 요청 결과를 확인하는 데 도움이 됩니다. 그러나 한 번 성공했다고 모든 작업이 정상인 것은 아니며, 한 번 측정한 수치가 전체 처리량을 나타내지도 않습니다. 실제 대상에 접속하고 연결 기록을 확인해 연결 지점 접속, 인증 성공, 요청 전송, 응답 완료를 구분하세요. 최초 연결 절차는 첫 연결 확인 목록을 참조하세요. 연결 스위치가 켜져 있는데 웹페이지가 열리지 않는다면 구독 갱신, DNS 수정, 프로토콜 변경을 동시에 하지 마세요. 어떤 조치가 영향을 주었는지 알 수 없게 됩니다.
실패 단계에 따라 점검 범위를 좁히세요
- 연결 지점에 도달하기 전: 로컬 네트워크, 서버 이름 해석, 주소, 포트를 확인하고 테스트 대상 항목이 선택되어 있는지 확인하세요.
- 세션 설정: 프로토콜 유형, TCP 또는 UDP 조건, TLS 이름, 시스템 시간, 인증서 문제를 확인하세요.
- 인증 단계: 비밀번호, UUID, 키, 서버 등록 상태를 확인하고 구독에 만료된 정보가 남아 있지 않은지 살펴보세요.
- 요청 단계: Global Routing, 규칙 일치 여부, 목적지 이름 해석, UDP 지원, 주소 체계를 확인하세요.
- 지속 전송: 패킷 손실, 유효 MTU, 서버 부하, 대역폭 예상치, 유휴 매핑 변화를 확인하세요.
단계별 판단은 특정한 오류 문구를 반드시 찾아야 한다는 뜻이 아닙니다. 확보한 근거를 올바른 단계에 연결하는 것이 중요합니다. 연결 지점에서 응답이 전혀 없다면 비밀번호를 확인해도 도움이 되지 않습니다. 핸드셰이크는 완료됐지만 특정 네트워크 대역만 실패한다면 라우팅과 반환 경로를 살펴보세요. 모든 대상에서 로딩이 시작되지만 큰 응답에서 멈춘다면 경로와 패킷 크기를 점검할 수 있습니다. 로그에 막연한 시간 초과만 표시되면 같은 네트워크와 모드에서 정상 작동하는 것으로 확인된 다른 항목을 테스트하는 등 비교 실험으로 근거를 보완하세요. 곧바로 해당 프로토콜이 적합하지 않다고 결론 내리지는 마세요.
백그라운드와 네트워크 전환도 배터리 비교에 포함하세요
배터리는 같은 유형의 작업과 비슷한 사용 시간을 기준으로 비교하고 화면 밝기, 신호, 백그라운드 앱, 테스트 시간을 가능한 한 동일하게 유지하세요. 발열 여부, 잦은 재연결, 유휴 상태 후 복구, Wi-Fi에서 셀룰러 네트워크로 전환한 뒤의 상태를 기록하세요. 짧은 시간 동안의 배터리 백분율 변화는 측정 단위가 거칠므로 특정 프로토콜이 배터리를 정해진 만큼 절약한다고 단정할 수 없습니다. 연결이 계속 실패하며 재시도한다면 원인을 해결한 뒤 비교하세요. 작업을 일찍 끝낸 경우 남은 유휴 시간도 관찰에 포함해야 일상 사용에 가까운 결과를 얻을 수 있습니다.
장시간 백그라운드 연결이 필요하더라도 Keepalive와 On Demand를 실제 필요에 맞게 설정하세요. 무조건 모두 켜지 마세요. Keepalive는 매핑을 유지할 수 있지만 네트워크 활동을 늘릴 수도 있습니다. On Demand는 조건에 따라 연결을 시작하는 기능이지 인증이나 규칙 오류를 고치는 기능이 아닙니다. 네트워크를 전환할 때마다 직접 복구해야 한다면 시스템 실행 조건, 전송 재설정, 서버 상태를 각각 확인하세요. 한 번의 전환 테스트만으로는 단서가 제한적이므로 같은 조건에서 반복 확인하고 복구 전후의 연결 기록을 보관하세요.
결론을 내리기 전에 적용 조건을 명시하세요
타당한 결론은 ‘이 기기, 이 네트워크, 이 작업, 이 서버 설정에서 어떤 조합이 더 안정적이었다’고 설명해야 합니다. 특정 프로토콜이 언제나 가장 빠르다고 단정해서는 안 됩니다. 일상적인 사용에서는 설정이 명확하고 안정적으로 복구되며 관리하기 쉬운 항목을 우선하세요. 특별한 네트워크 기능이 필요할 때 요구 사항에 맞는 유형을 선택하면 됩니다. 정상 작동이 확인된 기준 설정을 보관하고 기존 경로로 구독을 주기적으로 갱신하세요. 의미가 불분명한 복사본을 여러 개 관리하지 마세요. 추가 질문은 질문과 답변 또는 연결 후 인터넷에 접속할 수 없을 때의 단계별 점검을 참조하세요.