Shadowrocket Trojan 노드 추가 방법: 프로토콜 원리와 Add Server 설정 가이드

Trojan의 TLS 연결 방식부터 살펴보고, Add Server의 주소·포트·암호·SNI·인증서 검증 설정 방법과 잘못 입력했을 때의 증상을 설명합니다.

핵심 내용

서비스 제공업체에서 받은 연결 정보가 있고, Shadowrocket에서 Trojan을 직접 추가하려는 사용자를 위한 안내입니다. 서버 주소, TLS 인증에 쓰이는 서버 이름, 프로토콜 암호를 구분한 뒤 Add Server의 각 항목에 입력하고 연결을 확인합니다. 연결이 실패하면 어느 단계에서 문제가 발생했는지에 따라 점검하세요. 구독과 노드 정보는 이용 중인 서비스 제공업체에서 받으세요. 이 문서의 도메인과 매개변수는 입력 항목을 설명하기 위한 예시이며 실제 접속 정보가 아닙니다.

Trojan 작동 방식: TLS 연결 후 프로토콜 인증

Trojan은 프록시 프로토콜 데이터를 TLS로 암호화된 연결에 담아 전송합니다. 기본 연결은 주로 TCP를 사용합니다. 클라이언트가 서버 주소와 포트에 연결한 뒤 TLS 핸드셰이크와 인증서 검증을 마치고, Trojan 인증 정보와 대상 요청을 보냅니다. 서버는 인증을 통과한 뒤에야 트래픽을 전달합니다. 따라서 ‘포트 연결 가능’, ‘TLS 핸드셰이크 성공’, ‘암호 인증 통과’, ‘대상 웹사이트 접속 가능’은 각각 다른 점검 결과이며 서로 대신할 수 없습니다.

서버 주소 확인 TCP 연결 TLS 핸드셰이크 프로토콜 인증 대상으로 전달

TLS는 연결 암호화와 서버 인증을 담당하고, Trojan 암호는 프로토콜 접속 인증에 사용됩니다. 두 기능은 서로 다릅니다. 암호가 맞아도 만료된 인증서는 유효해지지 않으며, 인증서가 유효하다고 해서 암호까지 맞는 것은 아닙니다. 서버가 443 포트를 사용한다는 것은 해당 포트에서 연결을 받는다는 뜻일 뿐, Trojan 서비스를 제공한다고 단정할 수는 없습니다.

443
일반적인 TLS 서비스 포트. 실제 포트는 서비스 제공업체가 안내한 값을 사용하세요.
1–65535
입력할 수 있는 대상 포트 범위. 서버가 실제로 수신 대기 중인 포트와 일치해야 합니다.
자격 정보 2가지
인증서는 서버 인증에, Password는 Trojan 인증에 사용됩니다.

이 문서에서는 기본 Trojan over TLS 연결을 예로 듭니다. 서비스 제공업체가 WebSocket, 경로 또는 다른 전송 매개변수도 안내했다면 주소·포트·암호만으로는 연결되지 않을 수 있습니다. 하나의 완전한 설정 정보를 기준으로 확인하고, 서로 다른 설정의 SNI, Password, 전송 옵션을 섞어 입력하지 마세요.

Add Server 입력 전: 전체 매개변수 확인

직접 입력하기 전에 안내받은 정보에 Trojan이라고 명시되어 있는지 확인하세요. 포트나 도메인만으로 프로토콜을 추측해서는 안 됩니다. 서비스 제공업체가 제공한 모든 항목을 유지하려면 구독을 가져오는 방법이 적합하고, 항목별로 직접 확인하려면 수동 추가를 이용할 수 있습니다. 두 방법 모두 같은 연결 정보를 사용하며, 입력을 누가 처리하느냐가 다릅니다.

Home → Add Server: 주소·포트·암호 입력

Home 오른쪽 위의 추가 버튼을 누르고 Add Server로 이동한 다음 Type을 Trojan으로 설정하고 표의 항목을 입력하세요. 항목 순서와 추가 옵션의 표시는 현재 앱 화면에 따라 다를 수 있습니다. 오래된 화면의 위치를 따라 입력하기보다 각 항목의 의미에 맞춰 정보를 확인하세요.

항목입력 기준잘못 입력했을 때 나타나는 증상
Type서버 프로토콜과 일치하도록 Trojan을 선택합니다.주소에 접속할 수 있어도 프로토콜 인증이 완료되지 않을 수 있습니다.
Address서비스 제공업체가 안내한 호스트 이름 또는 IP. 예: edge.example.com도메인 조회 실패, 잘못된 주소로 연결 또는 연결 시간 초과
Port서버에서 수신 대기 중인 포트. 예: 443연결 거부, 시간 초과 또는 다른 서비스에 연결
Password서비스 제공업체가 제공한 Trojan 암호 원문TLS 연결은 성공해도 이후 인증이나 요청이 실패할 수 있습니다.
SNI서비스 제공업체가 지정한 TLS 호스트 이름. 예: tls.example.com잘못된 인증서를 받거나 호스트 이름 검증에 실패할 수 있습니다.
Allow Insecure유효한 일반 인증서를 사용하는 경우 이 옵션은 끄고 인증서 검증을 유지합니다.이 옵션을 켜면 서버 인증이 약해지며, 잘못된 연결 설정이 해결되지는 않습니다.
  1. 먼저 Type, Address, Port를 입력하고 Address에 포트 번호를 중복으로 넣지 않았는지 확인하세요.
  2. Password를 붙여 넣고 모든 문자가 정확히 입력됐는지 확인하세요. 암호 항목에는 URL 인코딩을 임의로 적용하지 말고 원문을 입력해야 합니다.
  3. 안내된 값에 따라 SNI를 설정하고 인증서 검증 옵션을 확인하세요. 추가 전송 설정이 필요하다면 함께 입력합니다.
  4. 저장한 뒤 Home으로 돌아가 방금 추가한 항목을 선택하고 연결을 켭니다. 시스템에서 VPN 구성을 추가하라는 메시지가 표시되면 안내에 따라 확인하세요.

포트가 같다고 해서 설정을 서로 바꿔 쓸 수 있는 것은 아니며, Port를 변경해도 서버의 수신 포트가 자동으로 바뀌지 않습니다. 포트 안내가 없다면 여러 일반 포트를 차례로 시도하지 말고 서비스 제공업체에 확인하세요. Password는 앱 구매 암호나 기기 잠금 암호와도 다릅니다.

SNI 및 인증서 검증: 주소가 같아도 인증 대상은 다를 수 있습니다

Address는 연결할 위치를 지정합니다. SNI는 TLS 핸드셰이크에서 서버 이름을 알리는 정보로, 서버가 적절한 사이트와 인증서를 선택하는 데 사용됩니다. 일반적인 도메인 설정에서는 클라이언트가 인증서를 신뢰할 수 있는지, 유효 기간 내인지, 인증서 이름이 예상한 서버 이름과 일치하는지도 확인해야 합니다. SNI는 암호가 아니며 인증서에 대한 신뢰를 추가하는 스위치도 아닙니다.

서비스 제공업체가 안내한 설정확인 방법
Address와 TLS 호스트 이름이 같은 경우안내된 호스트 이름을 그대로 입력하고 프로토콜 접두사나 경로는 추가하지 마세요.
Address는 IP이고 별도의 SNI가 지정된 경우IP는 주소 지정에, 지정된 호스트 이름은 TLS에 사용합니다. 두 값을 각각 유지하세요.
Address와 SNI가 서로 다른 도메인인 경우서비스 제공업체가 안내한 조합을 유지하고 SNI를 임의로 Address로 바꾸지 마세요.
인증서 검증 실패기기 날짜와 시간, SNI, 인증서 유효 기간, 신뢰 체인을 확인한 다음 서버에 인증서가 올바르게 설정되어 있는지 확인하세요.

요약: 인증서 오류가 나면 검증을 건너뛰기 전에 서버 이름부터 확인하세요.

Allow Insecure는 끈 상태로 두고 SNI가 안내된 값과 한 글자씩 일치하는지 먼저 확인하세요. 기기 날짜와 시간이 정확한데도 오류가 나면 오류 유형을 서비스 제공업체에 전달해 인증서 체인과 유효 기간을 확인하세요.

예를 들어 연결 주소가 IP이고 서버 인증서가 tls.example.com에 발급되었다면 해당 IP를 인증서 이름으로 간주할 수 없습니다. 반대로 관련 없는 웹사이트 도메인을 임의로 입력해도 서버가 그 도메인에 해당하는 인증서를 갖게 되거나 사이트 설정이 자동으로 완료되지는 않습니다. SNI에는 해당 연결에서 실제로 지원하는 이름을 입력해야 합니다.

사용자 지정 인증서나 별도의 신뢰 설정이 필요한 경우 신뢰 방식도 따로 확인해야 합니다. 오류 메시지를 일시적으로 없애려고 인증서 검증 건너뛰기를 계속 사용하지 마세요. TLS 연결이 성립했다는 것은 클라이언트와 해당 서버 사이의 연결 상태만 의미하며, 모든 대상 웹사이트에 접속할 수 있다는 뜻은 아닙니다.

저장 후 확인: 프로토콜 문제와 규칙 문제 구분하기

추가에 성공했다는 것은 로컬에 설정이 저장되었다는 뜻일 뿐, 서버 인증까지 성공했다는 의미는 아닙니다. 먼저 선택된 항목과 Global Routing을 확인한 뒤 동일한 방식으로 재현할 수 있는 접속 테스트를 진행하세요. Config에서는 요청이 설정된 규칙에 따라 정책을 선택하며, 일부 요청은 DIRECT를 사용할 수 있습니다. 따라서 웹페이지 하나가 열린 것만으로 Trojan이 작동한다고 단정할 수 없습니다.

  1. 선택된 항목 확인: Home으로 돌아가 현재 선택된 항목이 방금 저장한 Trojan 설정인지 확인하세요. 목록의 다른 항목이 선택되어 있지 않은지 살펴보세요.
  2. 라우팅 모드 확인: Global Routing에서 현재 Proxy, Direct, Config 또는 Scene 중 무엇을 사용하는지 확인하세요. Direct는 프록시 검증에 적합하지 않습니다. Scene을 사용하는 경우 실제로 적용되는 정책을 먼저 확인하세요.
  3. 분리 테스트: 필요한 경우 잠시 Proxy로 전환한 뒤 접근 권한이 있는, 접속 여부를 알고 있는 HTTPS 페이지를 테스트하세요. 완료 후에는 기존 설정으로 되돌립니다. Proxy는 규칙 라우팅 변수를 분리해 확인할 때만 사용하며, 잘못된 암호를 해결해 주지는 않습니다.
  4. 요청 기록 확인: 요청 기록과 확인 가능한 오류 정보를 함께 살펴보고 도메인 조회, 연결, TLS, 이후 전달 중 어느 단계에서 문제가 발생했는지 구분하세요. 테스트 수치는 테스트 유형에 맞춰 해석해야 하며, 지연 시간만으로 전체 사용 가능 여부를 판단할 수 없습니다.
  5. Config 재확인: Proxy에서는 정상인데 Config에서 문제가 생긴다면 규칙 순서와 연결된 정책을 확인하고, 해당 요청이 예상한 프록시를 실제로 선택했는지 살펴보세요.

규칙은 일반적으로 위에서 아래 순서로 확인하며, 처음 일치하는 규칙의 정책을 적용합니다. 다음 예시는 규칙의 의미를 보여 주기 위한 것으로 기존 Config를 대체할 완전한 설정이 아닙니다. 예시의 PROXY는 실제 설정에서 사용할 수 있는 정책과 연결되어야 합니다.

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

이 예시에서는 example.com과 하위 도메인을 PROXY로 보내고, 일치하지 않는 나머지 요청은 DIRECT로 보냅니다. 다른 도메인만 테스트하면 Trojan을 전혀 거치지 않을 수 있습니다. 같은 원칙은 설정의 GEOIP, IP-CIDR 규칙 등에도 적용됩니다. 먼저 요청이 어떤 규칙과 일치했는지 확인한 뒤 출구 연결 매개변수에 문제가 있는지 판단하세요. FINAL은 규칙의 마지막에 두어야 합니다.

자주 묻는 질문: 계속 다시 추가하지 말고 실패 단계부터 확인하세요

아래 내용은 문제를 살펴볼 방향이며, 특정 오류의 원인을 단정하는 기준은 아닙니다. 같은 시간 초과라도 주소에 접속할 수 없는 경우, 서버가 응답하지 않는 경우, 이후 요청에 응답이 없는 경우 등 원인이 다를 수 있습니다. 오류 정보와 발생 단계를 함께 확인하세요.

주소와 암호를 모두 입력했는데 계속 연결 시간이 초과되는 이유는 무엇인가요?

Home으로 돌아가 해당 항목을 편집하고 Address에 프로토콜 접두사, 경로 또는 공백이 들어 있지 않은지 확인한 다음 Port가 서비스 제공업체의 안내와 일치하는지 확인하세요. 연결이 성립되기 전에는 Password를 바꿔도 원인을 찾는 데 도움이 되지 않는 경우가 많습니다. 사용할 수 있는 다른 네트워크에서 같은 테스트를 반복한 뒤 주소와 포트의 서비스 상태를 제공업체에 확인하세요.

인증서 오류가 표시되면 Allow Insecure를 켜야 하나요?

먼저 끈 상태로 두세요. 기기의 날짜와 시간을 확인하고 안내된 SNI와 대조해 전체 URL을 잘못 붙여 넣지 않았는지 살펴보세요. 계속 실패한다면 서비스 제공업체에 인증서 이름, 유효 기간, 전체 인증서 체인을 확인해 달라고 요청하세요. 검증을 건너뛰어도 잘못된 포트가 수정되거나 예상한 서버에 연결되었다는 사실이 확인되지는 않습니다.

TLS 오류는 없는데 웹페이지가 열리지 않으면 무엇부터 바꿔야 하나요?

먼저 선택된 항목과 Global Routing을 확인한 다음 Password에 불필요한 공백이 없는지, 추가 전송 설정을 빠뜨리지 않았는지 살펴보세요. Proxy에서는 정상이고 Config에서 문제가 생기면 규칙과 정책을 확인하세요. 두 모드에서 모두 실패한다면 요청 기록을 참고해 인증과 서버 측 전달을 계속 점검하세요.

구독에 Trojan 항목이 이미 있으면 수동으로 다시 추가해야 하나요?

대개 그럴 필요가 없습니다. 먼저 서비스 제공업체에서 받은 구독을 사용하고 가져온 항목이 완전한지 확인하세요. 수동 테스트가 필요하다면 별도 항목으로 저장하고 이름을 구분하세요. 구독을 갱신해도 별도로 만든 수동 항목은 보통 함께 변경되지 않으므로 암호나 주소가 바뀌면 각각 확인해야 합니다.

연결 실패를 해결하기 위해 SNI를 아무 도메인으로나 바꿔도 되나요?

임의의 도메인을 범용 해결책으로 사용할 수는 없습니다. SNI는 서버의 TLS 사이트 선택에 영향을 주며, 사용되는 인증서도 서버 인증 조건을 충족해야 합니다. 서비스 제공업체가 지정한 값으로 되돌린 뒤 인증서나 네트워크 문제를 확인하세요. 추가 Host나 경로가 있다면 같은 설정에서 안내된 값과 짝을 맞춰 사용해야 합니다.

App Store 정품 확인