Shadowrocket 사용법 완벽 가이드

Home과 구성의 관계부터 이해하기

처음 실행한 뒤 먼저 세 가지 항목을 구분하세요. Home에서 선택할 수 있는 서버, Config에서 사용하는 규칙 구성, 시스템 연결을 시작하는 스위치입니다. 서버는 요청을 처리할 원격 대상을 정하고, 규칙 구성은 각 요청에 적용할 정책을 정하며, 스위치는 이번 네트워크 확장 기능의 실행 여부를 정합니다. 세 항목은 서로 관련되어 있지만 서로를 대신하지는 않습니다. 서버가 목록에 있어도 규칙이 적절하다는 뜻은 아닙니다. 규칙 파일이 있어도 서버 인증 정보가 올바르다는 뜻은 아니며, 스위치를 켠 뒤에도 실제 접속을 통해 결과를 확인해야 합니다.

처음 실행할 때 앱은 모든 권한 안내를 한꺼번에 표시하는 대신 관련 기능을 처음 사용할 때 권한을 요청할 수 있습니다. 현재 표시된 안내에서 권한의 용도를 읽고 계속 진행할지 결정하세요. 카메라 권한은 주로 QR 코드 스캔에, 알림 권한은 앱 알림에, 시스템 VPN 구성 권한은 연결 설정에 사용됩니다. 텍스트 링크만 가져오는 경우에는 같은 작업을 위해 카메라 권한을 미리 켤 필요가 없습니다. 사용하지 않는 기능의 권한은 실제로 필요할 때 시스템 절차에 따라 허용하면 됩니다.

시스템 VPN 구성 권한 이해하기

처음 연결을 켜려고 할 때 시스템에서 VPN 구성 추가를 허용하라는 메시지가 표시될 수 있으며 기기 인증을 요구할 수도 있습니다. 이는 시스템에 네트워크 확장 구성을 등록하는 절차입니다. 요청이 현재 조작 중인 Shadowrocket에서 온 것인지 확인한 다음 시스템 안내에 따라 진행하세요. 권한을 허용했다는 것은 시스템이 해당 구성을 실행하도록 허용했다는 뜻일 뿐, 네트워크의 모든 요청이 전달되거나 연결된 서버가 모든 대상에 접속할 수 있다는 뜻은 아닙니다. 실제 처리 방식은 Global Routing, 규칙 및 원격 서비스에 따라 달라집니다.

이전에 시스템 안내를 취소했다면 서버 정보를 확인한 뒤 연결을 다시 켜고 실제 표시되는 권한 절차를 진행하세요. 구성을 계속 설정할 수 없다면 기기가 조직에서 관리되는지, 관련 기능을 제한하는 정책이 있는지, 다른 네트워크 구성이 적용 중인지 먼저 확인하세요. 조직 관리 기기는 관리 규정을 따라야 하며 관리 제한을 일반적인 연결 문제로 간주해서는 안 됩니다. 여러 시스템 구성을 연달아 삭제하며 시험하지 마세요. 기존 업무 네트워크에 영향을 주지 않도록 현재 구성의 앱과 용도를 먼저 기록하세요.

시스템 상태와 앱 상태를 따로 판단하기

시스템에 VPN 상태가 표시되면 해당 네트워크 확장이 연결된 상태임을 뜻하지만, 대상 웹페이지가 성공적으로 로드되었다는 증거는 아닙니다. 반대로 기기 상태 표시줄에 공간이 부족해 특정 표시가 계속 보이지 않더라도 그것만으로 연결이 끊어졌다고 단정할 수 없습니다. 앱의 스위치 상태, 현재 선택된 서버, 실제 접속 결과를 함께 확인하세요. 시스템 설정에서 연결을 끊었는데 다시 자동 연결된다면 스위치가 복구된 것을 시스템이 조작을 받아들이지 않은 것으로 판단하지 말고 On Demand 등의 트리거 조건을 확인하세요.

서버, 라우팅 방식 또는 규칙 구성을 변경한 뒤에도 기존 연결이 이전 경로를 유지할 수 있습니다. 처음 확인할 때는 기존 접속을 중단한 뒤 필요에 따라 연결을 다시 설정하고 대상 페이지를 새로 여세요. 이전 세션을 유지한 상태에서 여러 설정을 바꾸고 페이지가 계속 재생되는지만으로 새 구성을 판단하지 마세요. 로그인이 필요한 앱은 앱 자체의 캐시와 세션 복구가 영향을 줄 수 있으므로 필요한 경우 대상 앱을 종료한 뒤 다시 접속하세요.

권한 확인은 '시스템에서 이 기능을 실행하도록 허용했는가?'에 답합니다. 연결 확인은 '현재 서버, 인증 매개변수, 규칙 및 대상 서비스가 정상인가?'에 답합니다. 두 항목을 별도로 기록하세요.

첫 작업의 복구 가능한 기준 만들기

정보를 가져오기 전에 현재 Wi-Fi와 셀룰러 중 어떤 네트워크를 사용 중인지 기록하고 일반 네트워크가 정상적으로 작동하는지 확인하세요. 웹페이지 인증이 필요한 Wi-Fi는 연결을 시험하기 전에 인증을 완료해야 합니다. 처음 설정하는 동안에는 자동 트리거를 켜지 않는 것이 좋습니다. 그러면 각 연결이 어떤 수동 조작으로 시작되었는지 분명히 알 수 있습니다. 기기에 네트워크 경로를 바꾸는 다른 기능이 이미 있다면 그 상태도 기록해 여러 기능이 동시에 작동한 결과를 하나의 설정 탓으로 돌리지 않도록 하세요.

자신만 보관하는 작업 기록을 준비해 현재 서버 이름, 구성 이름, Global Routing 방식 및 이번 변경 사항을 적어 두는 것이 좋습니다. 전체 비밀번호나 구독 인증 정보는 기록하지 마세요. 처음 연결에 성공하면 이 기록이 복구 기준이 됩니다. 아직 서비스를 가져오지 않았다면 이 단계에 머물러 있는 것이 정상입니다. 다음 장에서 사용자가 이미 보유한 정보를 추가하세요. 더 짧은 순서로 진행하려면 시작 가이드로 돌아가 권한 설정을 마친 다음 이 페이지에서 각 항목의 범위를 확인하세요.

라우팅 방식과 규칙 정책 구분하기

Global Routing은 요청을 어떤 방식으로 처리할지 정합니다. Config는 현재 구성의 규칙을 적용하고, Proxy는 클라이언트 처리 범위에 들어오는 요청에 프록시 경로를 사용하며, Direct는 직접 연결 경로를 사용합니다. 이들은 작동 방식이지 서로 다른 서버가 아닙니다. 방식을 바꿔도 잘못된 비밀번호가 수정되거나 기존 서비스의 유효 기간이 늘어나지 않습니다. 특히 Proxy를 기기의 모든 통신이 반드시 원격 서버를 거치는 것으로 단순하게 해석해서는 안 됩니다. 시스템 네트워크 동작, 처리 범위, 프로토콜 기능에는 각각 한계가 있습니다.

규칙의 PROXY, DIRECT, REJECT는 정책 키워드이며 Global Routing 화면의 항목과 혼동해서는 안 됩니다. 규칙의 PROXY는 현재 선택 항목 및 구성의 정책 정의를 함께 고려해야 합니다. 사용자 지정 정책 그룹을 사용하는 구성이라면 규칙 끝에 PROXY 대신 그룹 이름이 적혀 있을 수 있습니다. 처음 살펴볼 때는 기존 구성의 참조 관계를 확인하세요. 규칙 끝의 문구만 바꾸고 정책 조정이 끝났다고 판단하지 마세요.

위에서부터 순서대로 매칭하고 FINAL은 마지막에 배치하기

Config에서는 규칙을 위에서부터 순서대로 검사하고, 일치하는 규칙을 찾으면 해당 정책을 적용합니다. 구체적인 예외 규칙은 보통 관련된 포괄 규칙보다 앞에 두어야 합니다. 앞선 규칙이 먼저 일치하면 뒤에 있는 예외에는 적용될 기회가 없기 때문입니다. FINAL은 앞선 규칙에 일치하지 않은 요청을 처리하므로 마지막에 배치하세요. 순서 문제를 확인할 때는 새로 추가한 한 줄만 찾지 말고 규칙의 맨 위부터 살펴보세요. 실제로 적용된 규칙이 더 앞에 있을 수 있습니다.

아래는 .conf 파일의 규칙 구문 예시입니다. 구조와 매칭 순서만 설명하며 전체 구성은 아니고 모든 네트워크에 적합한 것도 아닙니다. example.com은 설명용 도메인입니다. 사용 전에 자신의 대상과 기존 정책 정의에 맞게 조정하세요. 편집 전에 원본 구성을 백업하고, 수정한 구성 파일이 현재 선택되어 있는지 확인하세요.

[Rule]
DOMAIN,example.com,PROXY
DOMAIN-SUFFIX,example.org,DIRECT
GEOIP,CN,DIRECT
FINAL,PROXY

DOMAIN은 정확한 도메인에, DOMAIN-SUFFIX는 지정한 도메인과 하위 도메인에 일치합니다. DOMAIN-KEYWORD는 도메인에 포함된 키워드로 매칭하므로 예상보다 넓은 범위에 적용될 수 있습니다. IP-CIDR과 IP-CIDR6은 주소 대역에, GEOIP는 주소가 속한 지역 데이터베이스를 기준으로 매칭합니다. 도메인 요청과 실제 연결 주소 사이에는 해석 과정이 있으므로 도메인 규칙과 주소 규칙은 서로 다른 정보를 기준으로 작동합니다. 최종적으로 표시된 주소 하나만 보고 전체 매칭 과정을 추정할 수는 없습니다.

대상 하나로 변경 사항을 확인하고 구성 전체를 한 번에 바꾸지 않기

규칙을 수정하기 전에 기대하는 결과를 명확히 하세요. 어떤 대상에 어떤 정책을 적용해야 하는지, 기존 결과가 왜 요구 사항과 달랐는지 정리합니다. 대상에 맞는 규칙 하나를 추가한 다음 요청을 다시 보내고 연결 기록에 표시된 정책 결과를 확인하세요. 동작이 달라지지 않으면 구성이 저장되었는지, 실제 선택되었는지, 더 앞선 규칙이 일치했는지, 기존 세션이 계속 유지되고 있는지 확인하세요. DNS, 서버, 여러 규칙을 한꺼번에 바꾸지 마세요. 정상화되더라도 어떤 변경이 효과를 냈는지 알기 어렵습니다.

대상을 DIRECT로 바꿔도 로컬 네트워크의 도메인 해석과 연결 상태에 따라 접속에 실패할 수 있습니다. PROXY로 바꾸더라도 원격 서버에서 해당 대상에 접속할 수 있다는 보장은 없습니다. REJECT는 요청을 적극적으로 거부하며 페이지 리소스, 로그인 과정, 앱 알림에 영향을 줄 수 있으므로 대상의 용도를 이해한 뒤 사용하세요. 규칙은 명확한 요구에 따라 작성해야 하며 규칙 수로 품질을 판단하지 마세요. 순서 사례는 사용자 지정 규칙 우선순위 및 FINAL 안내에서 자세히 확인할 수 있습니다.

권장 순서: 검증된 서버를 유지한 채 Proxy로 프록시 경로를 확인하고, 마지막으로 Config로 규칙 분기를 확인하세요. 임시 방식으로 비교를 마친 뒤에는 원래 사용하던 설정으로 되돌리세요.

Proxy에서는 접속되지만 Config에서는 실패한다면 규칙, 정책 참조, 구성과 관련된 DNS 동작을 먼저 확인하세요. 두 방식 모두 실패한다면 서버 인증, 전송 방식, 네트워크 접근성을 다시 살펴보세요. 이렇게 원인을 나누어 확인하면 방식을 반복해서 전환하는 것보다 효율적입니다. 최종적으로 사용하는 구성 이름과 Global Routing 방식을 기록하세요. 다음 장에서 연결을 확인할 때 재현 가능한 기준이 됩니다.

기기 통계는 서비스 측 잔여 용량과 다릅니다

Data에서는 클라이언트가 확인할 수 있는 범위의 트래픽과 관련 기록을 살펴볼 수 있습니다. 구체적으로 표시되는 항목은 현재 앱을 기준으로 확인하세요. 먼저 통계가 현재 연결, 특정 기간, 누적 데이터 중 무엇을 나타내는지 확인한 다음 수치 변화를 판단하세요. 클라이언트의 트래픽 기록을 서비스 측에서 차감하는 용량과 동일시해서는 안 됩니다. 두 쪽은 시간 범위, 계산 단위, 프로토콜 오버헤드, 과금 방식이 다를 수 있습니다. 기존 서비스의 잔여 용량을 확인하려면 클라이언트 누적 수치로 추산하지 말고 자신의 서비스 계정 정보를 확인하세요.

업로드와 다운로드는 기기 관점에서 이해하세요. 페이지 요청, 파일 전송, 클라우드 동기화는 업로드를 발생시킬 수 있고 페이지 콘텐츠, 동영상, 파일 수신은 다운로드를 발생시킵니다. 웹페이지를 직접 열지 않아도 백그라운드 동기화와 앱 알림으로 네트워크 활동이 생길 수 있습니다. 따라서 소량의 트래픽이 계속 변한다는 사실만으로 이상을 판단하기는 어렵습니다. 현재 실행 중인 작업, 백그라운드 활동, 기록 범위를 함께 살펴보고 단위를 확인하지 않은 채 속도와 누적량을 혼동하지 마세요.

속도, 누적량, 시간 범위 구분하기

속도는 단위 시간 동안 데이터가 변한 양을 나타내고, 누적량은 특정 통계 구간의 총량을 나타냅니다. 짧은 시간의 최고 속도만으로 장시간 전송 능력을 입증할 수 없으며 누적량이 늘어도 현재 전송이 계속되고 있다는 뜻은 아닙니다. 수치를 확인할 때는 단위와 바이트·비트의 차이를 먼저 확인한 뒤 비교하세요. 화면마다 단위 표시 방식이 다를 수 있으므로 문제를 기록할 때는 맥락 없는 숫자만 적지 말고 화면에 표시된 단위를 함께 적으세요.

다시 연결하거나 기록을 삭제하거나 통계를 초기화하면 확인 가능한 범위가 달라질 수 있으므로 실행 전에 각 옵션의 기능을 읽으세요. 숫자를 0으로 만들기 위해 서버나 구독을 삭제하지 마세요. 두 번의 접속에서 트래픽을 비교하려면 같은 대상과 비슷한 작업을 선택하고 시작 및 종료 시점의 통계 차이를 기록하세요. 브라우저 캐시가 이미 적용되었는지도 고려해야 합니다. 같은 페이지를 두 번째 열 때 트래픽이 줄어든 것은 캐시 때문일 수 있으며 네트워크 경로가 바뀌었다는 뜻은 아닙니다.

요청 기록으로 규칙 적용 결과 확인하기

앱에서 연결 기록을 제공한다면 대상 도메인 또는 주소, 적용된 규칙, 정책, 결과를 함께 확인해 요청 경로를 판단할 수 있습니다. 먼저 방금 보낸 요청이 무엇인지 확인한 뒤 해당 기록을 찾으세요. 목록에는 백그라운드 작업이나 다른 앱의 통신도 함께 표시될 수 있습니다. 도메인과 주소가 반드시 일대일로 대응하는 것은 아닙니다. 일부 연결은 주소를 직접 사용하고 다른 요청은 이전에 저장된 해석 결과를 사용할 수 있습니다. 예상한 도메인이 보이지 않는다고 해서 대상이 네트워크 요청을 전혀 보내지 않았다고 단정하지 마세요.

기록의 정책 정보는 특히 Config를 확인하는 데 유용합니다. 구체적인 도메인 규칙, 주소 규칙, FINAL 중 무엇이 적용되었는지 확인한 다음 참조된 정책이 예상과 일치하는지 살펴보세요. DIRECT가 표시되면 요청이 해당 서버를 사용하지 않았을 수 있으므로 서버만 변경하지 마세요. REJECT가 표시되면 요청이 적극적으로 거부되었는지 먼저 확인하세요. 기록이 예상과 다르면 4장으로 돌아가 위에서부터 규칙 순서를 확인하고 현재 선택한 구성과 편집 중인 파일이 같은지도 점검하세요.

트래픽 수치는 '얼마나 관찰되었는지' 알려주고 요청 기록은 '이 요청이 어떻게 처리되었는지' 파악하는 데 도움이 됩니다. 두 정보를 함께 사용하되 실제 대상 서비스의 응답 확인을 대신할 수는 없습니다.

트래픽이 이상할 때는 차이를 관찰하기

트래픽이 크게 늘면 동영상 재생, 시스템 업데이트, 클라우드 동기화 등 대용량 작업을 먼저 멈추고 변화가 줄어드는지 확인하세요. 그런 다음 작업을 하나씩 다시 시작해 증가와 관련된 활동을 찾습니다. 서버 이름만 보고 트래픽 출처를 판단하지 말고 통계 증가만으로 인증 정보가 유출되었다고 결론 내리지도 마세요. 전면 작업을 멈춘 뒤에도 증가가 계속되면 백그라운드 앱 활동과 연결 기록을 확인해 범위를 좁히세요. 통계에 앞서 발생한 데이터가 포함되는 기간인지도 확인해야 합니다.

서비스 측 잔여 용량은 줄었는데 기기의 Data 수치는 거의 변하지 않았다면 자신의 다른 기기에서 같은 서비스를 사용하고 있는지, 양쪽 통계 기간이 같은지, 서비스 측 계산 기준이 다른지 확인하세요. 사실을 확인한 다음 기존 서비스의 지원 채널에 문의해 측정 방식을 알아보세요. 클라이언트만으로 서비스 측의 모든 차감 세부 내역을 확인하기는 어렵습니다. 기기의 통계를 반복해서 초기화해 계정 용량 문제를 해결하려 하지 마세요. 초기화는 기기에 표시되는 정보만 바꾸며 서비스 기록은 바꾸지 않습니다.

진단 정보를 공유하기 전에 필요한 만큼만 남기기

요청 기록에는 방문한 도메인과 경로, 기기의 네트워크 정보, 개인 식별 정보가 포함될 수 있습니다. 문제를 외부에 설명하기 전에 현재 문제와 관련된 내용만 남기고 전체 구독 주소, 비밀번호, 개인을 식별할 수 있는 매개변수는 가리세요. 스크린샷 배경에 민감한 항목이 표시되지 않는지도 확인하세요. 필요 없는 기록은 앱에서 제공하는 기능으로 관리하세요. 보관 기간은 문제 해결에 필요한 범위로 정하면 되며 모든 기록을 장기간 쌓아 둘 필요는 없습니다. 일상적인 관리를 위해서는 재현 조건, 주요 오류, 효과가 확인된 해결 방법만 보관하면 됩니다.

이 단계의 목표는 숫자를 계속 지켜보는 것이 아니라 판단 기준을 익히는 것입니다. 통계가 어떤 범위를 다루는지 파악하고 실패한 요청을 찾으며 기기에서 관찰한 정보와 서비스 계정 정보를 구분할 수 있어야 합니다. 이 기준을 알면 Settings에서 실제 문제와 관련된 항목만 조정해 근거 없는 시도를 줄일 수 있습니다.

앱 업데이트와 구독 업데이트를 별도로 관리하기

앱 업데이트는 App Store에서 진행하며 주로 클라이언트 자체를 변경합니다. 구독 업데이트는 사용자가 이미 이용 중인 서비스에서 서버 목록을 다시 가져오는 작업으로, 둘은 서로 다릅니다. 구독 업데이트에 성공했다고 앱이 업데이트된 것은 아니며 앱 업데이트로 서비스 정보가 계속 유효해지는 것도 아닙니다. 일상적으로 App Store의 앱 상태와 자신의 구독 상태를 따로 확인하세요. 확인되지 않은 버전 정보를 쫓을 필요는 없습니다. 문제를 해결하는 중이라면 업데이트 전에 현재 증상을 재현하는 조건을 기록해 업데이트 전후를 비교할 수 있도록 하세요.

구독 새로 고침은 기존 서비스 안내와 실제 필요에 따르세요. 요청이 한 번 느렸다고 연속으로 새로 고칠 필요는 없습니다. 새로 고친 뒤 현재 선택한 항목이 남아 있는지, 이름이 바뀌었는지, 규칙의 정책 참조에 영향이 있는지 확인하세요. 목록 업데이트에 실패해도 기존 항목이 계속 사용 가능하다면 먼저 현재 상태를 유지하고 가져오기 과정을 점검하세요. 정상 사용과 유지 관리 작업을 구분하면 연결이 필요할 때 한 번의 정리 작업으로 사용 가능한 정보를 모두 잃는 일을 방지할 수 있습니다.

앱뿐 아니라 정보를 백업하기

앱 구매 내역, 서버 정보, 구독 링크, 규칙 구성은 각각 별도로 관리해야 합니다. App Store에서 앱을 다시 받을 수 있다고 로컬 콘텐츠 전체가 자동으로 복구되는 것은 아닙니다. 기기 백업에서 복구할 수 있는 범위도 실제 복구 결과로 확인해야 합니다. 기기를 옮기기 전에 앱의 내보내기 또는 백업 기능을 살펴보고 필요한 구성이 백업 범위에 포함되는지 확인하세요. 직접 입력한 항목은 원본 정보를 보관하는 것이 특히 중요합니다. 표시 이름만으로는 연결을 다시 설정할 수 없습니다.

백업에는 비밀번호, 구독 인증 정보 또는 다른 접속 매개변수가 포함될 수 있으므로 직접 관리하는 보호된 위치에 보관하세요. 전체 구성을 공개 메모, 공개 폴더, 문제 상담 게시물에 올리지 마세요. 백업에 용도와 구성 이름을 표시하고 사용이 검증된 버전을 하나 보관하는 것이 좋습니다. 규칙을 크게 변경하기 전에 기존 내용을 내보내세요. 백업의 유효성은 파일이 존재하는지가 아니라 필요한 정보를 읽고 복원할 수 있는지에 달려 있으므로 적절한 시점에 포함 범위를 확인해야 합니다.

기기 변경 후 의존 순서에 따라 복원하기

새 기기의 App Store에서 기존 구매 내역과 제품 정보를 확인한 뒤 스토어 조건에 따라 앱을 받으세요. 시스템 요구 사항, 공통 구매, 가족 공유 적용 여부는 모두 App Store 페이지를 기준으로 확인해야 합니다. 이어서 자신이 보유한 서버 또는 구독 정보를 복원하고 규칙 구성을 복원한 다음 시스템 VPN 구성 권한을 다시 확인하세요. 새 기기에서는 권한 안내를 별도로 따라야 할 수 있습니다. 기존 기기에서 이미 권한을 허용했다는 이유로 이 단계를 건너뛰지 마세요. 구매 복구 확인 방법은 구매 항목 복원 안내에서 확인할 수 있습니다.

복원 직후 모든 자동 트리거와 고급 옵션을 바로 켜지 마세요. 먼저 이미 알고 있는 항목 하나를 수동으로 선택해 연결과 자주 사용하는 대상을 확인하세요. Config에서 규칙 분기가 정상 작동하는 것을 확인한 다음 On Demand를 복원하세요. 기기 이름, Wi-Fi 환경, 시스템 설정, 앱 권한은 이전 기기와 다를 수 있으므로 같은 구성이더라도 트리거 조건이 똑같이 작동한다고 보장할 수 없습니다. 이전 과정에서 문제가 발생하면 전체 작업을 처음부터 반복하기보다 최근에 검증한 단계로 돌아가세요.

정해진 순서로 문제 복구하기

일상적인 문제는 네 단계로 확인할 수 있습니다. 기본 네트워크 확인, 현재 선택 항목 확인, 최근 변경 사항 점검, 검증된 기준으로 복구입니다. 첫 단계에서는 Wi-Fi 인증과 네트워크 연결 여부를 확인하고, 두 번째 단계에서는 서버, 구성, Global Routing을 확인합니다. 세 번째 단계에서는 최근 구독 업데이트, 규칙 수정, 자동 트리거 설정 여부를 살펴보세요. 네 번째 단계에서는 관련 변경 사항만 되돌립니다. 이렇게 하면 확인 근거를 유지하고 관계없는 조작을 줄일 수 있습니다. 특정 항목이 손상되었다고 확실히 알고 복구 자료도 있을 때만 삭제 후 재구성을 고려하세요.

특정 네트워크에서만 문제가 발생하면 구성을 그대로 유지한 채 자신이 사용할 수 있는 다른 네트워크에서 비교하세요. 서버 하나만 이상하면 다른 항목은 유지하고 해당 서버의 매개변수를 확인하세요. 대상 하나만 실패하면 요청 기록과 관련 규칙을 점검하세요. 서비스 이용 자격이나 한도 문제는 기존 서비스 지원 채널에 문의하고, 구매 내역 문제는 App Store 계정 기록에서 확인하세요. 해당 문제를 담당하는 항목에서 해결해야 하며 계정 관련 문제를 앱 설정으로 해결하려 하지 마세요.

복구 기준에는 사용 가능한 서버의 출처, 구성 이름, Global Routing 방식, 필요한 설정, 마지막으로 성공한 확인 작업이 포함되어야 합니다. 인증 정보는 별도로 보호하고 공개 문제 해결 기록에는 적지 마세요.

반복해서 시행착오를 겪는 대신 간단히 기록하기

유지 관리 기록에는 변경한 내용, 변경 이유, 비교에 사용한 조건, 효과 여부, 복구 방법만 간단히 적으면 됩니다. 검증되지 않은 추측을 고정된 규칙처럼 기록하지 말고 한 번 잠시 성공했다고 기존 백업을 삭제하지 마세요. 중복 항목과 불필요한 기록을 정기적으로 정리할 때는 먼저 현재 의존 관계를 확인하세요. 특히 구독으로 생성된 항목과 직접 추가한 항목을 구분해야 합니다. 정리의 목적은 혼란을 줄이는 것이지 목록을 무조건 짧게 만드는 것이 아닙니다.

전체 사용 흐름을 정리하면 다음과 같습니다. App Store에서 제품과 구매를 확인하고, 시스템 권한으로 연결을 허용하며, 기존 정보로 서버를 설정합니다. Global Routing이 처리 방식을 결정하고 실제 접속으로 결과를 확인합니다. Data와 기록은 판단 근거를 제공하고 Settings는 구체적인 요구를 해결하며 유지 관리 절차는 복구를 돕습니다. 간단한 작업 순서를 다시 따라 하려면 시작 가이드를 이용하세요. 특정 원리를 확인하려면 이 페이지의 목차에서 해당 장으로 이동하면 됩니다. 정상 작동 중인 항목을 처음부터 다시 설정할 필요는 없습니다.