서비스와 구독을 직접 이용 중인데 Shadowrocket에서 시간 초과나 연결 실패가 발생한 경우에 적용할 수 있는 안내입니다. 먼저 로컬 네트워크, 테스트 결과, 실제 프록시 요청을 구분한 뒤 주소, 포트, 인증 정보, TLS, 시스템 시간을 차례로 확인하세요. 마지막으로 규칙과 네트워크를 비교해 문제 범위를 좁히고, 다시 확인할 수 있도록 점검 내용을 기록합니다.
1. 테스트 시간 초과와 실제 연결 실패 구분하기
지연 시간 테스트에 숫자가 표시되더라도 테스트에서 확인한 연결 경로가 응답했다는 뜻일 뿐, 모든 웹사이트와 인증 과정, 전송 방식이 정상이라는 의미는 아닙니다. 반대로 테스트가 한 번 시간 초과되었다고 서버가 중단됐다고 단정할 수도 없습니다. 테스트 방법, 대상 주소, 네트워크 상태, 서버 측 제한이 결과에 영향을 줄 수 있습니다.
Shadowrocket의 연결 스위치가 켜져 있으면 시스템 VPN 터널이 연결되었거나 연결 중이라는 뜻입니다. 원격 서버의 인증까지 완료되었다는 의미는 아닙니다. 점검할 때는 ‘스위치가 켜진 상태로 유지되는지’, ‘테스트에 응답하는지’, ‘실제 요청이 성공하는지’를 각각 기록하고, 이 세 가지를 모두 ‘연결되지 않음’으로 뭉뚱그리지 마세요.
- 기본 네트워크 연결 실패: Shadowrocket을 끈 상태에서도 직접 접속할 수 있는 것으로 확인된 웹페이지가 열리지 않으면 Wi-Fi, 셀룰러 데이터 또는 네트워크 로그인 페이지부터 확인하세요.
- 테스트 실패: Home에서 테스트가 시간 초과됐지만 실제 접속 여부를 확인하지 않았다면, 결론은 테스트 단계에 한정됩니다.
- 프록시 요청 실패: 기본 네트워크는 정상이지만 서버를 선택한 뒤 실제 요청이 실패한다면 설정값과 로그를 확인하세요.
- 특정 대상 접속 실패: 다른 대상은 정상인데 특정 도메인 하나만 문제가 있다면 해당 대상, DNS, 분할 라우팅 규칙부터 확인하세요.
2. 테스트 조건을 고정하고 지연 시간 결과 비교하기
처음 점검할 때는 설정을 변경하지 마세요. 사용 중인 서버 항목 하나를 선택하고 같은 테스트 방법을 유지한 채 비슷한 시간대에 몇 차례 반복 테스트합니다. 테스트 방법을 기록하지 않고 숫자만 비교하면 의미가 다른 결과를 함께 판단하기 쉽습니다.
-
로컬 네트워크 연결 확인
Home에서 연결 스위치를 끄고 Safari로 직접 접속할 수 있다고 확인한 웹페이지를 엽니다. 공용 Wi-Fi에 로그인 페이지가 표시되면 먼저 로그인한 뒤 Shadowrocket으로 돌아오세요.
-
같은 항목 선택
Home으로 돌아가 확인할 서버를 선택합니다. 현재 Wi-Fi 또는 셀룰러 데이터 환경을 기록하고, 이름이 비슷한 다른 항목을 테스트하지 않았는지 확인하세요.
-
지연 시간 테스트 반복
Home에서 Connectivity Test를 실행하고 현재 테스트 방법을 확인하세요. 같은 조건으로 세 번 테스트해 응답 또는 시간 초과 여부를 각각 기록합니다. 짧은 간격으로 연속해서 누르는 대신 간격을 두고 다시 테스트하세요.
-
실제 요청 확인
연결을 켠 뒤 같은 대상 페이지를 열어 실제 접속을 확인합니다. 테스트 결과와 페이지 접속 결과를 따로 기록하고, 둘이 다르더라도 설정을 성급히 삭제하지 말고 차이를 그대로 남겨 두세요.
-
네트워크를 바꿔 재테스트
기기와 요금제에서 허용하는 경우 Wi-Fi와 셀룰러 데이터를 전환해 앞서 진행한 테스트를 반복합니다. 네트워크 외에는 어떤 항목도 변경하지 않아야 비교 조건을 유지할 수 있습니다.
결론: 네트워크에 따라 문제가 달라지는지 먼저 확인
같은 항목이 특정 네트워크에서만 실패한다면 해당 네트워크의 DNS, 로그인 상태, 전송 제한부터 확인하세요. 두 네트워크에서 모두 실패한다면 서버 설정값과 서비스 상태를 중점적으로 점검합니다. 어느 경우든 지연 시간 값만으로 원인을 단정할 수는 없습니다.
3. 주소, 포트, 인증, 전송 순서로 프로토콜 설정 확인하기
Home에서 해당 항목의 편집 화면을 열고 서비스 제공업체가 안내한 원본 정보와 대조하세요. 먼저 Type을 확인한 다음 나머지 항목을 살펴봅니다. 프로토콜마다 필요한 설정값이 다르므로 서버 주소와 비밀번호만 다른 Type에 그대로 옮겨서는 안 됩니다. 편집 전에 복구할 수 있도록 사본을 남기고, 특히 현재 사용할 수 있는 항목을 덮어쓰지 마세요.
| 확인 항목 | 세부 확인 내용 | 자주 하는 오판 |
|---|---|---|
| 주소와 포트 | 서버 주소가 완전한지, 포트가 원본 정보와 같은지 확인하세요. 포트 값은 1–65535 범위여야 합니다. | 443을 모든 상황에 적용되는 값으로 여기지 마세요. 포트가 443이라고 해서 모든 프로토콜에서 사용할 수 있는 것도 아니고 TLS를 사용한다는 뜻도 아닙니다. |
| Shadowsocks | 암호화 방식과 비밀번호를 확인하세요. 서버에서 플러그인을 사용하는 경우 플러그인과 관련 설정값도 확인해야 합니다. | 주소와 포트가 맞으면 암호화 방식이 일치하지 않아도 괜찮다고 생각하기 |
| VMess / VLESS | UUID, 전송 방식, 해당 항목에서 실제로 사용하는 보안 옵션을 확인하세요. VLESS에서 flow를 사용하는 경우 서버 설정과도 일치해야 합니다. | 두 프로토콜 모두 UUID를 사용하므로 Type을 서로 바꿔도 된다고 생각하기 |
| Trojan | 비밀번호, TLS 설정, Server Name, 설정된 전송 방식을 확인하세요. | 비밀번호만 업데이트하고 서버에서 변경된 도메인이나 전송 설정은 놓치기 |
| Hysteria2 | 인증, TLS, 포트와 설정된 난독화 매개변수를 확인하고, 현재 네트워크에서 해당 UDP 통신을 허용하는지도 확인하세요. | TCP 포트 테스트 한 번으로 UDP 연결도 정상이라고 판단하기 |
| WireGuard | 키 쌍이 올바르게 대응하는지, Endpoint, 터널 주소, AllowedIPs 등의 설정을 확인하세요. | 키, 라우팅, 핸드셰이크 문제를 모두 비밀번호 오류로 간주하기 |
| WS / gRPC | 해당 항목에서 관련 전송 방식을 사용하는 경우에만 WS의 Path와 Host 또는 gRPC의 Service Name을 확인하세요. | Path, Host, Server Name을 같은 항목으로 간주하기 |
Server Name은 일반적으로 TLS 핸드셰이크의 이름과 인증서 검증에 영향을 줍니다. WS의 Host는 HTTP 요청 정보이고 Path는 요청 경로입니다. 비슷한 문자열을 사용하더라도 세 항목을 임의로 합쳐서는 안 됩니다. 경로의 대소문자와 앞의 슬래시, UUID 안의 불필요한 공백도 원본 정보와 한 글자씩 대조하세요.
4. 시스템 시간과 TLS 확인하기: 인증서 검증을 끄지 마세요
인증서에는 유효 기간이 있습니다. 기기의 날짜가 크게 틀리면 네트워크와 비밀번호가 올바르더라도 TLS 단계에서 실패할 수 있습니다. 일부 프로토콜의 인증도 시간에 영향을 받습니다. 설정값을 확인한 뒤 시스템 시간을 점검하되, 모든 시도가 실패할 때까지 기다릴 필요는 없습니다.
- iPhone 또는 iPad에서 시스템 Settings → General → Date & Time을 열고 Set Automatically가 켜져 있는지, 표시된 날짜와 시간이 적절한지 확인하세요.
- 기기 관리 설정이나 다른 제한으로 인해 자동 설정을 사용할 수 없다면 먼저 해당 제한을 해결하세요. 만료된 인증서를 우회하려고 날짜를 과거로 바꾸지 마세요.
- 시간을 바로잡은 뒤 연결을 끊었다가 다시 연결하고 같은 항목과 대상을 사용해 재테스트하세요. 이전 페이지의 캐시만 확인하지 않도록 합니다.
- 시간이 맞는데도 인증서 문제가 표시되면 서버 주소, Server Name, 인증서에 포함된 도메인을 확인한 뒤 서비스 제공업체에 유효 기간과 인증서 체인을 문의하세요.
인증서 검증을 끄는 것을 일반적인 해결 방법으로 삼지 마세요. 보안 경계가 달라질 뿐 아니라 잘못된 서버에 연결했거나 도메인 설정이 틀린 문제를 가릴 수 있습니다. 기기 시간과 인증서가 올바른지는 각각 따로 확인해야 합니다.
5. 로그 원문으로 실패 단계 파악하기
실패한 뒤 연결 로그를 확인하고 오류 발생 시각, 대상 주소, 관련 로그 줄을 기록하세요. 아래는 네트워크 또는 TLS 로그에 표시될 수 있는 원문 예시입니다. 실제 로그에는 앞뒤 문맥이 함께 표시될 수 있으며 프로토콜마다 오류 문구가 완전히 같지는 않습니다. 오류는 실패 단계를 찾는 데 참고할 수 있지만, 그 자체만으로 구체적인 책임 소재를 증명하지는 않습니다.
오류: i/o timeout
원인: 읽기 또는 쓰기 단계가 제한 시간 안에 완료되지 않았습니다. 네트워크 패킷 손실, 원격 서버 무응답, 중간 경로의 제한 등이 원인일 수 있습니다.
해결 방법: 앞뒤 로그를 확인해 연결 중인 주소를 파악하고, 같은 설정으로 네트워크를 바꿔 다시 테스트한 뒤 포트와 원격 서비스 상태를 확인하세요.
오류: connection refused
원인: 연결 요청이 명시적으로 거부되었습니다. 대상 포트에서 서비스가 수신 대기 중이지 않은 경우가 흔하며, 중간 장비가 거부 응답을 보냈을 수도 있습니다.
해결 방법: 서버 주소와 포트부터 확인하세요. 발생 시각과 오류 내용을 서비스 제공업체에 전달해 수신 대기 상태를 확인하고, 포트를 무작위로 바꾸지 마세요.
오류: x509: certificate has expired or is not yet valid
원인: 인증서 유효 기간과 현재 시간이 일치하지 않습니다. 기기 시간이 잘못되었거나 원격 인증서에 문제가 있을 수 있습니다.
해결 방법: 먼저 시스템 Date & Time을 확인한 다음 원격 인증서의 유효 기간을 확인하세요. 인증서 검증은 켜 둡니다.
오류: EOF
원인: 데이터 스트림이 예기치 않게 종료되었습니다. 프로토콜 불일치, 인증 실패, 원격 서버의 연결 종료 등 여러 단계에서 발생할 수 있습니다.
해결 방법: 앞서 기록된 핸드셰이크 정보를 바탕으로 Type, 인증, 전송 설정을 확인하세요. 이 로그 한 줄만으로 비밀번호 오류라고 단정할 수 없습니다.
6. 연결된 뒤 라우팅과 On Demand 확인하기
테스트에는 응답이 있지만 웹페이지가 열리지 않는다면 요청이 선택한 서버를 실제로 거치는지 확인하세요. Home → Global Routing의 Proxy, Direct, Config, Scene은 서로 다른 라우팅 방식이며 연결 품질을 나타내는 등급이 아닙니다. Direct에서 직접 접속에 성공해도 프록시 서버가 정상이라고 확인되는 것은 아닙니다. Config는 현재 활성화된 설정과 함께 확인해야 합니다.
- 일시적으로 비교: 확인할 요청에 한해 Proxy를 잠시 사용해 규칙 분할 라우팅의 영향을 제외할 수 있습니다. 테스트가 끝나면 원래 Global Routing 설정으로 되돌리세요. 잘못된 설정을 계속 사용하지 않도록 변경 전 라우팅 방식도 기록해 두세요.
- 설정 확인: Config를 사용한다면 Config에서 현재 활성화된 파일을 확인한 뒤 규칙 순서와 정책 이름을 살펴보세요. Scene은 이름만 볼 것이 아니라 실제로 적용 중인 장면 설정을 확인해야 합니다.
- 규칙 확인:
DOMAIN-SUFFIX는 도메인과 하위 도메인을 일치시킵니다.IP-CIDR은 IP 대역을 기준으로 일치시키고,GEOIP는 IP 지리 정보를 기준으로 일치시킵니다.FINAL은 앞선 규칙에 일치하지 않을 때 적용되는 기본 규칙입니다. 도메인 확인과 규칙 순서 모두 최종 정책에 영향을 줄 수 있습니다. - 자동 연결 제외: Settings → On Demand에서 필요 시 연결 설정을 확인하세요. 수동으로 다시 테스트해야 한다면 On Demand를 잠시 비활성화하고 연결을 직접 제어할 수 있습니다. 테스트가 끝나면 원래 설정으로 되돌리세요.
On Demand는 조건에 따라 연결을 시작하는 기능이며 잘못된 비밀번호, 만료된 인증서, 수신 대기 중이 아닌 포트를 해결하지는 않습니다. 수동으로 연결을 끊은 뒤 다시 자동 연결된다면 시스템 VPN 설정을 반복해서 삭제하기보다 On Demand의 실행 조건을 먼저 확인하세요. 시스템 VPN 권한 문제와 원격 서버 시간 초과는 서로 다른 단계의 문제입니다.
7. 자주 묻는 질문과 점검 기록 정리
지연 시간이 매우 짧은데도 웹페이지가 열리지 않는 이유는 무엇인가요?
먼저 현재 테스트 방법이 어느 단계까지 확인하는지 파악한 다음 Home에서 선택한 항목과 Global Routing을 확인하세요. Proxy로 잠시 비교 테스트하고 실패한 요청의 로그도 살펴보세요. 특정 도메인만 실패한다면 지연 시간 순서를 다시 정하는 데 그치지 말고 DNS, 규칙, 대상 웹사이트 상태를 확인하세요.
Wi-Fi에서는 시간 초과가 발생하고 셀룰러 데이터에서는 정상입니다. 프로토콜을 바꿔야 하나요?
먼저 설정을 그대로 둔 채 Wi-Fi 로그인이 완료되었는지 확인하고 같은 대상을 다시 테스트하세요. 차이가 계속되면 프로토콜이 사용하는 전송 방식을 기록한 뒤 네트워크 관리자나 서비스 제공업체에 제한 여부를 문의하세요. 특히 UDP 관련 문제는 TCP 접속이 된다는 이유만으로 네트워크 문제를 배제할 수 없습니다.
구독 업데이트 후 모든 항목에서 시간 초과가 발생합니다. 업데이트에 실패한 건가요?
먼저 업데이트 자체의 실패와 업데이트 후 연결 실패를 구분하세요. Home에서 새 항목이 표시되는지, 올바른 항목을 선택했는지 확인한 뒤 서비스 제공업체의 안내와 Type, 주소, 포트를 대조합니다. 구독을 정상적으로 가져왔더라도 모든 원격 서비스가 작동한다는 뜻은 아닙니다. 프로토콜 설정을 확인하는 대신 구독 업데이트를 반복하지 마세요.
전체 설정과 구독 링크를 다른 사람에게 보내야 하나요?
그럴 필요 없습니다. 오류 원문, 발생 시각과 시간대, 현재 네트워크, 프로토콜 유형, 테스트 방법과 비교 결과를 정리하세요. 비밀번호, UUID, 개인 키, 구독 token은 가려야 합니다. 서버 측 확인이 필요하면 서비스 제공업체가 안내한 비공개 지원 채널로 문의하세요.
결론: 한 번에 조건 하나만 바꾸세요
다시 테스트할 때마다 네트워크, 설정값, 시간, 라우팅 중 하나만 변경하고 결과를 기록하세요. ‘어느 단계에서 실패했는지, 어떤 네트워크에서 재현되는지, 어떤 오류가 표시되는지’를 서비스 제공업체에 전달하면 ‘노드를 사용할 수 없다’고만 설명하는 것보다 원인을 찾기 쉽습니다.
점검이 끝나면 임시로 변경한 Global Routing과 On Demand 설정을 원래대로 되돌리고, 사용 가능하다고 확인된 설정을 보관하세요. Shadowrocket은 Apple 플랫폼의 클로즈드 소스 유료 앱입니다. 앱의 일회성 구매와 서버 회선 요금제는 별개입니다. 앱을 구매하는 일과 원격 서비스 문제를 해결하는 일은 서로 다르므로 앱을 다시 구매해도 원격 설정 문제는 해결되지 않습니다.