Shadowrocket Trojan 설정 방법: Password, SNI, Allow Insecure 입력 가이드

이 글의 핵심

Trojan을 추가할 때 Address는 연결 대상, Port는 연결 포트, Password는 프로토콜 인증 정보, SNI는 TLS 핸드셰이크에 사용할 서버 이름입니다. 기존 설정의 값을 각 항목에 그대로 입력하고, Allow Insecure는 보통 꺼 둡니다. 노드를 직접 입력하거나 가져온 뒤 연결에 실패한 경우에 참고하세요. 네트워크 연결 실패, 인증서 검증 오류, 비밀번호 오류를 구분해 살펴보고 인증서 검증을 건너뛰어 설정 문제를 감추지 않도록 합니다.

Trojan과 TLS: 연결, 인증서, 인증 구분하기

Trojan은 TLS를 통해 프록시 프로토콜 데이터를 주고받습니다. 일반적으로 Address와 Port로 지정한 서버에 연결한 뒤 TLS 핸드셰이크를 진행하고, 암호화된 채널에서 Trojan 인증과 요청 전달을 수행합니다. TLS는 전송 암호화와 서버 인증을 제공하며 Password는 Trojan 접속 인증에 사용됩니다. 두 설정은 서로 대체할 수 없습니다.

따라서 Password를 올바르게 입력해도 인증서가 유효하다는 뜻은 아니며, 포트에 연결되더라도 Trojan 인증에 성공한 것은 아닙니다. 일반 HTTPS 사이트와 Trojan 서버 모두 443 포트를 사용할 수 있지만, 임의의 HTTPS 주소를 Add Server에 입력한다고 Trojan 노드가 되는 것은 아닙니다.

연결 단계: Address가 올바르게 해석되는지, 지정한 TCP 포트에 연결할 수 있는지 확인합니다. 연결 시간 초과가 발생하면 먼저 이 단계부터 점검하세요.
TLS 단계: 서버 인증서의 유효기간, 신뢰 체인, 검증 대상 이름을 확인합니다. SNI가 잘못되면 서버가 이름과 일치하지 않는 인증서를 반환할 수 있습니다.
인증 단계: Password가 서버 설정과 정확히 일치하는지 확인합니다. TLS 핸드셰이크에 성공해도 이 단계에서 거부될 수 있습니다.
요청 전달 단계: 연결이 성립한 뒤에는 Global Routing, 규칙, 대상 사이트의 이름 해석 및 접속 가능 여부도 확인해야 합니다.

Add Server 항목: Address, Port, Password, SNI

먼저 사용 중인 서비스의 전체 설정값을 확인한 다음 편집 화면을 여세요. 아래의 도메인과 포트는 항목 간 관계를 설명하기 위한 예시일 뿐, 실제 연결 정보가 아닙니다. 실제 값은 원래 설정에 맞춰 입력하세요. 예시에서 443을 사용한다고 해서 기존 포트를 443으로 바꾸지 마세요.

항목	입력할 값	흔한 실수
Type	Trojan을 선택하고 서버의 프로토콜과 일치시키세요.	포트가 같다는 이유만으로 다른 프로토콜을 선택합니다.
Address	서버 도메인 또는 IP. 예: `edge.example.com`.	전체 URL을 입력해 `https://`, 경로 또는 포트까지 붙입니다.
Port	서버에서 수신 대기하는 포트. 예: `443`. 유효 범위는 1–65535입니다.	입력하지 않거나 임의로 추측하거나, 포트를 Address에 중복 입력합니다.
Password	기존 설정에 지정된 Trojan 비밀번호를 입력합니다. 문자와 대소문자를 그대로 유지하세요.	계정 로그인 비밀번호를 입력하거나 복사할 때 공백이나 줄바꿈이 섞입니다.
SNI	기존 설정에 지정된 TLS 서버 이름. 예: `tls.example.com`.	URL이나 IP와 포트를 입력하거나 임의의 다른 사이트 도메인을 사용합니다.
Allow Insecure	일반적인 인증서 검증을 유지하도록 꺼 둡니다.	오류가 발생할 때마다 켜서 인증서 문제를 감춥니다.

Address와 SNI가 서로 다를 수 있는 이유

Address는 네트워크 연결 대상이고 SNI는 TLS ClientHello에 포함되는 서버 이름입니다. 서버는 이를 바탕으로 인증서나 가상 호스트를 선택할 수 있습니다. 두 값은 같을 수도 있고 설정에 따라 다를 수도 있습니다. 예를 들어 특정 IP에 연결하면서 인증서가 적용되는 도메인을 TLS 이름으로 사용할 수 있습니다. 이 경우 기존 설정의 이름을 유지해야 하며 SNI를 해당 IP로 단순 변경하면 안 됩니다.

SNI는 인증서 검증과 관련이 있지만, SNI를 보냈다고 해서 인증서 검증에 통과했다는 뜻은 아닙니다. 인증서는 유효기간, 신뢰 체인, 이름 일치 등의 조건을 충족해야 합니다. SNI를 비워 둔 뒤 자동으로 추론되기를 기대해 불완전한 설정을 해결하려 하지 마세요. Address가 IP이거나 인증서 이름과 다르면 먼저 기존 설정에 지정된 TLS 이름을 확인하세요.

SNI에는 호스트 이름을 입력하세요. https://tls.example.com/이나 tls.example.com:443은 입력하지 마세요.
인증서 이름은 인증서의 Subject Alternative Name 범위와 일치해야 합니다. 와일드카드 인증서라고 해서 모든 단계의 도메인에 적용되는 것은 아닙니다.
기존 설정에 전송 방식, Host, Path 등의 항목이 지정되어 있다면 함께 유지하세요. 이러한 항목은 SNI로 대체할 수 없습니다.

직접 추가하기: 설정값을 저장한 뒤 실제 요청 확인

다음은 Trojan 노드 하나를 직접 추가하는 방법입니다. 기존 구독에서 가져온 노드라면 먼저 원본 설정값을 확인해 구독 항목이 원래 값과 다르게 변경되지 않도록 하세요. 이후 구독을 업데이트하면 항목이 다시 덮어써질 수 있습니다. 발견한 문제를 기록하고 원본 설정을 수정하세요. 앱에서 임시로 바꾼 값에 계속 의존하지 마세요.

추가 화면 열기

Home으로 이동한 뒤 오른쪽 위의 «+»를 눌러 Add Server를 엽니다. 새 항목을 추가 중인지 먼저 확인해 정상적으로 사용 중인 다른 설정을 잘못 수정하지 않도록 하세요.
프로토콜 선택

Type → Trojan으로 이동합니다. 프로토콜은 기존 설정을 기준으로 선택하세요. Address와 Port가 같아도 Type이 다르면 연결되지 않습니다.
연결 설정 입력

Add Server로 돌아가 Address, Port, Password를 입력합니다. Address에는 호스트 부분만 입력하고 Password는 원래 값 그대로 복사하세요. 따옴표를 덧붙이거나 직접 해시값으로 변환하지 마세요.
보안 설정 확인

해당 항목의 TLS 관련 설정에서 SNI와 Allow Insecure를 확인합니다. SNI에는 기존 설정에 지정된 이름을 입력하고 Allow Insecure는 꺼 둡니다. 다른 전송 항목이 있다면 기존 설정에 맞는지 하나씩 확인하세요.
저장 후 테스트

저장한 뒤 Home으로 돌아가 방금 추가한 항목을 선택합니다. 규칙의 영향을 확인하려면 Global Routing을 일시적으로 Proxy로 설정하고 연결 스위치를 켠 다음 시스템 안내에 따라 VPN 구성을 허용하세요. 정상 작동이 확인된 HTTPS 페이지에 접속해 테스트한 뒤 원래 라우팅 모드로 복원합니다.

Allow Insecure: 인증서 검증 설정 비교

Allow Insecure를 켜면 일반적인 TLS 인증서 검증을 완화하거나 건너뛸 수 있습니다. 연결이 평문 전송으로 바뀌는 것은 아니지만, 암호화 채널에서 상대 서버의 신원을 확실히 확인하지 못하면 사칭 서버에 연결될 수 있습니다. 이 설정으로 비밀번호 오류, 포트 폐쇄, 도메인 해석 실패 또는 서버 프로토콜 불일치를 해결할 수는 없습니다.

Allow Insecure 끔

권장

정상적인 인증서 검증을 유지합니다. 인증서 이름이 일치하지 않거나 만료되었거나 신뢰 체인에 문제가 있으면 오류를 표시해 바로잡아야 할 인증 문제를 확인할 수 있습니다.

적합한 경우: 일상적인 사용, 정식 설정, 일반적인 문제 해결.

Allow Insecure 켬

인증서 검증을 완화하면 요청이 계속 진행되더라도 서버 신원을 신뢰할 수 있다는 의미는 아닙니다. 인증서 만료나 SNI 오류를 장기간 해결하는 방법으로 사용하지 마세요.

적합한 경우: 인증서 위험을 이해하고 설정 차이를 확인할 때. 일상적인 사용에는 권장하지 않습니다.

결론: 인증서 문제를 바로잡고 검증 우회 설정은 사용하지 않기

같은 설정에서 Allow Insecure를 켜야만 연결된다면 다시 꺼 두고 SNI, 기기의 날짜 및 서버 인증서 체인을 확인하세요. 직접 해결하기 어렵다면 기존 서비스를 관리하는 담당자에게 오류 유형을 전달하세요.

먼저 기기의 시스템 설정에서 날짜와 시간이 정확한지 확인한 다음 인증서 만료 여부, 인증서가 예상한 이름을 포함하는지, 서버가 중간 인증서 체인을 모두 전송하는지 확인하세요. 자체 서명 인증서는 별도의 신뢰 관리가 필요합니다. 검증을 계속 건너뛰는 방식으로 신뢰할 수 있는 설정을 대신할 수는 없습니다.

증상별 문제 해결: 시간 초과, 인증서 오류, 인증 실패

연결 실패 메시지는 발생 단계를 기준으로 살펴보세요. 네트워크나 서버에 따라 비슷한 시간 초과 또는 연결 끊김이 나타날 수 있습니다. 다음은 문제를 확인하는 순서이며, 메시지 하나만으로 원인을 확정하는 방법은 아닙니다. 오류 내용을 기록할 때 유형은 남겨도 되지만 Password, 구독 토큰, 전체 연결 정보는 가리세요.

계속 시간 초과가 발생합니다. Password가 잘못된 건가요?

먼저 Home에서 해당 항목의 편집 화면을 열고 Address와 Port를 확인한 다음 현재 네트워크에서 해당 주소와 포트에 접속할 수 있는지 확인하세요. 시간 초과는 연결 수립이나 핸드셰이크 단계에서 발생할 수 있으므로 비밀번호 오류라고 단정할 수 없습니다. 직접 사용할 수 있는 다른 네트워크에서 같은 테스트를 진행하면 현재 네트워크가 원인인지 판단하는 데 도움이 됩니다.

인증서 오류가 발생합니다. SNI에는 어떤 도메인을 입력해야 하나요?

브라우저에서 접속할 대상 사이트의 도메인이 아니라 기존 설정에 지정된 TLS 이름을 입력하세요. SNI에 프로토콜 접두사, 포트 또는 공백이 포함되지 않았는지 확인하고 기기의 시간도 점검하세요. 이름이 올바른데도 오류가 발생하면 Allow Insecure를 바로 켜지 말고 서버 인증서의 유효기간과 체인을 확인하세요.

연결 직후 끊깁니다. 비밀번호를 새로 만들어야 하나요?

먼저 Password와 Type을 문자 단위로 대조하고 복사할 때 줄바꿈이 섞이지 않았는지, 기존 설정의 전송 항목이 빠지지 않았는지 확인하세요. 비밀번호를 임의로 새로 만들지 마세요. 서버 측 비밀번호가 함께 바뀌지는 않습니다. TLS 연결 후 바로 끊기는 데는 다른 원인도 있을 수 있으므로 서버 기록을 확인해야 합니다.

테스트 결과는 나오는데 웹페이지가 열리지 않습니다. 어떻게 해야 하나요?

Home에서 대상 항목이 선택되어 있는지 확인하고 Global Routing → Proxy를 임시로 사용해 같은 페이지에 접속하세요. Proxy에서는 되지만 Config에서는 안 된다면 현재 Config에서 활성화된 규칙과 정책 대상을 확인하세요. 두 모드 모두 실패하면 인증, DNS, 대상 사이트를 점검하세요. 지연 시간만으로 노드가 정상이라고 판단하지 마세요.

검증 후 Config 복원 및 규칙과 업데이트 확인

Global Routing → Proxy는 이번 테스트에서 규칙의 영향을 분리하기 위한 설정이지, 모든 상황에서 계속 사용해야 한다는 뜻은 아닙니다. Direct는 직접 연결을 의미하므로 Trojan을 통한 요청 전달을 확인하는 데 사용할 수 없습니다. Config는 현재 구성된 규칙에 따라 요청을 처리하고 Scene은 설정된 시나리오에 따라 라우팅 방식을 선택합니다. 일상적인 사용을 위해 원래 사용하던 유효한 모드로 복원하세요.

Proxy에서는 정상인데 Config에서 예상과 다른 결과가 나오면 현재 Config의 규칙 순서와 정책을 확인하세요. 예를 들어 다음 문법은 example.com과 하위 도메인을 PROXY로 보내고 나머지 요청을 DIRECT로 보냅니다. 규칙의 의미를 보여 주는 예시일 뿐, 기존 설정을 덮어쓰라는 뜻은 아닙니다. 실제 설정에서 정책 대상이 유효한지 확인하세요.

DOMAIN-SUFFIX,example.com,PROXY
FINAL,DIRECT

규칙 순서 확인: 앞에서 일치한 규칙이 요청을 먼저 처리할 수 있으므로 뒤쪽의 DOMAIN-SUFFIX 규칙은 적용되지 않을 수 있습니다. 특정 행 하나만 검색해 트래픽 분기 결과를 단정하지 마세요.
원본 설정 유지: 구독 항목을 업데이트한 뒤 Address, Port, SNI, 전송 설정이 바뀌었는지 확인하세요. 한 번 직접 수정했다고 해서 원본 설정까지 영구적으로 바로잡힌 것은 아닙니다.
자동 연결 확인: 직접 연결을 끊은 뒤 다시 연결된다면 Settings → On Demand에서 활성화된 온디맨드 연결 조건을 확인하세요. 자동 재연결을 노드 수정이 적용되지 않은 것으로 오해하지 않도록 합니다.
인증 정보 보호: 관리 담당자에게 문제를 설명할 때는 발생 단계, 네트워크 종류, Config에서만 실패하는지 전달하세요. Password가 가려지지 않았거나 구독 링크가 포함된 스크린샷은 보내지 마세요.