Shadowrocket
Settings 설정 항목 참고

1. Settings의 역할과 기본 상태

설정, 구성, 서버를 구분하세요

Shadowrocket에서 Settings는 클라이언트 동작을 관리하고, Config에는 구성 파일과 규칙이 들어 있으며, Home에서는 서버 선택, Global Routing 확인, 연결 제어를 할 수 있습니다. 서로 연관되어 있지만 각각의 역할은 다릅니다. DNS를 변경해도 서버 비밀번호가 채워지지 않으며, 서버를 바꿔도 잘못된 규칙이 자동으로 수정되지는 않습니다. 문제를 살펴보기 전에 특정 도메인에 접속할 수 없는지, 네트워크 전환 후 연결이 끊기는지, 모든 요청이 실패하는지 목표를 명확히 하세요. 문제에 따라 확인할 설정 경로가 달라집니다.

이 매뉴얼은 iPhone / iPad의 메뉴 경로를 기준으로 구성했습니다. Mac, Windows, Android, Linux용 Shadowrocket도 있지만 시스템 권한, 백그라운드 동작 방식과 표시되는 옵션은 다를 수 있습니다. 특정 항목이 보이지 않으면 다른 기기의 화면에서 똑같은 위치를 찾기보다 플랫폼과 현재 페이지를 먼저 확인하세요. 시스템 네트워크 권한은 기기에 표시되는 안내를 따르고, iPhone / iPad 시스템 요구 사항은 App Store 페이지를 확인하세요.

기본값, 현재 값, 권장 값은 서로 다릅니다

‘기본값’은 해당 설정을 처음 만들 때의 동작을, ‘현재 값’은 가져온 구성이나 백업 복원, 동기화의 영향을 받은 상태를 뜻합니다. ‘권장 값’은 사용 목적에 따라 달라집니다. 특정 기기의 현재 상태를 모든 버전에 공통으로 적용되는 초기 설정으로 안내하지 않습니다. 일관된 기본값이 없는 항목은 현재 화면이나 활성 구성을 확인하도록 안내합니다. 값이 비어 있다고 해서 기능이 꺼져 있다고 단정하지 말고, 매뉴얼과 비교하기 위해 모든 데이터를 초기화하지 마세요.

되돌릴 수 있도록 변경 내용 기록

작업 전에 활성 Config 이름, 선택한 서버와 Global Routing 상태를 기록한 뒤 변경할 항목의 현재 값을 저장하세요. 파일을 백업해야 한다면 본인이 관리할 수 있는 위치에 보관하세요. 구성에 인증 정보가 포함될 수 있으므로 전체 내용을 공개 게시물에 붙여 넣지 마세요. 관련 설정은 한 번에 하나씩 변경하는 것이 좋습니다. 예를 들어 라우팅은 그대로 두고 DNS만 조정한 뒤 결과를 확인하고, 다음으로 On Demand를 살펴보세요. 여러 항목을 동시에 바꾸면 연결이 복구되어도 무엇이 영향을 주었는지 알기 어렵고, 문제가 재발했을 때 원인을 찾기도 어렵습니다.

변경 후에는 테스트 연결을 새로 설정하세요. 브라우저의 기존 장기 연결이나 앱 캐시, 시스템 DNS 캐시에 이전 상태가 남아 있을 수 있으므로 같은 페이지를 새로고침하는 것만으로는 새 설정이 반영되지 않을 수 있습니다. 진행 중인 테스트를 중단하고 연결을 끊었다가 다시 연결한 뒤, 용도를 알고 있는 테스트 대상으로 접속해 보세요. 개선되지 않으면 먼저 이전 값을 복원한 다음 다른 문제 해결 경로를 확인하세요. 모든 스위치를 반복해서 켜고 끄는 방식으로 문제를 해결하려 하지 말고, 출처를 알 수 없는 전체 구성을 가져와 기존 설정을 덮어쓰지 마세요.

클라이언트는 일회성 구매이며 회선 구독과는 별개입니다. iPhone / iPad 버전은 App Store에서 $2.99 일회성 결제로 제공되며, Mac / Windows / Android / Linux 버전은 무료입니다. 이 사이트는 노드나 구독을 제공·판매·추천하지 않습니다. 클라이언트 설정만으로는 기존 서비스의 유효한 인증 정보나 연결 상태를 대신할 수 없습니다.

클라이언트가 필요하면 다운로드 안내를 확인하세요. iPhone / iPad 버전은 App Store에서 받을 수 있으며, Mac 버전은 Apple 실리콘용과 Intel용으로 제공됩니다. 그 밖의 플랫폼 설치 파일은 모두 사이트의 /dl/shadowrocket/에서 제공합니다. 처음 실행할 때 시스템에서 차단되는 경우 설치 허용 안내를 먼저 따른 뒤 이 페이지로 돌아와 설정을 조정하세요. 설치 문제와 DNS 및 규칙 문제는 구분해서 살펴보세요.

2. DNS 조회 경로와 문제 해결

DNS는 도메인을 주소로 변환합니다

도메인에 접속할 때 앱은 보통 먼저 해당 주소를 확인한 뒤 실제 연결을 시작합니다. 따라서 Connectivity Test에 결과가 나오는데 웹페이지가 열리지 않는다고 해서 원격 서버가 정상 또는 비정상이라고 단정할 수는 없습니다. 테스트가 연결의 일부만 확인했을 수 있고, 실제 페이지에서 다른 도메인을 요청할 수도 있습니다. DNS는 조회 결과를 제공하지만 잘못된 비밀번호, 만료된 인증 정보 또는 대상 웹사이트 자체의 문제를 해결하지는 않습니다. 모든 실패를 DNS 탓으로 돌리지 말고 조회, 연결, 앱 응답을 구분해 판단하세요.

기본 상태를 확인하려면 Settings의 DNS 관련 옵션과 활성 Config의 내용을 함께 살펴봐야 합니다. 가져온 구성에서 조회 서버를 지정했을 수도 있고, 시스템이 제공하는 조회 경로를 그대로 사용할 수도 있습니다. 항목이 비어 있다면 설명과 로그를 함께 확인하고 실제 동작을 판단하세요. 특정 공용 서비스가 사용된다고 임의로 단정해서는 안 됩니다. 처음 사용할 때는 정상적으로 동작하는 DNS 설정을 유지하고, 조회 실패를 뒷받침하는 명확한 근거가 있을 때만 해당 경로를 조정하세요. 모두에게 맞는 ‘최적값’을 찾겠다며 설정 전체를 바꾸지 마세요.

먼저 조회 요청이 DNS 서버에 도달하는지 확인

다음 순서로 확인하세요. 현재 네트워크에서 기본 서비스에 접속할 수 있는지, 서버 주소 자체를 조회할 수 있는지, 예상한 경로로 DNS 서버에 도달하는지, 반환된 주소로 연결이 되는지 살펴봅니다. 서버 주소가 도메인 이름이라면 연결을 시작하기 전에 먼저 DNS 조회가 필요할 수 있습니다. DNS 서버에 도달하는 데 프록시가 필요하지만 아직 프록시 연결이 설정되지 않았다면 의존성 순환이 생길 수 있습니다. 이 경우 DNS 서버를 계속 바꾸기보다 구성 설계를 점검하세요. 목록에 여러 주소를 입력한다고 해서 모두 예상한 방식으로 동시에 동작하는 것은 아닙니다.

주소 유형과 암호화 DNS의 범위

하나의 도메인에서 IPv4와 IPv6 주소를 모두 반환할 수 있습니다. IPv6 레코드가 있다고 해서 현재 네트워크에 완전한 IPv6 경로가 있다는 뜻은 아닙니다. 반대로 IPv6를 끄는 것이 모든 문제의 해결책도 아닙니다. 먼저 실패한 연결에 실제로 사용된 주소 유형을 확인하고 다른 경로와 비교하세요. 관련 설정을 잠시 바꿔야 한다면 기존 상태를 기록하고, 테스트가 끝난 뒤 네트워크 환경에 따라 유지할지 결정하세요. 특정 네트워크의 문제 때문에 다른 네트워크에서 정상적으로 동작하던 설정까지 계속 바꾸지 마세요.

암호화 DNS는 주로 조회 정보의 전송 방식을 바꾸며, 웹 트래픽의 라우팅 정책을 자동으로 변경하지 않습니다. 조회 결과가 현재 회선에 적합하다는 보장도 없습니다. 입력할 때는 DNS 서버 주소, 프로토콜, 연결 가능 여부를 구분하고, 현재 화면에서 해당 방식을 지원한다면 입력란의 형식에 맞추세요. 일반 웹페이지 주소를 DNS 서비스 주소로 입력하지 마세요. 인증서 검증 오류가 발생하면 시스템 시간과 입력 내용을 확인하세요. 조회 경로 문제를 감추기 위해 인증서 검증을 끄지 마세요.

DNS 설정 변경 결과 확인하기

반복해서 접속할 수 있는 도메인을 하나 선택하고 변경 전 증상을 기록한 뒤 DNS 설정 한 곳만 조정하세요. 연결을 새로 설정한 다음 Log에서 조회 성공 여부, 반환된 주소, 후속 요청에 적용된 정책을 확인합니다. 브라우저가 별도의 DNS 기능을 사용하거나 앱이 주소를 캐시할 수 있으므로 한 번 새로고침한 결과만 보지 말고 클라이언트의 실제 기록을 함께 확인하세요. 한 앱에서만 문제가 발생한다면 별도의 DNS 기능을 사용하거나 기존 연결을 재사용하는지도 살펴보세요.

DNS 조회가 성공해도 대상에 접속할 수 있다는 뜻은 아닙니다. 연결 시간 초과도 DNS 실패와 같지 않습니다. 실패가 발생한 단계를 먼저 파악한 뒤 DNS를 바꿀지 결정하세요.

원래 상태로 되돌릴 때는 DNS 서버, 주소 유형 관련 스위치와 활성 구성을 함께 복원하세요. 마지막으로 입력한 줄만 지우는 것으로는 충분하지 않을 수 있습니다. 복원 후에도 문제가 계속되면 네트워크를 바꿨는지, 다른 Config를 선택했는지 확인하세요. 전체 예시는 DNS 조회 실패 문제 해결을 참고하세요. 모든 대상에 연결할 수 없다면 연결할 수 없을 때 자주 묻는 질문을 확인하고 DNS 설정만 반복해서 바꾸지 마세요.

3. On Demand 조건에 따른 연결

연결 조건과 라우팅 정책은 별도로 설정

On Demand는 어떤 조건에서 시스템이 VPN 연결을 시작하거나 다시 연결할지 지정합니다. 서버 선택 기능이나 규칙 정책은 아닙니다. On Demand로 연결되더라도 각 요청이 PROXY 또는 DIRECT 중 어느 쪽을 사용할지는 Global Routing과 활성 구성에 따라 결정됩니다. 이 차이를 알아두면 특정 웹사이트를 프록시로 열기 위해 On Demand만 켜거나, 네트워크 전환 후 다시 연결되게 하려고 도메인 규칙만 계속 바꾸는 실수를 피할 수 있습니다.

기본 상태는 기기에 표시된 실제 스위치와 저장된 조건을 기준으로 확인하세요. 연결 버튼이 켜져 있다고 해서 On Demand가 활성화된 것은 아닙니다. 데이터를 복원하거나 시스템 VPN 설정을 변경한 뒤에도 다시 확인해야 합니다. 먼저 수동 연결이 안정적으로 작동하는지 확인한 뒤 On Demand를 설정하세요. 수동 연결에서도 오류가 계속된다면 자동 재시도가 같은 실패를 반복해 로그만 늘릴 뿐, 원격 주소나 인증 정보, 네트워크 문제를 해결하지는 않습니다.

네트워크 조건별로 규칙 설정

Settings › On Demand로 이동해 현재 화면에 표시된 조건 유형을 확인한 뒤 필요한 항목만 설정하세요. 무선 네트워크 이름으로 동작을 구분한다면 이름의 대소문자와 공백, 같은 이름의 네트워크가 있는지 정확히 확인하세요. 네트워크 이름은 조건에 사용할 수 있는 정보일 뿐 네트워크 신뢰성을 증명하지 않습니다. 이름이 같다고 동일한 보안 환경으로 간주하거나 로컬 프록시 포트의 접근 범위를 넓히지 마세요.

먼저 현재 무선 네트워크와 모바일 네트워크를 구분하는 등 쉽게 확인할 수 있는 조건 하나부터 설정하세요. 시스템에서 실제로 어떻게 작동하는지 확인한 뒤 다른 조건을 추가합니다. 조건에는 순서나 우선 적용 관계가 있을 수 있으므로 현재 화면의 안내에 따라 배열하세요. 조건이 적용되지 않으면 모든 조건을 바로 지우기보다 네트워크 인터페이스와 이름이 일치하는지 확인하세요. 테스트할 때는 전환 전후의 네트워크, 전환 시각과 연결 상태를 기록하세요. 이런 정보가 ‘가끔 끊긴다’는 설명보다 문제를 찾는 데 도움이 됩니다.

수동으로 연결을 끊은 뒤 다시 연결되는 이유

수동으로 연결을 끊은 뒤 곧바로 다시 연결된다면 클라이언트 오류로 단정하지 말고 On Demand와 시스템 VPN의 주문형 설정을 먼저 확인하세요. 이후 네트워크 요청이나 네트워크 변경으로 시스템이 다시 연결을 시작할 수 있습니다. 연결이 끊긴 상태를 테스트하려면 관련 조건을 먼저 일시 중지하고 시스템 상태를 확인하세요. 연결 스위치를 반복해서 누르는 것만으로 자동 연결이 중지되었다고 판단할 수 없습니다. 조건이 저장되어 있다면 기기를 재시동한 뒤 같은 문제가 다시 나타날 수도 있습니다.

연결 상태와 서비스 연속성은 같은 의미가 아닙니다. Wi-Fi에서 모바일 네트워크로 전환하면 기기 주소와 연결 경로가 바뀌므로 진행 중인 다운로드, 통화 또는 장기 연결을 앱에서 다시 설정해야 할 수 있습니다. On Demand가 모든 앱의 세션을 유지해 주거나 백그라운드 실행 및 네트워크 권한에 대한 시스템 제한을 우회하지는 않습니다. 새 요청으로 확인하고, 기존 세션이 끊긴 상황과 새 연결이 실패한 상황을 따로 기록하세요.

권장 순서: 수동 연결 확인 → On Demand 조건 하나 추가 → 네트워크 전환 테스트 → 다른 조건 추가. 조건을 하나씩 추가할 때마다 되돌릴 수 있도록 기존 상태를 기록하세요.

조건이 올바른 것처럼 보이는데도 작동하지 않으면 시스템의 VPN 구성이 여전히 Shadowrocket에 연결되어 있는지, 다른 연결이 사용 중인지, 기기에 관리 정책이 적용되어 있는지 확인하세요. 문제 해결을 위해 시스템 구성을 모두 삭제하지 마세요. 필요한 정보를 먼저 저장한 뒤 문제와 관련이 명확한 항목만 처리하세요. 첫 실행 권한과 Home 화면 안내는 첫 실행 설정을 참고하세요. 자동 연결 후 트래픽이 향하는 경로는 이 페이지의 Config › Rule에서 확인할 수 있습니다.

4. Ping 및 Connectivity Test의 측정 범위

먼저 어느 구간을 측정하는지 확인

Ping은 관련 테스트 설정을 찾기 위한 메뉴 이름입니다. 실제로 선택할 수 있는 방법은 현재 화면을 기준으로 확인하세요. 테스트 방법마다 확인하는 범위가 다릅니다. 네트워크 왕복 시간을 주로 확인하는 방식도 있고, 대상 포트 연결을 시도하거나 앱 수준의 요청까지 확인하는 방식도 있습니다. 숫자가 표시되었다고 인증, DNS 조회, 규칙 적용과 모든 웹사이트 접속까지 성공했다고 볼 수는 없습니다. 테스트 결과와 함께 사용한 방법을 기록하세요. 방법이 다른 테스트의 수치를 비교해도 진단에 도움이 되지 않습니다.

기본 테스트 방법, 제한 시간과 대상은 Settings › Ping에서 확인하세요. 기기나 복원된 데이터에 따라 사용자 지정 값이 설정되어 있을 수 있으므로 모든 네트워크에 맞는 고정 제한 시간을 지정하지 않습니다. 처음에는 현재 사용할 수 있는 방법을 유지하고 실제 접속 결과를 확인하세요. 여러 서버를 비교할 때는 네트워크, 테스트 방법, 대상을 동일하게 유지하고 여러 차례 측정하세요. 그래야 Wi-Fi 신호 변화와 원격 서버 차이를 구분할 수 있습니다.

테스트 방식에 따라 성공과 실패를 판단

화면에서 TCP 방식 테스트를 제공한다면 성공은 보통 해당 포트와 연결을 설정할 수 있다는 의미이며, 앱 수준 인증까지 통과했다는 뜻은 아닙니다. HTTP 방식 테스트를 제공한다면 대상의 응답, 리디렉션, 인증서, DNS 조회가 결과에 영향을 미치는지도 확인하세요. 네트워크 장비가 특정 테스트를 제한하거나 필터링할 수 있으므로 테스트는 실패해도 실제 서비스는 정상일 수 있습니다. 결과가 현재 문제와 관련 있는지 판단하기 전에 테스트 정의부터 확인하세요.

테스트 대상과 제한 시간 선택 방법

테스트 대상을 직접 설정할 수 있다면 용도가 명확하고 안정적으로 응답하는 대상을 사용하고, 비교하는 동안에는 같은 대상을 유지하세요. 로그인이나 잦은 리디렉션이 필요하거나 자동 요청을 제한하는 페이지를 회선 품질의 기준으로 삼지 마세요. 대상 자체에 문제가 있으면 모든 서버에서 실패로 표시될 수 있습니다. 대상을 바꾼 뒤 정상으로 돌아와도 회선이 복구되었다고 단정할 수 없습니다. 테스트 대상이 바뀌었는지, 조회·핸드셰이크·응답 중 어느 단계에서 실패했는지 기록하세요.

제한 시간이 너무 짧으면 일시적인 끊김도 실패로 처리하고, 너무 길면 연결할 수 없는 테스트가 오래 걸립니다. 먼저 현재 기본 동작을 유지하고 네트워크에서 실제로 더 긴 대기 시간이 필요하다는 점을 확인한 뒤 조정하세요. 지속적인 실패를 감추려고 제한 시간을 지나치게 늘리지 마세요. 여러 테스트를 동시에 실행하면 네트워크와 기기 자원을 사용하므로 신호가 약하거나 백그라운드 작업이 많을 때 측정 자체가 결과에 영향을 줄 수 있습니다. 비교하기 전에 불필요한 대용량 작업을 중지하고 테스트 조건을 비슷하게 맞추세요.

실제 접속 결과와 연관 지어 확인

Home에서 Connectivity Test를 실행한 뒤 실패한 서비스 하나를 정해 확인하세요. 도메인, Global Routing 상태와 선택한 서버를 기록한 다음 Log에서 새 요청을 살펴봅니다. 테스트는 성공했지만 페이지가 열리지 않는다면 페이지에 다른 정책이 적용되는지, 추가 도메인을 요청하는지, 인증서 또는 인증 오류가 있는지 확인하세요. 서버 목록의 정렬 순서만 보고 서버를 계속 바꾸지 마세요. 정렬 결과는 앱마다 필요한 조건을 반영하지 않습니다.

테스트 방법, 테스트 대상, 실제 접속 결과를 함께 기록하세요. 지연 시간은 대역폭과 다르며 한 번 성공했다고 계속 사용할 수 있다는 보장은 없습니다.

모든 테스트가 동시에 실패하면 먼저 기기의 기본 네트워크와 권한을 확인하세요. 서버 하나만 실패한다면 해당 서버의 주소, 포트와 프로토콜 매개변수를 확인합니다. 프로토콜에는 Shadowsocks, VMess, VLESS, Trojan, Hysteria2, WireGuard가 있으며 각 프로토콜에 필요한 항목이 다릅니다. 테스트 실패만으로 프로토콜을 임의로 바꾸지 마세요. 매개변수는 본인이 보유한 서버 정보와 일치해야 합니다. 가져오는 방법은 Add Server 사용 안내를 확인하고, 누락된 인증 정보를 테스트 설정으로 보완하려 하지 마세요.

5. Log 기록 범위와 문제 증거 정리

재현 가능한 작업 하나로 시작

Log는 연결과 처리 과정을 살펴보는 도구이지 모든 오류의 원인을 자동으로 판정하는 화면은 아닙니다. 같은 ‘시간 초과’도 DNS 서버, 서버 포트, 최종 대상 중 어디에서 발생했는지 주변 기록을 함께 보고 판단해야 합니다. 먼저 연결한 뒤 지정한 도메인을 여는 것처럼 문제를 한 번의 작업으로 좁힌 다음 해당 작업 전후의 기록을 확인하세요. 여러 앱을 동시에 열고 구독을 업데이트하며 테스트를 한꺼번에 실행하면 여러 이벤트가 섞여 원인과 순서를 파악하기 어려워집니다.

로그 기록 활성화 여부, 상세 수준, 저장할 수 있는 범위는 현재 Settings › Log 화면의 옵션을 확인하세요. 모든 플랫폼에 같은 수준의 기록 기능이 있다고 가정하지 않습니다. 기본 상태는 기존 설정에 따라 다를 수 있습니다. 평소에는 기본적인 문제를 찾는 데 필요한 수준으로 유지하고, 문제를 재현할 때만 잠시 상세도를 높이는 것이 좋습니다. 상세 기록을 계속 유지하면 저장 및 처리 부담이 커지고 도메인, 주소, 연결 정보가 더 많이 쌓일 수 있으므로 문제 해결 후 원래 수준으로 되돌리세요.

오류 단어만 찾지 말고 연결 단계를 따라 읽기

먼저 요청에 포함된 도메인이나 주소를 찾고, 적용된 정책을 확인한 뒤 연결 설정과 응답 과정을 살펴보세요. 요청이 전혀 보이지 않는다면 앱이 기존 연결을 사용하고 있거나, 요청이 현재 경로를 거치지 않거나, 기록 범위에 해당 이벤트가 포함되지 않을 수 있습니다. 그렇다고 네트워크 요청이 없었다고 단정할 수는 없습니다. REJECT가 명확히 표시되면 규칙을 우선 확인하세요. 연결 대상이 계속 서버 자체라면 최종 웹사이트의 도메인 규칙을 바꾸기 전에 프로토콜과 인증 정보를 살펴보세요.

최소 재현 기록 작성

시작하기 전에 기기의 현재 시간과 네트워크를 기록하고, 이전 로그 중 필요한 부분은 보관하세요. 그런 다음 화면에서 제공하는 방법으로 기록을 지우거나 시작 지점을 찾습니다. 작업은 한 번만 수행하고 결과를 기록한 뒤 추가 테스트를 중단하세요. 정리할 때 오류 단어 하나만 자르지 말고 문제 전후의 연속된 로그를 보존하세요. 이전 줄에 대상 주소가, 다음 줄에 재시도 결과가 표시될 수 있습니다. 이런 맥락이 없으면 같은 메시지가 연결 과정의 어느 단계에서 발생했는지 판단하기 어렵습니다.

Wi-Fi 전환 후에만 문제가 발생한다면 전환 전후의 로그를 따로 비교하고 새 연결에 새 경로가 사용되었는지 확인하세요. 특정 Config에서만 나타난다면 서버는 그대로 두고 활성 파일과 일치한 규칙을 비교하세요. 한 번에 변수 하나만 바꿔야 원인을 설정 범위로 좁힐 수 있습니다. 같은 오류가 반복된다고 해서 모든 디버그 항목을 바로 켜지 마세요. 자동 재시도나 On Demand가 다시 연결을 시도해 반복 기록을 남긴 것인지 먼저 확인하세요.

내보내기 전에 개인정보 처리

로그에 접속 도메인, 서버 주소, 계정 항목, 구독 주소 등 개인을 식별할 수 있는 정보가 포함될 수 있습니다. 공유하기 전에 구독 링크의 인증 매개변수, 비밀번호와 개인정보를 삭제하세요. 주소를 바꿔야 한다면 로그 전체에서 동일한 주소에 같은 별칭을 사용해야 연결 관계가 유지됩니다. 문제 설명 대신 전체 구성을 업로드하지 말고 인증 정보가 보이는 스크린샷도 공개 게시물에 올리지 마세요. 비밀번호가 직접 표시되지 않더라도 인증 매개변수가 포함된 링크는 민감한 정보로 다뤄야 합니다.

로그는 문제를 판단할 근거를 모으는 도구이지 특정 회선이 ‘항상 정상’임을 증명하는 자료가 아닙니다. 연결 단계, 적용 정책과 결과를 남기고 인증 정보와 개인정보를 지운 뒤 재현 방법을 설명하세요.

문제 해결이 끝나면 로그 수준을 복원하고 필요한 경우 로컬에 내보낸 사본을 정리하세요. 테스트를 위해 DNS나 라우팅을 변경한 상태로 남겨 두지 않았는지도 확인합니다. 계속 조사해야 한다면 문제를 DNS 조회, 인증, 규칙, 시스템 권한 중 하나로 분류한 다음 연결 문제 FAQ를 확인하세요. 로그를 더 많이 쌓는 것만으로 결론이 명확해지지는 않습니다. 재현 가능한 조건과 앞뒤 맥락이 다음 판단의 근거가 됩니다.

6. Widget 표시, 빠른 동작과 상태 확인

빠른 실행은 전체 설정 화면을 대신하지 않습니다

Widget은 시스템에서 지원하는 위치에 정보를 표시하거나 현재 제공되는 빠른 동작을 실행합니다. 구체적인 형태, 크기와 조작 기능은 시스템 및 현재 Shadowrocket 화면에 따라 달라집니다. 한 기기의 Widget 배치를 모든 플랫폼에서 사용할 수 있는 기능으로 간주하지 마세요. 반복해서 앱을 여는 일을 줄이는 데는 편리하지만 Config 편집, 프로토콜 매개변수 확인, 로그 분석을 대신하지는 않습니다. 상태가 이상하면 Widget 문구만 믿지 말고 Home과 시스템 VPN 상태를 확인하세요.

기본 표시 내용은 Settings › Widget과 시스템의 추가 화면에서 확인하세요. 홈 화면에 추가하지 않았다고 해서 클라이언트 연결 기능이 꺼진 것은 아닙니다. 먼저 클라이언트에서 연결과 해제가 정상적으로 작동하는지 확인한 뒤 필요한 Widget을 추가하세요. 시스템에서 해당 유형을 제공하지 않는다면 현재 사용할 수 있는 방법을 따르세요. 같은 모양을 찾으려고 DNS를 바꾸거나 서버를 다시 가져오지 마세요. Widget 표시 여부는 보통 시스템 표시 또는 권한 문제이며 도메인 규칙의 정확성과 직접 관련이 없습니다.

추가 후 연결된 상태 확인

시스템의 Widget 추가 화면에서 Shadowrocket을 선택하고 화면에 표시되는 방법에 따라 배치와 설정을 마치세요. 처음 사용할 때는 앱을 한 번 열어 표시할 정보가 저장되었는지 확인한 뒤 Widget으로 돌아와 내용을 확인합니다. Widget에서 항목을 선택할 수 있다면 현재 사용하는 대상과 연결되어 있는지 살펴보세요. 서버를 삭제하거나 이름을 바꾸고 구성을 조정한 뒤에는 빠른 실행이 여전히 유효한 항목을 가리키는지 확인해야 합니다. 예전 제목만 보고 연결이 그대로라고 판단하지 마세요.

새로고침, 백그라운드, 네트워크 전환

시스템에서 Widget 새로고침 빈도를 제한할 수 있으므로 표시 내용이 매 순간 클라이언트 상태와 일치하지 않을 수 있습니다. Widget은 편리한 바로가기와 상태 참고 수단으로 사용하고 연속적인 네트워크 모니터링 도구로 보지 마세요. 잠금 화면, 배터리 부족, 백그라운드 작업 예약과 네트워크 변경이 표시 시점에 영향을 줄 수 있습니다. 오래된 상태가 보이면 클라이언트에서 먼저 확인한 뒤 시스템이 갱신할 때까지 기다리세요. 아직 갱신되지 않은 표시를 따라가려고 구성을 계속 삭제하거나 서버를 바꾸지 마세요.

빠른 동작으로 연결을 끊었는데 다시 연결되었다면 Widget이 작동하지 않았다고 판단하기 전에 On Demand를 확인하세요. 동작은 성공했지만 이후 시스템이 조건에 따라 연결을 다시 설정했을 수 있습니다. 반대로 Widget에 연결 중으로 표시되어도 대상 요청에 올바른 정책이 적용되었다는 뜻은 아닙니다. Config의 DIRECT 또는 REJECT 규칙이 여전히 적용될 수 있습니다. 실제 요청을 새로 보내고 Log에서 경로를 확인하세요. 아이콘이나 스위치 모양만으로 트래픽 경로를 판단하지 마세요.

표시 정보와 개인정보 보호

Widget이 홈 화면이나 시스템의 다른 공개 영역에 표시되면 주변 사람이 서버 메모, 구성 이름 또는 연결 상태를 볼 수 있습니다. 계정, 이메일 주소, 인증 정보가 포함되지 않은 짧은 메모를 사용하세요. 화면 미러링, 발표 또는 화면 공유를 자주 한다면 Widget에 표시되는 내용을 미리 확인하세요. 이름을 바꿔도 연결 매개변수는 변경되지 않습니다. 구독 링크를 메모로 사용하거나 쉽게 구분하려고 비밀번호를 이름에 적지 마세요. 이름과 인증 정보는 따로 관리해야 합니다.

권장 원칙: 평소 필요한 정보만 표시하고 용도를 정확히 아는 빠른 동작만 남기세요. 시스템 상태와 실제 요청 결과가 다르면 클라이언트, 시스템 VPN 상태와 새 요청을 함께 확인하세요.

Widget을 계속 사용할 수 없다면 클라이언트가 정상적으로 열리는지, 시스템에서 해당 Widget 추가를 허용하는지, 연결된 항목이 아직 존재하는지 먼저 확인하세요. 그런 다음 시스템 안내에 따라 제거 후 다시 추가해 보세요. 표시 문제를 해결하려고 백업 없이 앱을 삭제하지 마세요. 로컬 구성을 잃을 수 있습니다. 클라이언트 자체도 연결되지 않는다면 Widget 문제 범위를 벗어난 것입니다. Settings 개요로 돌아가 변경 범위를 정한 뒤 DNS, 권한 또는 서버 매개변수에 따라 문제를 살펴보세요.

7. iCloud 동기화, 기기 이전과 덮어쓰기 위험

데이터 동기화, 구매 내역, 시스템 권한을 구분하세요

iCloud 관련 기능은 지원되는 환경에서 앱 데이터를 처리하는 데 사용됩니다. App Store 구매 내역을 대신하거나 시스템 VPN 권한을 새 기기로 이전해 주지는 않습니다. 새 기기에서 구성이 보이더라도 최초 네트워크 권한 확인이 끝났다는 뜻은 아닙니다. 같은 구매 계정으로 앱을 받아도 다른 기기의 설정이 모두 표시된다는 보장은 없습니다. 스토어 계정, 시스템 클라우드 서비스 계정, 클라이언트에서 실제로 동기화되는 범위를 각각 확인해 세 가지 상태를 하나의 스위치처럼 혼동하지 마세요.

동기화의 기본 활성화 여부와 대상 항목은 Settings › iCloud 및 시스템 설정에서 확인하세요. 이 매뉴얼은 모든 필드가 동기화된다고 가정하지 않으며 다른 플랫폼이 같은 클라우드 서비스를 사용한다고 보장하지 않습니다. 처음 활성화하기 전에 로컬에서 복원할 수 있는 사본을 저장하고 화면에 안내된 동기화 범위를 확인하세요. Config 하나만 옮기려는 경우에는 모든 동기화 항목을 켜기보다 안내된 내보내기 및 가져오기 절차를 사용하세요.

먼저 유지할 데이터를 정하세요

두 기기의 구성이 서로 다르다면 먼저 어느 쪽을 유지할지 정하고 다른 기기에만 있는 중요한 차이를 따로 기록하세요. 양쪽에서 항목을 대량으로 이름 변경, 삭제, 추가한 뒤 시스템이 더 적절한 구성을 알아서 선택하기를 기대하지 마세요. 동기화는 상태를 전달할 뿐 사용자의 의도를 판단하지 않습니다. 충돌이 발생하면 현재 화면의 안내를 읽으세요. 교체나 덮어쓰기 확인이 표시되면 먼저 멈추고 백업을 확인한 뒤 진행하세요.

동기화 후에도 실제 연결 확인

대상 기기에서 앱을 열고 항목이 모두 있는지 확인한 뒤 활성 Config, Global Routing, 선택된 서버를 살펴보세요. 이름만 같다고 확인하는 것으로는 충분하지 않습니다. 포트, 프로토콜과 추가 매개변수도 연결에 영향을 줄 수 있습니다. 그런 다음 수동으로 연결을 설정하고 필요한 권한 안내를 처리한 뒤 실제 대상으로 테스트하세요. 마지막으로 On Demand와 Widget을 설정하면 데이터 이전 문제와 자동 연결 및 표시 문제를 구분할 수 있습니다.

구독 동기화와 구독 업데이트는 서로 다른 작업입니다. 동기화로 다른 기기에 기존 항목을 전달할 수 있지만, 업데이트는 본인이 보유한 구독 주소에 접속해 반환된 내용에 따라 데이터를 처리합니다. 새 기기의 항목 수나 이름이 다르면 업데이트가 성공했는지, 같은 주소를 사용했는지, 로컬에서 편집했는지 먼저 확인하세요. 기존 데이터를 바로 삭제하고 업데이트를 반복하면 작동 중인 로컬 기록과 비교 근거를 함께 잃을 수 있습니다.

계정 및 민감한 데이터 관리

동기화를 켜기 전에 구성에 서버 주소, 비밀번호, 인증 항목과 구독 정보가 포함될 수 있음을 이해해야 합니다. 기기와 계정을 누가 관리하는지에 따라 이런 데이터를 볼 수 있는 사람도 달라집니다. 여러 사람이 사용하는 기기에는 전체 구성을 보관할 때 주의하세요. 기기를 판매하거나 양도하거나 더 이상 사용하지 않을 때는 시스템과 클라이언트가 제공하는 방법으로 개인정보를 처리하세요. 홈 화면에서 Widget을 제거해도 구성은 삭제되지 않으며, 동기화 스위치를 끄더라도 저장된 사본이 모두 지워지는 것은 아닙니다.

동기화는 별도의 백업이 아닙니다. 삭제나 잘못된 변경도 다른 기기로 전파될 수 있으므로 중요한 변경 전에는 실시간 동기화와 별도로 복원 가능한 사본을 보관하세요.

동기화가 오래 진행되지 않으면 클라우드 서비스 로그인, 사용 가능한 저장 공간, 네트워크와 앱 권한을 먼저 확인하고 클라이언트 안내를 살펴보세요. 동기화를 재촉하려고 두 기기의 설정을 모두 번갈아 바꾸지 마세요. 상태 차이만 커질 수 있습니다. 복원이 필요하다면 편집을 중단하고 양쪽 상태를 보존한 뒤 확인된 사본을 한 기기에 복원하고 결과를 확인하세요. 구매한 앱을 다시 받는 방법은 기기 변경 및 재설치 안내를 참고하세요. 데이터 복원은 클라이언트 구매 및 설치 절차를 대신하지 않습니다.

8. Proxy 로컬 포트와 접근 범위

로컬 수신 포트와 원격 서버 포트는 다릅니다

Proxy 관련 설정에는 기기에서 앱이 연결하는 로컬 HTTP 또는 SOCKS 프록시 포트가 포함될 수 있습니다. 구체적인 항목은 현재 화면에서 확인하세요. 이 포트는 클라이언트가 기기에서 제공하는 접속점이며 Add Server에 입력하는 원격 서버 포트와 다릅니다. 로컬 포트를 바꿔도 서비스에서 제공한 원격 매개변수는 바뀌지 않고 다른 앱이 자동으로 프록시를 사용하는 것도 아닙니다. 로컬 프록시를 사용하려는 앱이 해당 방식을 지원해야 하며 주소와 포트를 직접 입력해야 합니다.

기본 포트와 수신 주소는 현재 설정을 확인하고 온라인 예시를 보고 고정 숫자를 짐작하지 마세요. 로컬 프록시가 필요하지 않다면 기존 상태를 유지하고 ‘최적화’를 위해 수신 범위를 넓히지 마세요. 필요한 경우 포트, 프로토콜, 접근 범위를 기록하세요. 화면에서 주소를 지정할 수 있다면 기기에서만 사용할 접속점은 로컬 주소에 한정하는 것이 좋습니다. 로컬 네트워크로 접근 범위를 넓히면 접속할 수 있는 기기가 달라지므로 네트워크의 신뢰성, 접근 제어와 시스템 방화벽을 함께 고려해야 합니다.

주소, 포트, 프로토콜을 일치시키세요

루프백 주소 127.0.0.1은 현재 기기 자신을 뜻하며 같은 Wi-Fi 네트워크에 있는 다른 기기를 뜻하지 않습니다. 컴퓨터에 이 주소를 입력하면 컴퓨터에 연결될 뿐 휴대전화의 Shadowrocket에 연결되지 않습니다. 기기 간 접근을 실제로 설정하려면 서비스를 제공하는 기기에서 접근 가능한 주소를 사용하고 수신 범위를 확인해야 합니다. 이는 별도의 네트워크 관리 작업입니다. 포트가 열려 있다고 해서 다른 기기에서 연결할 수 있다고 단정하지 마세요.

포트 충돌과 연결 실패 구분

다른 프로세스가 포트를 사용 중이면 클라이언트가 해당 수신 포트를 열지 못할 수 있습니다. 이때는 서버 비밀번호를 바꾸기보다 안내와 로그를 확인해 어떤 로컬 접속점에서 실패했는지 확인하세요. 포트를 바꿔야 한다면 사용 중이 아니며 화면에서 허용하는 값을 선택하고 해당 프록시를 사용하는 앱의 설정도 함께 업데이트하세요. 클라이언트만 바꾸고 앱을 수정하지 않으면 설정이 서로 맞지 않게 됩니다. 테스트 후에는 다음에 설정을 복원할 때 오류가 나지 않도록 새 값을 기록하세요.

로컬 접속점에는 연결되지만 대상 요청이 실패한다면 클라이언트 연결 상태, Global Routing, 활성 규칙을 확인하세요. 앱이 요청을 로컬 프록시에 전달하는 데는 성공했지만 이후 원격 인증이나 대상 연결 단계에서 실패했을 수 있습니다. 반대로 앱에 로컬 연결 거부가 표시되면 클라이언트가 실행 중인지, 해당 접속점이 활성화되어 있는지, 주소와 포트가 올바른지 먼저 확인하세요. 두 상황을 구분하면 모든 문제를 회선 이상으로 돌리는 일을 피할 수 있습니다.

시스템 터널과 명시적 프록시의 차이

시스템 VPN 터널과 앱에 직접 입력하는 프록시 설정은 서로 다른 트래픽 연결 방식입니다. 모든 앱이 시스템의 명시적 프록시 설정을 따르는 것은 아니며, 로컬 포트를 열었다고 모든 앱에 적용되는 것도 아닙니다. 경로를 이해하지 않은 채 프록시를 여러 겹으로 설정하면 순환 연결이나 중복 처리가 발생하고 로그를 읽기 어려워질 수 있습니다. 먼저 한 가지 연결 방식이 작동하는지 확인한 뒤 다른 방식도 함께 사용할 필요가 있는지 판단하세요. 경로를 복잡하게 만드는 것이 기능을 늘리는 것은 아닙니다.

권장 원칙: 기기에서 사용할 목적이면 기기 내부로 제한하고, 기기 간 사용은 접근 범위를 먼저 명확히 하세요. 제어할 수 없는 네트워크에 로컬 프록시 포트를 노출하거나 외부 연결을 제공하는 서비스처럼 사용하지 마세요.

테스트를 끝낼 때는 Shadowrocket의 포트와 수신 상태를 복원하는 것뿐 아니라 다른 앱에 임시로 입력한 프록시 주소도 삭제하세요. 그렇지 않으면 클라이언트를 종료한 뒤에도 앱에서 작동하지 않는 로컬 접속점에 연결을 시도해 기기 전체의 네트워크 문제처럼 보일 수 있습니다. 데스크톱 시스템의 프록시도 변경했다면 기록한 원래 상태로 되돌리세요. 일반 네트워크가 정상인지 확인한 뒤 필요한 설정만 하나씩 켜세요. 규칙이 예상과 다르게 적용되면 로컬 포트를 계속 바꾸지 말고 다음 장에서 Config를 확인하세요.

9. Global Routing, 규칙과 설정의 연동

먼저 현재 라우팅 모드 확인

Global Routing의 Config, Proxy, Direct는 각각 구성, 프록시, 직접 연결 모드입니다. Config는 활성 구성에 따라 요청을 처리하고, Proxy는 프록시 방식으로, Direct는 직접 연결 방식으로 요청을 처리합니다. 규칙을 확인하기 전에 현재 모드가 Config인지 확인하세요. 그렇지 않으면 규칙 문법이 올바르더라도 요청 처리에 예상대로 적용되지 않을 수 있습니다. 기본 모드는 Home에 현재 표시된 내용을 기준으로 확인하고, 튜토리얼의 특정 단계에서 선택한 모드를 모든 기기의 초기 상태라고 간주하지 마세요.

규칙 순서와 FINAL의 위치

규칙은 위에서 아래로 확인하며 처음 일치하는 규칙의 정책을 적용합니다. 따라서 구체적인 조건을 넓은 조건보다 앞에 두는 것이 일반적입니다. DOMAIN은 지정한 도메인과 일치하고, DOMAIN-SUFFIX는 도메인 접미사를 기준으로 하며, DOMAIN-KEYWORD는 키워드로 판단합니다. IP-CIDR과 IP-CIDR6은 주소 범위에, GEOIP는 주소의 지역 정보에 따라 일치 여부를 판단합니다. 규칙마다 사용하는 정보가 다르므로 도메인이 존재한다고 해서 주소 규칙이 DNS 조회 없이 적용되는 것은 아닙니다.

FINAL은 앞의 규칙에 일치하지 않는 요청에 적용되는 기본 규칙이므로 일반적으로 목록의 마지막에 둡니다. 다른 규칙보다 앞에 두면 뒤에 있는 규칙이 적용되지 않을 수 있습니다. 다음은 문법을 이해하기 위한 최소한의 .conf 예시입니다. 완성된 구성이나 보편적인 권장 규칙 목록은 아닙니다. 예시 도메인과 로컬 네트워크 범위는 순서를 설명하기 위한 것이므로 가져오기 전에 본인이 사용하는 구성에 적합한지 확인하세요.

[Rule]
DOMAIN-SUFFIX,example.com,PROXY
DOMAIN-KEYWORD,example,DIRECT
IP-CIDR,192.168.0.0/16,DIRECT
GEOIP,CN,DIRECT
FINAL,PROXY

이 예시에서는 example.com과 하위 도메인이 먼저 DOMAIN-SUFFIX에 일치하므로 뒤의 키워드 규칙까지 내려가지 않습니다. PROXY, DIRECT, REJECT는 각각 프록시, 직접 연결, 거부 정책을 뜻합니다. 인터페이스 모드의 이름과 대소문자를 임의로 섞어 같은 의미로 사용하지 마세요. 특정 대상을 차단해야 한다면 REJECT를 사용할 수 있지만 먼저 영향 범위를 확인하세요. 웹페이지 하나가 여러 도메인을 사용하는 경우 특정 리소스를 거부하면 페이지 표시가 달라질 수 있으며, 눈에 보이는 버튼 하나만 비활성화되는 것은 아닙니다.

비교 테스트로 설정 영향 분리

Config에서는 실패하지만 Proxy에서는 성공한다면 서버를 바로 바꾸기보다 일치한 정책, 활성 파일과 DNS 경로를 먼저 확인하세요. 두 모드에서 모두 실패한다면 원격 매개변수와 기본 연결을 살펴봅니다. Direct 결과는 현재 직접 연결 경로의 상태만 보여 주며 다른 경로에도 반드시 문제가 있다는 뜻은 아닙니다. 모드를 바꾼 뒤에는 요청을 새로 만들어 테스트하세요. 기존 연결에 이전 라우팅이 남아 있으면 비교 결과가 서로 모순되는 것처럼 보일 수 있습니다.

구독 업데이트, 구성 파일 업데이트, 수동 편집은 구분해서 관리하세요. 구독은 본인이 보유한 서버 정보를 처리하는 데 사용하고 Config는 해당 설정 내용을 관리합니다. 한 항목을 업데이트했다고 다른 항목도 함께 바뀌었다고 볼 수는 없습니다. 편집 전 활성 파일을 확인하고, 업데이트 전 중요한 사용자 지정 규칙을 보관하세요. 외부 구성을 다시 가져온 뒤에는 로컬 변경 내용이 덮어써졌는지 확인하세요. 파일 이름이 같다고 내용도 그대로라고 판단하지 마세요.

평소에는 확인을 마친 Config를 사용하고 문제를 살펴볼 때만 Proxy와 Direct를 잠시 비교하세요. 테스트가 끝나면 원래 모드로 되돌리고 DNS, On Demand, 활성 규칙을 다시 확인해 임시 상태가 남지 않도록 하세요.

규칙과 DNS의 연동은 Log에서 확인하세요. 대상을 찾고 첫 번째로 일치한 규칙을 확인한 다음 후속 연결을 살펴봅니다. 규칙 우선순위를 더 알아보려면 사용자 지정 규칙 우선순위와 FINAL을 참고하세요. 가져오기 절차를 확인해야 한다면 Subscribe 사용 안내로 돌아가세요. 구성 변경, 요청 하나와 해당 기록을 연결해 확인하는 것이 규칙을 더 쌓는 것보다 안정적인 관리에 도움이 됩니다.