Shadowrocket
프로토콜 종류 및 설정값 안내

설계 배경과 한계

Shadowsocks는 비교적 간결한 프로토콜로 암호화된 프록시 전달을 제공하도록 설계되었습니다. 클라이언트가 서버에 대상 정보를 전달하면 서버가 해당 대상과 연결합니다. 기본 인증 조건으로 웹사이트 인증서를 사용하는 대신 양측이 합의한 비밀번호와 암호화 방식을 주로 사용합니다. 이 점을 이해하면 설정값을 구분하는 데 도움이 됩니다. 일반적인 Shadowsocks 설정에서는 Password와 Method가 모두 필요합니다. 다른 프로토콜의 비밀번호를 그대로 입력하거나 포트가 같다는 이유만으로 두 서비스를 서로 바꿔 쓸 수 있다고 판단해서는 안 됩니다.

암호화 방식에 따라 메시지 형식과 키 요구 사항이 다를 수 있습니다. 최신 방식과 이전 방식의 차이는 단순히 강도만이 아니라 키 인코딩, 길이, 구현 호환성에도 있을 수 있습니다. 서버에서 지정한 방식을 선택해야 합니다. 목록에서 일치하는 항목을 찾을 수 없다면 이름이 비슷한 항목으로 대체하지 말고, 해당 정보가 현재 클라이언트에서 사용할 수 있는 것인지 확인하세요. 가져온 뒤에도 암호화 방식의 이름을 확인하고, 특히 구독 변환 과정에서 누락되지 않았는지 살펴보세요.

주소, 포트, 비밀번호, 암호화 방식을 하나씩 확인

Server에는 서버 도메인이나 IP 주소를 입력하고, Port에는 실제로 수신 대기 중인 포트를 입력합니다. 주소에는 일반적으로 웹페이지 경로를 포함하지 않으며, 포트를 주소 입력란에 합쳐서 입력해서도 안 됩니다. Password는 제공받은 정보를 빠짐없이 입력하세요. 복사할 때 공백, 줄바꿈, 전각 문자가 들어가지 않았는지 확인합니다. Method는 구체적인 암호화 방식을 뜻하며 임의로 선택하는 항목이 아닙니다. 주소가 정상적으로 조회되는데 연결이 계속 실패한다면 포트와 암호화 방식도 확인하세요. 도메인으로 웹페이지가 열린다는 사실만으로 프록시 포트가 정상이라고 판단할 수는 없습니다.

일부 설정에는 추가 전송 매개변수가 포함될 수 있지만, 모든 Shadowsocks 서비스가 이를 요구하는 것은 아닙니다. 기존 정보에 명시된 경우에만 활성화하고, 해당 이름과 설정값을 그대로 유지하세요. 다른 설정에 특정 옵션이 있다고 해서 현재 연결에도 똑같이 추가해서는 안 됩니다. 추가 캡슐화는 서버가 예상하는 데이터 형식을 바꿀 수 있습니다. 가져온 항목과 수동 입력 결과가 다르다면 필드별로 비교하되, 원래 정보를 잃지 않도록 가져온 항목을 먼저 기준으로 보존하세요.

TCP 연결 성공이 UDP 사용 가능을 뜻하지는 않음

대부분의 웹 탐색은 TCP로 가능하지만 실시간 통신, 일부 도메인 조회, QUIC을 사용하는 앱에는 UDP가 필요할 수 있습니다. Shadowsocks에서 TCP와 UDP를 전달하려면 각각 조건을 충족해야 합니다. 서버가 해당 기능을 지원하고, 네트워크가 데이터를 허용하며, 클라이언트 설정에서 기능을 끄지 않아야 합니다. 웹페이지는 정상인데 실시간 서비스가 실패한다면 이 경로를 확인하세요. 웹페이지가 한 번 열렸다는 이유만으로 모든 앱에서 연결을 사용할 수 있다고 단정하지 마세요. 반대로 한 앱에서 실패했다고 전체 연결이 작동하지 않는다고 판단해서도 안 됩니다.

iPhone과 iPad에서는 전송 계층이 간결하면 확인할 요소가 적을 수 있지만, 항상 더 빠르거나 배터리를 덜 소모한다는 뜻은 아닙니다. 기기 칩의 알고리즘 처리 성능, 연결 수, 네트워크 재전송이 실제 결과를 바꿀 수 있습니다. 같은 설정이 Wi-Fi에서는 정상이고 셀룰러에서는 시간 초과된다면 먼저 연결 포트와 네트워크 접근성을 비교하세요. 부하가 높을 때만 속도가 크게 느려진다면 서버 부하와 지속 처리량도 살펴보세요. 프로토콜 이름만으로 결론을 내릴 수는 없습니다.

문제 해결은 ‘정보가 빠짐없이 입력되었는지, 서버에 연결할 수 있는지, 인증 정보가 일치하는지, 필요한 기능이 지원되는지’ 순으로 진행하세요. 먼저 구독 업데이트가 성공했는지 확인한 다음 현재 선택된 항목을 살펴보세요. 다른 항목을 수정해 놓고 엉뚱한 항목을 테스트하지 않도록 주의합니다. 인증 오류가 발생하면 비밀번호와 암호화 방식을 다시 확인하세요. 연결 시간 초과는 주소, 포트, 현재 네트워크부터 살펴보고, 일부 요청만 비정상이라면 규칙과 UDP를 확인하세요. 여러 설정을 동시에 바꾸기보다 원인과 결과를 분명히 확인할 수 있습니다.

기존 서버에서 Shadowsocks만 제공한다면 설정이 완전히 일치하는 항목을 사용하면 됩니다. 프로토콜 이름을 바꾸려고 유형을 변경할 필요는 없습니다. 사용할 수 있는 설정이 여러 개라면 같은 대상과 비슷한 시간대에 웹페이지 첫 로딩, 지속 전송, 백그라운드 대기 상태를 비교하세요. ‘가볍다’거나 ‘빠르다’고 단정하기보다 어떤 단계에서 개선되었는지 기록하면 네트워크 조건이 달라진 뒤에도 판단하기 쉽습니다.

인증서 신원과 사용자 비밀번호 구분

Trojan은 TLS 연결 안에서 프록시 세션을 처리합니다. 먼저 TLS로 보호된 채널을 만든 다음 그 안에서 프로토콜 인증 정보와 대상 정보를 전달합니다. 여기에는 서로 다른 두 가지 신원이 있습니다. 인증서는 연결 대상 서버를 확인하고, Password는 클라이언트의 접근 권한을 확인합니다. 비밀번호가 올바르다고 인증서 이름 오류가 해결되는 것은 아니며, 인증서가 유효하다고 서버가 비밀번호를 승인한 것도 아닙니다. 문제를 해결할 때는 모든 실패를 비밀번호 오류로 간주하지 말고 핸드셰이크 순서에 따라 살펴보세요.

이 방식은 보안 기능의 상당 부분을 TLS에 맡기므로 서버 이름, 인증서 유효 기간, 기기의 신뢰 조건이 중요합니다. 그렇다고 사용자가 모든 TLS 옵션을 직접 입력해야 한다는 뜻은 아닙니다. 기존 구독에는 일반적으로 필요한 설정이 포함되어 있습니다. 먼저 가져온 설정을 유지하고 오류를 바탕으로 누락된 항목을 찾으세요. 전체 설정 없이 이름을 임의로 바꾸어 시험하면 다른 서버에 연결될 수 있고, 문제 원인을 파악하기가 더 어려워집니다.

Server, Server Name, 인증서 체인

Server는 네트워크 연결에서 실제로 접속할 주소이고, Server Name은 TLS 핸드셰이크와 이름 확인에 사용되는 주요 정보입니다. 도메인으로 연결할 때는 두 값이 같은 경우가 많지만 IP로 연결하더라도 Server Name에는 기존 도메인을 유지해야 할 수 있습니다. 인증서 확인에는 유효 기간과 신뢰 체인도 관여하므로 이름이 올바른 것만으로는 충분하지 않습니다. 인증서가 만료되었거나 중간 인증서 설정에 문제가 있다면 비밀번호를 반복해서 바꾸지 말고 서버 설정을 수정해야 합니다.

기기 시간 오차, 네트워크 인증 페이지, 잘못된 도메인 조회는 비슷해 보이는 TLS 오류를 일으킬 수 있습니다. 공용 Wi-Fi에서 웹 로그인을 완료하지 않았다면 접속이 인증 페이지로 리디렉션될 수 있습니다. 잘못된 주소로 조회되면 해당 서비스와 무관한 인증서가 반환될 수도 있습니다. 이런 문제가 의심되면 먼저 네트워크 자체를 정상적으로 사용할 수 있는지 확인한 다음 도메인 조회 결과와 Server Name을 점검하세요. 연결 대상이 확인되기 전에 인증 정보를 더 입력하거나 신뢰 범위를 넓히지 마세요.

인증, 전송, 서비스 지원의 범위

Trojan의 Password는 대소문자와 기호를 포함해 그대로 유지하세요. 구독 링크의 전체 문자열을 그대로 붙여 넣지 마세요. 기존 정보에 추가 전송 방식이 지정되어 있다면 서버 설정과 일치시켜야 합니다. 일반적으로 흔히 사용하는 전송 방식이라는 이유만으로 설정에 명시된 추가 필드를 삭제해서는 안 됩니다. 가져온 뒤 유형, 주소, 포트, 비밀번호, TLS 이름을 확인하고 다른 전송 설정을 살펴보세요. 이 순서로 확인하면 가장 흔한 구조 오류를 먼저 찾을 수 있습니다.

UDP 사용 여부는 서버 지원, 클라이언트 설정, 실제 네트워크 조건에 따라 달라집니다. 프로토콜이 특정 유형의 데이터를 전달할 수 있다고 해도 모든 앱이 똑같이 작동하는 것은 아닙니다. 실시간 서비스는 지연과 지터에 민감하고, 장시간 다운로드는 서버의 외부 대역폭에 더 크게 영향을 받습니다. 일반 웹페이지는 정상인데 특정 실시간 앱에서 문제가 생긴다면 해당 앱의 사용 환경을 별도로 확인하세요. 웹페이지 접속만으로 앱 동작을 판단하거나, 문제를 가리려고 각종 시간 제한을 무작정 늘리지 마세요.

iOS에서 연결 재사용과 재연결 살펴보기

TLS 핸드셰이크에는 데이터 교환과 연산이 필요하므로 최초 연결과 이후의 안정적인 전송은 비용이 다릅니다. 짧은 연결을 자주 만드는 환경에서는 핸드셰이크 횟수가 응답 시간과 배터리에 영향을 줄 수 있습니다. 장시간 연결을 유지하면 이 비용이 분산되고 연결 품질이 더 중요해질 수 있습니다. 서버와 클라이언트가 관련 재사용 기능을 사용하는지도 결과에 영향을 줍니다. 테스트할 때는 처음 열었을 때와 연속으로 방문할 때를 따로 기록하세요. 세션이 이미 설정된 뒤의 속도를 최초 연결 성능으로 간주하지 마세요.

Wi-Fi에서 셀룰러로 전환하면 기기 주소와 연결 경로가 달라질 수 있어 기존 TCP 연결을 다시 설정해야 하는 경우가 많습니다. 전환 후 오랫동안 복구되지 않으면 현재 작업을 중지하고 새 네트워크가 정상인지 확인한 다음 재연결 시간을 테스트하세요. 바로 설정을 모두 지우지는 마세요. 백그라운드에서 연결에 반복해 실패하면 재시도와 무선 기능 활성 시간이 늘어나 배터리 소모가 증가할 수 있습니다. 먼저 실패 원인을 확인하고 암호화 연산을 배터리 소모 원인으로 단정하지 마세요.

안정적으로 작동하는 Trojan 설정이 이미 있다면 일상적으로 사용할 때 올바른 인증서 확인과 인증 설정을 유지하고 구독 업데이트 후 덮어쓰이지 않았는지 확인하는 것이 중요합니다. 다른 프로토콜과 비교하려면 네트워크 경로, 대상, 테스트 시간을 비슷하게 맞추고 연결 구성 전체의 성능을 비교하는 것인지 기록하세요. 프로토콜 설명은 문제를 찾는 데 도움을 주지만 서버의 작동 상태나 대상 서비스에 연결할 수 있는지 확인하는 일을 대신하지 않습니다.

네트워크 계층 데이터를 처리하는 방식부터 이해하기

WireGuard는 네트워크 계층 터널을 기반으로 하며, 특정 대상에 프록시 연결을 만드는 방식과는 다릅니다. 원격 주소뿐 아니라 로컬 주소, 키 신원, 터널로 보낼 주소 범위도 설정해야 합니다. 클라이언트에서 여러 연결을 통합 관리하더라도 이러한 네트워크 계층 조건은 그대로 필요합니다. 도메인과 비밀번호만으로 설정을 임의로 조립하지 말고 완전한 설정을 받아 사용하세요. 터널 주소나 피어 공개 키가 없으면 예상한 통신 관계를 만들기 어렵습니다.

WireGuard는 공개 키로 통신 피어를 식별합니다. 로컬 개인 키는 로컬 신원을 증명하고 피어 공개 키는 연결할 원격 신원을 지정합니다. 서로 바꿔 쓸 수 있는 두 문자열이 아닙니다. 클라이언트 개인 키는 비밀로 유지해야 하며 서버에도 해당 클라이언트와 연결된 공개 키가 설정되어 있어야 합니다. 휴대폰에 새 키를 입력한다고 서버가 이를 자동으로 인식하지는 않습니다. 관리자가 설정을 제공했다면 양측이 합의한 키 쌍을 그대로 유지하고 임의로 다시 만들어 덮어쓰지 마세요.

Endpoint, Address, Allowed IPs

Endpoint는 일반적으로 호스트와 UDP 포트로 구성되는 터널 피어의 연결 주소입니다. Address는 터널 내 로컬 주소이며 서버의 공인 주소가 아닙니다. Allowed IPs는 WireGuard의 기본 의미상 대상 라우팅 범위와 피어가 허용하는 주소 범위 모두와 관련됩니다. 클라이언트 통합 환경에서의 구체적인 처리는 앱 설정도 함께 확인해야 합니다. 이 역할을 이해하면 ‘핸드셰이크는 성공했지만 접속되지 않는’ 문제를 찾는 데 도움이 됩니다. 신원 핸드셰이크가 완료되었다는 것은 세션이 만들어졌다는 뜻이지 모든 대상에 올바른 경로가 있다는 뜻은 아닙니다.

조직 내부 네트워크에 접속하려면 대상 네트워크 대역이 제공된 설정 범위와 일치해야 하며 서버에도 전달 경로와 응답 경로가 있어야 합니다. 로컬 Wi-Fi 대역이 원격 내부 네트워크와 겹치면 라우팅 경로가 모호해질 수 있습니다. 이런 경우 키를 계속 바꿔도 도움이 되지 않습니다. 먼저 대상 주소가 실제로 어느 경로를 사용하는지 확인하세요. IPv6도 해당 주소와 라우팅 조건이 있는지 살펴봐야 합니다. IPv4를 사용할 수 있다고 다른 주소 공간도 자동으로 사용할 수 있는 것은 아닙니다.

Keepalive 설정과 모바일 네트워크의 균형

WireGuard는 UDP를 사용합니다. 모바일 기기가 주소 변환 장치를 거쳐 원격으로 접속할 때 유휴 상태의 매핑이 만료될 수 있습니다. Persistent Keepalive의 한 가지 목적은 주기적으로 패킷을 보내 관련 매핑을 유지하는 것이며 대역폭을 높이는 기능은 아닙니다. Keepalive 주기가 짧으면 무선 기능이 더 자주 작동하고, 길면 일부 네트워크에서 유휴 상태 이후 복구가 느려질 수 있습니다. 기존 설정을 따르고 유휴 상태 복구 문제가 실제로 발생할 때만 확인하세요. 모든 휴대폰에 같은 고정 간격을 적용하지 마세요.

네트워크를 전환하면 외부 연결 주소가 달라질 수 있습니다. WireGuard는 조건이 맞으면 피어 주소 변경에 대응할 수 있지만 실제 동작은 새 네트워크의 UDP 연결 가능 여부, 주소 변환, 서버 정책에 따라 달라집니다. Wi-Fi는 되는데 셀룰러에서 연결되지 않는다면 먼저 UDP 연결이 가능한지 비교한 뒤 통신사 네트워크와 피어 제한을 살펴보세요. 주소 갱신 기능이 있다고 모든 전환에서 연결이 끊기지 않는 것은 아닙니다. 한 번 빠르게 복구되었다고 모든 네트워크에서 세션이 유지된다고 판단하지 마세요.

MTU와 DNS를 각각 확인하기

터널 캡슐화는 패킷 공간을 차지합니다. 경로에서 전달할 수 있는 실제 크기와 MTU 설정이 맞지 않으면 작은 요청은 성공하지만 큰 응답이 멈출 수 있습니다. 다만 패킷 손실이나 서버 문제도 비슷한 증상을 일으킬 수 있습니다. 설정을 바꾸기 전에 원래 값을 저장하고 한 번에 하나만 변경한 뒤 같은 요청을 반복하세요. 온라인에서 찾은 MTU 값을 모든 환경에 적용하지 말고, 웹페이지가 열리지 않는다고 곧바로 값을 아주 낮추지 마세요. 처리량이 불필요하게 떨어질 수 있습니다.

DNS는 도메인이 어떤 주소를 사용하는지 결정하고 라우팅은 데이터가 어디로 전달되는지 결정합니다. 터널 환경에서는 두 문제가 함께 나타나기도 하지만 역할은 다릅니다. 알려진 내부 IP 주소로는 접속되지만 이름으로는 안 된다면 내부 DNS와 해당 DNS에 도달할 수 있는 경로부터 확인하세요. 내부 네트워크를 연결해야 하는 경우에는 프로토콜 속도 테스트보다 주소 계획이 더 중요합니다. 일반 웹페이지 환경에서는 Shadowrocket의 실제 정책을 확인해 요청이 예상한 연결로 전달되는지 살펴보세요.

동일한 작업으로 기준 결과 만들기

프로토콜 비교는 실제 사용 목적에 맞춰야 합니다. 일상적인 웹 탐색에서는 첫 응답과 연속 로딩을, 대용량 파일 전송에서는 안정적인 처리량과 중간 연결 끊김을, 실시간 통신에서는 지연·지터·UDP 동작을, 내부 네트워크 접속에서는 주소 계획·DNS·응답 경로를 살펴보세요. 사용할 수 있는 설정이 여러 개라면 먼저 작업을 완료할 수 있는 하나를 기준으로 삼고 다른 설정과 비교하세요. 모든 설정에서 실패한다면 프로토콜을 평가하기 전에 현재 네트워크와 대상 서비스 자체를 확인하세요.

유효하게 비교하려면 기기, 네트워크, 대상, 규칙 모드, 테스트 시간을 가능한 한 동일하게 유지하고 백그라운드에서 대용량 데이터를 전송하는 작업은 잠시 중지하세요. 최초 연결인지도 기록합니다. 각 설정을 몇 차례 반복하고 가장 좋았던 결과가 아니라 일반적으로 나타나는 결과를 기준으로 비교하세요. Connectivity Test는 연결할 수 없는 항목을 찾는 데 도움이 되지만 실제 웹페이지 사용 경험 전체를 보여주지는 않습니다. UDP, 내부 네트워크, 장시간 연결이 정상이라는 증거도 아닙니다. 연결 테스트, 실제 접속, 지속 전송을 나누어 확인해야 어느 단계에서 차이가 생기는지 파악할 수 있습니다.

Global Routing의 세 가지 모드로 변수를 분리

Config는 현재 설정의 규칙에 따라 연결 정책을 결정하고, Proxy는 해당 트래픽을 프록시 경로로 보내며, Direct는 직접 연결합니다. Config에서 실패하지만 Proxy에서는 정상이라면 비밀번호를 곧바로 바꾸기보다 규칙과 정책 연결을 확인해야 합니다. 프록시가 필요한 두 모드에서 모두 실패한다면 연결 주소, 인증, 전송 설정을 다시 확인하세요. Direct 테스트는 로컬 네트워크 기준을 확인하는 데만 도움이 됩니다. 대상에 직접 연결할 수 없다고 해서 그것만으로 프록시 프로토콜에 문제가 있다고 볼 수는 없습니다.

아래 예시는 도메인 접미사에 따라 정책을 선택하고 주소 대역에는 직접 연결을 적용한 뒤, 나머지 요청을 최종 규칙으로 처리하는 기본 구조입니다. 예시는 Shadowrocket의 .conf 규칙 내용이며 연결 가능한 서버 설정이나 인증 정보를 포함하지 않습니다. PROXY는 실제 설정에서 유효한 정책에 대응해야 합니다. 가져오거나 수정하기 전에 백업하고 현재 Config에서 편집할 파일을 선택했는지 확인하세요. 규칙은 일반적으로 위에서부터 순서대로 적용되므로 앞의 넓은 조건이 뒤의 구체적인 조건보다 먼저 일치할 수 있습니다.

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

도메인 규칙은 클라이언트가 적절한 단계에서 도메인 정보를 파악할 수 있어야 하고 IP 규칙은 주소를 기준으로 일치 여부를 판단합니다. 둘은 서로 간단히 바꿔 쓸 수 없습니다. 웹사이트는 여러 리소스 도메인을 사용할 수 있고 앱은 IP 주소에 직접 연결할 수도 있습니다. 따라서 ‘메인 페이지에 예상한 정책이 적용됐다’고 해서 관련 요청 모두에 같은 정책이 적용되는 것은 아닙니다. GEOIP 결과는 주소 데이터베이스와 대상 주소 변경의 영향을 받을 수 있습니다. 특정 웹사이트만 프록시를 사용하도록 하려면 지정한 웹사이트에 PROXY를 적용하는 규칙 안내를 참고한 뒤 필요한 조건을 추가하세요.

증상에 따라 해당 계층부터 확인

연결이 완전히 시간 초과되면 네트워크, 주소, 포트를 먼저 확인하세요. 인증 오류가 명확하면 비밀번호, UUID, 키 쌍을 다시 살펴보세요. TLS 오류는 시스템 시간, Server Name, 인증서를 확인합니다. 핸드셰이크는 성공했지만 업무가 실패한다면 대상 연결 가능 여부, DNS, UDP, 라우팅을 점검하세요. 도메인 하나만 실패하면 다른 알려진 대상으로 테스트하고 모든 도메인이 실패하지만 알고 있는 IP에는 연결할 수 있다면 DNS를 집중적으로 확인하세요. 설정을 한 번에 한 그룹만 변경하고 확인 결과를 기록하세요. 여러 추측을 동시에 설정에 반영하지 마세요.

재현 가능한 기록을 남긴 뒤 프로토콜 변경 여부 결정

문제 해결 기록에는 기기 네트워크, 대상 유형, Global Routing 모드, 오류가 발생한 단계와 조건을 포함하세요. 전체 구독 주소, 비밀번호, 개인 키는 공개할 필요가 없습니다. 스크린샷이나 글을 공유하기 전에 인증 정보와 개인 식별 정보를 삭제하고, 재현에 필요한 프로토콜 유형과 민감하지 않은 필드만 남기세요. 기존 구독을 업데이트한 뒤에는 유형, 전송 방식, 이름 필드가 바뀌었는지 비교할 수 있습니다. 새 설정이 정상 작동하는지 확인할 때까지 기존 항목을 기준으로 보존하세요.

최종 선택은 호환성과 재현 가능한 결과를 기준으로 해야 합니다. 작업을 완료하고 네트워크 전환 후 복구되며 장시간 사용 중 반복 재시도가 발생하지 않는 설정이 한 번 측정한 최고 속도보다 더 유용한 기준입니다. 가져오기 및 연결 문제는 빠른 시작의 문제 해결에서, 인터페이스 용어는 개념 빠른 참조에서, 기능 동작은 기능 안내에서 확인하세요. 서버 인증, 인증서, 라우팅 범위에 문제가 있다면 클라이언트에서 관련 없는 설정을 계속 바꾸기보다 기존 정보를 제공한 곳에 해당 설정을 확인하세요.