Shadowrocket
프로토콜 설명 및 선택
먼저 서버에서 지원하는 프로토콜을 확인한 뒤 전송 방식, 속도, 배터리 사용량을 비교하세요.
이 페이지는 보유한 구독 또는 서버 정보를 바탕으로 프로토콜 유형과 설정값을 확인할 수 있는 참고 매뉴얼입니다. 처음 추가하고 연결하는 경우에는 빠른 시작을 따라 기본 절차를 완료한 뒤, 해당 장에서 차이를 확인하세요. 각 점검 항목은 안내된 절차에 따라 직접 확인할 수 있습니다.
연결 계층과 점검 순서
프로토콜, 전송, 보안 계층, 규칙을 구분해 한 번에 여러 변수를 바꾸지 마세요.
프로토콜 유형은 속도 등급이 아닙니다
Add Server에서 Type을 선택하는 것은 클라이언트와 원격 서버가 데이터를 주고받을 때 사용할 형식을 지정하는 것입니다. 속도 등급을 고르는 항목이 아닙니다. 서버에서 사용하는 프로토콜과 호환되는 유형을 선택하고 그에 맞는 인증 정보를 입력해야 합니다. 같은 주소에 여러 포트가 열려 있어도 포트마다 제공되는 서비스가 다를 수 있습니다. Shadowsocks 항목의 유형을 Trojan으로 바꾼다고 서버 프로토콜까지 자동으로 바뀌지는 않습니다. 먼저 보유한 서버가 어떤 프로토콜을 지원하는지 확인한 다음, 사용할 수 있는 선택지를 비교하세요.
완전한 연결 정보에는 보통 네 가지 요소가 포함됩니다. 주소와 포트는 서비스를 찾고, 프로토콜과 인증 정보는 세션을 설정하며, TCP·WebSocket 또는 UDP 기반 전송은 데이터를 전달합니다. TLS 등의 보안 계층은 해당 연결을 암호화하고 서버 신원을 확인합니다. 프로토콜에 따라 자체 암호화를 제공하기도 하고 외부 보안 계층을 이용하기도 합니다. 필요한 필드 수와 전송 경로 설정도 다릅니다. 이름이 같더라도 전송 방식이 다른 두 설정은 주소와 비밀번호만 같다고 서로 바꿔 쓸 수 없습니다. 구독을 가져온 뒤에는 추가 정보가 제대로 유지됐는지도 확인하세요.
앱 요청이 처리되는 과정
iPhone 또는 iPad에서 Shadowrocket을 활성화하면 시스템이 해당 트래픽을 네트워크 확장 기능으로 전달하고, 앱은 현재 설정에 따라 연결 방식을 결정합니다. Global Routing에서 Config는 현재 설정의 규칙에 따라 처리한다는 뜻입니다. Proxy는 처리 대상 요청에 프록시 경로를 사용하고, Direct는 직접 연결합니다. 이 설정은 라우팅 경로를 정할 뿐 프로토콜 인증 오류를 해결하거나 서버에 없는 기능을 추가하지 않습니다. 요청이 이미 DIRECT 규칙에 해당한다면 원격 프로토콜을 바꿔도 해당 요청의 경로는 달라지지 않습니다.
DNS 조회, 규칙 판단, 클라이언트에서 서버로의 연결, 서버에서 목적지로의 연결은 각각 다른 실패 지점입니다. 웹페이지가 열리지 않는 원인은 도메인 조회 실패일 수도, TLS 검증 오류나 인증 실패, 목적지에 연결할 수 없는 문제일 수도 있습니다. Connectivity Test 결과는 지정된 테스트 절차만 보여 줄 뿐 모든 목적지와 포트, UDP 앱의 정상 작동을 보장하지 않습니다. 문제를 판단할 때는 단순히 “연결됨” 또는 “속도가 느림”이라고 뭉뚱그리지 말고 어느 단계에서 발생했는지 기록하세요.
| 계층 | 확인할 항목 | 흔한 오해 |
|---|---|---|
| 서비스 접속 지점 | Address, Port 및 연결 가능 여부 | 주소가 조회되면 포트에도 연결할 수 있다 |
| 프로토콜 인증 | Type, Password, UUID 또는 키 | 포트가 같으면 인증 방식도 같다 |
| 전송 및 TLS | 전송 유형, 경로, SNI, 인증서 | 모든 프로토콜에 비밀번호 하나만 있으면 된다 |
| 라우팅 및 DNS | Global Routing, 규칙 적용 결과, 조회 결과 | 모든 요청이 선택한 항목을 이용한다 |
조건을 고정해 반복 비교하기
프로토콜도 속도와 배터리 사용량에 영향을 주지만, 경로의 거리, 서버 부하, 무선 신호, 대상 서비스, 데이터 유형이 더 큰 영향을 미치는 경우가 많습니다. 기기, 네트워크, 대상, 테스트 시간을 동일하게 유지한 뒤 짧은 페이지의 첫 응답과 지속 전송의 안정성을 각각 확인하세요. 한 번 측정한 지연 시간만 비교하면 DNS 캐시나 연결 재사용의 차이를 프로토콜의 장점으로 오해할 수 있습니다. 대용량 파일의 최고 속도만 보면 자주 발생하는 짧은 연결과 기기 깨우기에 드는 비용을 놓칠 수 있습니다. 추상적인 프로토콜 순위보다 테스트 조건을 기록하는 편이 유용합니다.
배터리 사용량은 무선 연결이 활성화된 시간, 백그라운드 연결 유지, 재시도 횟수, 전송 효율을 중심으로 살펴보세요. 암호화 알고리즘이 가볍다고 항상 배터리를 절약하는 것은 아니며, 연결을 계속 재시도하면 단순해 보이는 설정도 자원을 더 사용할 수 있습니다. Wi-Fi와 셀룰러 네트워크를 오가며 판단하지 말고 같은 네트워크에서 관찰하세요. 특정 요청이 어떤 경로를 선택했는지 확인하려면 Global Routing의 세 가지 모드 안내를 참고하세요. 처음 설정하는 경우에는 빠른 시작의 순서대로 확인하세요.
Shadowsocks
필드는 비교적 간단하며, 암호화 방식과 인증 정보 형식이 원격 서버 설정과 일치하는지가 중요합니다.
설계 배경과 주요 특징
Shadowsocks는 암호화된 프록시 연결을 위해 설계됐으며, 일반적인 설정에는 서버 주소, 포트, 암호화 방식, 비밀번호가 포함됩니다. 가상 네트워크 터널처럼 인터페이스 주소와 전체 라우팅을 설정할 필요 없이, 클라이언트가 해당 요청을 원격 서버로 전달합니다. 필드가 간결해 확인하기 쉽지만 모든 암호화 방식이 서로 호환된다는 뜻은 아닙니다. 프로토콜 세대, 암호화 방식, 확장 옵션에 따라 호환 조건이 달라집니다. 항목을 받으면 Shadowsocks라는 이름만 기억하지 말고 정확한 암호화 방식까지 확인하세요.
일반적인 AEAD 방식은 기밀성을 제공하는 동시에 메시지를 인증해 데이터가 변조됐는지 확인합니다. 최신 프로토콜 설계에서는 세션, 재전송 방지, 키 형식이 달라질 수 있으므로 아무 텍스트 비밀번호나 모든 방식에 입력할 수는 없습니다. 특히 정해진 길이의 인코딩 키가 필요한 방식은 해당 형식에 맞는 인증 정보가 필요합니다. 이름만 보고 특정 방식이 더 빠르거나 안전하다고 단정할 수 없습니다. 우선 원격 서버 구현과 현재 앱의 지원 여부에 따라 사용할 수 있는 범위가 정해지고, 이후 기기와 네트워크에서 테스트해 판단할 수 있습니다.
Address, Port, Method 및 Password
Address에는 도메인 또는 IP 주소를, Port에는 서비스가 수신 대기하는 포트를 입력합니다. 두 값은 동일한 유효 서버 정보에서 가져와야 합니다. 도메인에 웹페이지 경로를 붙이거나 전체 구독 링크를 서버 주소란에 붙여 넣지 마세요. Method는 원격 서버 설정과 정확히 일치해야 하며 Password도 받은 그대로 입력해야 합니다. 복사할 때 앞뒤 공백, 줄바꿈, 전각 문자가 들어가지 않았는지 확인하세요. 구독에 같은 이름의 항목이 여러 개 있다면 표시 이름만 보고 동일한 서버라고 판단하지 마세요. 주소, 포트, 방식을 각각 확인해 이미 만료된 다른 항목을 수정하지 않도록 주의하세요.
일부 기존 설정에는 플러그인이나 추가 전송 매개변수가 포함될 수 있지만, 모든 Shadowsocks 연결에 공통으로 필요한 항목은 아닙니다. 원격 서버가 해당 기능을 명시적으로 사용하고 현재 앱에서도 관련 매개변수를 설정할 수 있을 때만 입력하세요. 다른 사람의 스크린샷만 보고 TLS, 경로, Host를 추가하면서 설정을 복잡하게 만드는 것은 해결책이 아닙니다. 가져온 뒤 알 수 없는 필드가 있거나 정보가 빠졌다면 원래 정보를 제공한 곳에 호환 형식을 확인하세요. 매개변수를 계속 추측해 입력하기보다 원본 정보를 대조하는 편이 좋습니다.
TCP, UDP 및 모바일 기기에서의 동작
웹 브라우징은 보통 TCP를 주로 사용하지만 UDP 기반 앱 프로토콜도 있을 수 있습니다. Shadowsocks 항목이 어떤 트래픽을 처리할 수 있는지는 클라이언트, 원격 서버, 중간 네트워크가 해당 전달 방식을 모두 지원하는지에 달려 있습니다. 웹페이지가 열린다고 UDP 연결까지 정상이라고 볼 수는 없으며, 반대로 실시간 앱 하나가 실패해도 비밀번호 오류라고 단정할 수 없습니다. 먼저 일반 웹페이지로 기본 연결을 확인하고, UDP가 필요한 대상을 별도로 테스트한 다음 원격 서버의 관련 포트와 네트워크 정책을 점검하세요.
iOS에서는 연결 구조가 단순하면 일상적인 짧은 요청이 안정적으로 처리될 수 있지만, 지연 시간과 처리량은 실제 경로에 따라 달라집니다. 지속 전송 시 암호화 처리, 무선 신호, 서버의 전송 능력이 배터리 사용량에 영향을 줍니다. 접속이 뜸한 경우에는 연결 설정과 무선 기능을 깨우는 과정이 더 중요할 수 있습니다. 네트워크가 불안정해 시간 초과가 반복된다면 암호화 방식을 바꿔도 해결되지 않을 수 있습니다. 연결 자체가 성립하지 않은 경우와 연결 후 전송이 느린 경우를 구분해, 접속 가능 여부와 지속 전송 조건 중 무엇을 점검할지 판단하세요.
사용 상황과 문제 해결 범위
보유한 서버가 Shadowsocks만 제공한다면 원본 정보를 그대로 가져오는 것이 올바른 선택입니다. 프로토콜 이름 때문에 다른 방식으로 옮길 필요는 없습니다. 같은 서버가 호환되는 여러 선택지를 제공한다면 필드가 적고 기본 문제를 파악하기 쉬운 방식을 비교 대상으로 삼을 수 있습니다. 연결에 실패하면 DNS, 포트, Method, Password를 확인한 뒤 UDP와 추가 옵션을 점검하세요. 네트워크를 바꾼 뒤 정상 작동한다면 인증 정보를 계속 초기화하지 말고 네트워크 조건을 살펴보세요. 라우팅 규칙도 별도로 확인해야 합니다. DIRECT 규칙이 적용된 요청을 Shadowsocks 테스트 결과로 잘못 판단하지 않도록 주의하세요.
VMess 및 VLESS
인증 프로토콜, 전송 방식, 보안 계층을 구분하세요. UUID만으로 설정이 완성되는 것은 아닙니다.
두 프로토콜의 차이
VMess는 사용자 인증과 데이터 보호 등의 메커니즘을 프로토콜에 포함하며, 일반적으로 UUID를 사용자 식별 정보로 사용합니다. VLESS는 프로토콜 자체를 더 간결하게 설계하고 데이터 보호는 보통 함께 사용하는 보안 계층에 맡깁니다. VLESS 자체에는 VMess와 같은 내장 암호화 의미가 없습니다. 사용자 식별자 형식이 같더라도 두 프로토콜은 서로 바꿔 쓸 수 없습니다. Type은 서버가 실제로 수신하는 프로토콜에 맞춰야 합니다. UUID가 있다는 이유만으로 유형을 추측해서는 안 됩니다.
이러한 연결은 TCP, WebSocket, TLS 설정과 함께 사용되는 경우가 많아 프로토콜과 전송 방식을 혼동하기 쉽습니다. 각 항목을 계층별 조합으로 이해할 수 있습니다. UUID는 사용자 식별에, 전송 방식은 데이터 교환에, TLS는 해당 보안 채널에 사용됩니다. 서버가 특정 조합만 허용한다면 UUID가 정확해도 경로나 보안 계층이 다를 경우 연결에 실패합니다. 여기서 든 조합은 이해를 돕기 위한 예시이며, 실제 선택지는 현재 앱 화면과 원격 서버 안내를 기준으로 확인하세요.
인증 필드와 시간 조건
UUID는 원본 그대로 복사해야 하며 표시 이름, 일반 비밀번호, 구독 식별자로 대체할 수 없습니다. 구독 링크의 접근 정보는 설정을 가져오는 데 쓰이고, 개별 서버의 UUID는 해당 서비스에 연결할 때 사용됩니다. 일부 VMess 기존 설정에는 추가 인증 매개변수가 포함되지만 예전 예시의 값을 모든 서버에 적용할 수는 없습니다. 정보 제공처에 해당 필드가 있으면 하나씩 대조하세요. 링크만 제공받았다면 값을 추측해 추가하기보다 가져오기 과정에서 정보가 제대로 유지됐는지 확인하세요.
VMess 인증에는 시간 조건이 관여하므로 기기 시간이 크게 어긋나면 연결 문제가 생길 수 있습니다. 시스템 날짜와 시간이 정상적으로 동기화됐는지 확인한 뒤 같은 항목으로 다시 시도하세요. 다만 모든 실패를 시간 문제로 돌려서는 안 됩니다. VLESS의 필드가 적어도 TLS나 기타 관련 검증을 생략할 수 있다는 뜻은 아닙니다. 두 프로토콜 모두 사용자 식별 정보 오류, 잘못된 서비스 포트를 가리키는 문제, 전송 경로 불일치, 보안 계층 불일치로 연결이 빠르게 종료될 수 있습니다. 대기 시간만으로 원인을 정확하게 구분하기는 어렵습니다.
WebSocket, Host, Path 및 TLS
WebSocket을 사용할 때 Path는 서버가 연결을 처리하는 경로입니다. 앞의 슬래시, 대소문자, 필요한 쿼리 내용을 그대로 유지하세요. Host는 HTTP 요청 라우팅에 사용될 수 있고, TLS의 SNI는 핸드셰이크 중 서버 이름을 선택하는 데 사용됩니다. 두 값이 같을 때도 있지만 배포 구조에 따라 다를 수 있습니다. 두 값을 모두 Address와 같게 맞추려 하지 마세요. Address는 접속 지점을 지정하고 Host와 SNI는 각각 다른 계층의 이름을 나타낼 수 있습니다. 올바른 조합은 원격 서버 구성 정보를 확인해야 합니다.
TLS 인증서는 예상한 서버 이름과 일치하도록 검증해야 합니다. 인증서 오류가 발생하면 SNI, 기기 시간, 인증서 유효 기간, 연결 주소를 먼저 확인하세요. 검증을 건너뛰어 오류를 숨기면 안 됩니다. VLESS에서 추가 보안 기능이나 특정 전송 옵션을 사용한다면 현재 앱과 원격 서버가 모두 지원해야 합니다. 다른 설정의 필드를 그대로 가져와서는 안 됩니다. 설정을 가져올 수 있다는 것은 일부 정보를 앱이 읽었다는 뜻일 뿐, 모든 조합으로 연결되거나 원격 서버에서 해당 기능을 사용한다는 의미는 아닙니다.
속도, 배터리 및 비교 방법
WebSocket에 TLS를 추가하면 핸드셰이크와 캡슐화에 따른 비용이 생기지만, 일상적인 연결이 반드시 느려진다고 단정할 수는 없습니다. 연결 재사용, 접속 위치, 경로 품질, 원격 서버 부하에 따라 차이가 줄거나 커질 수 있습니다. 짧은 요청이 많다면 첫 접속과 이후 접속의 차이를 확인하고, 지속 다운로드에서는 속도가 안정적으로 유지되는지 살펴보세요. 첫 핸드셰이크와 재사용 중인 연결을 직접 비교하지 마세요. iOS 배터리 사용량도 동일한 네트워크 조건에서 관찰해야 합니다. 설정 필드 수보다 연결 재시도가 계속 발생하는지가 더 중요할 수 있습니다.
보유한 정보에 VMess와 VLESS가 모두 포함되어 있다면 이름의 최신성으로 결정하지 말고, 매개변수가 명확하고 현재 앱이 지원하며 원격 서버 상태가 확인된 설정을 선택하세요. 문제를 해결할 때는 완전한 항목 하나를 고정하고 Type, UUID, 전송 방식, Path, Host, TLS를 순서대로 확인하세요. 원본 정보와 다른 점이 확인된 필드만 한 번에 하나씩 수정하세요. 가져온 뒤 목록에 항목이 없다면 구독 가져오기 및 빈 목록 확인 방법을 참고해 설정 가져오기 문제와 프로토콜 연결 문제를 구분하세요.
Trojan 및 TLS 점검
비밀번호 인증뿐 아니라 인증서 이름과 핸드셰이크 조건도 연결 성립 여부를 좌우합니다.
TLS 기반 설계의 주요 특징
Trojan은 TLS 연결 안에서 프록시 세션을 설정하고 비밀번호 인증으로 사용자를 확인합니다. 외부 TLS와 내부 인증을 구분해서 이해해야 합니다. TLS는 보안 채널을 만들고 서버 신원을 확인하며, 비밀번호는 프로토콜 수준에서 접근을 인증합니다. TLS 핸드셰이크에 성공해도 비밀번호가 맞다는 뜻은 아니며, 비밀번호가 맞아도 인증서 이름이 일치하지 않으면 연결할 수 없습니다. 암호화 방식 하나만 확인하는 설정에 비해 Trojan은 도메인, 인증서, 접속 지점의 연결 관계를 더 꼼꼼히 살펴야 합니다.
이 설계는 널리 사용되는 TLS 생태계를 활용하지만 인증서 유효 기간, 이름 검증, 핸드셰이크 협상 등의 요구 사항도 따릅니다. 일반 웹 연결과 같은 것은 아니며 HTTPS를 지원하는 주소라면 무엇이든 Trojan 서버로 쓸 수 있는 것도 아닙니다. 원격 서버에서 해당 서비스를 실제로 제공하고 인증이 설정되어 있어야 전체 세션을 연결할 수 있습니다. 필요한 것은 이미 보유한 완전한 서버 정보이지, 웹사이트 주소와 흔한 포트 번호를 조합해 임의로 만든 항목이 아닙니다.
Address, Password, SNI의 역할
Address는 네트워크 연결을 시작하는 접속 지점이고 Port는 서비스 포트입니다. Password는 원격 서버의 인증 설정과 일치해야 합니다. SNI는 TLS 핸드셰이크에서 대상 이름을 전달하며, 서버는 이를 기준으로 인증서와 처리 경로를 선택할 수 있습니다. IP 주소에 연결하더라도 도메인 형식의 SNI를 지정해야 할 수 있습니다. 반대로 Address가 도메인이라고 해서 원본 설정의 요구 사항을 무시해도 되는 것은 아닙니다. 기존 정보에 SNI가 명시되어 있다면 현재 표시된 서버 이름으로 바꾸지 말고 그대로 유지하세요.
인증서를 검증하려면 인증서 체인을 신뢰할 수 있어야 하고, 유효 기간 내에 있어야 하며, 예상하는 검증 대상 이름을 포함해야 합니다. 오류가 발생하면 기기 시간과 이름을 먼저 확인한 뒤 서버 인증서가 올바르게 배포됐는지 살펴보세요. 접속 지점만 바뀐 경우에는 서버 설정 안내를 통해 관련 필드를 확인해야 합니다. 클라이언트에서 검증을 끄지 마세요. 검증을 건너뛰면 서버 신원 확인이 약해집니다. 비밀번호 오류를 해결하지도, 원래 접속하려던 서버에 연결된다는 보장도 없습니다.
핸드셰이크, 앱 요청, UDP의 범위
TLS 핸드셰이크에 성공해도 연결 경로의 일부만 확인된 것입니다. 이어서 Trojan 인증을 통과하고 원격 서버가 목적지에 연결해 데이터를 돌려줘야 합니다. 따라서 “핸드셰이크는 되지만 페이지가 열리지 않는” 경우에는 인증과 원격 접속을 계속 확인하세요. 핸드셰이크 전에 시간 초과가 발생한다면 DNS 조회와 접속 지점의 연결 가능 여부부터 점검하는 편이 좋습니다. 특정 사이트만 실패한다면 규칙 적용 결과와 DNS 조회 결과도 확인하세요. 단계를 나눠 확인하면 모든 문제를 인증서 탓으로 돌리거나 이미 맞는 비밀번호를 계속 바꾸는 일을 줄일 수 있습니다.
Trojan의 UDP 전달 기능은 클라이언트와 서버가 함께 지원해야 하며 실제 동작은 전송 방식에도 영향을 받습니다. TCP 웹페이지가 정상적으로 열린다고 실시간 상호작용 트래픽까지 적합하다고 볼 수 없습니다. 일부 전송 구조에서는 패킷 손실이 대기 시간 증가로 나타날 수 있습니다. 실제 대상 앱으로 테스트하고 단일 웹페이지 결과에만 의존하지 마세요. 추가 전송 계층이 포함된 항목은 원본 설정을 기준으로 확인해야 합니다. 기본 Trojan 필드 목록을 모든 변형에 그대로 적용하지 마세요.
iOS에서 속도와 배터리 확인하기
TLS 핸드셰이크에는 네트워크 왕복과 계산이 필요하므로 장거리 경로에서는 첫 연결의 대기 시간이 더 크게 느껴질 수 있습니다. 이후 연결에서 비용이 줄어드는지는 구체적인 세션과 구현에 따라 다릅니다. 지속 전송에서는 첫 핸드셰이크보다 경로 품질, 혼잡 상태, 원격 서버 성능이 더 큰 영향을 미치는 경우가 많습니다. 배터리 사용량을 줄이려면 안정적인 연결과 불필요한 재시도 방지가 도움이 되지만, 오랜 시간 연결을 유지하면 무선 활동이 늘어납니다. TLS를 사용한다는 이유만으로 배터리를 많이 쓴다고 단정하거나 모든 네트워크에서 다른 프로토콜보다 낫다고 보장할 수는 없습니다.
보유한 서버에서 안정적으로 작동하는 Trojan 설정을 제공하고 인증서 이름, 비밀번호, 전송 정보가 모두 갖춰져 있다면 검증할 수 있는 선택지로 사용할 수 있습니다. 비교할 때는 대상과 네트워크를 고정하고 먼저 세션이 안정적으로 설정되는지, 이후 지속 전송과 백그라운드 상태가 어떤지 확인하세요. 업데이트 후 연결에 실패하면 구독 정보에 인증서 관련 이름이나 접속 지점 변경 사항이 반영됐는지 확인하세요. 업데이트 절차는 구독 수동 및 자동 업데이트 안내를 참고하고, 매개변수를 추측해 설정 동기화를 대신하지 마세요.
HTTP 및 SOCKS5
일반 프록시 인터페이스는 암호화된 터널과 다릅니다. DNS 조회 위치와 UDP 지원 여부를 각각 확인하세요.
일반 프록시 프로토콜의 기본 개념
HTTP 프록시는 HTTP 요청을 중계하기 위해 만들어졌습니다. HTTPS 대상에 연결할 때는 일반적으로 CONNECT를 사용해 지정된 대상과 바이트 통신 채널을 설정합니다. SOCKS5는 대상 주소와 포트를 지정할 수 있는 더 범용적인 프록시 협상 방식을 제공하며 웹 요청에만 한정되지 않습니다. 이 두 프로토콜은 기존 내부 네트워크나 명확히 관리되는 프록시 접속 지점에서 자주 사용됩니다. 필드가 간단해 보여도 실제 배포 환경에 따라 보안과 사용 가능한 기능이 달라집니다. “프록시 지원”을 암호화 보호 제공으로 받아들여서는 안 됩니다.
일반 HTTP 프록시와 HTTPS 프록시를 구분해야 합니다. 전자는 클라이언트와 프록시 사이에서 사용하는 기본 프로토콜을 가리키며, 후자는 이 연결에 TLS를 사용합니다. 접속 대상이 HTTPS 웹사이트라고 해서 클라이언트와 HTTP 프록시 사이의 모든 협상 정보까지 같은 수준으로 보호되는 것은 아닙니다. SOCKS5 기본 프로토콜도 전체 전송 구간의 암호화를 제공하지 않습니다. 네트워크에서 기밀성이 필요하다면 대상 URL이 HTTPS인지에만 의존하지 말고 기존 접속 지점에 보안 계층이 있는지 확인하세요.
사용자 이름, 비밀번호 및 허용되는 대상
Address와 Port는 실제 프록시 접속 지점을 가리킵니다. Username과 Password는 원격 서버에서 해당 인증을 요구할 때만 입력하세요. 인증 정보를 비워 두는 경우와 잘못 입력하는 경우 결과가 다를 수 있으며, 아무 계정 정보나 프록시 비밀번호로 쓸 수는 없습니다. HTTP 프록시는 CONNECT로 접속할 수 있는 대상 포트에 제한을 둘 수 있고 특정 대상만 허용할 수도 있습니다. 따라서 웹페이지 하나가 열린다고 이메일, 실시간 통신, 다른 포트도 모두 통과한다고 볼 수 없습니다. 문제를 해결하기 전에 기존 프록시의 접근 범위를 확인해 정책 제한을 앱 오류로 오인하지 않도록 하세요.
SOCKS5는 여러 인증 방식을 협상할 수 있지만 클라이언트와 서버에서 같은 방식을 지원해야 합니다. 가져온 뒤에는 포트 번호만 보고 판단하지 말고 유형이 SOCKS5로 인식됐는지 확인하세요. 흔히 사용하는 포트는 관례일 뿐 실제 서비스가 다른 포트를 사용할 수도 있습니다. 반대로 익숙한 포트 번호에서 전혀 다른 서비스가 실행 중일 수도 있습니다. 연결이 거부되면 주소와 수신 상태를 먼저 확인하고, 인증에 실패하면 해당 계정을 점검하세요. 포트, 유형, 비밀번호를 한꺼번에 바꾸면 원인을 찾고 재현하기 어려워집니다.
| 항목 | HTTP | SOCKS5 |
|---|---|---|
| 주요 방식 | HTTP 요청 전달 또는 CONNECT | 일반 프록시 협상 및 대상 연결 |
| 기본 프로토콜의 암호화 | 일반 HTTP는 자체적으로 TLS를 제공하지 않음 | 기본 프로토콜 자체에는 암호화 기능이 없음 |
| UDP | 일반 CONNECT를 범용 UDP 전달로 볼 수 없음 | 프로토콜에 UDP ASSOCIATE가 정의되어 있지만 양측 지원이 필요함 |
| 대상 제한 | CONNECT 포트 및 대상에 제한이 있을 수 있음 | 인증, 주소 정책, 전달 기능에 따라 제한될 수 있음 |
DNS 조회가 이루어지는 위치
프록시 협상에 도메인 이름이 포함될 수도 있고 이미 조회된 IP 주소가 포함될 수도 있습니다. 이에 따라 어느 쪽에서 이름을 조회하는지가 달라집니다. 실제 동작은 클라이언트 설정, 규칙 요구 사항, 프로토콜 사용 방식에 따라 결정되므로 SOCKS5를 선택했다고 DNS 조회가 반드시 원격에서 이루어지는 것은 아닙니다. 설정에서 조회 결과에 따라 IP 규칙을 적용해야 한다면 로컬에서 관련 DNS 요청이 발생할 수도 있습니다. 문제를 진단할 때는 도메인이 조회되는지, 결과가 적절한지, 프록시 서버가 대상에 연결할 수 있는지 각각 확인하세요. DNS 주소 하나만 바꾸면 모든 문제가 해결된다고 기대해서는 안 됩니다.
SOCKS5에는 UDP ASSOCIATE가 정의되어 있지만 원격 서버에서 기능을 활성화하지 않았을 수도 있고, 네트워크가 응답 경로를 허용하지 않거나 클라이언트에서 기능을 사용하지 않을 수도 있습니다. HTTP 프록시의 일반 CONNECT를 범용 UDP 전달 기능으로 취급해서는 안 됩니다. 웹페이지는 열리는데 실시간 앱이 실패한다면 해당 서비스가 UDP에 의존하는지 확인한 뒤 원격 서버가 명시적으로 지원하는 기능을 점검하세요. 실제 원인이 전달 기능 미지원인데 사용자 이름을 계속 바꾸지 마세요. 두 문제는 서로 다른 계층에 있습니다.
속도, 배터리 및 사용 범위
캡슐화가 적으면 일부 처리 비용을 줄일 수 있지만 경로 혼잡, 인증 대기, 원격 제한까지 없어지는 것은 아닙니다. iOS에서 짧게 테스트하면 캐시나 대상 차이 때문에 결과가 달라질 수 있습니다. 대상을 고정하고 연결 설정과 실제 전송 상태를 각각 기록하세요. 기존 HTTP 또는 SOCKS5 접속 지점은 명확히 지원되는 용도로 사용해야 하며 모든 터널 프로토콜을 대체한다고 가정해서는 안 됩니다. DNS 조회를 더 확인하려면 DNS 및 DNS over HTTPS 설정 안내를 참고하고 현재 규칙과 함께 요청이 실제로 지나가는 경로를 확인하세요.
WireGuard
키와 가상 네트워크 주소로 터널을 설정합니다. 일반 프록시의 비밀번호 방식과 혼동하지 마세요.
터널 프로토콜과 프록시 항목의 차이
WireGuard는 구조가 간결한 암호화 네트워크 터널을 만들기 위해 설계됐으며, 고정된 암호 알고리즘 조합을 사용하고 공개 키로 상대를 식별합니다. 네트워크 계층의 패킷을 처리하므로 설정에는 인터페이스 주소, 상대 키, 라우팅 범위 등이 포함됩니다. 프록시 비밀번호 하나만 입력하는 방식과 다릅니다. Shadowrocket에서 해당 항목을 사용하는 방법은 앱의 트래픽 처리와 규칙 기능을 함께 고려해야 합니다. 독립된 터널 설정의 모든 옵션이 앱의 특정 필드와 완전히 동일하다고 확인 없이 간주해서는 안 됩니다.
사용자 이름이나 UUID를 쓰는 프로토콜과 달리 WireGuard는 로컬 비밀 키와 원격 공개 키가 올바르게 연결되어야 합니다. 원격 서버도 로컬 공개 키를 알고 있어야 하며 적절한 주소와 접근 범위를 설정해야 합니다. Endpoint만 복사하거나 원격 공개 키만 가져오는 것으로는 연결을 완성할 수 없습니다. 설정 파일을 받았다면 먼저 Interface와 Peer가 각각 어느 쪽을 설명하는지 확인한 뒤 현재 앱에서 지원하는 방식으로 가져오세요. 원본 파일도 보관해 각 항목을 대조할 수 있도록 하세요.
키, Endpoint 및 주소 필드
PrivateKey는 로컬 비밀 정보이므로 공개 스크린샷이나 문의 내용에 올리지 마세요. Peer의 PublicKey는 일반적으로 원격 공개 키를 뜻하며 두 키를 서로 바꿔 쓸 수 없습니다. 일부 설정에는 추가 공유 비밀인 PresharedKey가 포함되며 양쪽에서 일치해야 합니다. 실제로 사용할 수 있는 자격 증명으로 오해하지 않도록 여기에는 키 예시를 넣지 않습니다. 문제를 설명할 때는 필드가 있는지, 가져오기 오류가 발생했는지, 오류 유형이 무엇인지 알려 주면 됩니다. 실제 키를 제출할 필요는 없습니다.
Endpoint는 원격 서버에 연결할 수 있는 주소와 UDP 포트를 뜻합니다. Address는 일반적으로 터널 안에서 로컬 기기에 할당되는 주소이며, 두 필드는 서로 다른 주소 공간에서 다른 역할을 합니다. DNS는 이름 조회 설정을 나타내고, WireGuard에서 AllowedIPs는 상대가 처리할 수 있는 주소 범위와 라우팅 선택에 연결됩니다. 원격 서버가 내부 네트워크 하나만 허용한다면 클라이언트에서 범위를 모든 주소로 넓혀도 전달 기능이 추가되지는 않습니다. 서버 측 라우팅과 전달, 응답 경로가 모두 정상이어야 합니다.
UDP, Keepalive 및 모바일 네트워크
WireGuard는 보통 UDP로 데이터를 전송하므로 네트워크에서 클라이언트와 Endpoint 사이의 해당 포트 통신을 허용해야 합니다. Wi-Fi에서는 정상인데 셀룰러 네트워크에서 문제가 발생한다면 키 오류뿐 아니라 UDP 경로, 주소 변경, 네트워크 주소 변환이 원인일 수 있습니다. 먼저 유효한 핸드셰이크가 있는지 확인한 다음 실제 서비스 요청이 통과하는지 점검하세요. 핸드셰이크가 됐다고 DNS, 대상 라우팅, 응답 경로까지 모두 정상인 것은 아닙니다. 특히 내부 네트워크에 접속할 때는 해당 네트워크가 현재 로컬 네트워크와 주소 범위가 겹치는지 확인하세요.
PersistentKeepalive는 필요한 경우 네트워크 매핑을 유지하는 데 사용하지만 값이 작을수록 안정적인 것은 아닙니다. 패킷을 자주 보내면 무선 활동과 배터리 사용량이 늘 수 있으며, 필요하지 않은데 켜 두어도 이득이 없을 수 있습니다. 설정 여부와 값은 기존 서버 구성 요구 사항과 실제 유휴 연결 끊김 현상을 바탕으로 판단하세요. 모든 환경에 같은 값을 적용하지 마세요. 화면 잠금, 네트워크 전환, 기기 재활성화 후의 동작도 따로 관찰해야 합니다. 화면을 켜 둔 상태의 한 번의 성공만으로 백그라운드 안정성을 판단할 수 없습니다.
MTU와 적용 범위
MTU는 관련 인터페이스에서 전송할 수 있는 패킷 크기를 나타냅니다. 캡슐화된 패킷이 경로에서 처리할 수 있는 크기를 초과하고 필요한 응답이 제대로 돌아오지 않으면 핸드셰이크와 작은 요청은 성공하지만 큰 응답이 멈출 수 있습니다. 다만 이는 여러 점검 항목 중 하나일 뿐 속도 문제마다 먼저 MTU를 바꿔야 하는 것은 아닙니다. 먼저 경로, DNS, 라우팅을 확인한 뒤 원격 안내에 따라 제한적으로 조정하고 기존 값도 기록하세요. 지나치게 작게 설정하면 패킷 수가 늘고, 지나치게 크게 설정하면 기존 문제가 계속될 수 있습니다.
관리 대상인 내부 네트워크에 접속해야 하고 관리자가 완전한 WireGuard 설정을 제공했다면 주소와 Peer 구조를 활용할 수 있습니다. 일반 프록시 용도로 사용하려면 원격 서버가 실제로 트래픽을 전달하는지 확인하세요. 내부 네트워크로 이어지는 터널만 설정되어 있을 수도 있습니다. 속도와 배터리 사용량은 무선 환경, 패킷 크기, Keepalive, 트래픽 양에 따라 달라집니다. 프로토콜 이름이 설정에 포함됐는지가 아니라 핸드셰이크, 라우팅, DNS, 대상 응답이 모두 정상인지로 판단하세요.
Hysteria2
QUIC 기반 전송은 UDP 경로가 작동해야 하며 대역폭 설정은 실제 연결에 맞춰야 합니다.
불안정한 경로를 고려한 설계
Hysteria2는 QUIC 기반 전송 구조를 사용해 지연 시간이 길거나 패킷 손실이 있는 환경에서 데이터 전달을 처리하도록 설계됐습니다. QUIC는 UDP를 기반으로 하지만 신뢰성 있는 스트림 전송을 제공할 수 있습니다. 따라서 “기반 전송이 UDP”라고 해서 모든 앱 데이터가 전송을 보장받지 못하는 것은 아닙니다. 그렇다고 불안정한 네트워크에서 항상 속도가 빨라지는 것도 아닙니다. UDP에 연결할 수 없거나 엄격한 속도 제한이 있거나 접속 지점의 부하가 크면 프로토콜 설계만으로 이런 기본 조건을 해결할 수 없습니다. 선택하기 전에 보유한 서버가 Hysteria2를 지원하는지 확인하세요.
Hysteria2는 이름이 비슷한 초기 프로토콜과 표시 이름만으로 호환 여부를 판단할 수 없습니다. 가져오기 형식과 인증 필드도 현재 앱 기준으로 확인해야 합니다. 일부 설정에는 난독화나 기타 확장 매개변수가 포함되며 원격 서버에서 같은 기능을 사용하는 경우에만 입력해야 합니다. 추가 옵션은 모든 환경에 통하는 성능 설정이 아니며 한쪽에서만 추가하면 연결 조건이 달라져 실패할 수 있습니다. 앱에서 항목을 저장할 수 있더라도 원격 서버가 실제 조합을 받아들인다는 뜻은 아니므로 전체 세션을 테스트해야 합니다.
인증, TLS 및 서버 이름
기본 점검 항목은 Address, Port, 인증 정보, TLS 관련 이름입니다. 인증 정보는 동일한 기존 설정에서 가져와야 하며 구독 링크의 자격 증명으로 대체할 수 없습니다. 가져오기 기능이 정보를 여러 필드로 나누었다면 모두 올바르게 분석됐는지 확인하세요. 전송 방식이 QUIC로 바뀌어도 SNI와 인증서 이름의 관계는 여전히 중요합니다. 기기 시간 오류, 예상 이름 불일치, 인증서 배포 문제로 인증 전후에 연결이 종료될 수 있습니다.
원격 설정에서 특정 난독화 유형과 비밀번호를 요구한다면 원본 정보를 그대로 적용하고 현재 앱이 해당 옵션을 지원하는지 확인하세요. 네트워크 연결이 되지 않는다고 모든 난독화 방식을 차례로 시도하지 마세요. 기존 문제에 새로 발생한 문제까지 더해질 수 있습니다. 포트를 바꾸려면 원격 서버가 해당 포트에서 실제로 수신 중이어야 합니다. 클라이언트에서 새로운 접속 지점을 만들 수는 없습니다. 출처는 명확하지만 필드 설명이 부족하다면 성능을 비교하기 전에 안내를 확인해 잘못 설정된 항목이 테스트에 포함되지 않게 하세요.
대역폭 설정값은 속도 측정 결과가 아닙니다
일부 설정에는 업로드, 다운로드 또는 혼잡 제어 관련 값이 포함됩니다. 이런 값은 전송 정책이나 예상 네트워크 조건을 나타낼 뿐 실제 속도를 보장하지 않으며 값이 클수록 좋은 것도 아닙니다. 지속 가능한 연결 능력보다 높게 설정하면 혼잡, 패킷 손실, 속도 변동이 커질 수 있습니다. 너무 낮게 설정하면 사용 가능한 처리량이 제한될 수 있습니다. 앱에 자동 협상이나 기본 동작이 있다면 원격 서버 안내에 따라 먼저 사용하세요. 반복해서 확인되는 문제가 있고 매개변수의 의미를 이해한 경우에만 변경 내용을 기록하며 조정하세요.
셀룰러 네트워크의 사용 가능한 대역폭은 신호, 위치, 기지국 부하에 따라 변하므로 짧은 속도 테스트의 최고값을 장기 설정에 그대로 적용하기 어렵습니다. Wi-Fi의 표시 연결 속도도 서버까지 실제로 사용할 수 있는 대역폭과 같지 않습니다. 최고 속도가 나온 순간만 보지 말고 지속 전송 중 안정적으로 유지되는 범위를 비교하세요. 확인 및 제어 트래픽에도 경로 자원이 필요하므로 업로드 대역폭도 무시할 수 없습니다. 대역폭 설정을 바꾼 뒤 배터리 사용량이 늘거나 속도 변동이 커지면 원래 값으로 되돌리고 조건을 다시 확인하세요.
iOS 성능 확인과 실패 유형
일부 패킷 손실 경로에서는 적절한 전송 방식과 혼잡 제어가 지속 전송을 개선할 수 있지만 실제 효과는 양쪽 구현과 네트워크 환경에 따라 다릅니다. 연결을 더 적극적으로 사용하면 무선 활동, 계산량, 배터리 사용량이 늘 수도 있습니다. 처리량이 높다고 배터리까지 절약되는 것은 아닙니다. 짧은 페이지의 대기 시간, 장시간 전송의 안정성, 유휴 상태 이후 재연결을 각각 확인하고 같은 시간대에 사용할 수 있는 다른 기존 항목과 비교하세요. 지연 시간 한 번만으로 QUIC 세션의 전체 동작을 판단하기는 어렵습니다.
특정 네트워크에서만 실패한다면 항목은 그대로 두고 사용 가능한 다른 네트워크로 전환해 UDP 경로 문제인지 확인하세요. 모든 네트워크에서 실패하면 주소, 포트, 인증, 인증서, 추가 매개변수를 하나씩 점검하세요. 일반 페이지는 열리지만 실시간 앱이 실패한다면 앱 트래픽 전달 기능과 기반 QUIC 연결을 구분해 살펴보세요. Hysteria2는 이미 사용할 수 있는 선택지 중 하나로 실제 테스트할 수 있지만, 별도 조건 없이 모든 연결을 개선하는 만능 해결책은 아닙니다.
사용 상황에 따른 선택과 단계별 문제 해결
이미 사용할 수 있는 조건을 바탕으로 일관된 절차에 따라 원인을 좁혀 보세요.
확인 가능한 조건으로 선택 범위 좁히기
일상적인 웹과 앱 이용에서는 설정 정보가 완전하고 세션을 안정적으로 설정할 수 있는 항목을 먼저 사용한 뒤 첫 응답과 지속 전송을 비교하세요. 내부 네트워크에 접속할 때는 WireGuard의 주소, 라우팅, Peer 권한을 확인하세요. UDP가 필요한 서비스라면 프로토콜, 원격 서버, 현재 네트워크가 모두 해당 전달 방식을 지원하는지 확인해야 합니다. 네트워크가 불안정할 때는 기존 Hysteria2 등 선택지를 테스트할 수 있지만 접속 지점의 연결 가능 여부 점검을 대신할 수는 없습니다. 선택 범위는 원격 서버가 실제 제공하는 기능으로 한정해야 하며 프로토콜 이름만으로 정답을 정해서는 안 됩니다.
배터리 사용량이 중요한 상황에서는 실제 사용 주기 동안 유휴 연결, 백그라운드 재시도, 네트워크 전환을 살펴보세요. On Demand는 연결을 시작할 시점을 제어하고 규칙은 트래픽이 향할 경로를 정합니다. 둘 다 프로토콜 선택과 관련은 있지만 같은 기능은 아닙니다. 필요한 요청이 적절한 경로를 사용하고 연결을 안정적으로 유지할 수 있어야 프로토콜 비용을 비교할 의미가 있습니다. 실패 후 재시도가 계속되면 먼저 실패 원인을 해결하세요. 필드가 적은 프로토콜로 바꾸기만 해서는 같은 네트워크 문제가 남을 수 있습니다.
| 상황 | 먼저 확인할 항목 | 비교할 항목 |
|---|---|---|
| 짧은 페이지와 일상 앱 | 인증, DNS, 규칙 적용 결과 | 첫 응답, 이후 응답, 재연결 |
| 장시간 지속 전송 | 원격 서버 부하와 지속 가능한 연결 성능 | 안정적인 처리량, 속도 변동, 기기 발열 |
| 실시간 상호작용 서비스 | UDP 전달 및 양방향 연결 가능 여부 | 지연 시간 변동, 패킷 손실, 복구 시간 |
| 명확하게 지정된 내부 네트워크 | 주소, 라우팅, 응답 경로 | 대상 연결 가능 여부, 네트워크 주소 중복, DNS |
요청이 테스트할 항목을 실제로 사용하는지 먼저 확인하세요
Config에서는 규칙의 순서에 따라 요청이 처리됩니다. 아래는 Shadowrocket의 .conf 규칙 일부만 보여 주는 예시이며 완전한 설정이 아닙니다. 도메인 접미사는 PROXY로, 지정된 사설 네트워크는 DIRECT로 보내고 나머지는 FINAL에서 최종 정책을 정합니다. 실제로 사용하기 전에 현재 설정에서 정책 참조가 유효한지와 FINAL의 영향을 확인하세요. 도메인 하나를 테스트하기 위해 원래 설정 전체를 덮어쓰지 마세요. 기존 설정을 저장한 뒤 필요한 범위만 최소한으로 테스트하세요.
[Rule]
DOMAIN-SUFFIX,example.com,PROXY
IP-CIDR,192.168.0.0/16,DIRECT
FINAL,PROXY같은 요청이 Direct에서는 정상이고 Proxy에서는 실패한다면 원격 연결을 추가로 확인할 수 있습니다. 다만 이것만으로 네트워크 전체를 진단할 수는 없습니다. 두 경로에서 DNS 조회 결과와 대상 접속 지점이 다를 수 있습니다. Config에서 문제가 발생하고 Proxy에서는 정상이라면 규칙과 DNS의 연관성을 먼저 확인하세요. Home, Config, Data, Settings의 위치는 인터페이스 영어 용어 안내를 참고해 존재하지 않는 프로토콜 옵션을 찾느라 잘못된 화면을 살펴보지 않도록 하세요.
실패 단계별 최소 점검 기록 작성
먼저 구독을 정상적으로 가져왔는지, 항목 정보가 완전한지 확인한 다음 주소 조회와 포트 연결을 점검하세요. 두 번째로 Type, 인증, 전송을 확인합니다. 세 번째로 TLS와 서버 이름을 확인하고, 마지막으로 대상 접속과 서비스 기능을 살펴보세요. 목록이 비어 있다면 아직 프로토콜 연결 단계에 도달하지 않은 것이므로 구독 가져오기나 분석 문제부터 해결해야 합니다. 핸드셰이크에 성공했지만 대상 응답이 없다면 서버에서 대상까지의 경로, 대상 제한, 응답 데이터를 확인하세요. 같은 구독을 다시 가져오는 일을 반복할 필요는 없습니다.
기기에서 사용한 네트워크 유형, 실패 당시의 Global Routing 설정, 선택한 프로토콜, 구독을 방금 업데이트했는지, 재현 가능한 오류 단계 등을 기록하세요. 오류 유형과 민감한 정보를 가린 필드 이름은 남길 수 있지만 실제 비밀번호나 키, 전체 구독 링크는 포함하지 마세요. 매번 차이가 확인된 필드 하나만 바꾸고 원래 값도 기록하세요. 효과가 없으면 원래 값으로 되돌린 뒤 다음 계층을 확인하세요. 네트워크 간 차이를 비교할 때는 서버 항목을 고정하고, 항목 간 차이를 비교할 때는 네트워크와 대상을 고정해야 변수의 영향을 줄일 수 있습니다.
설정 변경을 멈추고 기본 점검으로 돌아갈 때
같은 네트워크에서 모든 프로토콜이 실패하면 기기 네트워크, DNS, 시스템 권한부터 확인하세요. 특정 항목만 실패한다면 해당 항목의 인증 정보와 원격 서버 상태를 우선 점검하세요. 특정 대상만 실패하면 규칙과 대상 자체를 확인하세요. 모든 문제를 프로토콜 선택 문제로 바꾸어 생각하지 마세요. 관련 질문은 자주 묻는 질문에서 확인할 수 있습니다. 처음 연결하는 경우에는 빠른 시작을 따라 권한과 스위치 설정을 다시 확인하세요. 앱 받기, 구매, 호환성은 다운로드 확인 페이지에서 안내합니다. 가격과 시스템 요구 사항은 App Store 페이지를 확인하세요.