Shadowrocket 프로토콜 가이드

01 · 프로토콜 선택과 연결 단계

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

프로토콜 선택은 속도 순위가 아니라 호환성을 확인하는 과정입니다. 같은 서버 주소라도 포트마다 서로 다른 프로토콜을 사용할 수 있으며, 주소가 같다고 인증 및 전송 방식까지 서로 바꿔 쓸 수 있는 것은 아닙니다. Add Server에서 Type을 선택할 때는 기존 서버 안내나 구독을 불러온 결과를 기준으로 삼으세요. Shadowsocks를 Trojan으로 바꾼다고 기존 서버가 TLS를 지원하게 되는 것은 아닙니다. VMess의 인증 정보를 VLESS에 입력해도 연결되지 않습니다. 구독 내용과 설명이 다르면 먼저 같은 접속 지점을 가리키는지 확인한 뒤 필드를 조정하세요.

연결 과정은 네 단계로 나눠 볼 수 있습니다. 첫째, 현재 Wi-Fi 또는 셀룰러 네트워크에서 서버에 도달할 수 있는지 확인합니다. 다음으로 TCP, UDP, QUIC 같은 전송 방식이 있고, 그 뒤에 프로토콜 인증·암호화·선택적 TLS가 이어집니다. 마지막 단계는 대상 요청과 규칙 정책입니다. 시간 초과는 어느 단계에서든 발생할 수 있으므로 오류 메시지만 보고 비밀번호 문제라고 단정할 수 없습니다. 예를 들어 포트에 도달하지 못하면 인증 단계에 들어가지도 못하며, 인증서가 일치하지 않을 때는 대상 요청이 전송되지 않았을 수도 있습니다. 단계를 나눠 확인하면 점검 범위를 좁히고 서로 관계없는 옵션을 한꺼번에 바꾸는 일을 피할 수 있습니다.

같은 조건에서 속도와 배터리 소모 비교하기

연결 속도는 보통 연결 대기 시간, 첫 응답 시간, 지속 처리량이라는 서로 다른 지표로 나뉩니다. 짧은 웹페이지를 볼 때는 DNS, 핸드셰이크, 첫 응답의 차이가 두드러지고, 대용량 파일을 전송할 때는 회선 대역폭과 혼잡 제어, 서버 부하의 영향을 더 많이 받습니다. 한 번의 Connectivity Test 결과로 모든 앱의 실제 체감을 판단할 수 없으며, 이를 다운로드 속도로 바로 환산할 수도 없습니다. 기존 접속 지점을 비교할 때는 같은 기기와 네트워크, 테스트 대상, 비슷한 시간대를 유지하고, 새로 연결했을 때와 연결이 이미 설정된 뒤의 결과를 따로 기록하세요.

iPhone과 iPad의 배터리 소모도 프로토콜 이름만으로 판단할 수 없습니다. 암호화 연산은 프로세서 자원을 사용하지만, 무선 모듈이 계속 활성화되는 상황이나 패킷 손실에 따른 재전송, 잦은 핸드셰이크와 지나치게 잦은 연결 유지 신호도 큰 영향을 줄 수 있습니다. 신호가 약하면 알고리즘 자체보다 데이터 재전송이 배터리를 더 많이 소모할 수도 있습니다. 측정할 때 화면 밝기, 전면 앱, 테스트 시간을 비슷하게 맞춰 화면이나 백그라운드 동기화로 인한 소모를 프로토콜 탓으로 돌리지 않도록 하세요. 낮은 지연 시간과 낮은 배터리 소모를 동시에 얻기 어려울 수 있으니 실제 사용 목적부터 정하세요.

기존 서버가 한 가지 유형만 제공한다면 ‘프로토콜 선택’을 위해 다른 프로토콜을 새로 입력할 필요가 없습니다. 호환되는 유형을 선택하고 필수 필드를 확인하는 것이 올바른 방법입니다. 비교는 본인 소유 서버에 실제로 여러 접속 지점이 있을 때만 의미가 있습니다. 전송 및 보안 옵션은 서버의 구체적인 구성과 현재 앱의 지원 여부에 따라 달라집니다. 인터페이스에 해당 옵션이 없다면 이름이 비슷하다는 이유만으로 같은 기능이라고 보지 마세요. 원본 안내를 보관하고 현재 클라이언트에서 필요한 설정을 모두 지정할 수 있는지 확인하세요.

02 · Shadowsocks의 암호화와 트래픽 전달

간결한 전달 구조의 설계상 특징

Shadowsocks는 비교적 가벼운 암호화 프록시 전달을 제공하기 위해 설계되었습니다. 대상 주소와 앱 데이터를 캡슐화해 원격 서버로 전달합니다. 네트워크 계층 전체를 처리하는 터널과 달리 프록시 연결에 초점을 두므로 기기에 터널용 주소 전체를 할당할 필요가 없습니다. 구조가 간결해 배포와 문제 해결이 쉬운 편이지만, ‘암호화 프록시’라는 말만으로 모든 보안 특성을 판단할 수는 없습니다. 암호화 방식, 인증 강도, UDP 동작, 추가 전송 요구 사항은 서버 설정에 따라 각각 확인해야 합니다.

Shadowrocket에서 수동으로 추가할 때는 먼저 Shadowsocks를 선택하고 서버 주소와 포트를 입력한 다음 Method와 Password를 확인하세요. Method는 프로토콜 호환 조건이지 임의로 고르는 성능 옵션이 아닙니다. 양쪽에서 서로 다른 방식을 선택하면 비밀번호가 같아도 데이터를 올바르게 해석할 수 없습니다. Password를 복사할 때 앞뒤 공백, 줄바꿈, 대소문자를 확인하세요. 구독의 메모를 비밀번호로 착각하거나 공유 정보 전체를 인코딩된 상태 그대로 Password 필드에 넣지 마세요. 공유 정보 전체는 해당 가져오기 방식으로 처리해야 합니다.

AEAD, 호환성 및 추가 설정

AEAD 방식은 암호화와 데이터 무결성 검증을 함께 제공하므로 수신 측에서 데이터 변조나 인증 오류를 감지할 수 있습니다. 이는 단순히 ‘내용을 읽을 수 없게 만드는 것’과 다릅니다. 그렇다고 비슷한 알고리즘 이름을 가진 모든 방식을 서로 호환된다고 볼 수는 없습니다. 프로토콜 변형에 따라 키, 세션, 사용자 정보에 관한 추가 요구 사항이 있을 수 있습니다. 서버가 제공한 유형, 알고리즘 이름, 인증 정보는 하나의 설정 묶음으로 보관하세요. 구독에 추가 필드가 있다면 필드를 지워 입력을 통과시키기보다 원본 설정 안내를 먼저 확인하세요.

기존 설정에 추가 전송 구성 요소, 호스트 이름 또는 경로가 포함되는 경우도 있습니다. 이는 일반적인 Shadowsocks 필수 항목이 아니며 서버에서 실제로 사용하는 경우에만 맞춰야 합니다. 추가 구성 요소는 외부 데이터 형식을 바꾸거나 핸드셰이크와 설정을 복잡하게 만들 수 있으므로 일반 접속 지점에 임의로 활성화하지 마세요. 가져오기는 성공했지만 연결되지 않는다면 가져오기 과정에서 이러한 설정이 모두 유지되었는지, 현재 클라이언트가 해당 조합을 지원하는지 확인하세요. 항목이 표시된다는 것은 데이터를 해석했다는 뜻일 뿐, 양쪽의 프로토콜 협상이 완료됐다는 의미는 아닙니다.

TCP, UDP 및 iOS에서의 동작

TCP 요청은 성공하지만 UDP에 의존하는 앱이 작동하지 않는다면 별도로 점검해야 합니다. 서버에서 UDP 전달을 활성화하지 않았거나, 네트워크 경로에서 UDP가 허용되지 않거나, 현재 규칙이 해당 트래픽을 예상한 정책으로 보내지 않을 수 있습니다. 이때 Password를 반복해서 바꾸는 것은 대개 도움이 되지 않습니다. 먼저 일반 웹페이지로 기본 TCP 전달을 확인한 뒤 앱이 실제로 사용하는 트래픽 유형과 클라이언트 기록을 살펴보세요. 웹페이지가 한 번 열렸다고 모든 네트워크 기능이 갖춰졌다고 판단하거나, 한 번 실패했다고 프로토콜 전체가 부적합하다고 단정하지 마세요.

iPhone과 iPad에서는 추가 계층이 적을수록 설정이 단순해지는 경우가 많지만, 실제 처리량은 선택한 알고리즘을 기기가 처리하는 효율, 서버 성능, 네트워크 패킷 손실에 따라 달라집니다. 기기마다 알고리즘별 성능이 다를 수 있으므로 다른 기기의 결과를 그대로 적용하지 마세요. 지속 전송은 안정적이지만 첫 접속이 느리다면 DNS와 연결 설정을 먼저 확인하세요. 부하가 높을 때만 속도가 떨어진다면 프로세서 부하와 회선 제한을 살펴보세요. 알고리즘을 변경하려면 서버에서도 해당 방식을 지원해야 합니다. 클라이언트만 바꾸면 안 됩니다.

연결에 성공한 항목을 보관한 뒤 복사본을 만들어 한 가지 설정만 바꿔 확인하는 방법을 권장합니다. 먼저 Address, Port, Method, Password를 확인하고, 실제로 설정된 추가 옵션을 점검한 다음 UDP와 규칙 경로를 검증하세요. 구독 업데이트 후 문제가 생겼다면 업데이트 전후의 유형과 주요 필드를 비교하되 인증 정보가 포함된 전체 항목을 공개하지 마세요. 가져오기와 업데이트 방법은 Subscribe 업데이트 안내를 참고하세요. 이 장에서는 프로토콜 필드와 점검 순서를 설명하며, 서버 설정값의 출처를 대신하지 않습니다.

03 · VMess와 VLESS의 인증 및 전송

프로토콜 식별 정보와 전송 방식 구분하기

VMess와 VLESS는 모두 일반적으로 사용자 식별에 UUID를 사용하지만, Type만 바꾸면 서로 호환되는 형식은 아닙니다. VMess는 자체 프로토콜 설계에 인증과 데이터 보호를 포함하며, 일부 인증 절차는 시간 범위에 영향을 받으므로 기기 시간이 크게 어긋나면 실패할 수 있습니다. VLESS는 더 간결한 구조를 채택해 기본 프로토콜 자체에서 페이로드를 암호화하지 않으며, 일반적으로 배포 환경에 함께 구성된 보안 계층을 통해 데이터를 보호합니다. 두 프로토콜의 차이는 구조와 역할 분담에 있으므로 한쪽이 이름만으로 반드시 더 빠르다고 단정해서는 안 됩니다.

UUID는 본인이 보유한 서버 설정에서 가져와 문자와 구분 기호를 그대로 유지해야 합니다. 형식에 맞는 UUID를 무작위로 생성해도 서버가 해당 사용자를 승인하는 것은 아닙니다. 서버 주소, 포트, UUID가 맞더라도 확인이 끝난 것은 아닙니다. 전송 방식, TLS, Server Name, 경로 등이 연결 성립 여부를 좌우할 수 있습니다. 구독에 비슷한 접속 지점이 여러 개 있다면 서버 안내에서 같은 설정 묶음이라고 명시하지 않는 한 한 항목의 UUID와 다른 항목의 경로를 조합하지 마세요.

TCP, WebSocket, gRPC는 서로 다른 계층입니다

프로토콜은 인증 정보와 대상 요청을 표현하는 방법을 정하고, 전송 방식은 그 데이터를 전달하는 방법을 정합니다. WebSocket을 사용한다면 클라이언트가 해당 핸드셰이크를 완료해야 하며 Path와 Host 등의 설정이 서버 요구 사항과 일치해야 합니다. gRPC를 사용할 때는 해당 서비스 이름과 TLS 등의 설정을 확인하세요. 일반 TCP 접속 지점에는 WebSocket Path를 임의로 입력할 필요가 없습니다. 도메인이 같다는 이유만으로 전송 방식이 동일한 접속 지점을 공유한다고 볼 수 없습니다. 리버스 프록시는 경로, 호스트 이름, 서비스 이름에 따라 요청을 서로 다른 백엔드로 전달할 수 있습니다.

Host, Server Name, 서버 주소도 서로 구분해야 합니다. 서버 주소는 연결 대상이고, TLS의 Server Name은 핸드셰이크에서 이름을 표시하고 인증서를 확인하는 데 사용됩니다. WebSocket의 Host는 애플리케이션 계층 요청 정보입니다. 일부 배포 환경에서 이 값들이 같은 것은 설정 결과일 뿐, 모든 상황에서 같아야 한다는 프로토콜 요구 사항은 아닙니다. 안내에 따라 각각 입력해야 ‘올바른 서버에 연결했지만 잘못된 백엔드에 진입한 경우’와 ‘서버 자체에 도달하지 못한 경우’를 구분할 수 있습니다. 특정 계층의 오류를 감추려고 이름을 임의로 바꾸지 마세요.

보안 옵션과 성능 범위

VMess의 Security 같은 필드는 해당 프로토콜 자체의 설정이며 TLS 옵션과 같은 의미가 아닙니다. VLESS의 일부 보안 또는 흐름 제어 확장 기능도 특정 배포 조합에서만 사용할 수 있습니다. 서버가 지원한다고 명시하지 않았다면 이름만 보고 확장 기능을 선택하지 마세요. 가져온 설정에서 모르는 필드가 보이면 현재 앱의 관련 옵션과 서버 요구 사항을 확인하고 원본 항목을 보관하세요. 이해하지 못한 매개변수를 삭제하면 완전한 설정이 호환되지 않는 설정으로 바뀔 수 있습니다. ‘흔히 쓰는 값’을 입력하는 것이 근거를 보존하는 것보다 더 안전한 것도 아닙니다.

TLS나 애플리케이션 계층 전송을 추가하면 핸드셰이크와 캡슐화가 늘어날 수 있지만, 이것만으로 최종 속도가 느려진다고 단정할 수는 없습니다. 지속 연결에서는 핸드셰이크 비용을 분산할 수 있고, 네트워크 중간 장비도 전송 방식별 실제 성능에 영향을 줍니다. 짧은 연결을 자주 만드는 환경에서는 연결 설정 비용이 더 두드러지고, 장시간 전송에서는 혼잡과 서버 부하가 더 중요합니다. iOS에서 실패 후 반복적으로 재연결하면 안정적으로 연결을 유지할 때보다 배터리를 더 많이 쓸 수 있습니다. 따라서 처음부터 특정 캡슐화 계층을 줄이기보다 설정 불일치를 먼저 해결하세요.

문제를 해결할 때는 먼저 기기의 날짜 및 시간이 자동으로 설정되어 있는지 확인하고, 주소와 포트에 도달할 수 있는지 점검하세요. 그다음 UUID, 프로토콜 보안 필드, 전송 방식, TLS, 이름, 경로 순으로 확인합니다. TLS 연결이 성공했는데 요청이 실패한다면 인증과 백엔드 라우팅을 살펴보세요. 인증서 검증을 계속 끄는 것은 해결책이 아닙니다. 구독 업데이트 후에만 작동하지 않는다면 전송 필드가 바뀌었는지 확인하세요. 같은 그룹의 항목이 모두 실패한다면 현재 네트워크와 공통 도메인 해석을 먼저 점검하세요. 이 점검 순서는 연결 시간 초과 및 실패 점검 노트와 함께 참고할 수 있습니다.

04 · Trojan, HTTP, SOCKS5의 차이

Trojan: TLS 연결 내부에서 처리되는 인증

Trojan은 프록시 인증과 요청을 TLS 연결 안에서 처리하도록 설계되어, 널리 쓰이는 TLS 메커니즘으로 전송을 보호합니다. 설정에서 Password와 TLS 매개변수는 서로 다른 역할을 합니다. 비밀번호는 서버에서 사용자를 식별하고, 인증서와 이름 검증은 보안 연결이 올바른 대상을 향하는지 확인합니다. 비밀번호가 맞아도 인증서를 무시해도 되는 것은 아니며, 인증서가 유효해도 계정 인증이 성공한다고 보장할 수 없습니다. 이 두 가지 확인 절차를 구분해야 핸드셰이크 실패와 인증 실패에 맞는 조치를 취할 수 있습니다.

Server Name은 임의로 익숙한 도메인을 입력하는 값이 아니라 서버 인증서와 배포 요구 사항에 맞춰야 합니다. 서버 주소로 IP를 사용해도 TLS 핸드셰이크에서 특정 도메인을 요구할 수 있습니다. 이때 연결 대상과 인증 이름이 다른 것은 정상적인 구성일 수 있지만, 값은 기존 서버 안내를 따라야 합니다. 인증서 오류가 나면 기기 시간, 이름의 철자, 인증서 유효 기간, 인증서 체인을 확인하세요. 검증을 무시해 오류 메시지를 숨겨도 예상한 서버에 연결됐다는 증거가 되지 않으며, 장기적인 해결책으로 삼아서도 안 됩니다.

HTTP: 프록시 요청이 전체 구간 암호화를 뜻하지는 않습니다

HTTP 프록시는 애플리케이션 계층 요청을 전달하는 방식으로 만들어졌으며, HTTPS 대상에는 보통 CONNECT를 사용해 대상까지의 바이트 통로를 설정합니다. 여기서는 ‘대상 웹사이트가 HTTPS를 사용하는 것’과 ‘기기에서 프록시 접속 지점까지 TLS를 사용하는 것’을 구분해야 합니다. 전자는 웹사이트 세션을 보호하고 후자는 프록시까지의 연결 구간을 보호하므로 같은 설정이 아닙니다. 접속 지점 자체가 평문 HTTP라면 대상 주소가 HTTPS로 시작한다는 이유만으로 프록시 인증 정보와 접속 지점 메타데이터도 같은 수준으로 보호된다고 판단할 수 없습니다.

HTTP 유형의 접속 지점을 설정할 때는 서버 주소, 포트, TLS 사용 여부, Username과 Password 필요 여부를 확인하세요. 웹사이트 로그인 계정을 프록시 인증 정보로 착각하거나 URL의 경로 부분을 주소 필드에 임의로 입력하지 마세요. 서버가 일반 HTTP 프록시만 제공한다면 클라이언트에서 TLS를 켜도 자동으로 보안 연결로 전환되지 않습니다. 반대로 TLS가 필요한 접속 지점에 평문으로 연결하면 초기 단계에서 실패하는 경우가 많습니다. 양쪽에서 처음 전달되는 데이터를 같은 방식으로 해석해야 합니다.

SOCKS5: 유연한 전달 방식, 페이로드 암호화는 별도

SOCKS5는 대상 주소 표현, 인증 협상, 전달 요청 등의 기능을 정의하며 도메인 또는 IP 주소를 대상으로 지정할 수 있고, 일부 배포 환경에서는 UDP도 지원합니다. 하지만 자체적으로 일반적인 페이로드 암호화를 제공하지는 않습니다. Username과 Password 인증도 암호화된 통신 경로와 같은 의미가 아닙니다. 이 유형을 선택할 때는 기존 네트워크 환경에서 어떤 보호를 제공하는지, 접속 지점에 별도의 보안 캡슐화가 있는지 확인하세요. ‘비밀번호가 있다’는 사실만으로 데이터가 암호화됐다고 볼 수 없으며, 대상 앱의 보안을 모든 전송 데이터에 확대 적용해서도 안 됩니다.

SOCKS5에서 UDP를 사용하려면 서버, 네트워크 경로, 클라이언트가 함께 지원해야 합니다. 서버와 TCP 연결이 된다고 UDP 전달까지 가능하다는 뜻은 아닙니다. 도메인을 로컬과 원격 중 어디에서 해석하는지는 실제 요청 형식과 클라이언트 DNS 설정에 따라 달라집니다. 도메인 접속은 실패하지만 같은 대상의 IP로는 연결된다면 먼저 DNS 경로를 확인하세요. 일반 웹페이지는 열리는데 실시간 앱에 문제가 있다면 UDP와 규칙을 점검하세요. 근거가 충분하지 않은 상태에서 모든 차이를 인증 방식 탓으로 돌리지 마세요.

iPhone과 iPad에서 이 세 가지 프로토콜을 비교할 때도 기존 접속 지점을 전제로 해야 합니다. Trojan의 TLS 핸드셰이크, HTTP의 연결 재사용, SOCKS5의 전달 경로는 첫 응답에 영향을 줄 수 있지만 지속 속도는 주로 실제 네트워크 경로에 좌우됩니다. 명확한 전송 보호가 필요한 상황에서는 프로토콜 라벨만 보지 말고 접속 지점의 보안 계층을 확인하세요. 특정 앱에 UDP가 필요하다면 처음부터 끝까지 지원되는지 검증하세요. 사용할 수 있는 설정이 하나뿐이라면 호환되지 않는 유형을 바꾸기보다 해당 설정을 정확히 입력하는 것이 중요합니다.

05 · WireGuard의 키, 주소, MTU

네트워크 계층 터널과 프록시 접속 지점의 차이

WireGuard는 간결한 네트워크 계층 터널을 중심으로 설계되었습니다. 공개 키와 개인 키로 상대를 식별하고 UDP를 통해 보호된 데이터를 전달합니다. 앱 연결 전달에 주로 초점을 두는 프록시와 달리 터널 내부 주소와 라우팅 범위도 다룹니다. 따라서 설정을 ‘서버 주소와 비밀번호’만으로 이해할 수 없습니다. 기기에는 자체 키 식별 정보가 있어야 하고, 상대 측에도 해당 공개 키가 등록되어야 하며, 어떤 주소를 터널로 보낼지 양쪽에서 알아야 합니다. 인증에 성공했는지와 목적지에 도달할 수 있는지 사이에는 주소 할당과 라우팅 계획 점검이 추가됩니다.

PrivateKey는 현재 기기의 개인 키이므로 신뢰할 수 있는 로컬 설정에 보관해야 합니다. 상대 설정에서 PublicKey는 일반적으로 원격 측 공개 키를 뜻하며, 내 기기의 개인 키를 복사해 넣는 것이 아닙니다. 내 개인 키에서 파생된 공개 키는 원격 측에서 허용되어야 하고, 원격 공개 키는 연결 상대를 확인하는 데 사용됩니다. 양쪽 공개 키를 바꿔 입력했거나 서버에 내 기기의 신원이 등록되지 않았다면 주소와 포트가 맞아도 유효한 세션이 만들어지지 않습니다. 선택 항목인 PresharedKey는 추가 공유 키이며 양쪽에서 명시적으로 설정한 경우에만 입력하세요. 한쪽에서만 임의로 만들면 안 됩니다.

Address, Endpoint, 라우팅 범위

Address는 터널 내부에서 현재 기기에 할당된 주소로, 보통 프리픽스 길이를 포함합니다. Endpoint는 외부 네트워크에서 도달할 수 있는 원격 주소와 포트를 뜻합니다. 서로 다른 계층의 값이므로 공인 서버 주소를 터널 내부 주소로 그대로 사용할 수는 없습니다. 기존 설정에 IPv4와 IPv6 Address가 모두 있다면 각 프리픽스를 그대로 유지하세요. 터널 주소를 임의로 바꾸면 다른 기기와 충돌하거나 원격 측 허용 범위를 벗어나 핸드셰이크는 되지만 데이터가 예상대로 돌아오지 않을 수 있습니다.

WireGuard에서 AllowedIPs는 허용되는 터널 주소 범위와 상대를 선택하는 기능에 함께 연결됩니다. 클라이언트에 표시되는 구체적인 방식은 실제 인터페이스를 기준으로 확인하세요. Shadowrocket에서는 해당 엔드포인트 내부의 라우팅 범위와 앱 전체의 규칙 정책도 구분해야 합니다. 전자는 터널이 주소를 처리하는 방식을 정하고, 후자는 어떤 요청을 해당 정책으로 보낼지 정합니다. 원격 측에서 넓은 주소 범위를 허용한다고 해서 기기의 모든 요청이 터널을 통과한다고 볼 수는 없습니다. 먼저 규칙이 요청을 선택했는지 확인한 다음 터널 내부의 반환 경로와 대상 라우팅을 점검하세요.

MTU, DNS, 연결 유지 설정의 영향

MTU는 해당 인터페이스가 전달할 수 있는 패킷 크기의 상한입니다. 터널 캡슐화에는 추가 오버헤드가 생기므로 경로가 큰 패킷을 제대로 처리하지 못하면 작은 요청은 성공하지만 큰 응답은 멈출 수 있습니다. 이때 MTU를 조금 낮춰 확인할 수 있지만, 특정 값을 모든 네트워크에 통용되는 정답으로 보아서는 안 됩니다. 원래 값을 기록하고 한 번에 한 단계만 조정한 뒤 같은 대상을 다시 테스트하세요. 지나치게 낮추면 패킷 수와 처리 비용이 늘어납니다. 문제의 원인이 DNS나 대상 라우팅이라면 MTU 변경으로 해결되지 않는 경우가 많습니다.

DNS 설정은 도메인이 어떤 주소로 해석될지를 정하며, 잘못된 터널 라우팅을 자동으로 고쳐 주지는 않습니다. DNS 서버가 터널 내부에 있다면 먼저 해당 서버까지 도달할 경로가 있어야 합니다. 그렇지 않으면 도메인은 실패하지만 일부 IP는 연결되는 상황이 생길 수 있습니다. 연결 유지 신호는 필요할 때 NAT 매핑을 유지하는 기능이지 대역폭을 높이는 옵션이 아닙니다. 너무 자주 전송하면 모바일 기기의 무선 모듈이 더 자주 깨어나고, 간격이 너무 길면 한동안 사용하지 않은 뒤 첫 요청에서 경로를 다시 설정하느라 기다릴 수 있습니다. 네트워크 환경과 서버 안내를 기준으로 설정하세요.

WireGuard를 확인할 때는 핸드셰이크, 송수신 카운터, 실제 요청을 나눠 살펴보세요. 핸드셰이크가 있다는 것은 적어도 해당 시점에 상대 신원 확인과 외부 경로가 작동했다는 뜻이지 터널 내부의 대상에 도달할 수 있다는 뜻은 아닙니다. 송신만 늘고 수신은 늘지 않는다면 원격 라우팅, 허용 주소, 반환 경로를 추가로 확인해야 합니다. Wi-Fi에서 셀룰러로 전환한 뒤 잠시 연결이 회복되었다고 해서 곧바로 키 문제라고 단정할 수는 없습니다. 필드 간 관계와 조정 범위는 WireGuard 설정값 안내를 참고하고, 변경 전에는 현재 작동하는 설정을 백업하세요.

06 · Hysteria2의 QUIC 및 대역폭 설정

UDP를 기반으로 하는 연결 구조

Hysteria2는 QUIC을 기반으로 프록시 데이터를 전송합니다. QUIC은 UDP 위에서 보안 핸드셰이크, 연결 관리, 신뢰성 있는 데이터 스트림을 구현하므로 외부 전송이 UDP라는 이유만으로 내부 데이터까지 모두 비신뢰 방식으로 전달되는 것은 아닙니다. 연결과 혼잡 처리를 하나의 전송 구조 안에서 수행하는 것이 설계 특징 중 하나입니다. 패킷 손실이나 지연 변화가 있는 환경에서는 TCP 기반 전송과 다른 동작을 보일 수 있지만, 결과는 네트워크 정책, 서버 대역폭, 구현 설정에 따라 달라집니다. 이름만으로 속도를 보장할 수는 없습니다.

Hysteria2를 사용하려면 본인이 보유한 서버가 실제로 이 프로토콜을 제공해야 합니다. 다른 유형의 주소와 비밀번호를 그대로 옮겨 쓸 수 없으며 이름이 비슷한 프로토콜 세대끼리 호환된다고 가정해서도 안 됩니다. 먼저 Type, 서버 주소, UDP 포트를 확인하고 인증 정보와 TLS 설정을 점검하세요. 일부 배포에는 추가 난독화 설정도 포함될 수 있으며, 서버에서 실제로 사용할 때만 맞춰야 합니다. 해당 필드를 빠뜨리면 정상적인 핸드셰이크 전에 데이터가 폐기되어 명확한 인증 오류 없이 계속 시간 초과가 발생할 수 있습니다.

일반 웹페이지보다 UDP 경로 확인이 중요합니다

현재 Wi-Fi에서 일반 웹페이지가 열린다고 해서 대상 포트로 UDP 통신까지 허용된다고 볼 수는 없습니다. 일부 네트워크는 TCP와 UDP를 다르게 제한하며, 지속적인 UDP 트래픽을 별도로 처리하는 경로도 있습니다. 한 네트워크에서 Hysteria2 연결이 시간 초과되지만 같은 설정이 다른 네트워크에서는 작동한다면 비밀번호를 바로 바꾸기보다 외부 UDP 연결 가능 여부를 먼저 비교하세요. 설정을 바꾸지 않고 같은 항목으로 테스트해 네트워크 변화와 설정 변화를 혼동하지 않도록 해야 실제 원인을 확인할 수 있습니다.

여기서도 TLS 이름과 인증서 검증은 정확해야 합니다. Address는 데이터를 보낼 위치를 정하고 Server Name은 핸드셰이크에서 이름을 표시하고 상대 신원을 확인하는 데 쓰입니다. 서버 인증서가 도메인만 포함한다면 IP로 연결할 때도 해당 이름을 지정해야 할 수 있습니다. 구체적인 값은 기존 설정을 확인하세요. 기기 날짜가 크게 틀렸거나 도메인이 잘못된 접속 지점을 가리키거나 인증서 체인이 불완전하면 핸드셰이크에 실패할 수 있습니다. QUIC이 이런 보안 조건을 자동으로 우회해 주지는 않으며, 검증을 꺼도 다른 설정이 올바르다는 증거가 되지 않습니다.

대역폭 입력은 속도 향상 스위치가 아닙니다

대역폭 관련 필드는 현재 구현 방식, 서버 설정, 실제 네트워크 환경을 함께 고려해야 합니다. 일부 혼잡 제어 방식은 대역폭 정보를 바탕으로 전송 동작을 결정합니다. 사용 가능한 회선보다 훨씬 큰 값을 입력하면 대기열과 패킷 손실, 재전송이 늘어 응답성이 오히려 나빠질 수 있습니다. 구독 메모에 적힌 홍보용 속도를 정확한 설정값으로 간주하지 말고, 셀룰러 환경에서 집 회선의 명목상 대역폭만 기준으로 입력하지도 마세요. 단위도 중요합니다. 초당 비트와 초당 바이트를 혼동하지 말고 업로드와 다운로드 방향을 각 필드 설명에 맞춰 확인하세요.

다운로드는 빠른데 웹페이지를 누른 뒤 응답이 느리다면 DNS가 느린 것이 아니라 혼잡 상태에서 대기열이 너무 길어진 것일 수 있습니다. 대용량 전송을 중단한 뒤 짧은 요청을 다시 테스트해 차이가 사라지는지 확인하고, 기존 서버 안내에 따라 대역폭과 혼잡 설정을 점검하세요. 처리량이 커지면 무선 모듈과 프로세서의 활동이 늘고, 상태가 좋지 않은 경로에서 재전송이 반복되면 배터리 소모도 증가합니다. 순간적인 배터리 변화나 최고 속도 하나만 비교하지 말고 같은 작업을 완료하는 데 걸린 총시간과 총소모량을 비교하세요.

모바일 네트워크 전환 후 QUIC의 연결 식별자와 경로 관리 기능이 있다고 해서 모든 앱 세션이 반드시 유지되는 것은 아닙니다. 연결 복구 여부는 클라이언트 처리, 원격 서버 상태, NAT 매핑, 앱 자체의 시간 제한에 따라 달라집니다. 전환 전후의 연결 결과를 기록하고 아이콘이 계속 연결 상태로 표시되는지만 보지 마세요. 특정 네트워크에서 이 유형만 실패하고 기존의 다른 접속 지점은 작동한다면 비교 근거를 보관하세요. 모든 유형이 실패한다면 QUIC 설정만 계속 살펴보기보다 기본 네트워크, DNS, 전체 라우팅을 먼저 확인하세요.

07 · 설정 필드와 단계별 문제 해결

원본 정보를 보관한 뒤 가져오기 결과 확인

구독 또는 공유 정보를 가져온 뒤에는 ‘가져오기 성공’과 ‘연결 가능’을 별도로 확인해야 합니다. 전자는 클라이언트가 데이터 형식을 인식했다는 뜻일 뿐입니다. 연결하려면 네트워크, 인증, 보안 계층, 전달 기능이 모두 작동해야 합니다. 먼저 Type이 정보 출처와 일치하는지 확인하고 주소, 포트, 주요 인증 정보를 살펴본 다음 전송 확장을 점검하세요. 필드가 빠져 있어도 흔히 쓰는 값으로 바로 채우지 말고 본인이 보유한 설정과 대조하세요. 지원하지 않는 조합은 표시 이름을 바꾸거나 반복해서 가져와도 호환되지 않습니다.

가장 흔한 혼동은 여러 ‘이름’을 같은 항목으로 취급하는 것입니다. 메모는 로컬에서 항목을 구분하기 위한 값이고, Address는 실제 연결 대상, Server Name은 TLS, Host는 애플리케이션 계층 접속 지점, Path 또는 서비스 이름은 특정 전송 백엔드를 가리킬 수 있습니다. 한 접속 지점에서 이 값들이 같을 수도 다를 수도 있습니다. 문제를 기록할 때는 ‘도메인이 맞음’이라고만 적지 말고 각 값의 역할을 따로 적으세요. 서버에서 여러 백엔드를 사용한다면 같은 주소로 TCP 연결이 되더라도 이름이나 경로가 틀려 잘못된 서비스로 연결될 수 있습니다.

실패 범위에 따라 문제 좁히기

항목 하나만 실패한다면 해당 항목에만 있는 주소, 인증 정보, 전송 매개변수를 먼저 확인하세요. 같은 그룹의 항목이 함께 실패한다면 공통 도메인, 인증 정보 출처, 서버 상태를 점검하세요. 한 네트워크에서 모든 항목이 실패한다면 작동이 확인된 다른 네트워크와 비교하세요. 모든 네트워크에서 실패하는 경우 현재 Config, 기기 시간, 시스템 연결 상태도 살펴봐야 합니다. 이런 방식으로 범위를 나누면 테스트를 반복해서 누르는 것보다 효율적으로 문제를 로컬 접속 지점, 공통 설정, 기기 환경 중 어디에서 찾을지 판단할 수 있습니다.

시간 초과는 제한 시간 안에 필요한 결과를 얻지 못했다는 뜻이지, 비밀번호가 틀렸다는 뜻은 아닙니다. 연결 거부는 대상 포트에서 해당 서비스가 리스닝하지 않거나 경로상의 장비가 연결을 처리한 결과일 수 있습니다. 인증서 오류는 TLS 신원 확인을, 인증 오류는 프로토콜 인증 정보를 점검해야 한다는 신호입니다. 구체적인 메시지는 맥락과 함께 해석하고 서로 다른 영문 오류를 모두 같은 유형으로 분류하지 마세요. 기록을 확인할 때는 오류가 발생하기 전의 단계 정보를 보존하되, 다른 사람에게 설명할 때는 유형, 네트워크 조건, 인증 정보를 가린 오류만 공유하세요.

테스트 성공과 실제 사용 성공 구분하기

Connectivity Test 결과는 테스트 방식과 대상에 따라 달라지며 모든 웹사이트, UDP 앱, 규칙이 정상이라고 증명하지는 않습니다. 테스트는 성공했지만 웹 탐색이 안 된다면 실제 도메인의 DNS, 적용된 정책, 대상 응답을 확인하세요. 특정 앱만 실패한다면 다른 도메인에 접속하거나 다른 전송 방식을 사용하는지 살펴보세요. 연결 스위치가 켜져 있어도 시스템 터널 상태를 나타낼 뿐 대상 요청이 성공한다는 뜻은 아닙니다. 설정이 작동하는지 판단하기 전에 연결이 확인된 대상으로 실제 요청을 한 번 이상 보내세요.

DNS 문제를 점검할 때는 의존 관계를 특히 주의해야 합니다. 서버 주소 자체가 도메인이라면 연결을 설정하기 전에 정상적인 이름 해석이 필요합니다. 대상 웹사이트의 이름 해석은 현재 Config의 영향을 받을 수 있습니다. 터널 안에서만 접근할 수 있는 DNS 서버를 지정하면서 연결 시작에 필요한 경로가 없다면 순환 의존성이 생길 수 있습니다. 먼저 서버 도메인이 올바르게 해석되는지 확인한 다음 대상 도메인과 요청 정책을 살펴보세요. DNS 옵션을 한꺼번에 모두 바꾸지 말고 구체적인 설정 방법은 DNS 설정 안내를 참고하세요.

마지막으로 현재 네트워크, 프로토콜 유형, 실제 테스트 대상, 오류 단계, 이번에 변경한 필드 하나를 기록해 최소한의 재테스트 내역을 만드세요. 매번 같은 대상을 테스트해 결과를 확인한 다음 설정을 유지할지 원래대로 돌릴지 결정하세요. 구독 전체를 가져오지 못하는 문제와 단일 접속 지점의 인증 실패는 서로 다른 절차입니다. 전자는 구독 주소의 유효성과 가져오기 결과를 확인해야 하며, 자세한 내용은 구독 가져오기 실패 점검을 참고하세요. 설정 필드를 확인했는데도 특정 요청만 비정상이라면 다음 장에서 규칙과 연결 트리거를 점검하세요.

08 · Global Routing, 규칙, On Demand

프로토콜 연결 후 정책 선택 확인하기

프로토콜은 원격 서버와 연결하는 방식을 정하고 Global Routing은 요청을 어떤 방식으로 처리할지 정합니다. 서로 대신할 수 없습니다. Config는 현재 설정의 규칙에 따라 정책을 선택하고, Proxy는 의미를 확인한 뒤 규칙 변수를 일시적으로 줄이는 데 사용할 수 있으며, Direct는 직접 연결을 뜻합니다. 문제를 해결할 때는 현재 설정 상태를 먼저 기록하고 요청이 실제로 어떤 경로를 탔는지 확인하세요. Direct 상태에서 원격 프로토콜을 테스트하면 잘못된 결론을 내릴 수 있습니다. 테스트가 끝나면 원래 Config로 되돌리세요. 임시 변경을 유지하면 이후 비교와 로컬 네트워크 접속에 영향을 줄 수 있습니다.

규칙은 보통 순서대로 적용되므로 더 구체적인 조건을 적절한 위치에 두고, 앞선 규칙과 일치하지 않는 요청은 FINAL이 처리합니다. DOMAIN-SUFFIX는 도메인 접미사를, IP-CIDR은 주소 범위를, GEOIP는 해당 지역 데이터에 따른 주소 정보를 기준으로 판단합니다. 판단 대상이 서로 다르므로 대상 사이트 이름이 비슷하다는 이유만으로 서로 바꿔 쓸 수 없습니다. PROXY, DIRECT, REJECT는 각각 다른 처리 결과를 나타냅니다. 규칙에서 지정한 정책 이름도 현재 설정에서 올바르게 확인되어야 합니다. 실제 적용 결과는 목록 순서만으로 추측하지 말고 요청 기록을 확인하세요.

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

.conf 예시는 규칙 문법과 순서만 보여 주며 완전한 설정 파일이 아닙니다. example.com은 설명용 도메인이고, 사설 주소 범위의 DIRECT는 직접 연결을 뜻합니다. GEOIP 결과는 해당 지역 데이터에 따라 달라지며, 마지막에는 FINAL이 나머지 요청을 처리합니다. 자신의 Config에 적용하기 전에 기존 정책, DNS, 로컬 네트워크 범위를 확인하세요. 예시를 전체 설정에 그대로 덮어쓰지 마세요. 특히 예시의 지역 규칙이 모든 사용자에게 권장되는 설정이라고 생각하거나 규칙만 바꾸면 잘못된 Password나 TLS 이름 문제가 해결된다고 여겨서는 안 됩니다.

On Demand는 연결을 시작할 시점만 결정합니다

On Demand는 네트워크나 기타 설정된 조건에 따라 시스템 연결 동작을 시작합니다. 각 요청에서 어떤 프로토콜을 사용할지는 결정하지 않습니다. Wi-Fi, Cellular, 도메인 조건은 현재 인터페이스와 규칙이 지원하는 방식에 맞춰 설정해야 합니다. 조건에 따라 연결을 시작할지 결정하는 경우도 있고 이름 해석 환경이 관여하기도 합니다. 조건을 추가하기 전에 수동 연결이 안정적으로 작동하는지 먼저 확인하세요. 수동 연결 자체가 실패한다면 자동 시작 기능은 같은 문제를 반복하고 고장 원인을 더 파악하기 어렵게 만들 수 있습니다.

Wi-Fi 조건을 설정할 때는 SSID의 실제 문자열을 확인하고 이름이 비슷하지만 다른 네트워크와 혼동하지 않도록 주의하세요. 셀룰러 조건은 Wi-Fi에서 전환될 때와 다시 Wi-Fi로 돌아올 때의 동작을 각각 확인해야 합니다. 조건이 여러 개라면 우선순위와 기본 동작을 점검하세요. 범위가 넓은 조건이 먼저 적용되어 뒤의 구체적인 조건이 실행되지 않을 수 있습니다. 수동으로 끈 뒤 연결이 다시 시작됐다면 스위치가 고장 난 것이 아니라 조건이 다시 충족된 것일 수 있습니다. 시스템 연결 상태를 판단하기 전에 On Demand 규칙부터 확인하세요.

이름 순위가 아니라 실제 사용 상황으로 확인하기

일상적인 웹 탐색에서는 첫 응답, 안정적인 이름 해석, 유휴 상태 후 복구를 확인하세요. 지속 전송은 실제 처리량, 대기열, 재전송을 살펴봐야 합니다. UDP에 의존하는 앱은 종단 간 전달을 먼저 확인하고, 터널 내부 리소스 접속에서는 WireGuard 주소와 라우팅이 더 중요합니다. 호환되는 접속 지점이 여러 개라면 이런 목적별로 테스트하는 편이 특정 프로토콜이 ‘전반적으로 더 빠르다’고 단정하는 것보다 유용합니다. 같은 프로토콜을 사용해도 서버별 차이가 프로토콜 이름 간 차이보다 클 수 있으므로 비교할 때 통제할 수 없는 변수도 명확히 하세요.

배터리 테스트는 실제 사용 작업에 맞춰야 합니다. 기존 설정 두 가지로 비슷한 데이터 양과 사용 시간을 맞추고, 전면에서 안정적으로 사용하는 상태와 유휴 상태를 각각 관찰하세요. 백그라운드 동기화, 신호 강도, 화면 사용 시간도 결과에 영향을 주므로 함께 기록해야 합니다. 유휴 상태에서 소모가 뚜렷하게 늘면 연결 실패 후 반복 재시도, 지나치게 잦은 연결 유지 신호, On Demand 조건의 반복 전환을 확인하세요. 지속 전송 중에만 늘어난다면 처리량과 프로세서 부하를 함께 살펴보세요. 한 번의 시스템 배터리 통계로 고정적인 프로토콜별 소모 순위를 결론 내리지 마세요.

마지막으로 세 가지를 확인할 수 있어야 합니다. 항목의 Type이 서버 설정과 일치하는지, 실제 요청이 예상한 정책을 적용받는지, 네트워크 전환 후 연결 동작이 On Demand 설정에 맞는지 확인하세요. 완료되면 작동하는 설정을 저장한 뒤 자동화 조건을 하나씩 추가하세요. 필요에 따라 연결하는 구체적인 상황은 Wi-Fi 및 Cellular 트리거 규칙 안내를 참고하세요. 추가, 연결, 확인 과정을 처음부터 다시 살펴보려면 사용 안내로 돌아가세요. 이 프로토콜 가이드는 차이를 설명하고 문제 범위를 찾기 위한 자료이며, 설정값은 항상 본인이 보유한 서버 정보를 기준으로 해야 합니다.