Shadowrocket Trojan 설정 방법 | 비밀번호·SNI·TLS 옵션 안내

이 글의 핵심 내용

서비스 제공업체에서 Trojan 설정 정보를 받은 뒤 Shadowrocket에 직접 추가하거나 설정을 확인하려는 사용자를 위한 안내입니다. 서버 주소, 인증 비밀번호, TLS 서버 이름을 구분한 다음 Add Server의 각 항목에 입력하세요. 인증서 오류, 인증 실패, 연결 후 접속 불가가 발생하면 연결 단계별로 점검하고, Allow Insecure를 켜는 것을 만능 해결책으로 삼지 마세요.

Trojan 연결에서 주소·비밀번호·TLS가 각각 하는 일

Shadowrocket의 Trojan은 프록시 프로토콜입니다. 일반적으로 먼저 서버를 찾아 TCP 연결을 맺고, TLS 핸드셰이크를 완료한 다음 Trojan 인증 정보와 대상 요청을 보냅니다. TLS는 전송을 보호하고 서버 신원을 확인하며, Trojan 비밀번호는 서버 인증에 사용됩니다. 두 기능은 서로 다르므로 대체할 수 없습니다.

입력 전에 서비스 제공업체에서 서버 주소, 포트, 비밀번호, TLS에 사용할 도메인, 추가 전송 설정 여부 등 필요한 정보를 모두 확인하세요. ‘Trojan’이라는 항목만 보고 나머지 값을 추측하면 안 됩니다. 기존 구독 링크가 있다면 먼저 구독을 가져오고, 차이를 확인해야 할 때만 각 항목을 살펴보세요. 직접 복사하다가 빠뜨리는 일을 줄일 수 있습니다.

3개 항목

기본 연결 정보: 주소, 포트, 비밀번호. 하나라도 없으면 먼저 확인해야 합니다.

443

본문의 포트는 예시이며, 모든 Trojan 서비스가 이 포트를 사용하는 것은 아닙니다.

역할 2가지

주소는 연결할 위치를 정하고, TLS 도메인은 서버 신원 확인에 사용됩니다.

정보를 모두 확인한 뒤 항목을 추가하세요.

주소와 비밀번호만 받은 경우, 포트와 TLS 도메인을 서비스 제공업체에 먼저 확인하세요. 포트를 바꾸거나 인증서 검증을 끄면서 설정을 추측하지 마세요.

Add Server 항목별 입력 방법: 값을 그대로 유지해야 하는 항목

Home 오른쪽 위의 ‘+’를 눌러 Add Server로 이동한 다음 Type을 Trojan으로 설정하세요. 플랫폼에 따라 항목의 배열이 다를 수 있으므로 화면상의 위치를 그대로 따르지 말고 각 항목의 의미를 확인하세요. 아래 예시는 예약된 도메인으로 항목 간 관계만 설명하며, 실제 연결에 사용할 수 있는 설정은 아닙니다.

항목	입력 방법	흔한 오류
Type	Trojan을 선택합니다.	항목 이름만 바꾸고 프로토콜 유형은 변경하지 않았습니다.
Address	서비스 제공업체가 안내한 도메인 또는 IP를 입력합니다. 예: `edge.example.com`.	`https://`, 경로 또는 포트가 포함된 전체 URL을 붙여 넣습니다.
Port	안내받은 정수 포트를 입력합니다. 예: `443`. 유효 범위는 1~65535입니다.	예시 포트를 고정값으로 여기거나 주소 입력란에 포트를 적습니다.
Password	Trojan 인증 비밀번호를 대소문자와 특수문자까지 그대로 입력합니다.	구독 토큰이나 계정 비밀번호를 입력하거나, 앞뒤 공백이 포함된 값을 붙여 넣습니다.
SNI	지정된 TLS 도메인을 입력합니다. 예: `tls.example.com`.	URL, 경로, 포트 또는 현재 접속하려는 웹사이트의 도메인을 잘못 입력합니다.
Allow Insecure	일반적인 사용에서는 끈 상태로 두어 클라이언트가 서버 인증서를 검증하게 합니다.	인증서 검증을 건너뛰는 설정을 연결 속도 향상이나 인증 오류 해결 수단으로 사용합니다.

Trojan의 Password는 일반적으로 인증 문자열입니다. 직접 선택하는 암호화 알고리즘도 아니고 ‘사용자 이름+비밀번호’ 조합도 아닙니다. 서비스 제공업체가 안내한 문자열을 해당 항목에 그대로 입력하세요. 직접 Base64로 인코딩하거나 해시 처리하거나 따옴표를 붙이지 마세요. 공유 링크에서 비밀번호를 직접 분리할 때는 퍼센트 인코딩에 유의하세요. 인코딩된 문자열을 실제 비밀번호로 착각할 위험을 줄이려면 전체 링크를 클라이언트에서 가져오는 편이 좋습니다.

정보에 WebSocket 등 추가 전송 방식이 지정되어 있다면 해당 전송 항목도 안내에 따라 설정해야 합니다. SNI, WebSocket의 Host, 경로는 서로 다른 역할을 합니다. 특정 설정에서 같은 도메인을 사용하더라도 모든 서비스에서 동일하다고 볼 수는 없습니다. 안내되지 않은 옵션은 이름이 비슷하다는 이유만으로 켜지 마세요.

SNI와 인증서 도메인: 서버 IP와 TLS 신원은 다릅니다

SNI는 TLS 핸드셰이크 중에 전송되는 서버 이름으로, 같은 서버에서 도메인에 따라 인증서와 서비스를 선택할 때 사용됩니다. Address는 연결할 대상을 정하고, SNI는 TLS 연결에서 요청할 이름을 나타냅니다. 두 값은 같을 수도 다를 수도 있으므로 서비스 제공업체가 안내한 값을 기준으로 설정하세요.

주소가 도메인인 경우: 주소가 인증서에 포함된 도메인이고 서비스 제공업체가 별도의 SNI를 지정하지 않았다면, 가져온 설정이나 입력 안내를 따르세요. 항목을 비워둘 수 있다는 이유로 모든 설정에 SNI가 필요 없다고 단정하지 마세요.
주소가 IP인 경우: 예를 들어 192.0.2.10에 연결하지만 인증서에는 tls.example.com이 포함된 경우, 일반적으로 안내받은 TLS 도메인을 설정해야 합니다. 도메인용 인증서가 해당 IP도 포함한다고 가정하면 안 됩니다.
도메인이 여러 개인 경우: 노드 표시 이름, 구독 주소의 도메인, TLS 도메인은 서로 다른 개념입니다. 표시 이름은 메모일 뿐이며 구독 주소는 설정을 가져오는 데 사용됩니다. 어느 쪽도 SNI를 추측하는 근거가 되지 않습니다.
인증서 검증에 실패한 경우: 도메인 철자, 인증서 유효 기간, 인증서 체인, 기기의 날짜와 시간을 확인하세요. SNI가 맞더라도 만료된 인증서나 신뢰할 수 없는 인증서 체인은 검증을 통과하지 못할 수 있습니다.

SNI에는 tls.example.com처럼 이름만 입력하세요. https://tls.example.com:443/path처럼 입력하면 안 됩니다. TLS 인증서 검증은 일반적으로 인증서의 이름이 예상한 서버 신원과 일치하는지 확인합니다. SNI를 바꿔도 연결 대상을 임의로 대체할 수 없으며, 프록시 서버 인증서 오류를 해결하기 위해 접속하려는 웹사이트의 도메인을 입력해서도 안 됩니다.

Allow Insecure 옵션: 인증서 검증과 검증 건너뛰기의 차이

Allow Insecure는 서버 인증서 검증을 완화하는 옵션입니다. 연결이 TLS 암호화를 계속 사용하더라도 신원 확인을 건너뛰면 의도한 서버에 연결되었는지 확인하는 기능이 약해집니다. 잘못된 비밀번호를 고치거나, 서버에서 수신 대기하지 않는 포트를 열거나, 만료된 구독을 복구하지는 않습니다.

Allow Insecure 끔

권장

서버 인증서를 검증합니다. 도메인 불일치, 인증서 만료, 신뢰 체인 문제가 발생하면 설정과 서버 인증서를 확인하세요. 오류를 우회한 채 계속 사용하지 마세요.

적합한 경우: 일상적인 연결 및 유효한 인증서를 사용하는 Trojan 설정

Allow Insecure 켬

인증서 검증을 완화해 서버 신원을 확인하는 기능을 약화합니다. 위험을 이해한 상태에서 통제된 진단을 할 때만 고려하세요. 이 옵션을 켜서 연결된다고 설정이 올바르다는 뜻은 아닙니다.

적합한 경우: 담당자가 명확히 지시한 임시 인증서 오류 진단. 장기 설정으로 사용하지 마세요.

인증서 오류는 올바른 단계에서 해결하세요

기기 시간과 SNI를 확인한 뒤에도 인증서 오류가 발생하면 오류 유형을 서비스 제공업체에 알리고 서버 인증서 상태를 확인하세요. 문제가 해결되면 Allow Insecure를 끈 설정으로 다시 검증하세요.

항목 추가부터 연결 확인까지: 한 번에 설정 하나만 변경

아래는 직접 추가하는 방법입니다. 구독을 사용 중이라면 서비스 제공업체에서 구독 링크를 받아 가져오기 절차에 따라 사용하세요. 설정 하나를 확인하려고 기존 구독을 삭제하지 마세요. 구독으로 관리되는 항목은 다음 업데이트 때 덮어써질 수 있으므로, 지속적으로 수정해야 하는 설정은 먼저 서비스 제공업체에 확인하세요.

정보 확인

주소, 포트, Password, SNI, 전송 관련 설정을 준비하세요. 기존 Global Routing 상태를 기록해 두세요. Settings → On Demand에서 자동 연결을 켰다면 테스트 중 다시 연결될 수 있습니다. 자동 재연결을 수동 설정이 저장되지 않은 것으로 오해하지 마세요.
항목 추가

Home → ‘+’ → Add Server → Type → Trojan 순으로 이동합니다. 주소와 포트를 각각 입력하세요. 전체 공유 링크를 Address에 넣거나 구독 링크를 서버 주소로 사용하지 마세요.
서버 신원 확인

원본 인증 문자열을 Password에 입력하고 안내에 따라 SNI를 설정한 뒤 Allow Insecure는 끈 상태로 둡니다. 추가 전송 설정은 안내된 경우에만 입력하세요. 완료되면 저장한 다음 Home으로 돌아가 해당 항목을 선택합니다.
연결 테스트

Home에서 Connectivity Test로 기본 연결 상태를 확인한 다음 연결을 설정하고 프록시를 거쳐야 하는 대상에 접속해 보세요. 테스트에 응답이 있다고 해서 모든 웹사이트, 규칙, UDP 요청까지 확인된 것은 아닙니다.
라우팅 확인

규칙의 영향을 분리해 확인하려면 Global Routing을 잠시 Proxy로 설정한 뒤 같은 접속을 반복하세요. 테스트가 끝나면 원래 Config 등의 상태로 되돌려 기존 라우팅 동작이 계속 바뀌지 않도록 하세요.

한 번에 한 항목만 변경하고 변경 전후의 오류를 기록하세요. 예를 들어 “SNI를 바로잡자 인증서 오류가 사라졌지만 인증 실패가 발생했다”면 다음 점검 단계로 넘어간 것입니다. 이때는 TLS 옵션을 계속 무작위로 바꾸지 말고 Password를 확인하세요. 스크린샷이나 문의 내용에 비밀번호, 전체 공유 링크, 구독 토큰을 노출하지 마세요.

자주 묻는 질문: 오류가 발생한 단계별 점검

주소와 비밀번호를 모두 입력했는데 계속 시간 초과가 발생하는 이유는 무엇인가요?

먼저 Port와 주소를 확인하고 주소 입력란에 프로토콜 접두사나 경로가 포함되지 않았는지 확인하세요. 도메인 이름 해석 실패, 네트워크 연결 불가, 서버 포트 미개방 등이 시간 초과의 원인일 수 있습니다. 이런 오류는 TLS나 비밀번호 인증 단계까지 도달하지 않았을 수 있습니다. 사용 가능한 네트워크에서 같은 테스트를 다시 실행한 뒤 서비스 제공업체에 서버 상태를 확인하세요. 먼저 Allow Insecure를 켜지는 마세요.

인증서 오류가 표시됩니다. 비밀번호가 틀린 건가요?

먼저 TLS 단계를 점검하세요. SNI 철자, 기기의 날짜와 시간, 서버 인증서 상태를 확인합니다. Password는 이후 Trojan 인증에 사용되므로 비밀번호를 바꿔도 인증서 도메인 불일치는 해결되지 않습니다. 모든 TLS 옵션을 계속 바꾸기보다 오류 원문을 그대로 보관해 전달하는 편이 문제를 찾는 데 도움이 됩니다.

연결은 됐는데 웹페이지가 계속 직접 연결되는 이유는 무엇인가요?

Home → Global Routing을 확인하세요. Direct는 프록시 경로를 확인하는 데 사용할 수 없습니다. Config에서는 현재 설정의 규칙에 따라 라우팅 방식을 정합니다. Proxy로 잠시 바꿔 다시 시도해 증상이 달라지면 Config에서 활성화된 설정과 규칙 순서를 확인하세요. 라우팅 문제를 Trojan 비밀번호 오류로 오해하지 마세요.

어제 직접 수정했는데 구독을 업데이트한 뒤 설정이 다시 바뀐 이유는 무엇인가요?

구독을 업데이트하면 구독에서 관리하는 항목이 다시 생성될 수 있습니다. 업데이트 후 Address, Port, SNI가 원래 출처의 값으로 돌아갔는지 확인하고 서비스 제공업체에 구독 데이터를 문의하세요. 비교가 필요하면 별도의 수동 테스트 항목을 보관하세요. 구독 관리 항목을 반복해서 수정해 출처의 문제를 가리지 마세요.

Global Routing의 Proxy, Direct, Config, Scene은 프로토콜 옵션이 아닙니다. 이 항목들은 라우팅 방식을 결정하고, Trojan 설정은 서버 연결 방법을 결정합니다. Scene은 설정된 조건에 따라 동작하므로 문제를 확인할 때 실제 적용된 라우팅 방식도 살펴보세요. 연결 아이콘이 표시된다고 특정 웹 요청이 선택한 Trojan 항목을 통해 전송된다고 단정할 수는 없습니다.

규칙 확인 및 설정 정보 관리

Config로 되돌린 다음에는 요청을 구분할 수 있는 방식으로 규칙을 확인해야 합니다. 아래 예시는 매칭 관계만 보여 줍니다. 예시 도메인과 일치하는 요청은 PROXY로 보내고 나머지는 DIRECT로 보냅니다. PROXY가 실제로 사용할 수 있는 프록시 정책을 설정에서 찾을 수 있어야 합니다. 규칙 문구만 복사해도 Trojan 서버가 추가되는 것은 아닙니다.

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

규칙은 순서대로 확인합니다. DOMAIN-SUFFIX는 도메인과 그 하위 도메인에 일치하고, FINAL은 앞선 규칙에 일치하지 않는 경우 적용되는 기본 규칙입니다. 실제 설정에 앞 순서의 일치 규칙이 있다면 함께 확인해야 하며, 방금 추가한 두 줄만 확인해서는 안 됩니다. 문법을 더 알아보려면 규칙 참고 문서를 확인하세요. 웹사이트의 라우팅을 바꾸기 위해 SNI를 수정하지 마세요.

평소에는 인증서 검증을 유지하고, 테스트가 끝나면 원래 Global Routing 및 On Demand 설정으로 되돌리세요.
비밀번호, 노드 공유 링크, 구독 링크는 모두 민감 정보로 취급하세요. 문의할 때는 민감 정보를 가린 항목 관계, 오류 원문, 오류가 발생한 단계를 제공하세요.
공유 링크는 일반적으로 단일 연결 설정을 나타내며, 구독 링크는 여러 설정을 가져오고 업데이트하는 데 사용됩니다. 추가 정보가 필요하면 서비스 제공업체에 문의하세요.
새 비밀번호가 적용되었다면 기존 항목의 저장된 사본도 함께 처리하세요. 나중에 잘못 선택해 이미 해결된 인증 문제를 다시 점검하지 않도록 주의해야 합니다.