Shadowrocket 프로토콜 안내

프로토콜, 전송, 라우팅의 역할

먼저 설정이 어느 계층을 가리키는지 확인

프로토콜을 선택하기 전에 연결을 서로 독립적인 요소로 나눠 살펴보세요. 서버 주소는 연결 대상, 포트는 접속할 대기 지점, 프로토콜은 요청과 인증을 처리하는 방식, 전송 방식은 데이터를 전달하는 수단, 라우팅은 어떤 요청이 해당 연결을 사용할지를 결정합니다. 이 계층들을 혼동하면 주소와 비밀번호가 맞는데도 연결되지 않는 상황이 생길 수 있습니다. 노드 이름에 포함된 프로토콜 약칭 하나가 아니라 전체 설정을 기준으로 확인해야 합니다.

예를 들어 VLESS를 선택했더라도 서버에서 요구하는 전송 방식, TLS 조건, 추가 항목은 다를 수 있습니다. 유형이 같다는 것은 같은 계열의 요청 형식을 사용한다는 뜻일 뿐, 세부 설정까지 일치한다는 의미는 아닙니다. 구독을 가져오면 더 많은 항목이 보존되는 경우가 많지만, 가져온 결과도 확인해야 합니다. 클라이언트에서 인식하지 못하는 항목이 있으면 먼저 앱에서 실제로 선택할 수 있는 옵션을 확인한 뒤 기존 서버 관리자에게 문의하세요. 비슷해 보이는 이름의 항목으로 임의 변경하지 마세요.

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

프로토콜 설계는 핸드셰이크 횟수와 데이터 캡슐화, 재전송 방식에 영향을 주지만 실제 속도는 서버 부하, 왕복 시간, 패킷 손실, 무선 신호, 접속 대상에도 좌우됩니다. 짧은 웹 요청은 핸드셰이크와 이름 확인에 따른 지연이 두드러지고, 대용량 전송은 혼잡 제어와 가용 대역폭의 영향을 더 많이 받습니다. 한 번 측정한 지연 시간은 특정 조건에서의 응답만 보여줄 뿐, 실제 접속 테스트를 대신하거나 하루 종일의 처리량을 예측해 주지 않습니다. 비교할 때는 기기, 네트워크, 대상, 테스트 시간을 최대한 동일하게 맞추세요.

iPhone과 iPad의 배터리 소모는 암호화 알고리즘만으로 결정되지 않습니다. 셀룰러 신호가 약하거나 연결이 자주 재설정되는 경우, 백그라운드에서 데이터를 계속 전송하는 경우, Keepalive 간격이 지나치게 짧은 경우, 상세 로그를 오래 켜 둔 경우에도 배터리 사용량이 늘 수 있습니다. 안정적인 네트워크에서는 정상인 설정이 다른 네트워크에서 계속 재연결된다면 프로토콜 탓으로 단정하기 전에 연결 상태와 Keepalive 조건을 확인하세요. 배터리 설정의 사용량 통계에는 관찰 시간 동안 다른 앱의 활동도 반영됩니다.

프로토콜 안내는 서버 설명을 대신하지 않습니다

이 문서에서는 각 항목의 역할을 설명하지만, 역할만으로 유효한 값을 추측할 수는 없습니다. 주소는 사용자가 이미 보유한 정보에서 확인하고, 인증 정보는 서버 설정과 일치해야 하며, 전송 확장 기능은 양쪽에서 모두 지원해야 합니다. 변경하기 전에 기존 설정을 기록하고 테스트용 복사본을 따로 두는 것이 좋습니다. 한 번에 하나씩만 바꿔야 변경 사항과 결과의 관계를 파악할 수 있습니다. 프로토콜, DNS, 규칙을 동시에 변경하면 연결이 복구되더라도 원인을 알아내기 어렵습니다.

시스템에서 VPN 구성 추가를 허용하는 것은 클라이언트가 로컬 네트워크 처리 경로를 만들도록 승인하는 절차이며, 원격 서버 정보를 대신 입력해 주는 것은 아닙니다. 시스템에 연결됨으로 표시되어도 원격 인증, DNS, 대상 접속이 모두 성공했다는 뜻은 아닙니다. 승인 단계에서 진행되지 않으면 VPN 구성 안내를 먼저 확인하세요. 연결은 됐지만 접속할 수 없다면 아래 순서에 따라 문제를 나눠 살펴보고, 시스템 승인 문제를 프로토콜 선택 문제로 오인하지 마세요.

Shadowsocks: 간결한 구조와 암호화 설정

암호화된 트래픽 전달에 중점을 둔 설계

Shadowsocks는 비교적 간결한 프로토콜 구조로 앱 트래픽을 전달하고 클라이언트와 서버 사이의 데이터를 암호화하고 인증하도록 설계되었습니다. 원격 네트워크 전체를 기기로 가져오는 완전한 네트워크 계층 터널은 아닙니다. Shadowrocket에서 보이는 시스템 VPN 연결과 원격 서버가 사용하는 Shadowsocks는 서로 다른 계층입니다. 전자는 기기 트래픽을 연결하고 후자는 클라이언트와 서버 사이의 데이터를 주고받습니다. 이 차이를 이해하면 로컬 라우팅과 원격 프로토콜을 구분하는 데 도움이 됩니다.

구조가 간결하다고 해서 모든 설정이 같은 것은 아닙니다. 암호화 방식에 따라 데이터 형식과 키 요구 사항이 달라지고, 추가 전송 확장 기능도 실제 연결 방식을 바꿀 수 있습니다. 기본 설정과 플러그인 또는 기타 확장 기능을 사용하는 설정은 서버 주소와 비밀번호만 복사해 서로 바꿔 쓸 수 없습니다. 직접 추가할 때는 현재 앱이 서버에서 요구하는 조합을 지원하는지 항목별로 확인하세요. 구독에서 가져온 정보라면 먼저 전체 설정을 그대로 보존하고, 낯선 항목을 임의로 삭제하지 마세요.

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

기본 항목은 서버 주소, 포트, 비밀번호, 암호화 방식입니다. 암호화 방식은 길수록 안전한 임의 선택 항목이 아니라 양쪽에서 일치해야 하는 프로토콜 설정입니다. 서버가 한 방식을 사용하는데 클라이언트에서 다른 방식으로 바꾸면 비밀번호가 같아도 정상적으로 복호화할 수 없습니다. 최신 방식 중에는 특정 길이와 인코딩 형식의 키를 요구하는 것도 있으므로, 평소 사용하는 임의의 문자열을 같은 비밀번호라고 간주할 수 없습니다. 원래의 대소문자와 기호, 인코딩을 그대로 유지하고 공백을 임의로 추가하거나 끝 문자를 삭제하지 마세요.

구독을 업데이트한 뒤 갑자기 연결에 실패하면 먼저 유형과 암호화 방식이 바뀌었는지 확인한 다음, 기존 설정이 업데이트로 덮어써졌는지 살펴보세요. 비밀번호를 복사할 때 메신저의 줄바꿈, 서식에 따른 공백, 선택 범위 누락으로 값이 달라질 수 있습니다. 주소와 포트에 접속할 수 있다는 사실은 네트워크 접속 지점이 존재한다는 뜻일 뿐 비밀번호가 맞다는 뜻은 아닙니다. 연결 직후 끊기는 경우도 있고 계속 대기하는 경우도 있습니다. 따라서 화면에 표시된 단일 시간 초과 메시지보다 오류가 발생한 단계가 문제 분석에 더 유용합니다.

TCP와 UDP를 각각 확인

일반적인 웹 접속으로 TCP 사용 여부를 일부 확인할 수 있지만 UDP까지 사용할 수 있다는 뜻은 아닙니다. 실시간 음성·영상, 일부 DNS 요청 및 다른 앱은 UDP에 의존할 수 있으며, 전달 가능 여부는 서버 기능, 클라이언트 설정, 네트워크 경로에 따라 달라집니다. 웹은 정상인데 실시간 앱이 작동하지 않으면 해당 경로를 따로 확인하고 웹 속도 측정만 반복하지 마세요. 반대로 UDP를 사용하는 앱 하나가 정상이라고 해서 모든 도메인 확인과 TCP 요청이 예상대로 처리된다는 보장도 없습니다.

기기에서 Shadowsocks 설정을 비교할 때는 대용량 파일을 한 번 전송한 속도보다 연결이 계속 안정적인지, 짧은 요청이 자주 대기하는지, 네트워크를 바꾼 뒤 복구되는지를 우선 확인하세요. 기기의 하드웨어 암호화 가속, 실제 처리량, 데이터 양이 함께 처리 부담에 영향을 줍니다. 안정적이고 설정이 명확하며 검증된 기존 구성을 기준으로 삼는 편이, 확인되지 않은 알고리즘 이름을 좇는 것보다 낫습니다. 성능 문제는 반복 테스트로 확인하세요.

테스트에는 응답이 있지만 웹 페이지가 열리지 않는다면 주소 확인, 인증, UDP, 규칙 적용, 대상 사이트 순서로 살펴보세요. 일부 도메인만 문제가 있다면 DNS 문제 해결 안내도 확인할 수 있습니다. 이름 확인 문제를 해결하려고 암호화 방식을 계속 바꾸거나, 특정 검사를 건너뛰는 것을 장기적인 해결책으로 삼지 마세요. 항목의 출처, 양쪽의 지원 여부, 오류 단계가 확인된 뒤에야 변경 이유를 판단할 수 있습니다.

VMess와 VLESS: 인증과 전송을 따로 확인

비슷한 항목이 있어도 같은 프로토콜은 아닙니다

VMess에는 사용자 식별, 요청 구성, 데이터 보호와 관련된 메커니즘이 포함됩니다. VLESS는 요청과 인증 구조를 더 간결하게 구성하며 기본 프로토콜 자체로는 같은 방식의 데이터 암호화를 제공하지 않아 적절한 보안 전송과 함께 사용하는 경우가 많습니다. 두 프로토콜 모두 UUID가 포함되거나 TLS 또는 WebSocket을 사용할 수 있지만, 공통점이 있다고 유형을 서로 바꿔 쓸 수 있는 것은 아닙니다. 서버가 VMess를 제공하는데 클라이언트에서 UUID를 그대로 둔 채 VLESS를 선택해도 프로토콜이 일치하지 않습니다.

두 프로토콜의 차이를 이해할 때는 각 기능이 어디에 배치되는지 살펴보세요. 어떤 프로토콜은 더 많은 기능을 자체적으로 처리하고, 어떤 프로토콜은 데이터 보호를 외부 보안 채널에 맡깁니다. 항목이 적다고 자동으로 더 빠른 것도 아니고, 많다고 더 신뢰할 수 있는 것도 아닙니다. 실제 연결에는 전송 계층 수, 핸드셰이크 경로, 서버 구현, 네트워크 조건도 영향을 줍니다. 먼저 기존 서버가 지원하는 구성을 확인하고 사용 가능한 조합을 비교하세요. 특정 이름을 먼저 고른 뒤 모든 항목을 거기에 맞추려 해서는 안 됩니다.

UUID 외에 전송 설정도 확인해야 합니다

직접 추가할 때는 유형, 주소, 포트, UUID를 먼저 확인하고 전송 방식과 보안 설정을 살펴보세요. UUID는 사용자 식별자이지 서버 주소가 아니며, 비밀번호 방식 프로토콜의 인증 항목을 대신할 수도 없습니다. 일부 VMess 설정에는 추가 인증 또는 암호화 옵션이 포함될 수 있으므로 원래 설정을 기준으로 확인하고, 오래된 안내에 맞추려고 임의로 값을 채우지 마세요. 기기 시간이 크게 어긋나면 인증이나 인증서 확인에 영향을 줄 수 있으니 시스템의 날짜와 시간이 정상인지 확인하세요.

WebSocket을 사용하는 경우 경로와 요청 헤더의 Host는 서로 별개의 항목입니다. 경로는 보통 맨 앞의 슬래시와 대소문자를 그대로 유지해야 합니다. 도메인을 경로 칸에 입력하거나 웹 주소 전체를 Host로 입력하지 마세요. TLS 사용 시 SNI는 서버 이름 협상과 인증서 확인에 사용됩니다. 배포 방식에 따라 연결 주소, Host, SNI가 서로 다를 수 있지만 기존 설정에 그 차이가 명시되어 있어야 합니다. 겉보기에 통일하려고 세 값을 같은 값으로 바꿔서는 안 됩니다.

오류 발생 단계를 구체적으로 파악

접속 지점 시간 초과는 먼저 주소, 포트 또는 경로에 도달할 수 있는지 확인해야 합니다. TLS 오류가 발생하면 이름, 인증서 체인, 기기 시간을 확인하세요. 핸드셰이크 직후 연결이 종료된다면 사용자 식별 정보와 프로토콜 항목을 추가로 점검해야 합니다. 서버 앞에 중계 접속 지점이 있다면 접속 지점과 백엔드 사이에서 오류가 발생했을 수도 있습니다. 이때 UUID를 계속 바꿔도 접속 경로 불일치는 해결되지 않습니다. 테스트 시간, 네트워크 유형, 오류 요약을 기록하면 여러 항목을 연달아 바꾸는 것보다 원인을 찾기 쉽습니다.

iOS에서 여러 계층을 거치는 전송은 첫 요청의 대기 시간을 늘릴 수도 있고 연결 재사용으로 이후 핸드셰이크를 줄일 수도 있습니다. 두 가지 영향을 실제 사용 환경에서 함께 살펴봐야 합니다. 연결 재사용을 어디서나 통하는 속도 향상 스위치로 여기지 마세요. 여러 요청이 같은 하위 연결을 공유하면 패킷 손실이나 연결 장애가 여러 요청에 동시에 영향을 줄 수 있습니다. 현재 설정에서 관련 옵션을 제공한다면 먼저 서버가 지원하는지 확인한 뒤 동일한 웹 페이지와 지속 전송으로 각각 검증하세요. 한 번의 속도 측정만으로 판단하지 마세요.

기존 구독을 정상적으로 가져올 수 있다면 가져온 설정을 기준으로 삼고 항목의 의미를 하나씩 확인하세요. 낯선 스트림 매개변수, 보안 확장, 전송 유형이 있으면 생략한 채 연결을 시도하거나 클라이언트가 지원한다고 가정하지 마세요. 원본 정보를 보존하고 앱에서 실제로 선택할 수 있는 항목을 확인한 다음 서버 관리자에게 문의할지 판단하세요. 프로토콜 확인을 마친 뒤에도 시작하기에 따라 Global Routing과 실제 요청을 검증해야 합니다. 인증 성공이 올바른 트래픽 분배를 뜻하는 것은 아닙니다.

Trojan: TLS 서버 식별과 비밀번호 인증

보안 채널과 프록시 요청은 역할이 다릅니다

Trojan의 기본 설계는 프록시 요청을 TLS 연결에 실어 보내고, 검증된 보안 채널로 전송을 보호한 뒤 프로토콜의 인증 정보로 사용자를 확인합니다. 두 단계로 나눠 이해할 수 있습니다. 먼저 서버와 신뢰할 수 있는 TLS 연결을 맺고, 다음으로 서버가 프록시 요청과 사용자 정보를 확인합니다. 첫 단계가 성공해도 두 번째 단계까지 성공한 것은 아닙니다. 따라서 인증서가 정상인지와 비밀번호가 맞는지는 별도로 확인해야 합니다. 두 항목을 하나의 스위치처럼 취급하면 문제 해결 방향을 잡기 어렵습니다.

서버 주소는 도메인일 수도 있고 기존 배포 방식에 따라 명시된 다른 접속 지점일 수도 있지만, TLS 확인에 사용되는 이름은 올바르게 설정해야 합니다. SNI는 클라이언트가 요청하는 이름을 서버에 알리고, 인증서는 해당 이름의 신원을 증명해야 합니다. 연결 주소와 인증서 이름이 다르면 기존 설정에 따라 해당 항목을 입력하세요. 문제를 피하려고 SNI를 삭제하지 마세요. 주소는 접속 지점을 찾고 이름은 신원을 확인하므로 서로 역할이 다르며 대체할 수 없습니다.

인증서는 만료 여부만 확인해서는 안 됩니다

인증서 문제는 이름 불일치, 불완전한 인증서 체인, 잘못된 기기 시간, 서버 배포 오류 때문에 발생할 수도 있습니다. 유효 기간만 확인해서는 전체 검증이 정상인지 판단할 수 없습니다. 관련 오류가 나타나면 기기 시간을 확인하고, 서버 이름이 설정 요구 사항과 일치하는지 살펴본 뒤 서버 관리자에게 인증서 배포를 확인해 달라고 요청하세요. 인증서 확인을 끄면 신뢰 경계가 달라지고 서버의 신원을 확인할 수 없게 됩니다. 비밀번호, 라우팅, 도메인 확인 문제의 해결책으로 사용해서도 안 됩니다.

비밀번호는 원래 문자를 그대로 유지하고 복사할 때 줄바꿈이나 공백이 들어가지 않았는지 특히 주의하세요. 표시 이름은 직접 바꿀 수 있지만 이름을 바꿨다고 비밀번호, 포트, 프로토콜 유형을 추측해 조정해서는 안 됩니다. TLS 연결은 성공했지만 인증이 실패하면 비밀번호와 서버가 실제로 제공하는 프로토콜 유형을 확인하세요. 기본 Trojan과 추가 전송 확장을 사용하는 설정은 메모 하나만 다른 것이 아닙니다. 확장 기능을 사용하는 경우 양쪽이 모두 지원해야 하며 해당 경로나 기타 설정도 입력해야 합니다.

핸드셰이크 비용은 연결 재사용과 함께 살펴보세요

처음 연결할 때는 보통 네트워크 연결과 TLS 핸드셰이크가 필요하며, 거리가 멀거나 패킷 손실이 많거나 네트워크가 바뀌면 대기 시간이 늘어날 수 있습니다. 이후 요청에서 하위 연결을 재사용하는지는 실제 구현과 설정에 따라 달라지므로 프로토콜 이름만으로 판단할 수 없습니다. 처음 웹 페이지를 열 때, 연속해서 방문할 때, 데이터를 계속 전송할 때를 나눠 비교하세요. 처음만 느리고 이후에는 정상이라면 도메인 확인과 핸드셰이크를 우선 살펴보세요. 지속 전송도 계속 끊긴다면 경로 품질과 서버 부하를 추가로 확인해야 합니다.

iPhone의 배터리 소모는 TLS 암호화만으로 결정되지 않습니다. 앱이 짧은 연결을 계속 만들거나 연결에 실패한 뒤 재시도하면 무선 모듈과 시스템의 네트워크 처리 시간이 늘어날 수 있습니다. 같은 네트워크와 비슷한 데이터 양으로 비교하고 화면이 켜진 시간, 백그라운드 대기, 실제 전송을 구분하세요. 동영상을 오래 재생한 뒤의 배터리 변화를 몇 분간 정적 웹 페이지를 본 결과와 바로 비교하지 마세요. 사용량이 다르면 유효한 비교가 아닙니다.

웹 페이지에 인증서 경고가 표시되면 경고가 어느 계층에서 발생했는지 확인해야 합니다. 클라이언트가 서버에 연결할 때 TLS 실패를 보고한 것인지, 브라우저가 대상 웹사이트에 접속하다 인증서 문제를 표시한 것인지 구분하세요. 전자는 현재 연결 설정을 확인해야 하고 후자는 대상 사이트, 기기 시간 또는 다른 네트워크 설정과 관련될 수 있습니다. ‘인증서’라는 문구만 보고 Trojan 비밀번호를 바꾸지 마세요. 오류가 나타난 위치와 시간을 기록하면 두 문제를 구분하기 쉽습니다.

기존 서버가 완전하고 검증 가능한 TLS 설정을 제공하고 인증 항목이 명확하며 실제 접속도 안정적이라면 Trojan을 계속 사용할 수 있습니다. TLS를 사용한다는 이유만으로 다른 방식보다 자동으로 우수해지는 것도 아니고 모든 네트워크 경로에서 정상 작동하는 것도 아닙니다. 기존 설정이 정상이다가 최근 이름 또는 인증서 오류가 발생했다면 프로토콜을 바로 바꾸기보다 서버 배포 변경을 먼저 확인하세요. 구매 및 앱 업데이트 문제는 별도로 문제 해결에서 확인할 수 있습니다.

HTTP와 SOCKS5: 범용 프록시의 범위

두 가지 범용 인터페이스는 서로 다른 문제를 해결합니다

HTTP 프록시는 HTTP 요청 전달을 중심으로 만들어졌으며, 자주 사용되는 CONNECT 방식은 지정한 대상까지 바이트 스트림을 연결할 수 있습니다. SOCKS5는 대상 주소, 연결 명령, 선택적 인증 절차를 정의하는 더 범용적인 프록시 협상 프로토콜이며 상위 계층의 콘텐츠가 웹이어야 한다고 제한하지 않습니다. 두 프로토콜 모두 기존 네트워크 환경에서 표준 인터페이스로 사용되지만, ‘범용’이라는 말은 인터페이스의 용도를 뜻할 뿐 모든 구현이 모든 명령과 인증 방식, 앱 트래픽을 지원한다는 의미는 아닙니다.

HTTP 프록시를 통한 대상 웹사이트의 HTTPS와 클라이언트에서 프록시 서버까지의 연결 암호화 여부는 서로 다른 문제입니다. CONNECT로 HTTPS 웹사이트에 접속하면 웹사이트 세션 자체의 TLS 보호를 유지할 수 있지만 프록시 연결은 실제 유형에 따라 따로 확인해야 합니다. SOCKS5 기본 프로토콜도 자동으로 데이터를 암호화하지 않으며 사용자 이름과 비밀번호 인증은 암호화된 채널과 다릅니다. 따라서 웹 주소에 보안 표시가 있다는 이유만으로 프록시 구간의 모든 메타데이터도 똑같이 보호된다고 볼 수 없습니다.

인증 방식과 대상 도메인 확인을 따로 살펴보세요

기존 HTTP 또는 SOCKS5 정보를 추가할 때는 서버 주소와 포트, 인증 필요 여부, 현재 앱에서 지원하는 인증 방식을 먼저 확인하세요. 접속 지점에 따라 계정과 비밀번호가 필요하지 않을 수도 있고 둘 다 입력해야 할 수도 있으므로, 장기간 빈칸으로 두고 시험해서는 안 됩니다. 기존 안내에 TLS로 보호되는 프록시 접속 지점이라고 명시되어 있다면 클라이언트에서 선택한 유형과 보안 옵션이 일치하는지도 확인하세요. 일반 HTTP 항목을 모든 보안 프록시 방식의 통칭처럼 취급하지 마세요.

도메인을 어느 쪽에서 확인하는지에 따라 접속 결과와 오류 분석이 달라질 수 있습니다. SOCKS5는 도메인 대상 지정이 가능하지만 실제 요청에서 도메인 확인을 원격으로 처리하는지는 클라이언트의 확인 방식과 라우팅 처리에 따라 달라집니다. HTTP CONNECT의 대상도 호스트 이름 또는 주소로 지정할 수 있습니다. 원격에서는 도메인을 확인할 수 있는데 기기 로컬 확인은 실패한다면 확인 위치를 바꿔 결과를 비교할 수 있습니다. 다만 먼저 현재 설정을 이해한 뒤 검증하세요. 프로토콜이 도메인을 지원한다는 이유만으로 모든 요청이 원격에서 확인된다고 단정하지 마세요.

웹 접속 성공이 전체 서비스의 정상 작동을 뜻하지는 않습니다

일반 HTTP CONNECT는 보통 TCP를 대상으로 하며, 이것만으로 UDP 앱이 작동한다고 볼 수 없습니다. SOCKS5에는 UDP 관련 기능이 정의되어 있지만 실제 배포 환경에서는 TCP만 열려 있거나 UDP 응답 경로가 네트워크 조건에 제한될 수 있습니다. 채팅 메시지는 전송되는데 통화가 실패한다면 해당 서비스가 사용하는 전송 방식을 따로 확인하세요. 웹 대상만 계속 바꿔 보는 것은 웹 접속 여부만 확인할 뿐, 부족한 UDP 기능을 추가하거나 앱의 모든 요청이 같은 경로를 거친다는 것을 증명하지 못합니다.

두 프로토콜의 처리 구조는 비교적 단순할 수 있지만 배터리 소모와 속도는 암호화 계층, 연결 유지 시간, 네트워크 품질, 서버 구현에 따라 달라집니다. 프로토콜 항목이 적다고 셀룰러 네트워크 활동이 자동으로 줄어들지는 않습니다. 인증이 계속 실패하거나 접속 지점이 자주 끊기면 오히려 사용 경험이 나빠질 수 있습니다. iOS에서는 ‘표준 프로토콜’이라는 이유만으로 성능을 판단하지 말고 연결 재시도, 대상 접속, 백그라운드 동작을 확인하세요.

사용자가 보유한 업무 또는 테스트 환경에서 이러한 접속 지점을 명확히 제공하는 경우 해당 기능 범위에 맞게 사용할 수 있습니다. 민감한 데이터를 전송해야 한다면 대상 앱의 자체 암호화와 프록시 경로의 보호 여부도 확인하세요. 인증이 거부되면 계정 항목을 먼저 확인하고, 연결은 됐지만 대상에 접속할 수 없다면 도메인 확인과 원격 접근 권한을 살펴보세요. 권한 문제를 해결하려고 임의로 프로토콜 유형을 바꾸거나 도움을 요청하면서 계정과 비밀번호를 공개하지 마세요. 관련 설정 방법은 처음 추가하고 연결하기를 참고하세요.

WireGuard: 네트워크 계층 터널과 키의 관계

요청 전달 대신 주소와 피어를 기준으로 이해하기

WireGuard는 암호화된 네트워크 계층 터널을 위해 설계되었으며, 고정된 최신 암호화 조합과 공개 키 기반 신원 확인을 사용하고 프로토콜 옵션과 핸드셰이크를 가능한 한 간결하게 구성합니다. 특정 대상 연결을 주로 설명하는 프록시 프로토콜과 달리 로컬 터널 주소, 피어 신원, 엔드포인트, 도달 가능한 네트워크 범위의 관계를 중점적으로 다룹니다. Shadowrocket에서 사용할 때도 클라이언트가 기기 트래픽과 해당 연결의 관계를 구성해야 합니다. 다른 환경의 전체 라우팅 동작이 여기에서도 그대로 적용된다고 가정하지 마세요.

설정 항목이 많지 않아 보여도 각각 분명한 역할을 맡고 있습니다. 엔드포인트 주소는 실제 네트워크에서 피어를 찾는 데, 터널 주소는 터널 안에서 로컬 신원을 나타내는 데, 공개 키는 피어를 식별하는 데, 개인 키는 로컬 신원을 증명하는 데 사용됩니다. 엔드포인트 주소와 터널 주소는 대개 서로 다른 종류의 주소이므로 바꿔 입력할 수 없습니다. 서버의 공인 주소를 로컬 터널 주소 칸에 입력하면 포트가 맞더라도 주소와 라우팅 관계에 문제가 생깁니다.

키는 어느 쪽에 속하는지 구분해야 합니다

로컬 개인 키는 비밀로 유지해야 하며, 피어 공개 키는 연결 대상을 확인하는 데 사용됩니다. 두 키를 서로 바꿔 넣을 수 있는 항목으로 취급해서는 안 됩니다. 설정에 사전 공유 키가 포함되어 있다면 추가 키 자료이므로 양쪽의 값이 일치해야 하며 피어 공개 키로 대체할 수 없습니다. 가져온 설정에서 핸드셰이크에 실패하면 먼저 키의 소유 측과 엔드포인트를 확인한 뒤 네트워크 연결 가능성을 살펴보세요. 로컬 키를 새로 만들면 신원이 바뀝니다. 서버가 기존 공개 키만 허용한다면 클라이언트에서 단독으로 키를 바꿔도 원래 연결을 복구할 수 없습니다.

WireGuard에서 Allowed IPs는 피어가 담당하는 주소 범위와 암호화 라우팅 관계에 관여합니다. 단순한 메모도 아니고 기기에서 최종 적용되는 모든 트래픽 분배 규칙을 뜻하지도 않습니다. Shadowrocket의 Global Routing과 Config도 트래픽이 선택한 연결로 전달되는 방식에 영향을 줍니다. 터널 핸드셰이크는 정상인데 일부 주소에 접속할 수 없다면 터널 주소 범위, 원격 전달 조건, 클라이언트 라우팅을 함께 확인하세요. 마지막 규칙 하나만 보고 원격 접속이 반드시 가능하다고 단정하지 마세요.

핸드셰이크, MTU, Keepalive를 각각 확인

WireGuard는 UDP를 사용하므로 일반 웹 페이지에 접속할 수 있다고 해서 엔드포인트가 필요한 UDP 경로까지 열려 있다는 뜻은 아닙니다. 핸드셰이크가 계속 실패하면 먼저 엔드포인트 도메인, 포트, 키, 네트워크 경로 조건을 확인하세요. 핸드셰이크는 성공하고 적은 양의 데이터는 전달되지만 큰 페이지나 업로드가 멈춘다면 MTU를 살펴볼 수 있습니다. 터널 캡슐화에는 추가 공간이 필요합니다. 경로의 패킷 크기 제한을 제대로 처리하지 못하면 일부 요청은 성공하지만 큰 전송이 멈추는 현상이 생길 수 있습니다.

다른 사람의 기기에서 사용한 MTU 값을 그대로 가져오지 마세요. 먼저 현재 값을 기록하고 통제된 조건에서 조금씩 조정해 웹 페이지, 업로드, 지속 전송이 함께 나아지는지 확인하세요. MTU를 낮추면 패킷 분할 문제를 피할 수 있지만 같은 데이터 양을 보내는 데 더 많은 패킷이 필요해지므로 낮을수록 좋은 것은 아닙니다. 패킷 크기와 관련된 증상이 있고 조정 후 반복적으로 개선될 때만 변경을 유지하세요. 사용자 신원 확인 문제는 MTU로 해결할 수 없습니다.

Persistent Keepalive 같은 Keepalive 설정은 일부 네트워크 장비의 매핑을 유지하는 데 사용되지만, 전송 간격이 백그라운드 네트워크 활동에 영향을 줍니다. 기존 환경에 실제로 필요할 때만 설정하고 ‘더 안정적’이라는 이유만으로 짧은 간격을 일괄 적용하지 마세요. 셀룰러와 Wi-Fi를 전환한 뒤 피어가 새 네트워크 위치를 제때 인식하는지도 실제로 확인해야 합니다. iPhone에서는 계속되는 Keepalive, 약한 신호, 잦은 네트워크 전환이 프로토콜 연산보다 배터리에 더 크게 영향을 줄 수 있습니다.

기존 피어 설정이 완전하고 서로 일치하며 접속할 주소 범위를 알고 있을 때 사용할 수 있습니다. 핸드셰이크부터 터널 내부 주소, 도메인 확인, 실제 서비스 순으로 검증하세요. 핸드셰이크 한 번의 성공을 전체 설정 완료로 보지 마세요. 주소로는 접속되지만 도메인 확인이 실패하면 DNS를 살펴보세요. 특정 네트워크 범위만 실패하면 라우팅과 원격 전달을 확인하고, 기기가 잠자기 모드에서 깨어난 뒤 문제가 생기면 매핑과 Keepalive를 살펴보세요. 이런 순서로 나눠 확인하면 키와 라우팅을 동시에 바꾸는 것보다 결론을 얻기 쉽습니다.

Hysteria2: QUIC, 대역폭 설정, 네트워크 경로

UDP 기반 전송의 고려 사항

Hysteria2는 QUIC 기반으로 전송을 구성하고 보안 핸드셰이크와 다중 스트림 기능을 활용하며 지연 시간이 길거나 패킷 손실이 있는 네트워크 조건을 고려한 전송 방식을 제공합니다. 모든 네트워크에서 같은 속도를 내기 위한 것이 아니라 특정 경로에서 기존 TCP 전송과 다른 제어 방식을 사용하는 데 목적이 있습니다. QUIC은 UDP를 사용하므로 접속 지점과 중간 네트워크가 UDP를 처리하는 방식에 따라 연결 가능 여부가 달라집니다. 일반 웹 접속이 가능하더라도 이 경로가 정상이라는 증거는 아닙니다.

다중 스트림을 이해하려면 각 스트림의 전송 독립성과 공유 자원을 구분해야 합니다. 한 스트림의 데이터 대기가 단일 순서 바이트 스트림처럼 모든 다른 스트림의 전달을 막지는 않을 수 있지만, 여러 스트림은 여전히 같은 네트워크 경로와 혼잡 제어, 가용 대역폭을 공유합니다. 무선 신호가 나빠지거나 접속 지점이 제한되면 다중 스트림이 용량을 늘려 주지는 않습니다. 여러 요청이 함께 느려지면 대상 웹사이트마다 문제가 생겼다고 보기보다 전체 경로를 먼저 살펴보세요.

인증, TLS, 추가 항목을 각각 확인

기본 확인 순서는 프로토콜 유형, 서버 주소, 포트, 인증 정보, TLS 이름입니다. Hysteria2는 이름이 비슷한 다른 프로토콜 형식과 서로 바꿔 쓸 수 없으므로 클라이언트 유형이 기존 서버와 일치해야 합니다. 인증 항목은 원래 형식을 그대로 유지하고 SNI와 인증서 요구 사항도 각각 확인하세요. 기존 설정에 추가 처리 옵션이 포함되어 있더라도 현재 앱에 해당 기능이 있고 서버에서도 같은 설정을 사용할 때만 입력하세요. 항목 이름만 보고 값을 추측하지 마세요.

대역폭 관련 항목을 속도 측정 결과로 오해하기 쉽습니다. 해당 항목은 적용 가능한 혼잡 제어 방식에서 전송 동작의 참고값이나 제한값으로 사용될 수 있지만 입력한 수치만큼의 속도를 클라이언트가 보장하는 것은 아닙니다. 업로드와 다운로드의 단위 또는 입력 방식도 다를 수 있으므로 현재 항목 설명과 기존 설정을 기준으로 확인하세요. 수치를 높게 입력해도 회선 대역폭이나 경로 용량을 넘어설 수는 없습니다. 오히려 대기열과 패킷 손실을 늘리거나 다른 서비스에 방해가 될 수 있습니다.

성능은 응답성과 처리량을 함께 확인해야 합니다

다운로드 속도가 계속 높다고 해서 웹 검색, 음성 통화, 백그라운드 동기화도 모두 더 나아지는 것은 아닙니다. 데이터를 전송하는 동안 다른 요청의 응답을 관찰해 대기열이 눈에 띄게 늘어나는지 확인하세요. 가장 잘 나온 결과 하나만 고르거나 서로 다른 대상과 네트워크에서 측정한 값을 비교하지 마세요. 먼저 보수적이고 반복 가능한 기준을 만든 다음 대역폭 관련 항목을 조정했을 때 처리량과 응답성이 함께 개선되는지, 한쪽만 달라지는지 살펴보세요.

iOS 기기에서는 QUIC 처리, 높은 데이터 처리량, 지속적인 무선 활동이 모두 전력 소모를 늘릴 수 있지만 UDP를 사용한다는 이유만으로 배터리 소모량을 단정할 수는 없습니다. 같은 시간에 더 많은 데이터를 내려받으면 기기가 더 뜨거워질 수 있습니다. 비교하는 데이터 양이 서로 다르면 이 결과만으로 프로토콜 효율이 낮다고 볼 수 없습니다. 같은 데이터 양을 완료하는 데 걸리는 시간과 같은 사용 시간 동안의 백그라운드 활동을 각각 비교하고 신호 상태와 화면 상태를 고려하세요.

Wi-Fi에서는 정상인데 셀룰러 네트워크에서 계속 연결되지 않는다면 인증 정보를 바꾸기 전에 두 네트워크의 UDP 지원 여부를 먼저 확인하세요. 네트워크 전환 후 잠시 문제가 있다가 사라진다면 재연결이 복구되는지 살펴보세요. 계속 실패하면 로그에서 오류가 발생한 단계를 확인하세요. 경로의 패킷 크기, 서버 자원, 접속 지점 제한이 원인일 수 있으므로 기존 서버 관리자에게 확인해야 할 수도 있습니다. 앱에 표시된 시간 초과 하나만으로 어떤 계층이 요청을 거부했는지 알 수는 없습니다.

기존 서버가 Hysteria2를 명확히 지원하고 현재 앱에서 필요한 모든 항목을 설정할 수 있으며 대상 네트워크에서 반복 테스트한 결과 안정적인 이점이 확인된다면 계속 사용할 수 있습니다. 기존 설정을 모두 교체해야 하는 것은 아닙니다. 현재 TCP 기반 설정으로 필요한 작업을 할 수 있고 사용 중인 네트워크에서 UDP가 불안정하다면 검증된 설정을 유지하는 편이 좋습니다. 프로토콜 선택은 사용 환경에 따라 결정해야 하며 이름이 새것인지 오래된지에 따라 바꿀 필요는 없습니다.

사용 환경에 맞게 선택하고 단계별로 검증

설정 조건을 먼저 충족한 뒤 사용 경험을 비교

프로토콜 선택은 사용자가 이미 가진 정보부터 확인해야 합니다. 서버가 지원하는 프로토콜과 필수 항목, 대상 서비스, 현재 네트워크의 TCP 또는 UDP 조건을 살펴보세요. 일반 웹 검색, 장시간 데이터 전송, 실시간 앱, 원격 네트워크 접속은 핸드셰이크, 처리량, 지터, 라우팅에서 중요하게 보는 부분이 다릅니다. 모든 용도를 포괄하는 단일 지표는 없습니다. 항목이 불완전하거나 경로 조건이 맞지 않는 조합을 먼저 제외한 뒤 남은 설정을 비교하면 모든 유형을 하나씩 시험하는 것보다 효율적입니다.

일반적인 웹 사용에서는 안정적이고 설정이 명확하며 첫 화면 응답이 적절한 기존 구성을 우선 유지할 수 있습니다. 실시간 서비스는 UDP, 지터, 연속성을 따로 확인하고 원격 네트워크 접속은 주소 범위와 응답 경로를 확인해야 합니다. 사용할 수 있는 설정이 여러 개라면 같은 기기와 네트워크, 대상에서 반복해 관찰하고 DNS, 규칙, 전송 방식을 동시에 바꾸지 마세요. 테스트 결과는 해당 환경에만 적용되며 모든 기기에서 특정 프로토콜이 늘 우수하다는 결론으로 확대해서는 안 됩니다.

Global Routing이 요청의 경로를 결정합니다

프로토콜 설정이 올바르더라도 규칙 때문에 요청이 잘못된 경로로 갈 수 있습니다. Config는 현재 규칙에 따라 처리 방식을 결정하고, Proxy는 규칙의 영향을 잠시 줄여 확인할 때, Direct는 일반 네트워크 접속을 비교할 때 사용할 수 있습니다. 모드 전환은 진단 방법일 뿐 자동으로 문제를 해결하지는 않습니다. Proxy에서는 정상인데 Config에서 실패한다면 비밀번호를 다시 입력하기보다 규칙, 정책 이름, DNS를 먼저 확인하세요. 비교를 마친 뒤에는 원래 필요한 모드로 되돌려 임시 테스트 설정이 다른 서비스에 계속 영향을 주지 않도록 하세요.

아래는 Shadowrocket 설정에 사용할 수 있는 간단한 규칙 예시입니다. 도메인, 주소, 최종 규칙의 순서를 보여 줄 뿐 전체 설정은 아닙니다. 규칙은 보통 위에서 아래로 일치 여부를 확인하므로 FINAL은 앞선 규칙 뒤에 배치해야 합니다. 여기서 PROXY와 DIRECT는 정책을 뜻하며 서버 비밀번호를 정책 위치에 입력하는 것이 아닙니다. 이름이 지정된 정책을 사용한다면 현재 설정에 해당 이름이 실제로 정의되어 있는지도 확인해야 합니다.

[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 주소의 지역 데이터 정보를 기준으로 일치 여부를 판단합니다. FINAL은 앞선 규칙에 일치하지 않은 요청을 처리합니다. 이런 항목은 프로토콜 설정이 아니며 원격 인증을 바꾸지도 않습니다. 도메인 규칙을 사용하려면 요청 처리 과정에서 해당 도메인 정보가 유지되어야 합니다. 대상 주소만 보이는 상황에서는 일치 조건이 달라질 수 있습니다. 규칙 위치, 확인 결과, 요청 유형을 함께 살펴보세요. 자세한 내용은 규칙 작성법과 일치 방식을 참고하세요.

정해진 순서로 오류 범위를 좁히기

첫째, 앱이 시스템 승인을 받았고 예상한 연결이 선택되어 있는지 확인합니다. 둘째, 접속 주소를 확인할 수 있고 실제로 접속 가능한지 살펴봅니다. 셋째, 프로토콜 인증과 TLS가 완료됐는지 확인합니다. 넷째, DNS를 검증합니다. 다섯째, 규칙과 정책을 살펴봅니다. 마지막으로 대상 앱 자체를 확인합니다. 앞 단계에서 실패했다면 먼저 그 문제를 해결하고 뒤 단계의 항목을 한꺼번에 바꾸지 마세요. Connectivity Test 결과는 실제 웹 접속, 업로드, 필요한 서비스와 함께 판단해야 합니다. 테스트 하나의 성공이 모든 경로를 확인해 주지는 않습니다.

문제를 기록할 때는 네트워크 유형, Global Routing 모드, 선택한 연결, 오류 단계, 반복 재현 여부를 남기고 인증값은 공개하지 마세요. 장시간 전송이 멈추면 MTU, 패킷 손실, 서버 상태를 추가로 확인하세요. 지연 시간은 정상인데 도메인 접속이 실패한다면 DNS 문제 해결을 참고하세요. 시스템 연결 스위치에 문제가 있다면 문제 해결을 확인하세요. 한 번에 하나씩 변경하고 실패하면 기존 기준 설정으로 되돌려 검증되지 않은 변경이 쌓이지 않도록 하세요.

최종적으로 남겨야 할 것은 우연히 연결된 상태가 아니라 이유를 설명할 수 있는 설정입니다. 유효한 항목과 적용 환경을 따로 기록하고 기존 구독을 업데이트한 뒤 주요 항목을 다시 확인하세요. 네트워크 조건이 바뀌면 같은 순서로 점검하면 됩니다. 일상적인 사용 절차는 시작하기를 참고하세요. App Store 구매, 구입 항목 복원, 기기 호환성은 구입 및 정품 확인에서 별도로 확인할 수 있으므로 프로토콜 문제 해결과 구매 문제를 한꺼번에 처리할 필요는 없습니다.