Shadowrocket 연결은 켜졌는데 인터넷이 안 될 때: 서버 상태·모드·DNS·규칙 점검

1. 기본 네트워크와 프록시 연결 문제 구분하기

앱을 삭제하거나 모든 설정을 초기화하는 것부터 시작하지 마세요. 먼저 Home에서 연결 스위치를 끄고, 현재 Wi-Fi 또는 셀룰러 네트워크로 평소 직접 접속할 수 있는 웹사이트가 열리는지 확인합니다. 공용 Wi-Fi에서 로그인이 필요하다면 먼저 네트워크 인증을 완료하세요. 연결을 끈 상태에서도 일반 웹페이지가 열리지 않는다면 기기 네트워크 연결이나 네트워크 접속 문제부터 해결해야 합니다.

스위치를 껐을 때는 정상이고 켠 뒤 문제가 생긴다면, 활성화 후의 트래픽 경로와 관련된 문제일 수 있습니다. 하지만 이것만으로 서버 문제라고 단정할 수는 없습니다. 잘못된 DNS, 규칙의 REJECT, 유효하지 않은 서버 매개변수, 다른 네트워크 확장 기능과의 충돌도 비슷한 증상을 일으킬 수 있습니다.

1. 현재 설정 기록하기

   Home에서 선택된 서버와 Global Routing을 기록하고, Config에서 현재 적용 중인 구성 파일을 확인하세요. 수정하기 전에 구성 파일 사본을 보관하고, 비밀번호·구독 링크·액세스 토큰은 공개된 곳에 올리지 마세요.

2. 직접 연결 확인하기

   연결 스위치를 끈 뒤 브라우저에서 직접 접속할 수 있는 것으로 확인된 웹페이지를 엽니다. 공용 Wi-Fi의 인증 페이지가 표시되면 먼저 인증을 완료한 다음 Home으로 돌아가세요.

3. 테스트 페이지 지정하기

   문제가 발생하는 전체 웹 주소 하나를 정합니다. 이후 설정을 바꿀 때마다 같은 주소를 다시 로드해 페이지 시간 초과, 도메인 이름 확인 실패, 정상적인 HTTP 오류를 구분하세요.

4. 네트워크별 비교하기

   셀룰러 데이터 사용이 가능하다면 Wi-Fi와 셀룰러 네트워크를 비교하세요. 서버, 모드, 구성은 그대로 유지합니다. 한 네트워크에서만 실패한다면 해당 네트워크의 제한 사항과 DNS 확인 조건을 먼저 점검하세요.

2. Home에서 서버와 연결 테스트 확인하기

Home에서 현재 선택된 서버가 본인이 이용 중인 유효한 서비스 정보에 해당하는지 확인한 다음 Connectivity Test를 실행하세요. 테스트에 응답이 있다는 것은 해당 테스트 방식이 사용하는 연결 경로에서 응답을 받았다는 뜻일 뿐입니다. 브라우저의 DNS, 규칙 일치 여부, 대상 웹사이트 접속까지 정상이라는 보장은 없습니다. 반대로 한 번 시간 초과가 발생했다고 서버가 무효라고 단정할 수도 없습니다. 실제 요청과 다른 네트워크에서의 재테스트 결과도 함께 확인하세요.

현재 서버의 편집 항목을 열어 서비스 정보와 유형, 주소, 포트, 인증 정보를 대조하세요. Shadowsocks, VMess, VLESS, Trojan, Hysteria2, WireGuard는 설정 항목이 서로 다르므로 ‘시험 삼아’ Type을 임의로 바꾸면 안 됩니다. 원래 자료에서 TLS를 사용한다면 관련 서버 이름과 인증서 확인 설정도 검토하세요. 인증을 끄는 것은 일반적인 해결 방법이 아닙니다.

• 주소: 불필요한 공백이 복사되지 않았는지, 도메인 철자가 올바른지 확인하세요. 서버 주소가 도메인 이름이라면 도메인 확인도 정상적으로 이루어져야 합니다.
• 포트: 기존 서비스 정보를 기준으로 확인하세요. 예를 들어 정보에 443이라고 적혀 있다면 443인지 확인해야 합니다. 다른 포트가 흔히 쓰인다는 이유로 본인의 포트를 80이나 443으로 바꾸면 안 됩니다.
• 인증: 비밀번호, UUID, 키, 암호화 매개변수가 서버 설정과 일치해야 합니다. 서버와 기본 연결이 성립했다고 해서 인증까지 완료된 것은 아닙니다.
• 구독: 서비스 제공자가 서버 정보를 변경했다면 Home에서 기존 구독을 업데이트한 뒤 선택된 항목을 다시 확인하세요. 업데이트에 성공해도 목록의 모든 서버를 사용할 수 있다는 뜻은 아닙니다.

‘시간 초과’라는 말만 보지 말고 오류 원문으로 원인 범위 좁히기

연결 기록이나 진단 결과에 다음과 같은 영어 오류가 표시되면 해당 항목을 기준으로 확인할 수 있습니다. 구체적인 오류 문구는 실패 단계에 따라 달라지며, 웹페이지가 열리지 않을 때마다 아래 오류가 표시되는 것은 아닙니다.

구독 업데이트만 실패하고 기존 서버로는 웹페이지에 접속할 수 있다면 구독 주소 접속 문제로 보아야 합니다. 이 문제만으로 사용 가능한 구성을 지우지 마세요. 구독 주소의 토큰은 민감 정보입니다. 문의할 때는 전체 링크를 보내지 말고 오류 내용과 발생 단계를 설명하세요.

3. Global Routing 모드별로 비교하기

Home → Global Routing에서 현재 선택된 모드를 확인하세요. Config는 적용 중인 구성의 규칙에 따라 요청을 처리합니다. Proxy는 프록시 모드에서 비교할 때, Direct는 직접 연결을 비교할 때 사용합니다. Scene은 본인의 시나리오 설정에 따라 동작하므로 Config와 항상 같은 옵션으로 볼 수 없습니다. 모드를 잠시 바꾸는 것은 진단을 위한 방법입니다. 점검이 끝나면 원래 필요한 모드로 복원하세요.

4. DNS와 dns-server 설정 확인하기

DNS는 도메인 이름을 IP 주소로 변환합니다. 서버 주소 자체가 도메인 이름이라면 프록시 연결을 시작하기 전에 해당 주소를 확인해야 할 수도 있습니다. 따라서 ‘서버 주소 확인 실패’와 ‘대상 웹사이트의 도메인 확인 실패’는 서로 다른 단계입니다. 기록할 때 두 문제를 구분하고 모두 서버 접속 불가로 취급하지 마세요.

Config에서 현재 적용 중인 파일을 확인한 다음 편집 내용을 열어 [General] 아래의 dns-server를 확인하세요. 아래 내용은 시스템 리졸버를 사용하는 단일 항목 진단 예시이며, 모든 사용자가 기존 설정을 덮어쓰라는 의미는 아닙니다. 네트워크의 시스템 DNS 확인 자체에 문제가 있다면 system으로 바꾸어도 저절로 해결되지 않습니다.

[General]
dns-server = system

1. 복원할 수 있도록 기존 dns-server 행과 관련 DNS 설정을 먼저 저장하세요.
2. 철자 오류, 작동하지 않는 주소, 복사 과정에서 남은 내용을 확인하세요. DNS 서버는 현재 네트워크와 라우팅 조건에서 접속할 수 있어야 합니다. 주소 형식이 올바르다는 이유만으로 사용할 수 있다고 판단하지 마세요.
3. 시스템 DNS 확인과 비교해야 한다면 해당 항목만 바꾸고 저장하세요. 수정한 구성이 실제로 적용 중인지 확인한 뒤 연결을 다시 설정하고 웹페이지를 로드합니다.
4. 결과에 변화가 없다면 기존 값으로 복원하고 규칙과 서버를 계속 확인하세요. 접속이 복구됐다면 네트워크 환경을 고려해 기존 리졸버에 접근할 수 없었던 이유를 확인합니다.

5. REJECT, 규칙 순서, FINAL 확인하기

일부 웹사이트만 열리지 않는 경우, 특히 Proxy에서는 정상이고 Config에서 문제가 생긴다면 Config에서 현재 적용 중인 파일의 [Rule]을 확인하세요. 규칙은 순서대로 일치 여부를 확인하며, 일치하는 항목의 정책을 적용합니다. 범위가 넓은 규칙이 앞에 있으면 뒤에 있는 세부 규칙이 적용되지 않을 수 있습니다.

DOMAIN-SUFFIX는 도메인과 하위 도메인을, IP-CIDR은 IP 대역을, GEOIP는 IP 지리 데이터베이스를 기준으로 일치 여부를 확인합니다. 각 규칙은 서로 다른 기준을 사용합니다. IP 기반 규칙을 사용할 때는 도메인 확인 결과도 영향을 줄 수 있습니다. 문제를 확인할 때는 실패한 요청의 도메인과 실제로 적용된 규칙을 먼저 찾고, 규칙 키워드를 서로 바꿔 쓰지 마세요.

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

이 예시는 example.com과 그 하위 도메인의 연결을 거부하고, 어떤 규칙에도 일치하지 않은 요청은 DIRECT로 보냅니다. 오류 원인을 설명하기 위한 예시이지 권장 설정이 아닙니다. 실제 웹사이트가 유사한 규칙에 잘못 포함되면 연결 스위치가 정상이고 서버 테스트에 응답이 있어도 웹페이지가 열리지 않을 수 있습니다.

• 먼저 REJECT 확인: 거부 규칙의 일치 범위가 지나치게 넓지 않은지 확인하세요. 웹사이트는 로그인, 이미지, API 도메인에도 의존할 수 있습니다. 메인 페이지는 열리지만 로그인이 실패한다면 실패한 요청을 구체적으로 확인하세요.
• 다음은 대상 정책 확인: 규칙에 DIRECT가 있으면 직접 연결합니다. PROXY가 있다면 현재 프록시 선택 항목이 유효한지 확인하세요. 사용자 지정 정책 그룹 이름을 사용한다면 정의된 정책 이름과 일치해야 합니다.
• 마지막으로 FINAL 확인: FINAL,DIRECT와 FINAL,PROXY는 기본 처리 방향이 다릅니다. FINAL은 규칙 목록의 맨 끝에 두어야 하며, 아직 일치 여부를 확인해야 하는 규칙보다 앞에 놓으면 안 됩니다.
• 편집 대상 확인: 수정한 뒤 저장하는 파일이 현재 적용 중인 구성인지 확인하세요. 구성이 원격 업데이트로 제공되는 경우 진단 중 수정 내용이 다음 업데이트에서 덮어쓰이지 않도록 먼저 로컬 사본을 보관하세요.

규칙을 수정한 뒤 Global Routing → Config에서 같은 주소를 다시 테스트하세요. 메인 페이지는 복구됐지만 리소스가 계속 실패한다면 FINAL을 반복해서 바꾸지 말고 실패한 리소스의 도메인을 확인하세요. 여러 도메인에 의존하는 웹사이트는 기본 도메인만 허용해도 모든 요청이 처리되지 않을 수 있습니다.

6. On Demand와 반복 연결 현상 확인하기

스위치를 꺼도 곧 자동으로 다시 연결되거나 네트워크를 전환할 때마다 테스트 조건이 달라진다면 Settings → On Demand에서 현재 상태를 기록하세요. 진단 중에는 활성화된 On Demand를 잠시 끈 다음 Home에서 직접 연결을 제어할 수 있습니다. 자동 연결이 비교 결과에 영향을 주지 않도록 하기 위한 조치입니다. 점검이 끝나면 원래 필요에 따라 복원하세요.

• 연결이 자동으로 복구됨: On Demand가 작동시킨 것인지 먼저 확인하세요. 자동 재연결을 서버가 반복해서 끊기는 현상으로 바로 판단하지 마세요.
• 다른 네트워크 확장 기능이 있음: 기기의 시스템 설정에서 다른 VPN 또는 네트워크 필터 구성을 확인하세요. 일시 중지해도 되는 것으로 확인되면 하나씩 중지하고 다시 테스트합니다. 여러 설정을 한꺼번에 삭제하지 마세요.
• 특정 앱에서만 실패: 브라우저에서 같은 서비스에 접속해 비교한 다음 해당 앱의 네트워크 접근 권한과 서비스 상태를 확인하세요. 모든 요청을 같은 정책으로 바꾸지 마세요.
• 추가로 문의해야 하는 경우: 발생 시간, 네트워크 유형, Global Routing 설정, 일부 도메인에만 문제가 있는지, 오류 원문, 완료한 비교 테스트를 정리하세요. 서버 비밀번호, UUID, 개인 키, 구독 토큰은 공개하지 마세요.

앱 재설치는 비교에 필요한 구성과 기록을 잃을 수 있으므로 첫 번째 해결 방법으로 권장하지 않습니다. 서버 정보가 유효하지 않다면 본인이 이용 중인 서비스 제공자에게 확인하고, 규칙이 잘못 일치한다면 규칙을 수정하세요. 기본 네트워크에 연결할 수 없다면 네트워크 접속 문제부터 해결해야 합니다. 문제를 구체적인 단계로 좁히면 스위치를 반복해서 바꾸는 것보다 결과를 확인하기 쉽습니다.

7. 자주 묻는 질문과 설정 복원 확인