Shadowrocket의 연결 스위치를 켜면 시스템 네트워크 터널이 활성화되지만, 서버와 DNS, 접속하려는 웹사이트까지 모두 연결되었다는 뜻은 아닙니다. 사용할 서비스와 구독이 있고, 가져오기를 마쳤지만 접속이 되지 않는 경우에 적용할 수 있습니다. ‘기본 네트워크 → 서버 → Global Routing → DNS → Rule’ 순서로 한 번에 설정 하나씩 바꾸면 문제 구간을 좁힐 수 있습니다. 점검이 끝나면 원래 설정으로 되돌리고, 테스트용 설정을 계속 사용하지 마세요.
시작하기 전에: 테스트 조건을 고정하고 기본 네트워크 확인
먼저 ‘모든 웹페이지가 열리지 않는 경우’와 ‘특정 도메인 하나만 접속되지 않는 경우’를 구분하세요. 전자는 기본 네트워크와 서버를 먼저 확인해야 하며, 후자는 대상 웹사이트나 도메인 조회, 특정 규칙이 원인일 수 있습니다. 시스템 VPN 표시만 보고 네트워크가 정상이라고 판단하거나, 지연 시간 테스트 한 번에 성공했다고 모든 요청이 정상이라고 단정하지 마세요.
-
현재 상태 기록
Home에서 현재 선택된 서버와 Global Routing 값을 기록한 다음, Config에서 활성화된 구성 파일을 확인하세요. 원래 구성의 사본을 보관하고, 실패한 도메인과 발생 시각, Wi-Fi 또는 셀룰러 네트워크 사용 여부를 적어 두세요. 기록을 공유하기 전에는 비밀번호, 구독 주소, 인증 정보를 가리세요.
-
자동 연결 일시 중지
Settings → On Demand에서 원래 설정을 기록한 뒤, 테스트하는 동안 필요 시 연결을 일시적으로 끄고 Home의 연결 스위치도 끄세요. 그러면 기본 네트워크를 확인하는 중 네트워크 상태가 바뀌어 터널 연결이 다시 시작되는 일을 방지할 수 있습니다.
-
기본 네트워크 테스트
연결을 끈 상태에서 평소 바로 접속할 수 있는 웹페이지를 여세요. 여전히 접속되지 않는다면 먼저 Wi-Fi 로그인 인증을 완료하고, 셀룰러 데이터 권한을 확인하거나 다른 네트워크를 사용하세요. 이 단계에서는 Rule이나 DNS를 먼저 변경하지 마세요.
-
테스트 요청 고정
기본 네트워크가 정상이면 다시 연결하고, 매번 동일한 전체 웹 주소로 테스트하세요. ‘열리지 않음’만 기록하지 말고 DNS 조회 오류, 연결 시간 초과, 인증서 오류 중 어떤 문제가 발생했는지 적어 두세요. Wi-Fi와 셀룰러 네트워크를 바꿔 테스트할 때는 별도의 테스트 회차로 기록하세요.
터널을 끈 뒤 접속이 된다면 그 시점에 직접 접속 경로가 작동했다는 뜻일 뿐, 기존 서버가 정상이라는 증거는 아닙니다. 반대로 특정 대상에 직접 접속하지 못해도 기본 네트워크가 끊겼다고 단정할 수 없습니다. 직접 접속이 가능한 것으로 확인된 다른 대상을 골라 비교하세요.
1단계: Home에서 서버와 연결 매개변수 확인
Home에서 예상한 서버가 선택되어 있는지 확인한 다음, 해당 항목의 편집 화면을 열어 서비스 제공자가 안내한 정보와 하나씩 대조하세요. 주소, 포트, Type, 인증 정보가 모두 맞아야 합니다. 포트가 443이라고 해서 설정이 올바른 것은 아니며, 포트 번호만으로 프로토콜을 추측할 수도 없습니다.
- 주소와 포트: 불필요한 공백이나 오타가 없는지, 포트 번호를 잘못 입력하지 않았는지 확인하세요. 서버 주소가 도메인인 경우 연결을 시작하기 전에 해당 도메인을 먼저 조회해야 합니다.
- 프로토콜과 인증: Shadowsocks, VMess, VLESS, Trojan, Hysteria2, WireGuard는 매개변수 구성이 서로 다릅니다. 해당하는 Type을 선택하고 기존 안내에 따라 입력하세요. 한 프로토콜의 항목을 다른 프로토콜에 그대로 적용하지 마세요.
- TLS 관련 항목: TLS를 사용하는 연결이라면 서비스 제공자가 안내한 SNI, 인증서 이름, 전송 매개변수를 확인하세요. 연결 주소와 인증서 이름은 서로 다를 수 있으므로 임의로 같은 값으로 바꾸지 마세요.
- 구독 상태: 구독에서 가져온 항목이라면 먼저 Home에서 구독을 업데이트하고, 현재 선택한 항목이 여전히 유효한지 확인하세요. 구독 업데이트와 Config에서 구성 파일을 활성화하는 것은 서로 다른 작업이며, 한쪽이 다른 쪽을 대신할 수 없습니다.
Home에서 연결 또는 지연 시간 테스트를 실행할 때는 테스트 방식과 결과를 함께 확인하세요. TCP 연결이 성공했다는 것은 테스트 당시 해당 주소와 포트로 연결을 수립할 수 있었다는 뜻일 뿐, 인증, TLS, 전달 과정, 대상 웹사이트의 응답까지 모두 확인한 것은 아닙니다. 서버가 여러 개라면 다른 설정은 그대로 둔 채 이미 보유한 다른 항목을 선택해 비교할 수 있습니다.
오류: connection refused
원인과 해결: 대상 호스트나 중간 장치가 연결을 명시적으로 거부한 경우입니다. 포트에서 연결을 수신하지 않거나 연결이 차단되었을 수 있습니다. 먼저 주소와 포트를 확인한 다음, 이용 중인 서비스 제공자에게 해당 연결 지점의 상태를 문의하세요. 포트 연결 거부 문제를 해결하기 위해 DNS나 규칙부터 바꾸지 마세요.
오류: i/o timeout
원인과 해결: 네트워크 작업이 제한 시간 안에 완료되지 않았다는 뜻입니다. 도메인 조회, 연결 수립, 이후 데이터 읽기·쓰기 단계 중 어디에서든 발생할 수 있습니다. 오류 주변에 표시된 주소와 작업을 확인해 문제가 발생한 위치를 파악하고, 다른 네트워크에서 같은 항목을 테스트하세요. 시간 초과만으로 비밀번호가 틀렸다고 단정할 수 없습니다.
오류: no such host
원인과 해결: 도메인 조회에서 사용할 수 있는 결과를 얻지 못한 상태입니다. 오류에 표시된 도메인이 서버 도메인인지 대상 웹사이트 도메인인지 먼저 확인한 후 철자와 DNS 설정을 점검하세요. 어떤 도메인인지 파악하기 전에 서버와 구성 파일을 동시에 변경하지 마세요.
위 오류는 네트워크 로그에 표시될 수 있는 실제 문구이며, 모든 화면에 같은 문구가 나타나는 것은 아닙니다. 점검할 때는 실제 오류와 앞뒤 맥락을 함께 보관하세요. ‘timeout’이라는 문구만 따로 보면 서버 연결 실패와 웹사이트 응답 지연을 혼동하기 쉽습니다.
2단계: Global Routing에서 Proxy, Direct, Config, Scene 구분
Home → Global Routing에서 현재 모드를 확인하세요. 서버를 올바르게 선택해도 요청이 예상한 경로를 따르지 않으면 연결 스위치가 켜져 있는데도 접속이 실패할 수 있습니다. 테스트할 때는 서버를 고정하고 모드를 하나씩 비교하세요. 서버, DNS, 구성 파일을 동시에 바꾸지 마세요.
| 모드 | 문제 해결 시 참고 사항 | 확인할 항목 |
|---|---|---|
Proxy | 프록시 라우팅을 기준으로 비교해 Rule 분할이 테스트에 미치는 영향을 줄입니다. | 선택한 서버, 연결 매개변수, 대상의 응답을 확인합니다. ‘다른 설정이 모두 초기화된다’는 뜻은 아닙니다. |
Direct | 프록시 서버를 통해 요청을 전달하지 않고 직접 접속하는 경로와 비교합니다. | 로컬 네트워크에서 테스트 대상에 접속할 수 있는지 확인합니다. 시스템 터널을 끈 상태와 완전히 같은 것은 아닙니다. |
Config | 현재 구성 파일의 규칙에 따라 요청 처리 방식을 결정합니다. | Config에서 활성화된 파일, Rule 순서, 규칙이 적용된 뒤의 정책 |
Scene | 설정된 시나리오 조건에 따라 라우팅 동작을 전환합니다. | 현재 네트워크에 적용되는 시나리오 설정입니다. 문제를 확인할 때는 잠시 명확한 고정 모드를 사용하세요. |
정리: 한 요청에서 변수 하나만 비교
같은 서버에서 Proxy로는 열리지만 Config에서 실패한다면 현재 구성의 규칙과 정책을 먼저 확인하세요. 두 모드에서 모두 실패한다면 서버와 DNS를 계속 점검해야 합니다. 이는 원인 범위를 좁히는 방법이지, 장애 원인을 최종적으로 판단하는 기준은 아닙니다.
Direct에서는 접속되지만 Proxy에서 실패하더라도 이 결과만으로 서버가 중단되었다고 단정할 수 없습니다. 프록시 경로의 도메인 조회, 인증, TLS 또는 대상 웹사이트의 제한이 영향을 줄 수 있습니다. 테스트가 끝나면 Global Routing을 원래대로 복원하세요. Scene을 사용하는 경우에는 시나리오 조건도 되돌려 다음 네트워크 전환 후 동작이 달라지지 않도록 하세요.
3단계: DNS에서 서버 도메인 조회와 웹사이트 도메인 조회 구분
DNS 문제는 두 지점에서 발생할 수 있습니다. 서버 도메인을 먼저 조회할 때, 또는 접속하려는 웹사이트 도메인을 조회할 때입니다. 전자가 실패하면 프록시 연결 자체를 수립할 수 없고, 후자가 실패하면 서버 테스트는 응답하지만 웹페이지는 열리지 않을 수 있습니다. 오류에 표시된 도메인을 먼저 확인한 다음 변경할 항목을 정하세요.
- Config에서 현재 활성화된 파일의 편집 화면을 열고
[General]의dns-server를 확인한 뒤 기존 값을 기록하세요. 활성화되지 않은 같은 이름의 파일을 편집하지 마세요. - 기존 구성에서 사용자 지정 DNS를 사용한다면 주소와 형식, 현재 네트워크에서 접속 가능한지 확인하세요. DNS over HTTPS를 사용하는 경우에는 HTTPS 엔드포인트에 접속할 수 있는지, 엔드포인트 도메인 조회와 인증서가 정상인지도 점검해야 합니다.
- 구성 파일의 사본에서 DNS를 시스템 DNS로 임시 변경해 비교할 수 있습니다. 사본을 저장하고 활성화한 다음 연결을 다시 수립하세요. DNS만 바꾸고 서버와 Global Routing은 그대로 유지하세요.
- 같은 도메인을 다시 열어 보세요. 결과가 나아졌다면 기존 DNS 경로를 계속 확인하고, 달라지지 않았다면 원래 값으로 복구한 뒤 규칙을 점검하세요. 검증되지 않은 변경을 계속 추가하지 마세요.
[General]
dns-server = system
[General]은 구성 파일의 일반 설정 섹션입니다. dns-server = system은 해당 설정에 시스템 DNS를 사용한다는 뜻입니다. 이 내용은 비교 테스트용 예시이며 완성된 구성 파일이 아닙니다. 기존 구성의 다른 섹션을 이 내용으로 덮어쓰지 마세요. 시스템 DNS를 사용해도 결과는 현재 네트워크에서 제공하는 DNS 서비스에 따라 달라집니다.
DNS over HTTPS는 HTTPS로 조회 요청을 전송하지만 모든 네트워크에서 접속할 수 있는 것은 아닙니다. 조회 엔드포인트, 서버 주소, 대상 웹사이트는 서로 다른 대상입니다. DNS 전송 방식을 바꾸는 것만으로 서버 포트 거부나 인증 매개변수 오류를 해결할 수는 없습니다.
4단계: Config에서 Rule 순서와 실제 정책 확인
Config로 돌아가 테스트 중 활성화된 파일을 확인하세요. Global Routing이 Config일 때 규칙은 일반적으로 순서대로 적용되며, 먼저 일치한 요청은 뒤에 있는 같은 유형의 규칙에서 다시 처리되지 않습니다. 대상 도메인에 해당하는 규칙을 먼저 확인한 다음 IP 규칙과 최종 정책을 확인하세요. 구성에 ‘PROXY’가 적혀 있어도 해당 요청이 그 규칙에 일치한다는 뜻은 아닙니다.
[Rule]
DOMAIN-SUFFIX,example.com,PROXY
IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
GEOIP,CN,DIRECT
FINAL,PROXY
[Rule]: 규칙 섹션을 시작합니다. 이 예시는 문법을 설명하기 위한 것이며example.com은 예시 도메인입니다. 연결 테스트 주소가 아니며 모든 사용자에게 적합한 분할 라우팅 방식을 의미하지 않습니다.DOMAIN-SUFFIX,example.com,PROXY:example.com과 그 하위 도메인에 일치시키고PROXY정책을 적용합니다. 일치 기준은 요청 도메인의 접미사이며 웹페이지 경로에 포함된 단어가 아닙니다.IP-CIDR,192.168.0.0/16,DIRECT,no-resolve: 해당 IPv4 대역에 일치시키고DIRECT를 적용합니다.no-resolve는 이 규칙에 일치시키기 위해 도메인 조회를 새로 시작하지 않는다는 뜻이지, DNS를 전역적으로 끈다는 뜻은 아닙니다.GEOIP,CN,DIRECT: IP 지리 데이터베이스의 국가 코드로 대상을 확인해 직접 접속합니다. 웹페이지 언어, 도메인 접미사, 서비스 제공자 이름이 아니라 IP 정보를 기준으로 하며, 데이터베이스 결과가 실제 서버 위치와 다를 수도 있습니다.FINAL,PROXY: 앞선 규칙에 일치하지 않는 경우PROXY를 사용합니다. 최종 정책은 이미 적용된DIRECT또는REJECT규칙을 덮어쓰지 않습니다.
대상이 Proxy에서는 정상이고 Config에서는 실패한다면 더 앞에 있는 DIRECT 또는 REJECT 규칙에 일치하는지, 사용자 지정 정책 그룹에 사용 가능한 항목이 선택되어 있는지 확인하세요. 임시 검증이 필요하면 사본에 단일 대상을 위한 DOMAIN 또는 DOMAIN-SUFFIX 규칙을 추가하고 충돌할 수 있는 규칙보다 앞에 배치하세요. 도메인 하나 때문에 Rule 섹션 전체를 삭제하지 마세요.
정리: 규칙이 있는지만 보지 말고 실제 적용 여부 확인
변경한 구성을 저장하고 활성화한 다음 같은 요청을 다시 보내세요. 앱 내 연결 기록이나 로그에서 대상과 적용된 정책을 확인하세요. 현재 파일 활성화, 요청의 예상 규칙 일치, 해당 정책 사용 가능 여부가 모두 확인되어야 이번 규칙 테스트를 마칠 수 있습니다.
마무리: 테스트 결과로 범위를 좁히고 설정 복원
4단계 점검의 목적은 모든 설정을 바꾸는 것이 아니라 재현 가능한 비교 결과를 얻는 것입니다. 어떤 테스트 회차에서 성공하거나 실패했는지 기록하고, 다음 테스트에서도 같은 조건을 유지하세요. 특정 웹사이트만 실패한다면 해당 사이트 자체의 상태도 확인해야 합니다. 한 사이트의 문제를 모든 프록시 연결의 장애로 간주하지 마세요.
| 비교 결과 | 다음 확인 항목 |
|---|---|
| 연결을 끈 뒤에도 직접 접속할 수 있는 것으로 확인된 웹페이지가 열리지 않음 | 먼저 Wi-Fi 인증, 셀룰러 네트워크 권한, 기본 네트워크를 확인하세요. |
| 같은 항목이 Wi-Fi에서는 실패하지만 셀룰러 네트워크에서는 성공 | Wi-Fi 네트워크의 DNS, 포트, 전송 연결을 확인하고 두 테스트의 오류 기록을 보관하세요. |
| Proxy는 성공하지만 Config는 실패 | 활성화된 파일, 규칙 순서, 적용된 정책, 정책 그룹의 항목을 확인하세요. |
| dns-server만 변경했는데 결과가 달라짐 | 원래 DNS의 연결 가능 여부와 조회 결과를 다시 테스트해 일시적인 네트워크 변동이 아니었는지 확인하세요. |
| 모든 모드에서 같은 대상 하나만 실패 | 대상 서비스 상태, 조회 결과, 인증서 오류를 확인하고 전역 설정을 무작정 계속 바꾸지 마세요. |
- 원래 Global Routing, DNS, Settings → On Demand 설정을 복원하세요. 검증용 임시 규칙은 삭제하거나 용도가 명확히 표시된 구성 사본으로 보관하세요.
- 이용 중인 서비스 제공자에게 문의할 때는 프로토콜 유형, 서버 주소와 포트, 네트워크 유형, 실패 시각, 민감한 정보를 가린 오류 내용을 전달하세요. 비밀번호 전체나 구독 인증 정보는 보내지 마세요.
- 구독을 업데이트한 뒤 현재 선택된 항목을 다시 확인하세요. 구성 파일을 수정한 뒤에는 Config에서 활성화된 파일을 다시 확인해 실제 사용 중인 항목과 기록이 일치하는지 점검하세요.
Shadowrocket은 Apple 플랫폼용 유료 앱으로 주로 iPhone과 iPad에서 사용하며, App Store에서만 받을 수 있습니다. 시스템 요구 사항, 기기 호환성, 유니버설 구입 지원 여부는 App Store 페이지의 안내를 확인하세요. 앱 구매와 회선 서비스는 별개입니다. 이 사이트는 노드나 구독을 제공·판매·추천하지 않습니다.