Shadowrocket
프로토콜 및 설정값 참고

프로토콜 계층: 연결에서 확인할 네 가지

프로토콜·전송·보안·라우팅은 서로 다른 계층입니다

Add Server에서 프로토콜 유형을 선택하면 클라이언트가 어떤 형식으로 서버에 대상 주소와 인증 정보를 전달하고 데이터를 주고받을지 정하게 됩니다. 전송 방식은 TCP 바이트 스트림, WebSocket, UDP 기반 방식처럼 이 데이터를 어떻게 전달할지 결정합니다. 보안 계층은 통신을 어떻게 암호화하고 원격 서버의 신원을 확인할지 다룹니다. 라우팅 계층은 특정 요청을 이 연결로 보낼지 결정합니다. 이 네 가지를 혼동하면 프로토콜을 바꿔도 잘못된 도메인 문제는 해결되지 않고, 규칙을 수정해도 인증 실패는 그대로일 수 있습니다.

연결 정보에는 최소한 서버 주소, 포트, 인증 방식이 포함되어야 합니다. 조합에 따라 전송 경로, TLS 서버 이름, 기타 협상 설정이 필요할 수 있습니다. 서버 주소는 실제로 연결할 대상이고, 대상 웹사이트 주소는 사용자가 접속하려는 리소스이므로 서로 다릅니다. 포트는 접속 지점을 구분하는 번호일 뿐, 흔히 쓰이는 포트라는 이유만으로 TLS가 활성화되어 있다고 판단할 수 없습니다. 가져온 뒤에는 먼저 유형이 맞는지 확인하고 추가 옵션을 점검하세요. 비슷해 보이는 항목이 있다고 정보를 다른 프로토콜에 옮기지 마세요.

속도는 핸드셰이크·전송량·안정성으로 나눠 살펴보세요

짧은 웹페이지를 열 때는 도메인 조회, 연결 수립, 보안 핸드셰이크가 본문 전송보다 오래 걸릴 수 있습니다. 대용량 파일을 연속 전송할 때는 혼잡 제어, 서버의 외부 회선, 원격 사이트 성능이 더 중요합니다. 음성 통화나 실시간 작업은 지터, 패킷 손실, 연결 복구에 더 민감합니다. 한 번의 지연 시간 테스트로는 이 중 일부만 확인할 수 있습니다. 측정값이 낮다고 다운로드 속도가 반드시 빠른 것은 아니며, 대역폭이 높아도 신호가 약한 곳에서 상호작용이 더 안정적이라는 보장은 없습니다. 비교할 때는 대상, 접속 네트워크, 대략적인 시간을 동일하게 맞추세요. 그렇지 않으면 차이가 프로토콜과 무관할 수 있습니다.

iOS에서의 배터리 사용량은 암호화 방식 이름만으로 판단할 수 없습니다

배터리 소모에는 프로세서 연산, 무선 통신, 백그라운드 깨우기, 실패 후 재시도가 모두 영향을 줍니다. 최신 암호화 알고리즘의 연산 비용은 여러 요소 중 하나일 뿐입니다. 신호가 약할 때의 재전송, 지속적인 탐색, 잦은 연결 재수립을 함께 점검해야 합니다. 배터리 사용량을 비교할 때는 화면 밝기, 사용 콘텐츠, 네트워크 신호를 최대한 일정하게 유지하고 충분한 시간 동안 관찰하세요. 배터리가 한 번 줄었다고 프로토콜 탓으로 단정할 수 없고, Keepalive를 추가한다고 반드시 안정성이 높아지는 것도 아닙니다. Keepalive는 연결 재수립을 줄일 수 있지만 유휴 상태의 통신량을 늘릴 수 있습니다.

프로토콜을 선택할 때 속도 순위를 나열하기보다 서버에서 제공하는 기능, 현재 네트워크의 조건, 주로 사용하는 작업을 먼저 확인하세요. 보유한 정보가 한 가지 유형만 지원한다면 다른 이름을 찾기보다 올바르게 가져와 안정적으로 검증하는 것이 중요합니다. 기존 설정 여러 개를 비교할 때는 원본을 보존하고 한 번에 변수 하나만 바꾸세요. DNS 조회, 연결, 인증, 대상 접속 중 어느 단계에서 실패했는지도 기록합니다. 그래야 네트워크가 바뀐 뒤에도 결과를 다시 활용할 수 있습니다.

프로토콜 유형은 양측이 합의하는 설정이지 클라이언트가 일방적으로 선택하는 취향이 아닙니다. 서버에 해당 접속 지점이 없다면 Shadowrocket에서 유형을 바꿔도 자동으로 호환되지 않습니다.

Shadowsocks: 공유 키와 간결한 전송 구조

설계 배경과 일치시켜야 할 설정 항목

Shadowsocks는 사전에 공유한 인증 정보를 사용해 암호화된 프록시 연결을 만들고, 대상 주소와 후속 데이터를 서버에 전달하는 방식입니다. 웹 세션이나 완전한 네트워크 인터페이스를 중심으로 설계되지 않아 기본 설정이 비교적 단순합니다. 일반적으로 주소, 포트, 비밀번호, 암호화 방식을 확인합니다. 항목이 적다고 점검을 생략해도 되는 것은 아닙니다. 양측의 암호화 방식이나 인증 정보가 다르거나 서버 접속 지점이 해당 프로토콜을 지원하지 않으면 정상적인 통신이 시작되기 전에 실패합니다.

암호화 방식은 서버 정보에 기재된 값과 정확히 일치하게 입력해야 합니다. 방식마다 키 파생, 데이터 형식, 인증 방식이 다르므로 이름이 비슷해도 서로 호환된다고 볼 수 없습니다. 인증 암호화를 사용하는 설정은 데이터 무결성도 확인합니다. 키가 잘못되면 명확한 비밀번호 오류가 표시되지 않고 연결 직후 끊길 수도 있습니다. 인증 실패를 모두 회선 불안정으로 해석하지 마세요. 일부 최신 프로토콜 변형에는 키 형식에 대한 별도 요구 사항이 있으므로 일반 비밀번호 입력 방식으로 추측하지 말고 해당 설정 항목의 정의를 따르세요.

기본 프로토콜과 추가 전송 방식을 따로 확인하세요

보유한 정보에 플러그인이나 외부 전송 방식이 포함되어 있다면 Shadowrocket의 해당 옵션이 서버 설정과 일치하는지 확인하세요. 기본 프로토콜, 외부 전송 방식, 접속 포트가 모두 연결 조건이며 한 계층이라도 빠지면 시간 초과가 발생할 수 있습니다. 특히 오래된 기록을 옮길 때 주소와 비밀번호만 복사하고 추가 안내를 놓치지 마세요. 반대로 추가 전송 정보가 없는 설정에 ‘더 완전하게’ 보이도록 옵션을 임의로 켜지 마세요. 클라이언트가 보내는 형식이 달라지면 서버가 인식하지 못할 수 있습니다.

TCP와 UDP의 사용 가능 여부도 각각 확인해야 합니다. 웹페이지가 열린다는 것은 해당 요청의 경로가 작동한다는 뜻일 뿐, UDP에 의존하는 작업도 된다는 의미는 아닙니다. 서버가 UDP를 허용하는지, 접속 네트워크가 관련 트래픽을 허용하는지, 현재 설정이 해당 요청을 전달하는지에 따라 결과가 달라질 수 있습니다. 특정 작업만 실패하면 비밀번호를 바꾸기 전에 먼저 해당 작업이 사용하는 전송 방식을 확인하고 경로를 점검하세요. 프로토콜을 비교할 때 동일한 대상을 테스트해야 대상 사이트 자체의 차이를 프로토콜 탓으로 돌리지 않을 수 있습니다.

속도·배터리 사용량·문제 진단

네트워크 품질이 양호하고 서버 부하가 적절하면 간결한 캡슐화 구조가 추가 처리 부담을 줄이는 데 도움이 될 수 있습니다. 하지만 실제 속도는 경로의 용량과 서버 성능에 따라 달라집니다. 한 기기에서 특정 암호화 방식이 보인 성능이 다른 기기에서도 같다고 볼 수 없습니다. 하드웨어 가속, 구현 방식, 작업 크기가 모두 영향을 줍니다. 모바일 환경에서는 첫 연결 시간만 비교하기보다 연속 탐색이 원활한지, 네트워크 전환 후 복구되는지, 유휴 상태에서 반복 재연결이 발생하는지 확인하는 편이 유용합니다.

문제 진단은 주소와 포트에 도달할 수 있는지 확인한 다음 암호화 방식과 인증 정보를 살펴보고, 마지막으로 추가 전송 방식을 점검하세요. 모든 대상이 실패하면 공통 접속 지점을 먼저 확인하고, 특정 사이트만 실패하면 규칙 적용, 도메인 조회, 원격 응답을 확인하세요. 오류 메시지에 인증 정보를 알기 쉽게 표시하지 않는 경우도 있으므로 ‘비밀번호 오류’ 안내가 없다고 인증 정보가 올바른 것은 아닙니다. 원본 기록에서 새 항목을 가져와 비교할 수 있지만, 이름이 같은 항목을 너무 많이 남기면 수정한 항목이 실제로 선택된 것인지 헷갈릴 수 있습니다.

이 유형은 서버가 해당 접속 지점을 제공하고 비교적 단순한 설정을 원하는 경우에 적합합니다. TLS 인증서 설정을 대신하는 개념이 아니며, 모든 보안 동작이 TLS와 같다는 뜻도 아닙니다. 원격 서버의 신원과 인증 정보를 확인하려면 프로토콜이 어떤 신뢰 기반에 의존하는지 이해해야 합니다. 정보를 받은 뒤에도 비밀번호와 키를 안전하게 관리하세요. 다른 사람에게 문제를 설명할 때는 유형, 오류가 발생한 단계, 민감 정보를 가린 설정 구조를 공유하고 전체 인증 정보는 공개하지 마세요.

먼저 암호화 방식을 확인한 다음 비밀번호를 확인하세요. 호환성을 고치겠다며 암호화 이름을 임의로 바꾸면 올바른 설정도 사용할 수 없게 될 수 있습니다.

VMess: 인증 정보와 외부 전송을 나눠 점검

프로토콜이 담당하는 기능 이해하기

VMess는 사용자 인증, 대상 주소 표현, 데이터 보호를 자체 프로토콜 구조에 담고 있으며 여러 외부 전송 방식과 조합할 수 있습니다. 모든 기능을 외부 계층에 맡기지 않고 프로토콜 내부에 세션 및 인증 메커니즘을 두는 설계입니다. 클라이언트 사용자는 프로토콜 설정과 전송 설정을 함께 이해해야 합니다. UUID만 알아서는 완전한 연결을 구성할 수 없습니다. 전송 유형이나 보안 설정이 빠지면 사용자 인증 정보가 올바르더라도 통신이 전혀 되지 않을 수 있습니다.

UUID는 사용자 식별 정보이지 서버 주소도 TLS 인증서의 이름도 아닙니다. 복사할 때 공백이나 보이지 않는 문자가 섞이지 않도록 전체 형식을 유지하세요. 과거 인증 방식과 관련된 항목이 포함된 오래된 정보도 있을 수 있습니다. 이런 항목은 경험만으로 특정 값을 채우지 말고 서버의 현재 요구 사항을 확인해야 합니다. 수동으로 조합하는 것보다 가져오기 링크를 사용하면 항목을 더 정확히 보존할 수 있습니다. 다만 가져오기에 성공했다는 것은 클라이언트가 데이터 구조를 읽었다는 뜻일 뿐, 원격 인증·인증서·전송 경로가 검증되었다는 의미는 아닙니다.

WebSocket, Host, 경로의 역할 구분

WebSocket을 사용하면 해당 연결에 맞는 업그레이드 절차가 필요하고, 경로와 요청의 호스트 정보가 서버 접속 지점을 결정할 수 있습니다. 경로는 서버가 지정한 접속 지점이지 임의로 입력하는 웹사이트 디렉터리가 아닙니다. 경로의 대소문자, 앞에 붙는 슬래시, 쿼리 문자열 유무가 다르면 요청이 해당 프로토콜을 처리하지 않는 위치로 전달될 수 있습니다. 서버가 일반 웹페이지나 오류 페이지를 반환하면 연결 자체는 된 것처럼 보여도 프록시 세션은 성립하지 않은 상태입니다. ‘주소가 열린다’는 이유만으로 설정이 올바르다고 판단하지 마세요.

WebSocket과 TLS를 함께 사용할 때는 연결할 주소, TLS 서버 이름, HTTP 계층의 Host를 구분해야 합니다. 세 값이 같을 수도 있고 배포 방식에 따라 다를 수도 있습니다. 클라이언트는 먼저 주소에 연결한 다음 보안 핸드셰이크에서 이름을 확인하고, 애플리케이션 계층 요청으로 지정된 서비스에 접속합니다. 어느 한 계층이라도 맞지 않으면 실패할 수 있습니다. 서버 관리 기록의 도메인을 모든 항목에 그대로 복사하지 말고 각 항목의 역할을 파악한 뒤 원본 정보에 따라 입력하세요.

시간 관련 검증과 인증 오류의 구분

VMess 인증에는 시간 관련 검증이 포함되므로 기기 시간이 실제와 크게 다르면 연결 문제가 발생할 수 있습니다. 진단할 때 시스템의 날짜와 시간 설정을 확인할 수 있지만, 모든 실패를 시각 오류로 돌려서는 안 됩니다. TLS 인증서의 유효 기간도 시간의 영향을 받지만 두 항목은 서로 다른 검증 단계입니다. 인증 실패와 인증서 실패는 겉으로 비슷하게 보일 수 있어도 해결 방법은 다릅니다. 확인할 수 있는 오류 정보를 먼저 살펴본 뒤 기기 시간, 사용자 인증 정보, 서버 인증서 중 무엇을 점검할지 판단하세요.

성능 측면에서 외부 전송은 핸드셰이크나 캡슐화 비용을 추가할 수 있지만 모든 네트워크에서 동일한 비율로 느려지는 것은 아닙니다. 장시간 전송에서는 이 비용이 분산될 수 있고, 짧은 연결을 자주 열 때는 세션 설정 부담이 더 크게 느껴질 수 있습니다. 모바일에서는 Wi-Fi에서 셀룰러 데이터로 전환한 뒤 복구되는지도 확인해야 합니다. 기존 세션이 실패한 뒤 제때 다시 연결되는지, 서버가 상태를 계속 유지하는지에 따라 사용감이 달라지므로 고정된 지연 시간 숫자만으로 하루 전체의 경험을 판단할 수 없습니다.

‘사용자 인증 정보, 전송 방식, 접속 정보, 보안 설정’ 순서로 점검 내용을 기록하세요. 같은 서버에 사용할 수 있는 다른 설정이 있다면 모두 다시 입력하기보다 항목별 차이를 먼저 비교하세요. 특정 외부 전송 방식을 켠 설정만 실패한다면 접속 경로와 서버 측 연결을 집중적으로 확인합니다. 네트워크를 바꾼 뒤 복구되었다고 해서 기존 네트워크가 특정 프로토콜을 차단했다고 단정할 수는 없습니다. DNS 조회 결과, 주소 계열, 접속 가능 여부가 접속 네트워크에 따라 바뀔 수 있습니다.

VMess의 UUID, WebSocket 경로, TLS 서버 이름은 각각 다른 역할을 합니다. 한 항목이 올바르다고 다른 계층의 오류까지 해결되지는 않습니다.

VLESS: 경량 프로토콜과 보안 계층의 조합

프로토콜 부담을 줄여도 보안 점검은 생략할 수 없습니다

VLESS는 사용자 인증 정보와 대상 전달을 비교적 간결하게 구성하며 기본 프로토콜 자체에서 일반적인 데이터 암호화 기능을 담당하지 않습니다. 따라서 보통 적절한 보안 계층과 함께 사용해야 합니다. 여기서 ‘경량’은 프로토콜의 역할 분담을 뜻할 뿐 속도를 보장하거나 서버 검증을 생략해도 된다는 의미가 아닙니다. VLESS를 이해할 때는 원격 서버가 사용자 인증 정보를 어떻게 확인하는지, 전송 중인 데이터를 어느 계층에서 보호하는지 함께 살펴보세요. VLESS라는 이름만으로 연결의 보안 수준을 판단하기에는 정보가 부족합니다.

보유한 정보의 UUID, 주소, 포트가 정확히 일치하는지 확인하고 전송 유형, 보안 방식, 추가 항목도 점검해야 합니다. UUID를 TLS 대신 사용하는 항목으로 취급하지 마세요. 사용자 인증은 요청에 서버가 인정하는 인증 정보가 있는지 확인하고, 보안 핸드셰이크는 세션 보호와 원격 서버 신원 확인을 다룹니다. 둘은 서로 다른 절차입니다. 보안 연결을 수립한 뒤 잘못된 인증 정보가 거부될 수도 있고, 서버 이름이 틀리면 그보다 먼저 실패할 수도 있습니다. 실패 단계별로 확인하면 방향 없이 설정을 반복해서 바꾸는 일을 줄일 수 있습니다.

TLS, REALITY, flow 설정

TLS를 사용하는 설정은 서버 이름과 인증서 검증 조건을 확인해야 합니다. 기존 정보에 REALITY가 지정되어 있다면 클라이언트의 지원 여부, 서버 설정, 필요한 공개 키 등의 항목이 서로 일치해야 합니다. REALITY는 임의의 TLS 접속 지점에 추가하는 범용 옵션이 아닙니다. 보안 방식마다 필요한 항목이 다르므로 서로 대신 입력할 수 없습니다. 핵심 정보가 없다면 본인이 가진 원본 자료에서 보충하세요. 특정 서버 설정과 연결된 값을 인터넷에서 그럴듯해 보인다는 이유로 가져오지 마세요.

일부 조합에는 데이터 처리 방식을 제한하는 flow 등의 설정이 포함됩니다. 이 항목을 자동으로 속도를 높이는 스위치로 여기거나 속도를 위해 임의로 추가해서는 안 됩니다. 서버 지원 여부, 선택한 전송 방식과의 호환성, 클라이언트의 실제 구현 조건에 따라 조합의 작동 여부가 달라집니다. 가장 안전한 방법은 가져온 설정의 원래 값을 유지하고, 직접 입력해야 할 때는 각 항목을 하나씩 대조하는 것입니다. 알 수 없는 항목은 의미가 비슷한 다른 입력란에 넣지 말고 앱에서 사용할 수 있는 항목인지 먼저 확인하세요.

속도와 배터리 사용량은 조건에 따라 판단하세요

프로토콜 자체가 담당하는 작업이 적다고 전체 연결 경로의 배터리 소모까지 줄어드는 것은 아닙니다. 실제 사용에는 보안 핸드셰이크, 외부 전송, 혼잡 제어, 무선 통신이 포함되며 장시간 연결을 재사용하는지에 따라서도 비용이 달라집니다. 콘텐츠를 계속 시청하는 작업은 최초 핸드셰이크보다 안정적인 전송량이 중요할 수 있고, 간헐적인 접속은 기기 깨우기와 연결 수립의 영향이 더 클 수 있습니다. 두 설정을 비교할 때 서버 위치, 대역폭, 보안 조합이 다르면 결과를 VLESS와 다른 프로토콜의 차이만으로 설명할 수 없습니다.

‘테스트 결과는 나오지만 웹사이트가 열리지 않는’ 경우에는 테스트 대상과 실제 요청이 같은 경로를 사용하는지 확인하세요. 일부 테스트는 접속 지점에 도달할 수 있는지 또는 특정 대상에 연결되는지만 확인하지만, 웹사이트에 접속하려면 도메인 조회, 새 연결 수립, 여러 리소스 가져오기가 필요합니다. Global Routing이 예상한 모드인지, 선택한 설정이 방금 확인한 서버를 사용하는지도 확인하세요. 통제된 접속 테스트와 연결 기록으로 문제를 좁혀 가세요. 모든 검증을 꺼서 겉으로만 성공하는 상태를 만들지 마세요.

적용 여부를 판단하려면 서버가 전체 조합을 제공하고, 클라이언트에서 필요한 모든 항목을 설정할 수 있으며, 원격 서버의 신원을 확인할 수 있어야 합니다. 정보가 일부 항목뿐이라면 보안 방식을 계속 바꾸기보다 먼저 누락된 설정을 확인하세요. 구독을 다시 가져와야 한다면 구독을 가져오는 네 가지 방법을 참고하세요. 가져오기 자체로 서버에 없는 정보가 추가되지는 않습니다.

Trojan, HTTP, SOCKS5: 인증과 암호화를 구분해 이해하기

Trojan에 필요한 TLS 조건

Trojan은 일반적으로 TLS 연결을 통해 프록시 프로토콜을 전달하고 보안 채널 안에서 인증과 대상 정보 전송을 처리합니다. 각 설정 항목에 암호화 기능을 맡기기보다 이미 널리 사용되는 보안 계층을 활용하는 방식입니다. 비밀번호가 올바른 것은 필요한 조건 중 하나일 뿐이며 서버 인증서, 이름, 접속 지점도 정확해야 합니다. 도메인 인증서가 유효해도 실제 연결이 다른 접속 지점에 도달하면 프록시 세션을 만들 수 없습니다. 접속 지점은 맞더라도 인증서 검증에 실패하면 단순한 비밀번호 문제로 취급할 수 없습니다.

서버 이름은 보안 핸드셰이크와 신원 확인에 사용되며 사용자가 접속하려는 웹사이트 이름과는 다릅니다. 인증서는 확인 대상 이름을 포함해야 하며 기기 시간도 올바르게 설정되어 있어야 합니다. 배포 환경에 따라 애플리케이션 계층 프로토콜 협상 옵션 등이 추가될 수 있으므로 보유한 정보에 따라 입력하세요. 인증서 오류가 발생하면 이름의 철자, 기기 시간, 서버 인증서 체인을 먼저 확인한 다음 본인의 서버 관리자에게 문의하세요. 검증을 건너뛰면 신원 확인이 약해지므로 일반적인 해결 방법으로 사용해서는 안 됩니다.

HTTP 프록시 연결에 TLS가 자동으로 적용되는 것은 아닙니다

HTTP 프록시는 지정된 요청 형식이나 CONNECT 메서드로 대상에 접속합니다. 기존 프록시 게이트웨이를 사용하는 환경에서 흔히 볼 수 있고 의미와 설정 정보를 파악하기 쉽지만, ‘HTTP 프록시’라는 이름만으로 클라이언트와 프록시 사이의 연결이 암호화된다고 볼 수는 없습니다. 대상 웹사이트가 HTTPS를 사용하면 사이트 콘텐츠는 종단 간 TLS로 보호될 수 있지만 프록시는 대상 주소와 연결 메타데이터를 볼 수 있습니다. 이는 클라이언트가 TLS로 프록시에 먼저 연결하는 방식과는 별개의 보안 경계입니다.

설정할 때 프록시 접속 지점이 보안 연결을 요구하는지, 사용자 이름과 비밀번호가 필요한지, 필요한 대상 포트를 허용하는지 확인하세요. 일부 게이트웨이는 제한된 접속 방식만 허용하므로 특정 웹페이지가 열린다고 모든 작업과 호환되는 것은 아닙니다. 인증 실패, 대상 포트 거부, 상위 서버 접속 실패는 서로 다른 문제입니다. 문제가 발생하면 테스트를 반복하기보다 오류가 발생한 단계와 상태 정보를 기록하는 편이 효과적입니다. 웹사이트가 반환한 로그인 페이지나 거부 페이지를 클라이언트 프로토콜의 인증 실패로 오해하지 마세요.

SOCKS5의 협상 기능과 보안 범위

SOCKS5는 대상 주소와 인증 방식을 협상하고 여러 요청 기능을 정의하지만 기본 프로토콜은 전체 연결 경로를 암호화하지 않습니다. 사용자 이름과 비밀번호 인증을 암호화된 채널과 같은 것으로 볼 수 없습니다. 보유한 게이트웨이 정보에서 특정 보안 전송 방식의 사용을 요구한다면 모든 조건을 따르세요. 그렇지 않다면 접속 네트워크와 원격 접속 지점 사이의 신뢰 관계를 충분히 이해해야 합니다. 유형은 서버에서 실제로 제공하는 인터페이스에 맞춰 선택하고 HTTP와 SOCKS5를 서로 바꿔 쓸 수 있는 이름처럼 취급하지 마세요.

SOCKS5의 도메인 처리와 UDP 기능은 요청 방식, 클라이언트 동작, 서버 구현에 따라 달라집니다. 프로토콜 규격에 특정 기능이 있더라도 현재 접속 지점에서 그 기능을 사용할 수 있다는 뜻은 아닙니다. 특히 실시간 통신에서는 웹 탐색이 성공했다는 이유로 결론을 내리지 말고 실제 작업에 필요한 트래픽을 테스트하세요. 도메인이 어느 쪽에서 조회되는지도 프로토콜 이름만으로 판단할 수 없습니다. 클라이언트의 DNS 설정과 요청 경로를 함께 확인해야 원격 연결을 점검하면서 로컬 DNS 문제를 놓치지 않습니다.

속도와 배터리 사용량은 이름만 비교하기보다 실제 전송 방식을 기준으로 살펴보세요. 보안 핸드셰이크, 연결 재사용, 게이트웨이 응답 시간은 짧은 요청에 영향을 주고 지속적인 트래픽은 접속 지점의 용량과 네트워크 품질에 좌우됩니다. 기존 HTTP 또는 SOCKS5 게이트웨이에 접속한다면 지원되지 않는 조합을 덧붙이기보다 해당 인터페이스에 맞게 설정하는 것이 일반적으로 더 안정적입니다. 신원 확인이 중요한 환경에서는 핸드셰이크를 한 번 줄이는 이점을 따지기 전에 보안 범위를 확인하세요. 시작 시간이 조금 빨라졌다는 이유로 필요한 신원 확인을 생략해서는 안 됩니다.

WireGuard: 대상 프록시에서 네트워크 계층 터널로

설계 모델에 따라 설정값의 의미가 달라집니다

WireGuard는 네트워크 계층 터널을 위한 프로토콜로, 공개 키 기반 신원 확인과 암호화된 데이터그램으로 IP 트래픽을 전달합니다. 특정 대상 연결만 표현하는 프록시 프로토콜과는 모델이 다르므로 설정에 인터페이스 주소, 피어 공개 키, 엔드포인트, 허용 주소 범위가 포함됩니다. 협상 복잡성을 줄이기 위해 암호화 조합을 비교적 고정했지만, 알고리즘 선택이 단순하다고 네트워크 설정까지 간단한 것은 아닙니다. 주소가 어떻게 할당되는지, 어떤 목적지 트래픽을 피어로 보낼지, 응답 트래픽이 기기에 어떻게 도달하는지 이해해야 합니다.

개인 키는 본인 측의 신원을 증명하고 공개 키는 상대방을 식별하므로 서로 바꿔 입력하면 안 됩니다. 엔드포인트는 상대방에 실제로 연결할 주소와 포트를 나타내고, 인터페이스 주소는 터널 내부에서 사용하는 주소이므로 구분해야 합니다. 사전 공유 키가 필요한 경우 양측에서 동일하게 설정해야 합니다. 가져온 뒤 여러 기기에 인증 정보와 내부 주소를 통째로 복사하지 마세요. 서버에서 해당 정보를 특정 피어에 연결해 두었을 수 있어 중복 사용은 세션 충돌이나 응답 경로 문제를 일으킬 수 있습니다.

AllowedIPs, 라우팅, MTU

AllowedIPs는 피어와 주소를 연결하고 트래픽을 선택하는 데 사용되므로 단순한 웹사이트 허용 목록으로 보면 안 됩니다. 클라이언트에 통합된 환경에서는 앱의 라우팅 정책과 함께 이해해야 합니다. 한 계층은 요청이 해당 연결로 들어갈지 결정하고, 다른 계층은 터널에서 어떤 주소가 피어와 관련되는지 제한합니다. 범위를 너무 좁게 설정하면 필요한 주소로 가는 경로가 없을 수 있고, 너무 넓게 설정하면 원래 접속 범위를 벗어날 수 있습니다. 서버에서 제공한 네트워크 계획을 유지하고 경험에 의존해 모든 주소 범위를 최대한 넓히지 마세요.

MTU는 해당 인터페이스에서 전송할 수 있는 패킷 크기의 상한을 나타냅니다. 외부 캡슐화가 공간을 차지하므로 하위 경로에서 큰 패킷을 제대로 처리하지 못하면 작은 요청은 성공하지만 큰 응답이 멈출 수 있습니다. 다만 가능한 원인 중 하나일 뿐이며 페이지 일부가 로드되지 않는다고 바로 MTU를 조정해서는 안 됩니다. 먼저 대상 서비스, DNS, 패킷 손실 문제를 제외하고 재현 가능한 테스트에서 값을 조금씩 바꾸며 원래 값을 기록하세요. 지나치게 낮게 설정하면 분할 전송과 처리 부담이 늘어날 수 있습니다.

네트워크 전환과 Keepalive는 서로 다른 기능입니다

WireGuard는 인증된 데이터 교환 중에 상대 피어 주소의 변화를 감지하도록 설계되어 있어 모바일 네트워크에서 유용할 수 있습니다. 하지만 실제 복구 여부는 접속 네트워크, 주소 변환 상태, 서버 접속 가능 여부에 좌우됩니다. 휴대폰이 Wi-Fi에서 셀룰러 데이터로 전환되면 기존 주소 매핑이 무효가 될 수 있고, 새 데이터가 사용할 경로를 다시 구성해야 할 수 있습니다. 모든 전환이 중단 없이 이어진다고 보장할 수 없으며, 한 번의 전환 실패만으로 키 오류라고 판단해서도 안 됩니다. 먼저 한 네트워크에서 연결이 안정적인지 확인한 뒤 전환 후 복구를 점검하세요.

PersistentKeepalive는 주기적으로 통신해 일부 주소 변환 매핑을 유지하는 데 쓰이며 속도 향상 기능이 아닙니다. 유휴 상태에서 계속 데이터를 보내면 무선 통신이 늘어납니다. 반대로 Keepalive를 사용하지 않으면 특정 네트워크 환경에서 인바운드 연결 복구가 느려질 수 있습니다. 필요한지, 어떤 간격으로 설정할지는 본인의 서버 정보와 네트워크 조건에 따라 판단하세요. 트래픽이 있을 때는 정상 작동하지만 장시간 유휴 후 첫 요청이 실패한다면 주소 매핑과 Keepalive를 점검할 수 있습니다. 모든 설정에 일괄 적용하지 마세요.

성능 이점은 실제 작업 조건에 맞춰 평가해야 합니다. 고정된 암호화 설계와 간결한 데이터 경로는 예측 가능한 처리 비용에 도움이 될 수 있지만 UDP 접속 가능 여부, 경로의 패킷 손실, 서버의 전송 성능이 병목이 될 수 있습니다. 대용량 파일 전송 한 번으로 백그라운드 유휴 상태의 배터리 효율을 알 수는 없습니다. 모바일 기기에서는 연속 작업, 짧은 대기 시간, 여러 차례의 네트워크 전환을 함께 관찰하세요. 같은 테스트 중 터널 설정 여러 개를 바꾸면 개선 원인을 파악하기 어렵습니다.

개인 키를 공개하거나 터널 설정 전체를 일반적인 스크린샷처럼 공유하지 마세요. 문제 진단 기록에는 항목 이름, 일부를 가린 주소 범위, 오류 발생 단계만 남기세요.

완전한 터널 네트워크 계획이 있고 내부 주소와 피어 신원을 명확하게 관리할 수 있는 경우에 더 적합합니다. 받은 정보가 일반 프록시 주소와 비밀번호뿐이라면 이를 WireGuard 설정으로 바꾸려 하지 마세요. 반대로 핸드셰이크에 성공했다고 모든 조건이 충족된 것은 아닙니다. 실제 접속이 완전히 작동하는지 확인하려면 대상 주소의 라우팅, DNS, 서버 응답 경로도 검증해야 합니다.

Hysteria2: QUIC 전송과 대역폭 설정의 균형

먼저 UDP와 보안 핸드셰이크 조건을 확인하세요

Hysteria2는 QUIC 기반 전송 방식을 사용합니다. QUIC은 UDP 위에서 동작하며 연결 관리에 보안 핸드셰이크와 스트림 관리를 결합합니다. 이 설계는 불안정한 경로에서 기존 TCP 조합과 다른 선택지를 제공하지만, 무선 신호가 약하거나 경로가 혼잡하거나 서버 용량이 부족한 문제를 없애지는 못합니다. 속도를 비교하려면 먼저 클라이언트가 UDP 접속 지점에 연결할 수 있어야 합니다. 현재 네트워크에서 데이터그램 처리가 원활하지 않다면 이 프로토콜로 바꿔도 사용감이 개선되지 않을 수 있습니다.

확인해야 할 정보에는 보통 주소, 포트, 인증 정보, 보안 이름, 기타 추가 조건이 포함됩니다. Hysteria2는 이름이 비슷한 이전 프로토콜과 같은 유형이라고 간주할 수 없으므로 가져온 뒤 실제 유형을 확인하세요. 접속 포트가 흔히 쓰이는 웹 서비스 포트와 같아 보여도 전송 방식이 같다고 추정할 수 없습니다. 문제를 진단할 때 TCP 접속 가능 여부를 확인하는 것인지 UDP를 통한 실제 핸드셰이크를 확인하는 것인지 구분하세요. TCP 접속이 된다고 UDP 핸드셰이크까지 확인된 것은 아니며 웹페이지가 열리는지도 이 접속 지점의 사용 가능 여부를 증명하지 않습니다.

대역폭 설정은 동작에 영향을 주는 입력값이지 속도 측정 결과가 아닙니다

일부 설정에는 업로드·다운로드 대역폭 등의 항목이 있습니다. 값은 클라이언트가 사용하는 모드와 서버 제한을 고려해 해석해야 합니다. 전송이나 혼잡 제어 정책에 반영될 수 있지만 값을 높게 입력한다고 그만큼의 용량을 얻는 것은 아닙니다. 실제 용량은 접속 네트워크, 공유 회선, 서버, 대상에 따라 제한됩니다. 예상치를 지속 가능한 용량으로 오해하면 대기열, 패킷 손실, 재전송이 늘어 다운로드는 빨라 보이지만 상호작용 요청은 더 느려질 수 있습니다.

특히 업로드 용량이 작은 네트워크에서는 업로드와 다운로드를 따로 살펴봐야 합니다. 업로드가 가득 차면 다른 연결의 확인 데이터나 제어 데이터도 대기열에 쌓여 전체 사용감에 영향을 줄 수 있습니다. 이런 현상이 나타나면 먼저 동시 작업을 줄이고 부하가 없는 상태와 있는 상태의 차이를 관찰한 다음 대역폭 설정을 확인하세요. 서버를 바꾸고 대역폭 값을 여러 개 높이는 동시에 대상 파일까지 바꾸지 마세요. 결과가 개선되어도 어떤 변경이 효과가 있었는지 알 수 없습니다.

불안정한 네트워크에서는 전송량과 지터를 함께 확인하세요

패킷 손실이나 지연 변동이 있는 경로에서 QUIC의 스트림 및 연결 관리가 다른 복구 특성을 보일 수 있습니다. 하지만 ‘불안정한 네트워크에 적합하다’는 설명은 실제로 확인해야 하는 조건입니다. 연속 다운로드의 전송량 유지와 짧은 요청의 빠른 응답은 서로 다른 지표입니다. 먼저 간단한 상호작용 작업을 수행하고 안정적인 연속 작업을 추가해 동시에 사용할 때 대기 시간이 눈에 띄게 늘어나는지 확인하세요. 실제 사용과 비슷한 테스트를 해야 현재 네트워크에 적합한 조합인지 판단할 수 있습니다.

배터리 영향도 신중하게 해석해야 합니다. 데이터그램 재전송, 지속적인 전송, 암호화 처리, 무선 모듈의 작동 시간이 모두 전력 소모에 관여합니다. 같은 작업을 더 빠르게 끝내면 작동 시간이 줄어들 수 있지만, 높은 부하의 전송이나 잦은 실패는 배터리를 더 많이 소모할 수 있습니다. UDP 기반이라는 이유만으로 배터리가 절약된다고 단정하거나 기기가 뜨겁다는 이유만으로 프로토콜 탓을 해서는 안 됩니다. 화면, 미디어 디코딩, 백그라운드 동기화, 신호 변화를 최대한 통제하고 충분히 오래 반복 관찰하세요.

핸드셰이크에 실패하면 주소, 포트, UDP 접속 가능 여부부터 확인한 다음 인증 정보와 보안 이름을 점검하세요. 연결은 되지만 전송 후 불안정해지면 대역폭 설정, 동시 연결 수, 접속 네트워크 용량 변화를 확인합니다. 특정 웹사이트만 실패하면 DNS와 규칙 경로를 다시 살펴보세요. 일부 설정에는 별도의 난독화 항목이 있을 수 있지만 서버에서 요구하고 동일한 정보를 제공한 경우에만 입력해야 합니다. 인증이나 인증서 오류를 해결하는 만능 옵션이 아닙니다.

Hysteria2는 현재 경로에서 실제 작업이 어떻게 수행되는지를 비교해야 합니다. 대역폭 값을 더 크게 입력하거나 테스트 항목이 더 빠르게 응답하더라도 지속적인 접속이 더 안정적이라고 단정할 수 없습니다.

시도하려면 해당 서버 정보를 이미 보유하고 있고, 보안 설정이 완전하며, 접속 네트워크에서 관련 UDP 통신이 허용되는지 확인할 수 있어야 합니다. 이런 조건을 확인할 수 없다면 이미 검증된 연결을 사용해 기준 테스트를 먼저 진행하세요. 복구할 수 있도록 원본 정보를 보존하고 한 번에 설정 하나만 바꿔 통제된 방식으로 테스트하는 편이, 반복해서 다시 가져온 뒤 기억에 의존해 비교하는 것보다 신뢰할 수 있습니다.

DNS·규칙·사용 환경에 맞는 선택: 검증 가능한 절차로 정리하기

도메인 조회 결과가 이후 연결의 출발점을 결정합니다

DNS는 도메인을 연결 가능한 주소로 변환하며 대상 접속뿐 아니라 프록시 서버 자체의 연결에도 영향을 줄 수 있습니다. 두 가지는 나눠 확인해야 합니다. 대상 웹사이트의 DNS 조회가 실패해도 서버 접속 지점에 도달할 수 없는 것은 아닙니다. 반대로 서버 주소가 도메인이고 그 조회가 실패하면 모든 요청이 실패할 수 있습니다. 암호화 DNS를 설정해도 이후 웹사이트 요청이 반드시 프록시를 통과하는 것은 아닙니다. DNS 경로와 접속 경로에는 각각 별도의 설정과 라우팅 조건이 적용됩니다. DNS 이름 하나만 보고 판단하지 말고 실제 경로를 기준으로 점검하세요.

DNS에는 부트스트랩 의존성도 있습니다. DNS 서버 자체를 도메인으로 지정했다면 처음에 사용할 수 있는 조회나 연결 경로가 필요합니다. 잘못 설정하면 의존성 순환이 생겨 앱을 시작하자마자 모든 도메인이 조회되지 않을 수 있습니다. DNS 설정을 한꺼번에 모두 바꾸지 마세요. 먼저 작동하는 현재 상태를 보존하고 선택한 설정이 서버 도메인과 대상 도메인을 어떻게 처리하는지 확인하세요. IPv4와 IPv6 결과는 다른 경로를 사용할 수 있습니다. 일부 대상만 시간 초과되면 주소 계열과 실제 접속 가능 여부를 확인하고, 조회 결과가 있다는 이유만으로 점검을 끝내지 마세요.

Global Routing에서 선택한 연결로 트래픽을 보낼지 결정합니다

설정 모드는 Config, 프록시 모드는 Proxy, 직접 연결 모드는 Direct입니다. Config는 현재 설정의 규칙에 따라 정책을 선택하고, Proxy는 해당하는 트래픽을 프록시 경로로 보냅니다. Direct는 직접 연결합니다. 라우팅 선택은 서버에서 요구하는 인증 및 보안 설정을 바꾸지 않으며 잘못된 인증서도 해결하지 못합니다. 프로토콜을 비교하기 전에 두 테스트가 모두 예상한 경로를 사용하는지 확인하세요. 한 번은 직접 연결하고 한 번은 프록시를 사용했다면 결과를 비교할 수 없습니다. Scene을 사용하려면 별도의 장면 설정이 필요하므로 이 세 가지 기본 모드와 혼동하지 마세요.

[Rule]
DOMAIN-SUFFIX,example.com,PROXY
GEOIP,CN,DIRECT
FINAL,PROXY

위의 내용은 규칙 구문을 설명하는 예시입니다. 예시 도메인에는 PROXY를 사용하고, 지정한 주소 범위에 해당하는 요청에는 DIRECT를 적용하며, 그 외에는 FINAL이 처리합니다. 완전한 설정이 아니며 보유한 서버 정보를 대신하지 않습니다. 규칙은 보통 설정된 순서대로 일치 항목을 찾으므로 범위가 넓은 규칙의 위치에 따라 더 구체적인 규칙이 적용되지 않을 수 있습니다. 지정한 웹사이트만 프록시를 사용하도록 하려면 DOMAIN-SUFFIX와 FINAL,DIRECT 작성 방법을 확인하고 Config 모드에서 실제 적용 규칙을 점검하세요.

사용 환경에 따라 선택 순서를 정하세요

일상적인 웹 탐색에서는 연결 시작 시간, DNS 안정성, 네트워크 전환 후 복구를 우선 확인하세요. 지속적인 전송은 유지 가능한 처리량, 동시 작업 중 대기열, 서버 용량을 살펴봅니다. 실시간 상호작용에서는 지터, 패킷 손실, 작업에 필요한 UDP 지원 여부가 중요합니다. 장시간 모바일 사용에서는 유휴 통신과 배터리 사용량도 관찰하세요. 기존 HTTP 또는 SOCKS5 게이트웨이가 있다면 먼저 해당 인터페이스와 보안 조건을 충족해야 합니다. 기존 WireGuard 네트워크 계획이 있다면 주소와 응답 경로부터 확인하세요. 다른 프로토콜도 이름으로 순위를 매기기보다 완전한 설정이 일치하는지 확인하는 것부터 시작합니다.

간단한 테스트 기록을 만들어 접속 네트워크, 테스트 대상, 사용한 설정, Global Routing, 네트워크 전환 여부, 오류 발생 단계를 적어 두세요. 안정적인 환경에서 짧은 요청과 연속 작업을 먼저 테스트한 뒤 통제된 조건에서 네트워크를 전환합니다. 매번 항목 하나만 바꾸고 실패하면 원래 값으로 되돌리세요. Connectivity Test는 문제의 단서를 찾는 기능이지 모든 앱의 실제 사용 경험을 보장하지 않습니다. 전체 절차는 연결 확인 단계를 참고하고, 자주 묻는 질문은 초보자를 위한 질문 10가지에서 확인하세요.

정보 보존과 문제 진단 자료 공유 시 주의할 점

구독을 업데이트하면 서버 항목이나 일부 설정값이 달라질 수 있으므로 수정하기 전에 구독에서 가져온 항목과 로컬 설정을 구분하세요. 직접 수정한 값이 업데이트 후 덮어쓰였다면 프로토콜이 저절로 바뀌었다고 생각하지 말고 정보 관리 방식을 확인해야 합니다. 본인의 서비스 제공자에게 문의할 때는 처음 실패한 단계, 특정 대상에만 문제가 있는지, 네트워크를 바꾼 뒤 결과가 달라졌는지 설명하세요. 비밀번호, UUID, 개인 키, 전체 구독 주소는 가려야 합니다. 재현 가능한 현상은 단순히 ‘연결되지 않음’이라고 적힌 스크린샷보다 문제를 찾는 데 도움이 됩니다.

선택 결과는 조건을 포함해 작성하세요. ‘보유한 이 설정과 이 접속 네트워크, 이 작업에서는 이 조합이 더 적합하다’고 설명할 수 있습니다. 네트워크나 서버 조건이 달라지면 다시 검증해야 하며, 한 번의 테스트 결과를 영구적인 순위처럼 적용해서는 안 됩니다.