Shadowrocket 프로토콜 가이드

01 / Connection Model

연결 모델: 네 가지 설정 계층 구분하기

프로토콜을 선택할 때 가장 먼저 고려할 점은 이름으로 성능을 추측하는 것이 아니라 서버 설정과 일치시키는 것입니다. Shadowrocket의 연결 항목에는 보통 서버 주소, 인증 정보, 전송 방식, 보안 설정이 함께 들어가며, 규칙은 어떤 요청을 해당 항목으로 보낼지 결정합니다. 네 가지 중 하나라도 맞지 않으면 연결 시간 초과가 발생할 수 있습니다. 설정을 변경하기 전에 현재 작동하는 구성을 보관하고, 정보가 기존 서비스 제공자나 직접 관리하는 서버에서 나온 것인지 확인하세요. 기억에 의존해 빠진 항목을 채우면 안 됩니다.

프로토콜, 전송 방식, TLS는 서로 다른 설정

Shadowsocks, VMess, VLESS, Trojan은 서로 다른 프로토콜 메커니즘을 설명합니다. TCP, UDP, WebSocket은 데이터를 전달하는 방식을 다루고, TLS는 특정 연결 계층에서 암호화와 인증을 담당합니다. 하나의 연결 항목에 프로토콜 이름, WebSocket, TLS가 함께 포함될 수 있으며, 이는 셋 중 하나를 고르라는 뜻이 아닙니다. 제공받은 연결 정보를 계층별로 맞춰야 합니다. TLS를 활성화했다고 프로토콜 인증을 생략할 수 없고, UUID를 입력했다고 전송 계층까지 올바르게 설정된 것도 아닙니다.

주소와 이름도 용도가 다릅니다. Server는 일반적으로 클라이언트가 연결할 대상을 지정하고, Port는 접속할 서버 포트를 지정하며, SNI는 TLS 핸드셰이크 중 서버 이름을 전달합니다. WebSocket의 Host는 HTTP 요청 정보이고 Path는 서버에서 정한 경로를 가리킵니다. 이 값들은 우연히 같을 수도, 의도적으로 다를 수도 있습니다. 서로 바꿔 쓸 수 있는 대체 입력란이 아닙니다. 연결 정보에서 요구하지 않은 항목은 가져온 값이나 기본값을 유지하고, 모든 항목에 서버 주소를 넣지 마세요.

Global Routing은 트래픽이 연결 항목을 거칠지 결정합니다

Global Routing의 Config는 현재 구성 파일의 규칙에 따라 트래픽을 매칭합니다. Proxy는 클라이언트가 처리하는 트래픽을 프록시 정책으로 보내고, Direct는 직접 연결에 사용됩니다. 세 가지 모드는 라우팅 선택을 바꿀 뿐 서버 프로토콜을 변경하지 않습니다. Proxy로 전환했을 때는 접속되지만 Config로 돌아오면 실패한다면 서버 항목을 바로 다시 만들기보다 규칙과 실제 적용된 정책부터 확인하세요. 반대로 Direct에서 접속된다고 해서 프록시 연결이 성립한 것은 아닙니다.

DNS는 여러 계층에 걸쳐 필요한 선행 조건입니다. 클라이언트는 먼저 서버 도메인을 확인해야 할 수 있고, 대상 웹사이트의 도메인은 별도로 확인할 수도 있습니다. 서버 도메인을 확인하지 못하면 인증 단계까지 진행되지 않습니다. 대상 도메인 확인에 문제가 있어도 연결 항목 자체는 정상일 수 있습니다. 따라서 ‘서버를 찾을 수 없음’과 ‘서버를 통해 특정 대상에 접속할 수 없음’을 구분하고, 오류에 표시된 도메인과 발생 단계를 기록하세요. 모든 DNS 문제를 프로토콜 비호환으로 판단하지 마세요.

iPhone과 iPad의 실제 사용 경험은 무선 신호, 네트워크 전환, 백그라운드 작업, 서버 부하의 영향을 받습니다. 지연 시간이 낮다는 것은 특정 테스트의 왕복 비용이 적다는 뜻일 뿐, 대용량 전송 속도가 더 빠르다는 의미는 아닙니다. 한 번 빠르게 로드됐다고 대기 중 배터리 소모가 적다고 볼 수도 없습니다. 프로토콜을 비교할 때는 같은 기기와 네트워크, 비슷한 시간대, 동일한 대상을 사용하고 추가 전송 계층을 적용했는지도 기록하세요. 그래야 결과를 재현하기 쉽습니다.

이 페이지는 각 설정 항목의 역할과 확인 순서를 설명하며 서버 설정 안내를 대신하지 않습니다. 가져온 뒤 문서에 없는 추가 옵션이 보이면 변경하기 전에 현재 서버에서 필요한 항목인지 확인하세요. 사용할 수 있는 설정은 전송 방식 조합에 따라 다르므로 앱에 실제로 표시되는 항목을 기준으로 합니다. 저장할 때는 관련 설정을 한 번에 한 묶음씩만 변경하고 원래 값을 기록하세요. 그래야 다음 테스트에서 어떤 계층이 결과에 영향을 주었는지 알 수 있습니다.

02 / Shadowsocks

Shadowsocks: 암호화 방식과 비밀번호 조합

Shadowsocks는 비교적 적은 프로토콜 상호작용으로 프록시 트래픽을 전달하도록 설계되었으며, 암호화와 데이터 전송을 함께 처리합니다. 완전한 기기 간 네트워크를 구성하는 프로토콜은 아니며, 인증서 이름으로 사용자를 식별하지도 않습니다. 클라이언트에서 가장 기본적으로 맞춰야 할 항목은 주소, 포트, 암호화 방식, 비밀번호이며 모두 서버 설정과 일치해야 합니다. 이름이 같은 서버 항목이라도 설정값이 같다는 보장은 없습니다. 특히 서버 포트나 인증 정보가 변경되면 이전 항목이 남아 있어도 더 이상 작동하지 않을 수 있습니다.

Method는 비밀번호가 연결에 사용되는 방식을 결정합니다

Method는 임의로 조정할 수 있는 성능 옵션이 아닙니다. 각 방식은 키 파생, 데이터 캡슐화, 무결성 확인 방법을 정의하므로 클라이언트와 서버가 호환되어야 합니다. 최신 인증 암호화 방식은 데이터를 보호하고 변조를 감지할 수 있지만, 어떤 방식이든 모든 서버에서 사용할 수 있다는 뜻은 아닙니다. 제공된 암호화 방식을 정확히 확인하세요. 같은 알고리즘 계열이라는 이유로 바꾸거나 이름이 길수록 더 안전할 것이라고 추측해 선택하지 마세요.

Password도 제공된 값을 그대로 사용해야 합니다. 복사 과정에서 공백이나 줄바꿈이 섞이거나 비슷하게 보이는 문자가 바뀔 수 있습니다. 일부 프로토콜 변형은 키의 인코딩과 길이 요건이 정해져 있어 일반 텍스트 비밀번호처럼 다시 입력하면 안 됩니다. 링크로 가져온 비밀번호가 길더라도 형식을 유지하고, 대소문자를 바꾸거나 끝의 기호를 임의로 제거하지 마세요. 다시 확인해야 한다면 기존 정보를 관리하는 경로에서 확인하고, 비밀번호 전체를 스크린샷이나 공개된 대화에 붙여 넣지 마세요.

일반적인 AEAD 방식에는 AES-GCM과 ChaCha20-Poly1305 계열이 있습니다. 처리 비용은 기기의 하드웨어 명령어 지원, 구현 방식, 트래픽 유형에 따라 달라지므로 알고리즘 이름만 보고 iPhone에서 어느 쪽이 항상 배터리를 덜 소모한다고 단정할 수 없습니다. 지속적인 전송에서는 프로세서 효율이 처리량에 영향을 줄 수 있고, 간헐적인 접속에서는 기기 깨우기 횟수와 무선 통신 시간이 더 중요할 수 있습니다. 서버가 호환되는 선택지를 함께 제공할 때만 알고리즘 비교가 의미 있습니다.

TCP가 작동한다고 UDP도 작동하는 것은 아닙니다

Shadowsocks는 다양한 유형의 대상 트래픽을 전달할 수 있지만, 실제 UDP 전달은 서버, 클라이언트 설정, 현재 네트워크가 모두 지원해야 합니다. 웹페이지는 보통 TCP로 연결되지만 일부 실시간 앱은 UDP에 의존합니다. 따라서 ‘웹페이지는 열리지만 다른 앱은 실패하는’ 상황도 충분히 가능합니다. 먼저 해당 서비스에 UDP가 필요한지 확인한 뒤 기존 서버가 UDP 전달을 허용하는지 살펴보세요. 웹페이지 로드 결과만으로 UDP가 작동한다고 판단하지 마세요.

연결 정보에 추가 플러그인이나 전송 설정이 포함되어 있다면 이 역시 전체 연결 구성의 일부입니다. 기본 프로토콜 이름이 같더라도 추가 캡슐화가 적용된 항목에서 해당 설정을 삭제하면 작동하지 않을 수 있습니다. 반대로 일반적인 연결 항목에 요구되지 않은 TLS, Host, Path를 임의로 추가하지 마세요. 설정을 더하면 일치해야 할 조건만 늘어날 뿐, 주소 오류나 만료된 비밀번호, 연결할 수 없는 포트가 자동으로 해결되지는 않습니다.

iPhone에서 현재 설정을 유지할지 판단하는 방법

현재 Shadowsocks 항목으로 일상적인 작업을 안정적으로 처리할 수 있다면 이름이 더 복잡한 프로토콜로 바꾼다고 반드시 이점이 생기는 것은 아닙니다. 먼저 앱을 처음 열었을 때의 접속, 지속적인 데이터 전송, 화면을 잠근 뒤 연결 복구 등 세 가지 사용 경험을 기록해 보세요. 최초 접속은 연결 수립을, 지속 전송은 안정적인 처리량을, 복구 테스트는 시스템 네트워크 변화 후 재연결을 확인합니다. 각 테스트가 확인하는 내용이 다르므로 하나의 ‘속도 점수’로 합치지 마세요.

실패하면 먼저 서버 도메인을 확인할 수 있는지, 포트가 올바른지 살펴보고 Method와 Password를 확인한 뒤 UDP나 추가 전송 요구 사항을 점검하세요. 같은 네트워크에서 모든 대상 접속이 실패하면 접속 지점과 인증을 먼저 살펴보세요. 특정 대상만 문제가 있다면 규칙, 대상 도메인 확인, 서버에서 대상까지의 경로를 확인합니다. 암호화 방식을 계속 바꾸는 것보다 계층별로 범위를 좁히는 편이 재현 가능한 결과를 얻기 쉽습니다.

구독에서 가져온 항목을 관리할 때는 구독 업데이트와 수동 변경을 구분해야 합니다. 업데이트가 서비스 제공자가 관리하는 설정을 덮어쓰거나 이름이 비슷한 새 항목을 추가할 수 있습니다. 테스트하기 전에 방금 확인한 연결이 실제로 선택되어 있는지 확인하세요. 한 항목을 수정하고 다른 항목을 테스트하는 일을 피할 수 있습니다. 사용자 지정 설정을 계속 유지해야 한다면 해당 유형의 항목이 업데이트될 때 어떻게 처리되는지 먼저 확인하고, 복구할 수 있도록 원래 연결 정보를 보관하세요.

03 / VMess · VLESS

VMess와 VLESS: 인증과 전송 설정을 각각 확인하세요

VMess와 VLESS는 다양한 전송 방식과 함께 사용되지만 서로 바꿔 쓸 수 있는 이름은 아닙니다. VMess에는 자체 인증 및 데이터 보호 메커니즘이 있고, VLESS는 프로토콜 자체를 단순화하고 보안 보호를 함께 사용하는 보안 계층에 맡기는 방식입니다. 이는 서로 다른 설계 선택을 나타낼 뿐, 단순한 속도 업그레이드 관계가 아닙니다. 기존 서버에서 사용하는 프로토콜에 맞춰 클라이언트 유형을 선택해야 합니다. UUID만 유지한 채 프로토콜 이름을 바꾸면 안 됩니다.

UUID는 사용자 식별 정보이지 전체 설정이 아닙니다

UUID는 연결 사용자를 식별하는 데 쓰이지만 올바른 UUID만으로 인증 정보가 모두 갖춰지는 것은 아닙니다. Server, Port, 전송 유형, 관련 보안 옵션도 모두 일치해야 합니다. 가져오기에 실패했을 때 UUID만 다시 입력하고 잘못된 WebSocket Path를 그대로 두면 연결 결과는 바뀌지 않습니다. 다른 항목의 UUID를 빌려 테스트하지 마세요. 사용자마다 권한, 유효 상태, 서버 접속 지점이 다를 수 있습니다.

VMess 인증에는 시간 정보가 관련되므로 기기 시간이 크게 어긋나면 연결에 실패할 수 있습니다. 문제를 진단할 때 시스템의 날짜 및 시간 설정에서 자동 설정 상태를 확인하고 시간대나 수동 설정에 오류가 없는지도 살펴보세요. 표시되는 시간대가 다르다고 해서 시스템 시간이 반드시 잘못된 것은 아닙니다. 실제 시각이 정확한지가 중요합니다. 시간 문제를 해결하려고 오래된 인증 관련 설정을 반복해서 바꾸지 말고, 먼저 기기와 서버의 시간 기준이 올바르게 맞도록 하세요.

VLESS는 TLS와 동등한 전송 암호화 보호를 자체적으로 제공하지 않습니다. 따라서 ‘인증에 성공했다’고 해서 연결 경로가 충분히 보호되고 있다고 볼 수 없습니다. 기존 서비스에서 지정했고 클라이언트가 지원하는 보안 조합을 사용하세요. 정보에 TLS가 요구되어 있다면 이름 확인과 인증서 체인을 점검해야 합니다. 별도의 보안 설정이 포함되어 있다면 각각 제공된 정보에 따라 설정하세요. 앱에서 빈 항목을 저장할 수 있다는 이유만으로 실제 네트워크에 적합한 조합이라고 판단하지 마세요.

WebSocket의 Host와 Path가 가진 의미를 유지하세요

WebSocket은 데이터를 정해진 연결 전송 방식에 담을 때 자주 사용되며, 연결 과정에 HTTP 요청, TLS, 리버스 프록시가 포함될 수 있습니다. Host는 요청을 처리할 접속 지점을 식별하고 Path는 서버 측 경로를 구분합니다. 둘 다 장식용 설정이 아닙니다. Path는 대소문자를 구분하는 경우가 많으며 앞의 슬래시와 쿼리 문자열도 중요할 수 있습니다. 정보를 복사할 때 임의로 줄이지 마세요. 웹페이지나 일반 HTTP 오류 내용이 표시된다면 UUID보다 접속 경로를 먼저 확인해야 할 수 있습니다.

일부 연결 정보에는 특정 흐름 제어 또는 멀티플렉싱 설정도 포함될 수 있습니다. 이러한 설정은 일반적으로 서버 구현, 프로토콜 유형, 전송 조합에 따라 제약되므로 다른 연결 항목에서 그대로 가져오면 안 됩니다. 특히 온라인에서 찾은 설정 이름을 서로 다른 조합에 바로 추가하면 기존에 작동하던 연결이 실패할 수 있습니다. 앱에 해당 항목이 표시되는지, 서버에서 명시적으로 요구하는지가 설정 여부를 결정하는 기준입니다. 설정 이름이 최신처럼 들리는지는 기준이 아닙니다.

추가 캡슐화의 영향을 확인하는 방법

모바일 네트워크에서는 추가 핸드셰이크가 최초 접속에 영향을 줄 수 있지만, 연결이 유지되면 뒤따르는 트래픽에 비용이 분산됩니다. 전송 계층에서 거치는 접속 지점과 경로 길이, 서버 부하가 프로토콜 헤더 비용보다 더 큰 영향을 줄 수도 있습니다. 따라서 VMess와 VLESS를 비교할 때는 가능한 한 같은 서버 접속 지점과 전송 조합을 사용하세요. 서버 위치까지 다르면 측정된 차이를 프로토콜 자체의 영향으로 볼 수 없으며, 다른 사용자에게도 일반화할 수 없습니다.

‘유형과 인증 정보, 전송 설정, 보안 설정, 기기 시간’ 순서로 확인하고 같은 대상을 반복 테스트하는 것이 좋습니다. 구독 업데이트 후 설정이 달라졌다면 먼저 정보 업데이트로 인한 변화인지 확인한 뒤 이전 값으로 되돌릴지 판단하세요. 시간 초과와 시간 조정의 구체적인 점검 순서는 연결 실패 시 3단계 문제 해결에서 확인할 수 있습니다. 원인을 파악하기 전에 여러 계층을 한꺼번에 변경하지 마세요.

04 / Trojan · TLS

Trojan과 TLS: 먼저 서버 인증을 완료하세요

Trojan은 프록시 인증과 데이터 전송을 TLS 연결 안에서 처리하며, 검증된 보안 전송 메커니즘으로 통신을 보호하도록 설계되었습니다. 설정이 제대로 작동하려면 두 가지 조건을 모두 충족해야 합니다. TLS 연결이 올바르게 수립되고, 이어서 서버가 프로토콜 비밀번호를 받아들여야 합니다. 비밀번호가 정확해도 인증서 이름이 일치하지 않으면 해결되지 않습니다. TLS 핸드셰이크가 성공했다고 Trojan 인증까지 완료된 것도 아닙니다. 이 두 단계를 구분해야 해당 연결에서 발생하는 오류를 이해할 수 있습니다.

Server, SNI, 인증서 이름의 관계

Server는 네트워크 연결 지점을 지정하고, SNI는 클라이언트가 핸드셰이크 중 전달하는 이름이며, 인증서는 서버의 신원을 증명합니다. 일부 구성에서는 접속 주소와 인증서에 연결된 도메인이 다르므로 기존 정보에 SNI가 별도로 지정되어 있습니다. 이때는 제공된 대응 관계를 유지하세요. 모든 이름을 접속 주소로 바꿔 겉보기만 통일하면 안 됩니다. 인증서 검증은 예상한 서버 신원을 확인하는 절차이므로 주소에 접속할 수 있다는 이유만으로 생략할 수 없습니다.

IP 주소를 접속 지점으로 사용할 때는 이름 검증에 특히 주의해야 합니다. 도메인 이름으로 발급된 인증서가 해당 IP 주소에도 자동으로 적용되는 것은 아닙니다. 임의로 추측하지 말고 서버에서 제공한 이름을 사용해 연결하세요. 반대로 익숙한 도메인이라는 이유만으로 SNI에 아무 이름이나 입력해서도 안 됩니다. 접속 지점이 그 이름에 대한 서비스를 제공하지 않을 수 있습니다. 이름이 잘못되면 인증 전에 연결이 종료될 수 있으므로 이 경우 Password를 계속 바꿔도 도움이 되지 않습니다.

인증서 검증에는 인증서 체인, 유효 기간, 기기의 신뢰 상태도 관련됩니다. 시스템 시간이 크게 잘못되면 유효한 인증서가 아직 유효하지 않거나 만료된 것으로 표시될 수 있습니다. 서버가 중간 인증서를 올바르게 제공하지 않아 기기마다 결과가 달라질 수도 있습니다. 문제를 진단할 때 오류가 가리키는 이름과 검증 단계를 기록하고 서버 관리자에게 인증서 설정을 확인해 달라고 요청하세요. 인증서 검증을 계속 건너뛰는 것을 일반적인 해결 방법으로 삼지 마세요. 서버 신원 확인이 약해집니다.

Password와 ALPN의 역할

Password는 프로토콜 인증 정보이므로 현재 서버 설정과 정확히 일치해야 합니다. TLS 인증서의 개인 키와는 다른 값이며 SNI, Host, Path에 넣어서도 안 됩니다. 복사한 뒤 문자 하나하나가 온전한지 확인하되, 문제를 해결하려고 공개된 기록에 원래 값을 표시하지 마세요. 다른 사람에게 도움을 요청할 때는 설정을 확인했는지와 오류가 발생한 단계만 설명하고 인증 정보 전체를 가리세요.

ALPN은 TLS 내부에서 애플리케이션 계층 프로토콜을 협상하는 데 사용됩니다. 일부 구성에서는 협상 결과가 정해져 있지만 다른 구성에서는 기본 동작을 사용합니다. 모든 연결에서 직접 입력해야 하는 가속 옵션이 아니며, 임의로 프로토콜 이름을 추가한다고 호환성이 높아지는 것도 아닙니다. 기존 정보에 ALPN이 지정되어 있다면 순서와 내용을 그대로 유지하세요. 지정되지 않았고 가져온 값이 비어 있다면 그대로 두고, 서버 요구 사항을 확인한 뒤에만 변경하세요.

핸드셰이크, 배터리 사용량, 연결 재사용

TLS 최초 핸드셰이크에는 네트워크 왕복과 암호화 연산이 필요하지만, 이 사실만으로 Trojan이 iPhone에서 반드시 배터리를 더 많이 소모한다고 볼 수는 없습니다. 연결이 유지되면 핸드셰이크 비용은 분산되고, 기기의 암호 알고리즘 지원 여부도 처리 효율에 영향을 줍니다. 실제 배터리 소모는 약한 신호에서의 재전송, 잦은 네트워크 전환, 반복적인 연결 수립에도 좌우됩니다. 간헐적인 접속과 지속적인 전송을 구분해 비교하세요. 한 번의 시작 지연으로 하루 전체의 배터리 사용량을 추정하지 마세요.

작은 요청은 정상인데 대용량 파일이 자주 끊긴다면 연결 품질, 시간 초과, MTU 문제 가능성을 확인하세요. 모든 요청이 연결 수립 단계에서 실패한다면 접속 지점과 TLS부터 살펴봅니다. 특정 도메인에서만 문제가 있다면 Global Routing, 규칙, 대상 도메인 확인도 필요합니다. 프로토콜에 보안 계층이 있다고 해서 이후에 발생하는 모든 문제가 인증서 오류인 것은 아닙니다. 오류가 발생한 지점을 기준으로 범위를 좁히세요.

관리할 때는 가져온 원본 항목을 보존하고 복사본으로 범위를 정한 테스트를 진행하세요. 서버의 인증서나 접속 지점이 바뀌었다면 검증을 건너뛰는 항목을 여러 개 쌓기보다 기존 정보도 함께 업데이트되었는지 먼저 확인하세요. 연결이 복구되면 더 이상 필요하지 않은 테스트 복사본을 삭제해 이름이 비슷한 항목을 잘못 선택하지 않도록 합니다. 구매 정보와 시스템 호환성은 프로토콜 설정이 아니라 App Store 정품 확인 안내에 연결된 경로에서 확인하세요.

05 / HTTP · SOCKS5

HTTP와 SOCKS5: 프록시 기능이 암호화를 뜻하지는 않습니다

HTTP 프록시와 SOCKS5는 앱이 중간 서버를 통해 대상 리소스에 접근하도록 설계되었으며, 기기 전체를 연결하는 터널과는 차이가 있습니다. HTTP 프록시는 HTTP 요청과 연결 터널을 중심으로 작동하고, SOCKS5는 더 일반적인 대상 주소와 연결 요청을 전달합니다. 기존 서버에서 실제로 제공하는 서비스 유형을 먼저 확인하고 보안 전송이 포함되는지도 살펴보세요. ‘프록시를 지원한다’는 사실만으로 클라이언트와 프록시 사이의 연결이 암호화된다고 볼 수 없습니다.

HTTP 프록시의 CONNECT

HTTP 프록시는 일반 HTTP 요청을 처리하거나 CONNECT 요청으로 대상까지의 바이트 터널을 만들 수 있습니다. 대상 웹사이트가 HTTPS를 사용하면 웹사이트 콘텐츠는 보통 클라이언트와 대상 사이의 TLS로 보호됩니다. 그러나 이것과 클라이언트에서 프록시까지 별도의 TLS를 사용하는지는 다른 문제입니다. 프록시는 연결할 대상 등의 정보를 여전히 알아야 하므로 주소창에 HTTPS가 표시된다는 이유만으로 프록시 접속 지점의 인증이나 메타데이터 전송 방식까지 판단할 수 없습니다.

서버가 TLS를 사용하는 HTTP 프록시 접속 지점을 제공한다면 클라이언트도 해당 접속 지점의 요구에 맞는 보안 설정을 선택해야 합니다. 일반 HTTP 프록시 항목을 TLS가 필요한 포트에 연결하거나 그 반대로 설정하면 프로토콜 협상 단계에서 실패할 수 있습니다. 포트 번호가 특정 서비스 유형을 보장하지는 않습니다. 같은 번호를 서로 다른 서비스에서 사용할 수 있으므로 흔히 쓰이는 포트만 보고 프로토콜을 추측하지 말고 명확한 서버 정보를 따르세요.

Username과 Password가 필요한지는 프록시 서비스의 인증 요구 사항에 따라 다릅니다. 비어 있다고 해서 인증이 필요하지 않은 것일 수도 있고, 가져온 정보가 불완전한 것일 수도 있으므로 단정할 수 없습니다. 인증 관련 오류가 발생하면 계정이 현재 접속 지점에 해당하는지, 문자가 온전한지, 해당 조합에서 서버의 인증 방식을 지원하는지 확인하세요. 웹사이트 로그인 비밀번호를 프록시 인증란에 입력하지 마세요. 둘은 적용되는 신원 범위가 다릅니다.

SOCKS5 연결과 UDP의 범위

SOCKS5는 대상 도메인이나 IP 주소를 표현할 수 있고 여러 명령을 지원합니다. UDP 전달에는 일반적으로 UDP ASSOCIATE가 사용됩니다. 그러나 프로토콜 사양에 해당 기능이 있다고 해서 모든 서버가 이를 제공하거나 모든 접속 네트워크에서 사용할 수 있는 것은 아닙니다. 실제로 테스트할 때는 서버의 UDP 허용 여부, 클라이언트 설정의 지원 여부, 방화벽과 응답 경로를 확인하세요. SOCKS5라는 이름만으로 실시간 서비스가 반드시 작동한다고 판단할 수 없습니다.

SOCKS5에서 흔히 사용하는 인증 방식은 암호화 방식과 다릅니다. 서버에서 사용자 이름과 비밀번호를 요구하더라도 클라이언트와 접속 지점 사이의 전송 보호는 별도로 평가해야 합니다. 대상 앱의 TLS는 해당 서비스 콘텐츠를 보호할 수 있지만 프록시 접속 지점의 신뢰성을 대신 확인해 주지는 않습니다. 기존 서비스가 신뢰할 수 있는 내부 네트워크에서만 사용하도록 정해져 있다면 그 범위를 지키세요. 내부 용도의 프록시 주소를 설계 조건에 맞지 않는 환경에서 사용하지 마세요.

도메인을 어디서 확인할지는 실제 설정에 따라 다름

프록시 요청에 도메인이 포함될 수도 있고 클라이언트가 이미 확인한 주소가 사용될 수도 있습니다. 구체적인 동작은 앱, 규칙, DNS 설정에 따라 달라집니다. 따라서 내부 도메인이나 분리된 DNS 문제에서 HTTP와 SOCKS5 유형만 바꿔서는 해결되지 않을 수 있습니다. 먼저 어느 네트워크 환경에서 도메인을 확인해야 하는지, 확인 결과가 서버에 적합한지 파악한 다음 실제 요청 경로를 확인하세요. 접속 지점은 연결되지만 내부 사이트에 접속할 수 없다면 인증보다 DNS나 접근 권한이 문제일 수 있습니다.

iPhone과 iPad에서 이 두 프로토콜도 환경에 상관없이 속도를 단정할 수 없습니다. 단순한 핸드셰이크가 일부 짧은 연결의 비용을 줄일 수 있지만, 주요 사용 경험은 여전히 대상까지의 거리, 프록시 서버 성능, 네트워크 품질에 좌우됩니다. 기존에 사용할 수 있는 프록시 서비스가 있고 인증과 보안 조건을 파악했으며 업무 유형이 서비스 기능에 맞는 경우에 적합합니다. 설정 항목이 적다는 이유만으로 모든 연결의 대체 방식으로 삼아서는 안 됩니다.

검증할 때는 접근이 허용된 고정 대상을 선택해 인증과 TCP 전달을 확인한 뒤 필요한 다른 작업도 테스트하세요. 내부 리소스만 실패한다면 기존 서비스 관리자에게 권한, 대상 도메인 확인, 접근 범위를 문의하세요. 진단 정보를 저장할 때는 상태와 대상 유형만 기록하고 전체 계정 정보나 내부 주소 목록은 포함하지 마세요. 프로토콜 선택은 클라이언트가 접속 지점과 통신하는 방식을 정할 뿐, 원래 없던 리소스 접근 권한을 자동으로 부여하지 않습니다.

06 / WireGuard

WireGuard: 키, 주소, 라우팅을 함께 이해하기

WireGuard는 암호화된 IP 터널을 위한 프로토콜로, 간결한 암호화 구성과 피어 모델을 통해 통신하는 데 중점을 둡니다. 대상별로 프록시 연결을 만드는 프로토콜과 달리 서버 접속 지점뿐 아니라 로컬 터널 주소, 키, 라우팅 범위도 설정해야 합니다. WireGuard를 선택한다는 것은 Password 하나를 다른 형식으로 바꾸는 일이 아닙니다. 서버에서 할당하고 서로 대응시킨 터널 설정 전체가 필요합니다.

Private Key와 Public Key의 방향

클라이언트의 Private Key는 클라이언트 신원을 증명하는 데 사용되며 서버 측에는 이에 대응하는 클라이언트의 Public Key가 저장됩니다. 클라이언트 연결 항목의 상대 Public Key는 서버를 식별하는 데 사용됩니다. 두 공개 키의 위치를 바꾸면 주소와 포트가 올바르더라도 의도한 핸드셰이크를 완료할 수 없습니다. Private Key는 민감한 인증 정보이므로 공개 스크린샷, 로그 첨부 파일, 도움 요청 글에 포함하지 마세요. 새로 설정하기 전에 서버 측 정보도 함께 변경해야 하는지 확인하세요.

일부 구성에는 기존 키 교환에 공유 비밀을 추가하는 Preshared Key가 포함됩니다. 서버에서도 이 항목을 요구하고 같은 값을 설정한 경우에만 입력하세요. 값을 임의로 생성해도 서버가 자동으로 받아들이지는 않습니다. 서버에서 요구하지 않는다면 기존 정보를 그대로 두면 됩니다. 키의 길이, 인코딩, 문자는 모두 형식상 의미가 있으므로 임의로 잘라내거나 수정하지 마세요. 비슷해 보이는 다른 키를 대신 사용할 수도 없습니다.

Address, Endpoint, Allowed IPs

Address는 클라이언트에 할당된 터널 내부 주소이고, Endpoint는 상대와 연결하는 데 사용하는 네트워크 주소와 포트입니다. 전자는 터널 내부에, 후자는 외부 접속에 사용되므로 서로 대신 입력할 수 없습니다. 기기마다 별도의 신원과 주소가 필요한 경우가 많습니다. 같은 클라이언트 키를 여러 기기에 복사하면 서버에서 확인되는 접속 지점이 계속 바뀌어 서로 영향을 줄 수 있습니다. 기존 서비스에서 각 기기에 할당한 정보를 사용하세요.

WireGuard에서 Allowed IPs는 피어를 선택하는 경로 지정에 참여하는 동시에 해당 피어에서 허용할 출발지 주소 범위도 제한합니다. 웹사이트 도메인 목록이 아니므로 DOMAIN-SUFFIX 문법으로 입력하면 안 됩니다. Shadowrocket의 Global Routing과 구성 규칙은 별도의 계층입니다. 터널 라우팅 범위를 넓게 지정했다고 모든 트래픽이 반드시 터널로 흐르는 것은 아닙니다. 앱에서 요청을 연결 항목으로 전달하는 방식과 터널이 IP 패킷을 처리하는 방식을 각각 확인해야 합니다.

DNS 옵션은 해당 연결에서 도메인을 확인하는 방식을 지정하지만, 특정 요청에 적용되는지는 클라이언트의 전체 DNS 설정에도 영향을 받습니다. 연결 후 IP 주소로는 접근할 수 있지만 도메인으로는 안 된다면 키를 다시 만들기보다 DNS 연결 상태와 규칙을 확인하세요. 터널 안에 사설 IP 주소 대역이 있다면 현재 Wi-Fi의 로컬 네트워크와 겹치는지도 확인해야 합니다. 주소 대역이 중복되면 요청이 잘못된 인터페이스로 전달되어 대상 서버가 응답하지 않는 것처럼 보일 수 있습니다.

MTU와 Persistent Keepalive의 영향

WireGuard는 보통 UDP로 터널 데이터를 전달합니다. 추가 캡슐화에는 패킷 공간이 필요하므로 실제 경로에 맞지 않는 MTU를 설정하면 작은 요청은 정상인데 대용량 전송이 멈출 수 있습니다. MTU가 클수록 빠르거나 작을수록 안정적인 것은 아닙니다. 증상이 있고 테스트 결과를 재현할 수 있을 때 조정하세요. 서버에서 제공하거나 검증된 설정을 먼저 사용하고 원래 값을 기록한 뒤 범위를 좁혀 확인하세요. DNS, 라우팅, MTU를 한꺼번에 바꾸지 마세요.

Persistent Keepalive는 필요한 경우 네트워크 주소 변환 장치의 매핑을 유지하는 데 사용됩니다. 대기 후 연결할 수 없는 일부 상황을 개선할 수 있지만 주기적으로 데이터를 보내므로 모바일 기기의 네트워크 활동이 늘어날 수 있습니다. 모든 클라이언트 환경에서 직접 설정할 필요는 없으며 간격을 줄인다고 항상 더 안정적인 것도 아닙니다. 기존 서비스의 요구 사항과 실제 유휴 상태 연결 끊김을 기준으로 판단하세요. 보편적인 절전 또는 속도 향상 옵션으로 취급해서는 안 됩니다.

WireGuard의 간결한 설계는 일부 처리 비용을 줄일 수 있지만 모바일 기기의 배터리 사용량은 트래픽 규모, 재전송, 연결 유지 동작에 따라 달라집니다. Wi-Fi와 셀룰러 네트워크 사이를 전환할 때 접속 지점이 바뀌는 현상은 네트워크 정책과도 관련될 수 있습니다. 문제를 진단할 때는 키 방향, Endpoint, 터널 주소, 라우팅 범위, DNS 순으로 확인하세요. 패킷 크기와 관련된 증상이 있을 때만 MTU를 집중적으로 테스트합니다. 기존 사설 네트워크에 접근하려는 것이 주된 목적이라면 라우팅 범위를 넓히는 것보다 서버에서 허용하는 네트워크 대역을 먼저 확인하세요.

07 / Hysteria2

Hysteria2: UDP 경로와 대역폭 설정

Hysteria2는 QUIC 등의 메커니즘을 기반으로 지연, 패킷 손실, 대역폭 변화가 있는 네트워크 환경에 맞는 전송 방식을 제공합니다. 주로 TCP에 의존하는 연결과는 선택 기준이 다르지만, 그렇다고 ‘어떤 네트워크에서든 더 빠르다’고 볼 수는 없습니다. 먼저 현재 접속 네트워크에서 서버가 요구하는 UDP 접속 지점에 도달할 수 있어야 합니다. 그다음 인증, 보안, 대역폭 관련 설정을 맞춰야 합니다. 접속 지점에 도달할 수 없다면 앱에서 속도를 기대해도 소용이 없습니다.

먼저 UDP 접속 지점을 확인한 뒤 인증을 살펴보세요

Server와 Port는 기존 정보에 기재된 실제 접속 지점을 가리켜야 합니다. 일부 네트워크에서는 일반적인 웹 연결은 허용하면서 다른 UDP 트래픽은 제한할 수 있습니다. 따라서 웹페이지에 직접 접속된다고 Hysteria2 접속 지점도 도달 가능하다는 뜻은 아닙니다. 같은 항목이 Wi-Fi에서는 작동하지만 셀룰러 네트워크에서는 작동하지 않는다면 인증 설정은 유지하고 네트워크 경로부터 비교하세요. 네트워크를 전환할 때마다 비밀번호를 다시 만들면 네트워크 문제와 인증 문제가 뒤섞입니다.

인증 정보는 현재 서버의 요구 사항에 맞춰 입력해야 합니다. 추가 난독화 설정이 제공되는 경우에도 이는 로그인 인증과는 다른 계층입니다. 난독화 유형, 관련 비밀번호, 활성화 여부를 한 세트로 맞춰야 하며 클라이언트에서 옵션만 켜서는 안 됩니다. 필수 항목 중 하나라도 빠지면 더 이른 단계에서 연결이 실패할 수 있습니다. 가져온 뒤 용도가 다른 비밀 항목이 두 개 보이더라도 관리하기 편하게 같은 값으로 바꾸지 마세요.

TLS 이름과 인증서 검증 원칙은 앞에서 설명한 내용과 같습니다. 서버 접속 주소가 특정 주소라고 해서 인증서에 그 주소가 포함되어 있는 것은 아닙니다. 서버에서 지정한 SNI를 유지하세요. QUIC이 UDP를 사용한다고 TLS 신원 확인을 생략해도 되는 것은 아니며, 모든 핸드셰이크 실패가 패킷 손실 때문인 것도 아닙니다. 시간, 이름, 인증서 체인, 인증 오류를 각각 확인해야 합니다. 막연히 ‘시간 초과’라고 설명하는 것보다 오류가 발생한 단계가 진단에 더 유용합니다.

대역폭 설정값은 측정으로 보장되는 수치가 아닙니다

Hysteria2의 대역폭 설정은 전송 동작과 혼잡 제어 선택에 영향을 줄 수 있으며, 구체적인 기능은 서버와 앱이 제공하는 옵션에 따라 다릅니다. 업로드와 다운로드를 구분하고 입력 단위도 확인하세요. 통신사의 가입 회선 대역폭, 무선 연결 속도, 한 번 측정한 최고 속도를 실제 경로에서 지속 가능한 용량이라고 보고 입력해서는 안 됩니다. 실제 회선보다 훨씬 높은 값을 설정하면 패킷 손실, 재전송, 지터가 늘어 상호작용 요청이 오히려 느려질 수 있습니다.

업로드 대역폭은 특히 놓치기 쉽습니다. 다운로드 중에도 확인 응답과 제어 정보를 보내야 합니다. 백그라운드 작업이 업로드를 모두 사용하면 다운로드 용량이 충분해도 사용 경험이 나빠질 수 있습니다. 네트워크가 비교적 한가할 때 테스트하고 백그라운드 동기화가 함께 진행 중인지 확인하세요. 서버에서 자동 조정을 지원하거나 권장값을 제공한다면 해당 안내를 우선 따르세요. 모든 상황에서 대역폭을 직접 지정해야 최적화되는 것은 아닙니다.

처리량, 지연 시간, 배터리 사용량을 따로 확인하세요

전송 설정을 적극적으로 조정하면 품질이 나쁜 경로에서 처리량을 유지하는 데 도움이 될 수 있지만, 지속적인 패킷 전송과 손실 복구, 사용자 공간 처리는 리소스를 사용합니다. iPhone에서는 다운로드를 더 빨리 끝내면 무선 통신 시간을 줄일 수 있지만, 네트워크에서 패킷 손실이 계속되면 재전송으로 발열과 배터리 소모가 늘어날 수 있습니다. 효과가 서로 반대일 수 있으므로 프로토콜 이름만으로 결론을 내리지 마세요. 작업 완료 시간, 상호작용 안정성, 기기 상태를 함께 기록하세요.

대용량 파일을 테스트할 때 시작 몇 초의 최고 속도만 보지 마세요. 먼저 전송이 끝까지 안정적으로 완료되는지 확인한 다음 다운로드 중 일반 웹페이지나 다른 상호작용이 눈에 띄게 느려지는지 살펴보세요. 처리량은 높아졌지만 짧은 요청이 모두 느려졌다면 대기열이 쌓이거나 회선이 포화되었을 수 있습니다. 테스트 조건과 대역폭 설정을 다시 검토하세요. 모바일 네트워크에서는 신호 변화에 따라 사용 가능한 용량도 달라지므로 한 가지 고정값이 모든 장소에 맞지는 않습니다.

작은 요청은 되지만 대용량 전송이 멈춘다면 패킷 크기, 네트워크 손실, 대역폭 설정, 서버 리소스를 추가로 확인하세요. 연결을 전혀 수립할 수 없다면 접속 지점과 보안 계층을 다시 살펴보세요. 특정 네트워크에서만 실패한다면 설정을 계속 바꾸는 것보다 같은 항목으로 네트워크를 바꿔 확인하는 편이 의미 있습니다. 최종적으로 사용할 조합은 순간 최고 속도가 나온 설정이 아니라 실제 작업을 안정적으로 완료하고, 설정 출처가 명확하며, 결과를 재현할 수 있는 조합이어야 합니다.

08 / Selection · Diagnostics

프로토콜 선택과 문제 해결: 같은 조건에서 결과 확인하기

실제 프로토콜 선택은 기존 서비스에서 지원하는 조합부터 시작합니다. 사용할 수 있는 접속 지점이 하나뿐이라면 해당 설정을 정확히 구성하는 것이 우선입니다. 사용자가 기존에 보유한 서비스에서 여러 옵션을 제공할 때만 프로토콜을 비교할 수 있습니다. 먼저 필요한 TCP, UDP, 사설 네트워크 대역, 보안 조건을 충족한 뒤 연결 안정성과 관리 편의성을 비교하세요. 설정 항목 하나를 줄이려고 필요한 인증을 생략하지 말고, 특정 프로토콜을 쓰려고 서버에서 지원하지 않는 캡슐화를 추가하지 마세요.

업무 조건에 따라 선택지를 좁히세요

일상적인 웹 및 앱 접속에서는 최초 연결, 지속적인 사용 가능 여부, 네트워크 전환 후 복구를 확인하세요. 지속적인 전송에서는 처리량과 동시 사용 시 상호작용을 살펴봅니다. 기존 사설 네트워크에 접근하려면 주소 할당, 대상 네트워크 대역, DNS를 확인해야 합니다. UDP가 필요한 작업은 전달 기능을 별도로 테스트하세요. 업무마다 적합한 조합은 다를 수 있지만, 모든 조건은 서버가 이미 제공하고 사용을 허용한 기능을 전제로 합니다. 클라이언트가 없는 기능을 새로 만들어 내지는 못합니다.

규칙을 사용해 테스트 요청의 경로 확인

테스트 전에 Global Routing에서 Config를 선택했는지, 수정하려는 구성 파일이 현재 활성화되어 있는지 확인하세요. 아래 예시는 규칙 매칭만 설명하며 서버 정보는 포함하지 않습니다. PROXY를 사용하려면 현재 구성에 해당하는 유효한 프록시 정책이 있어야 합니다. 구체적인 도메인을 더 넓은 범위의 규칙보다 앞에 두고 마지막에 FINAL로 나머지 트래픽을 처리하세요. 나머지 요청을 직접 연결하려면 예시를 그대로 복사하지 말고 목적에 맞게 마지막 정책을 조정하세요.

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

규칙은 위에서 아래로 평가되며 먼저 일치한 항목이 이후 경로를 결정합니다. GEOIP는 IP 주소가 속한 범위를 확인하며 웹사이트의 표시 언어로 위치를 추측하지 않습니다. 위의 예시용 도메인은 문법 설명을 위한 것으로 속도 테스트 대상이 아닙니다. 실제 검증에는 접근 권한이 있고 결과가 안정적인 리소스를 사용한 뒤 연결 기록에서 적용된 정책을 확인하세요. 더 자세한 문법은 규칙 키워드와 매칭 범위를 참고하고, 일부 사이트만 프록시를 사용하려면 특정 웹사이트 라우팅 안내를 확인하세요.

오류가 발생한 단계에 따라 진단하세요

첫 번째 단계는 접속 지점 확인과 연결 상태입니다. Server, Port, 현재 네트워크를 확인하고 서버 도메인이 예상한 주소로 확인되는지 살펴보세요. 두 번째 단계는 보안과 인증입니다. 프로토콜에 따라 인증서 이름, 기기 시간, 비밀번호, UUID, 키를 확인하세요. 세 번째 단계는 업무와 라우팅입니다. 규칙, DNS, UDP, 대상 접근 권한, 대용량 전송을 살펴봅니다. 인증 단계에 도달하지 못했다면 사용자 식별 정보를 다시 만들지 마세요. 접속이 이미 수립되었다면 포트만 반복해서 바꾸지 마세요.

Connectivity Test 결과는 해당 테스트가 실제로 무엇을 측정하는지에 맞춰 해석해야 합니다. 특정 연결이나 요청에 걸린 시간을 나타낼 수 있지만 실제 업무의 모든 경로를 확인하는 것은 아니며 지속 처리량과도 다릅니다. 테스트는 성공했는데 앱은 실패한다면 실제 요청에 사용되는 도메인, 프로토콜, 정책을 살펴보세요. 반대로 테스트는 실패했지만 일부 작업이 된다면 테스트 대상 자체에 접근할 수 있는지 확인해야 합니다. 한 번의 결과를 유일한 결론으로 삼지 말고 관련 증거를 함께 비교하세요.

속도를 비교할 때는 매 회차 변수 하나만 바꾸고 같은 기기와 네트워크에서 비슷한 시간 동안 테스트하세요. 백그라운드 동기화, 시스템 업데이트, 다른 기기의 대역폭 사용은 되도록 피하고, 최초 연결인지 이미 연결된 상태인지, 신호가 약한 장소인지 기록하세요. 배터리를 비교하려면 반복 가능한 동일한 작업을 더 긴 시간 동안 실행해야 합니다. 시스템 배터리 통계는 참고 자료가 될 수 있지만 모든 네트워크 사용량을 특정 프로토콜 탓으로 돌릴 수는 없습니다. 짧은 시간의 발열도 전송량과 함께 해석해야 합니다.

검증이 끝나면 일상 사용에 필요한 Global Routing과 규칙으로 되돌리고, 더 이상 쓰지 않는 테스트 복사본을 삭제하세요. 원래 정보와 유효한 설정을 연결해 보관합니다. 최초 연결 순서는 사용 튜토리얼에서 확인하고 자주 묻는 사용 질문은 초보자 질문 빠른 답변을 참고하세요. 이 페이지는 프로토콜 선택과 설정 항목을 설명하며 서버 관리나 App Store 구매 범위를 대신하지 않습니다. 시스템 요구 사항은 App Store 페이지에 표시된 내용을 기준으로 확인하세요.