Shadowrocket 문제 해결 가이드

01 · 시스템 권한 및 연결 상태

연결 스위치가 켜지지 않거나 켜진 직후 꺼짐

먼저 스위치가 어느 단계에서 실패하는지 확인하세요. 눌러도 아무 반응이 없는지, 시스템 권한 요청이 표시된 뒤 완료되지 않는지, 잠깐 연결된 후 바로 끊기는지 살펴봅니다. 각각 점검해야 할 항목이 다릅니다. 스위치는 시스템 네트워크 확장이 시작되는 과정이며, 서버가 트래픽을 정상적으로 전달한다는 뜻은 아닙니다. 연결이 안정적으로 유지되어야 서버 테스트와 웹페이지 확인도 의미가 있습니다. 수동으로 상태를 확인하는 동안에는 On Demand를 잠시 꺼 자동 연결이 관찰을 방해하지 않도록 하세요.

시스템 권한을 승인한 다음 구성을 확인하세요

처음 켤 때 시스템에서 VPN 구성을 추가하도록 허용할지 물을 수 있습니다. 방금 실행한 앱이 Shadowrocket인지 확인한 뒤 시스템 안내에 따라 권한을 승인하고 기기 인증을 완료하세요. 이전에 요청 창을 취소했다면 앱으로 돌아와 다시 켜고 요청이 표시되는지 확인하세요. 학교나 회사에서 관리하는 기기는 관리 정책에 따라 권한이 제한될 수 있습니다. 이런 제한은 서버 매개변수 변경으로 해결할 수 없으므로, 해당 기기에서 네트워크 구성을 추가하고 실행할 수 있는지 먼저 확인해야 합니다.

시스템 Settings에서 VPN 관련 설정을 찾아 Shadowrocket 구성이 있는지, 다른 네트워크 연결이 활성화되어 있는지 확인하세요. 다른 연결을 먼저 끈 다음 Shadowrocket으로 돌아가 다시 시도해 네트워크 구성 요소를 동시에 바꾸지 않도록 합니다. 상태 막대에 표시가 있는지만으로 성공 여부를 판단하지 마세요. 기기와 화면 상태에 따라 일부 표시가 숨겨질 수 있으므로 앱의 연결 상태와 시스템 VPN 페이지를 함께 확인해야 합니다.

구성 로드 오류와 서버 통신 오류 구분

시스템 권한을 승인했는데도 스위치가 바로 꺼진다면 Config에서 현재 선택한 구성을 정상적으로 열 수 있는지 확인하세요. 특히 직접 수정한 필드, 완료되지 않은 구성 가져오기, 참조 대상인 정책 이름이 남아 있는지 살펴보세요. 새 설정을 계속 추가하기보다 변경 전에 저장한 사본으로 먼저 복원하세요. 복원 후 연결이 유지된다면 구성 간 차이가 우선 점검 대상입니다. 곧바로 앱을 삭제하거나 서버 정보를 전부 다시 만들 필요는 없습니다.

Home에 사용할 수 있는 서버 정보가 있고, 프록시가 필요한 설정에서 대상 서버를 선택했는지도 확인하세요. 서버 목록이 비어 있거나 그룹 설정의 참조가 끊겼거나 구성이 삭제된 이름을 가리키면 연결 결과가 예상과 다를 수 있습니다. 매개변수를 직접 확인한 기존 서버 하나를 선택해 최소한으로 테스트할 수 있습니다. 여기서 최소한이란 구성 간 의존성을 줄인다는 뜻이지, 인증서 검증을 끄거나 모든 트래픽에 영구적으로 같은 정책을 적용하라는 뜻은 아닙니다.

복구 가능한 순서로 시스템 조치

먼저 연결을 정상적으로 끄고 현재 편집 화면에서 나간 다음 앱을 다시 열어 시도하세요. 그래도 실패하면 기기를 재시동해 시스템 네트워크 확장을 다시 초기화합니다. 재시동하기 전에 저장하지 않은 구성 변경 사항을 보관하세요. 네트워크를 전환한 뒤에만 문제가 생긴다면 안정적인 Wi-Fi에서 먼저 확인한 뒤 셀룰러 네트워크 권한을 따로 점검하세요. 기기의 저장 공간이 부족하면 필요한 공간을 확보해 구성 저장과 진단 기록 작성이 막히지 않도록 하되, 확인 없이 구성 파일을 삭제하지 마세요.

구성을 백업했고 서버 정보를 다시 가져올 수 있으며 시스템 구성이 실제로 손상된 것으로 확인된 경우에만 시스템에서 해당 VPN 구성을 제거한 뒤 앱에서 다시 만들도록 하세요. 작업 전에 On Demand를 끄고 연결을 중단해 자동 실행이 삭제 절차를 방해하지 않도록 합니다. 네트워크 설정 재설정을 첫 조치로 삼지 마세요. 다른 네트워크 기록에도 영향을 주며 매개변수 오류를 해결하지 못할 수 있습니다. 권한을 다시 승인한 뒤 스위치가 안정적으로 켜지는지 먼저 확인하고 다음 장에서 실제 통신을 테스트하세요.

02 · 기본 네트워크, 라우팅 설정 및 규칙

연결됨으로 표시되지만 웹페이지나 앱에서 인터넷을 사용할 수 없음

먼저 Shadowrocket을 끄고 평소 바로 열리는 웹페이지에 접속해 기기 자체가 인터넷에 연결되어 있는지 확인하세요. 공용 Wi-Fi는 먼저 네트워크 로그인이 필요할 수 있고, 라우터가 로컬 네트워크에만 연결되어 외부 인터넷은 사용할 수 없는 경우도 있습니다. 기본 네트워크가 복구되지 않은 상태에서는 프록시 매개변수를 바꿔도 문제가 해결되지 않습니다. 로그인하거나 네트워크 문제를 해결한 다음 Shadowrocket을 켜고 같은 웹페이지로 다시 테스트하세요. 테스트 대상과 시간을 최대한 비슷하게 유지합니다.

Global Routing으로 문제 범위 좁히기

Global Routing의 Config, Proxy, Direct는 문제 진단에 유용한 구분 기준입니다. Config는 현재 구성의 규칙에 따라 정책을 선택하고, Proxy는 현재 프록시 경로를 확인하며, Direct는 직접 연결 결과를 확인합니다. 이는 네트워크 품질 등급이 아니며 모든 대상에 접속할 수 있다는 보장도 아닙니다. 테스트 전에 기존 설정을 기록하고 한 번에 항목 하나만 바꾸세요. 어떤 경로를 확인하는지 명확히 한 뒤 테스트가 끝나면 원래 설정으로 복원하세요.

Direct에서는 테스트 웹페이지에 접속되지만 Proxy에서 실패한다면 전체 규칙을 바로 바꾸지 말고 선택한 서버부터 확인하세요. Proxy는 정상인데 Config에서 실패한다면 해당 대상이 Config에서 어떤 정책과 일치하는지 살펴보세요. 먼저 일치한 REJECT 규칙이 원인일 수도 있고, 프록시가 필요한 대상이 DIRECT로 전달되었을 수도 있습니다. 세 설정 모두 문제가 있다면 기본 네트워크, DNS, 시스템 연결을 다시 확인하세요. 웹페이지 테스트 한 번만으로 구독을 사용할 수 없다고 결론 내리면 안 됩니다.

규칙 순서와 실제 대상 확인

규칙은 일반적으로 순서대로 적용되므로 앞쪽의 포괄적인 규칙이 뒤쪽의 구체적인 규칙보다 먼저 적용될 수 있습니다. 아래 예시는 구체적인 조건을 먼저 일치시키고 마지막에 FINAL을 사용하는 구조를 보여주기 위한 것으로, 기존 구성을 그대로 덮어쓰라는 뜻이 아닙니다. PROXY가 현재 구성에서 사용할 수 있는 정책을 참조해야 합니다. 기존 구성이 다른 정책 이름을 사용한다면 실제 정의를 확인하세요. 사본에서 먼저 편집하고 기록을 통해 일치 결과를 확인해, 파일에 적힌 내용만 보고 동작 경로를 추측하지 않도록 하세요.

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

웹페이지는 보통 하나의 도메인만 요청하지 않습니다. 페이지 본문, 이미지, 로그인 API, 미디어 콘텐츠가 각각 다른 대상에 연결될 수 있으므로 ‘홈페이지는 열리지만 로그인이 실패하는’ 현상도 라우팅이 일치하지 않는 문제일 수 있습니다. 실패 당시 연결 기록에서 실제로 실패한 도메인과 적용된 정책을 찾아 규칙 변경이 필요한지 판단하세요. 편의를 위해 관련 없는 도메인까지 모두 같은 정책으로 바꾸지 말고, 페이지 제목만으로 모든 요청이 같은 주소를 사용한다고 추측하지 마세요.

앱 세션과 로컬 네트워크의 영향 확인

라우팅 설정을 바꾼 뒤에도 기존 장기 연결은 이전 세션을 계속 사용할 수 있습니다. 테스트 앱의 관련 페이지에서 나와 요청을 새로 시작하세요. 필요하다면 연결을 정상적으로 끊었다가 다시 켠 뒤 결과를 비교합니다. 특정 앱에서만 문제가 생긴다면 같은 서비스에 브라우저로 접속해 앱 캐시, 로그인 상태, 네트워크 경로를 구분하세요. 한 서비스의 점검, 인증 실패, 접근 제한도 로딩이 멈춘 것처럼 보일 수 있습니다. 다른 웹페이지가 정상이라는 이유만으로 규칙에 문제가 없다고 단정하지 마세요.

라우터 관리 페이지, 로컬 네트워크 기기, 가정용 저장 장치에 접속할 때는 로컬 네트워크 대역이 잘못 프록시로 전달되지 않는지 확인하세요. 예시의 네트워크 대역을 그대로 사용하지 말고 현재 네트워크의 주소 할당을 기준으로 판단합니다. 연결 기록상 규칙은 올바른데 도메인이 계속 조회되지 않으면 DNS 장으로 이동하세요. 도메인이 주소로 변환되었지만 서버 경로가 설정되지 않으면 서버 연결 시간 초과 장으로 이동합니다. 이런 분기 기준을 따르면 규칙, 구독, 시스템 설정을 반복해서 바꾸는 일을 줄일 수 있습니다.

03 · 서버 주소, 인증 및 전송

서버 연결 시간 초과 또는 Connectivity Test 실패

시간 초과는 정해진 시간 안에 테스트가 완료되지 않았다는 뜻일 뿐, 어느 필드가 잘못되었는지는 알려주지 않습니다. 먼저 테스트 종류를 확인하세요. 포트 연결, 프록시를 통한 웹 요청, DNS 조회, 앱 내 Connectivity Test는 서로 다른 계층을 검사합니다. 포트 연결에 성공해도 인증이나 데이터 전달이 정상이라는 뜻은 아닙니다. 웹 테스트가 실패한 이유가 테스트 대상의 일시적인 접속 불가일 수도 있습니다. 테스트를 반복해서 누르기보다 대상과 오류 내용을 기록하는 편이 원인을 찾는 데 도움이 됩니다.

서버 주소와 포트부터 확인

해당 서버 정보를 열고 서비스 제공자가 안내한 내용과 Address, Port를 대조하세요. Address에는 보통 호스트 이름이나 주소를 입력합니다. 전체 웹 주소, 경로, 불필요한 공백을 함께 붙여 넣지 마세요. Port는 서버에서 실제로 수신하는 포트와 일치해야 하며 프로토콜 이름만 보고 추측하면 안 됩니다. 주소가 도메인이라면 먼저 이름 조회가 성공하는지 확인하세요. 조회부터 되지 않는다면 Password나 전송 설정을 계속 바꾸는 것은 의미가 없습니다.

그다음 프로토콜 유형과 인증 필드를 확인하세요. Trojan의 Password, VMess 또는 VLESS의 ID 필드, Shadowsocks의 암호화 방식과 비밀번호는 서로 다른 역할을 하므로 다른 프로토콜의 값을 그대로 적용할 수 없습니다. 가져오기에 성공했다는 것은 텍스트를 인식했다는 뜻이지 원격 서버 매개변수가 검증되었다는 뜻은 아닙니다. 직접 입력했다면 줄바꿈, 앞뒤 공백, 전각 문자가 섞이지 않았는지 특히 확인하세요. 수정한 뒤 저장하고 해당 항목을 다시 선택해 방금 편집한 서버를 실제로 테스트하는지 확인합니다.

TLS와 전송 매개변수를 따로 확인

TLS를 사용하는 경우 Address와 SNI는 서로 다를 수 있습니다. 전자는 연결할 엔드포인트를 지정하고, 후자는 서버 이름 표시와 인증서 검증에 사용됩니다. 기존 서버의 실제 설정에 맞춰 입력하고 임의의 도메인을 SNI에 넣지 마세요. 시스템 날짜, 시간, 시간대가 올바른지도 확인하세요. 시간 차이로 인증서 검증에 실패할 수 있습니다. 인증서 이름 불일치 또는 만료 메시지가 표시되면 원격 서버의 배포 상태를 확인하고 검증 무시 설정을 장기적인 해결책으로 사용하지 마세요.

서버에서 추가 전송 계층을 요구한다면 해당 Host, Path, 전송 유형도 확인해야 합니다. Path의 첫 슬래시, 대소문자, 추가 내용이 라우팅에 영향을 줄 수 있으므로 대략 비슷한지만 확인하면 안 됩니다. Hysteria2처럼 UDP를 사용하는 연결은 현재 네트워크에서 해당 트래픽을 허용하는지도 고려해야 합니다. TCP 웹페이지에 접속된다고 UDP 경로도 정상인 것은 아닙니다. 여러 프로토콜 필드를 한꺼번에 바꾸기보다 사용할 권한이 있는 다른 네트워크에서 비교하는 편이 원인을 파악하기 쉽습니다.

교차 테스트로 로컬 문제와 원격 문제 구분

같은 서버 정보를 유지한 채 Wi-Fi와 셀룰러 네트워크에서 각각 테스트하세요. 이어서 같은 네트워크에서 이미 보유하고 있고 사용 가능하다고 확인한 다른 서버도 테스트합니다. 첫 번째 비교는 네트워크 차이를, 두 번째 비교는 특정 엔드포인트 문제를 파악하는 데 도움이 됩니다. 네트워크, 서버, 구성을 동시에 바꾸지 마세요. 문제가 해결되어도 원인을 알 수 없습니다. 같은 엔드포인트가 여러 네트워크에서 실패하고 다른 기존 엔드포인트는 정상이라면 원래 서비스 제공자에게 엔드포인트 상태와 매개변수 변경 여부를 확인하세요.

서비스 제공자에게 문의할 때는 민감 정보를 제거한 오류 유형, 네트워크 환경, 테스트 시간만 전달하세요. 인증 정보를 통째로 공개하지 마세요. 포트 연결은 성공하지만 실제 웹 요청이 실패한다면 인증, 전송, 대상 응답을 추가로 확인하세요. 모든 기존 엔드포인트가 특정 네트워크에서만 실패한다면 해당 네트워크와 라우터부터 점검하세요. Trojan 필드의 의미는 Trojan 매개변수 안내에서 확인할 수 있습니다. 값을 임의로 넣어보는 대신 안내된 매개변수와 대조하세요.

04 · 콘텐츠 가져오기, 조회 및 로컬 목록

구독을 업데이트할 수 없거나 가져온 뒤 서버가 표시되지 않음

구독 업데이트에는 구독 주소 연결, 응답 수신, 콘텐츠 식별, 항목 파싱, 로컬 목록 갱신 등 여러 단계가 있습니다. 목록이 비어 있다고 해서 주소에 연결하지 못했다는 뜻은 아닙니다. 서버에서 로그인 페이지, 오류 안내 또는 현재 가져오기 화면에서 인식할 수 없는 콘텐츠를 반환했을 수도 있습니다. 먼저 업데이트 중 표시된 오류를 기록한 뒤 주소와 응답 단계를 확인하세요. 기존 목록을 계속 삭제하지 마세요. 이전 항목은 여전히 사용할 수 있을 뿐 아니라 업데이트 전후의 차이를 판단하는 중요한 기준입니다.

구독 주소와 단일 서버 공유 링크 구분

본인의 서비스 제공자에게 전체 구독 주소를 확인하고, 복사 과정에서 쿼리 매개변수, 끝부분 문자, 필요한 인증 정보가 빠지지 않았는지 살펴보세요. 구독 주소와 단일 서버 공유 링크는 용도가 다릅니다. 전자는 보통 갱신 가능한 여러 항목을 가져오고, 후자는 하나의 연결 정보를 나타냅니다. 단일 서버 내용을 구독 업데이트 화면에 넣거나 구성 파일 주소를 서버 구독으로 사용하면 인식에 실패할 수 있습니다. 주소가 길어 보인다는 이유만으로 구독이라고 판단하지 말고 콘텐츠 유형에 맞는 가져오기 화면을 선택하세요.

복사한 내용에 설명 문구, 따옴표, 공백, 줄바꿈이 들어갔는지도 확인하세요. 일부 공유 기능은 제목과 주소를 함께 복사하므로 실제 주소만 남겨야 합니다. 구독의 인증 정보는 민감하므로 공개 링크 검사 페이지에 붙여 넣거나 다른 사람에게 테스트를 부탁하며 토론 공간에 올리지 마세요. 문제를 설명할 때는 오류 유형을 알리고 주소에서 식별 정보를 모두 제거하세요. 몇 글자만 가리는 것으로는 부족합니다.

요청 실패와 잘못된 응답 구분

호스트 조회, 연결 시간 초과, TLS 관련 오류라면 구독 도메인의 조회와 요청 경로부터 확인하세요. 구독 업데이트가 프록시를 통과하는지는 설정과 구성에 따라 달라질 수 있으므로 웹페이지가 열린다고 업데이트 요청도 같은 경로를 사용한다고 단정할 수 없습니다. 현재 서버를 사용할 수 없고 구독 요청도 그 서버에 의존한다면 업데이트 실패가 반복되는 상황이 생길 수 있습니다. 허용되고 사용 가능한 네트워크에서 요청을 확인하고 기존 구성을 보존하세요. ‘서버 변경’과 ‘구독 다시 가져오기’를 하나의 작업으로 섞지 마세요.

접근 거부 또는 리소스 없음 오류가 표시되면 서비스 제공자가 주소를 변경했는지, 인증이 만료되었는지, 계정에서 읽기가 허용되는지 먼저 확인하세요. 리디렉션이 발생했다면 최종 응답이 실제 구독 콘텐츠인지, 로그인이 필요한 웹페이지인지 살펴보세요. 브라우저에 페이지가 정상 표시되어도 오류 안내일 수 있습니다. 반대로 브라우저에서 텍스트를 내려받거나 표시할 수 있어도 각 서버 항목을 현재 가져오기 화면에서 제대로 인식한다는 뜻은 아닙니다.

목록이 비어 있을 때 필터, 파싱, 덮어쓰기 확인

콘텐츠를 받았는데도 항목이 보이지 않는다면 먼저 Home의 검색 조건을 지우고 해당 그룹을 펼친 다음 방금 업데이트한 구독을 보고 있는지 확인하세요. 업데이트 전후의 항목 수와 이름을 비교해 전체가 파싱되지 않았는지, 특정 프로토콜이나 필드만 인식되지 않았는지 살펴봅니다. 구독 자체에 필터 조건이 있다면 모든 항목이 제외되지 않았는지 확인하세요. 비어 있는 그룹 하나만 보고 같은 주소를 반복해서 가져오지 마세요. 알아보기 어려운 중복 항목이 생길 수 있습니다.

구독 업데이트 과정에서 관리 대상 서버 항목이 다시 생성될 수 있으므로 직접 수정한 내용은 다음 업데이트 때 덮어써질 수 있습니다. 계속 유지해야 하는 변경 사항은 관리 방식을 먼저 확인하고 사본을 보관하세요. 콘텐츠 문제와 네트워크 문제를 구분하려면 본인이 보유한 완전한 서버 정보를 직접 추가해 테스트할 수 있습니다. 직접 추가한 항목은 정상인데 같은 출처의 구독을 계속 파싱하지 못한다면 구독 형식과 응답 콘텐츠를 확인해야 합니다. 시스템 VPN 권한을 반복해서 바꿀 필요는 없습니다.

가져오기 방법을 다시 확인하려면 구독 및 단일 서버 가져오기 방법을 읽어보세요. 콘텐츠 유형이 확실하지 않다면 공유 링크 형식 안내를 참고하세요. 복구 후 업데이트가 한 번 성공한 결과를 확인하고 적절한 업데이트 주기를 설정하세요. 잦은 재시도로 지속적인 요청 오류를 감추지 말고, 업데이트 버튼을 서버 연결 테스트로 사용하지 마세요.

05 · 응답 대기와 지속 전송

연결은 되지만 페이지가 느리게 열리거나 전송이 불안정함

‘느림’은 먼저 첫 응답 대기, 웹페이지 리소스 로딩, 지속적인 데이터 전송의 세 단계로 나눠 살펴보세요. 누른 뒤 오랫동안 응답이 없으면 이름 조회, 연결 설정, 핸드셰이크가 원인일 수 있습니다. 페이지의 텍스트는 나타났지만 이미지가 늦게 표시된다면 여러 대상에 연결하는 경로가 서로 다를 수 있습니다. 처음에는 정상인데 전송이 이어질수록 느려진다면 혼잡, 패킷 손실, 서버 부하도 고려해야 합니다. 단일 지연 시간 숫자만 보는 것보다 어느 단계에서 느려지는지 파악하는 편이 진단에 유용합니다.

같은 조건에서 비교 테스트

안정적으로 재현할 수 있는 대상을 하나 선택해 비슷한 시간대, 동일한 네트워크, 기기, 서버에서 두세 번 반복하면 충분합니다. 테스트 중에는 시스템의 대용량 파일 동기화, 다른 기기의 대량 전송, 관련 없는 백그라운드 작업을 중지하세요. 웹페이지 콘텐츠 자체도 바뀔 수 있으므로 같은 페이지와 작업을 사용하도록 합니다. 대용량 테스트를 여러 개 동시에 실행하면 같은 연결을 서로 나눠 쓰게 됩니다. 그 결과 평소 속도가 아니라 서로 간섭한 상태를 측정하게 됩니다.

그런 다음 Wi-Fi와 셀룰러 네트워크를 비교하거나 본인이 보유한 다른 서버와 비교하세요. 매번 조건 하나만 바꿉니다. 모든 서버가 특정 Wi-Fi에서만 느리다면 라우터, 무선 신호, 네트워크 부하를 확인하세요. 서버 하나만 느리다면 해당 엔드포인트와 대상까지의 경로를 우선 살펴보세요. 특정 대상만 느릴 때는 대상 서비스의 응답과 리소스 배포도 고려해야 합니다. 이를 클라이언트 전체의 성능 문제로 바로 결론 내리지 마세요.

지연 시간, 대역폭, 실제 사용감은 서로 다른 지표

지연 시간이 짧으면 상호작용이나 짧은 요청에 유리할 수 있지만 지속적인 다운로드가 반드시 빨라지는 것은 아닙니다. 지연 시간이 길다고 대역폭이 부족한 것도 아닙니다. 앱 내 테스트 결과도 테스트 주소, 요청 유형, 시간 초과 기준에 영향을 받습니다. 사용 가능 여부는 실제 작업을 기준으로 판단하세요. 로그인이 완료되는지, 동영상이 계속 버퍼링되는지, 파일 전송이 중단되는지 확인합니다. 한 번의 테스트 결과만으로 서버를 자주 바꾸지 마세요. 서버 변경은 일부 세션을 종료하고 새 핸드셰이크 비용을 발생시킵니다.

Global Routing 설정도 결과에 영향을 줍니다. Config에서는 일부 리소스만 프록시를 통과할 수 있지만 Proxy에서는 더 많은 요청이 선택한 경로로 전달됩니다. 두 결과를 비교할 때 설정을 기록하지 않으면 엄밀한 비교가 아닙니다. 연결 기록에서 반복해서 실패하는 리소스, 특히 로그인 API, 미디어 조각, DNS 요청을 살펴보세요. 특정 요청이 계속 재시도되면 페이지 전체가 느려 보일 수 있지만 실제로는 규칙 하나나 접속할 수 없는 도메인만 해결하면 될 수도 있습니다.

연결 경로에 따라 처리하고 매개변수를 무작정 바꾸지 마세요

Wi-Fi 신호가 약하거나 기기가 여러 액세스 포인트 사이를 자주 전환하면 전송 속도가 떨어지고 연결이 다시 설정될 수 있습니다. 먼저 액세스 포인트 가까이에서 테스트하고 기기가 여러 네트워크 사이를 자동으로 전환하지 않는지 확인하세요. 현재 네트워크에 로그인이 필요하다면 로그인 세션 만료로 백그라운드 연결이 반복해서 실패할 수도 있습니다. UDP를 사용하는 프로토콜은 현재 네트워크에 명확한 제한이나 패킷 손실이 있는지 따로 비교하세요. 다른 프로토콜이 작동한다고 해서 모든 트래픽의 조건이 같다는 뜻은 아닙니다.

근거 없이 MTU, 동시 연결 수, 프로토콜 고급 매개변수를 변경하지 마세요. MTU 불일치가 전송에 영향을 줄 수는 있지만 비슷한 증상은 대상 서비스, 무선 연결, 원격 서버 혼잡에서도 생길 수 있습니다. 문제가 안정적으로 재현되고 명확한 배포 요구 사항이 있을 때만 원래 값을 저장한 뒤 항목별로 변경해 비교하세요. 변경 후 안정적인 개선이 없다면 원래 값으로 복구하세요. 여러 설정이 서로의 영향을 가려 다음 문제 해결을 더 어렵게 만들 수 있습니다.

마지막으로 기기 온도, 배터리 상태, 로컬 저장 공간을 확인하세요. 장시간 전송, 화면 녹화, 기타 연산 작업을 동시에 수행하면 기기 전체의 성능이 달라질 수 있습니다. 관련 없는 작업을 중단하고 기기가 정상 상태로 돌아온 뒤 같은 작업을 다시 테스트하세요. 처음 열 때만 느리고 이후에는 정상이라면 DNS 캐시와 연결 재사용을 확인할 수 있습니다. 지속적인 전송만 불안정하다면 네트워크 변동, 원격 서버 상태, 세션 중단 기록을 중점적으로 살펴보세요.

06 · 이름 조회와 연결 경로

DNS 조회 실패 또는 일부 도메인만 열리지 않음

DNS는 도메인을 연결에 필요한 주소로 변환합니다. ‘어느 서버에 연결하는지’, ‘어떤 라우팅 정책을 사용하는지’와 연관되어 있지만 같은 단계는 아닙니다. 도메인 조회에 실패하면 요청이 대상 연결 단계에 도달하기도 전에 중단될 수 있습니다. 주소를 얻었더라도 라우팅, 포트, 대상 응답 문제로 실패할 수 있습니다. 기록에서 오류가 DNS 조회, 연결 설정, TLS 중 어느 단계에 해당하는지 먼저 확인하세요. 모든 웹페이지 접속 실패를 DNS 탓으로 돌리지 말고, 조회 결과가 있다는 이유만으로 DNS 관련 차이를 배제하지도 마세요.

서버 도메인과 대상 도메인을 각각 확인

최소한 세 가지 도메인을 구분하세요. 프록시 서버 도메인, 구독 주소 도메인, 접속하려는 웹사이트 도메인입니다. 프록시 서버 도메인을 조회할 수 없으면 연결 자체가 설정되지 않을 수 있습니다. 구독 도메인 조회 실패는 업데이트에 영향을 주지만 기존 서버 항목에는 영향이 없을 수도 있습니다. 대상 도메인 조회 실패는 일부 서비스만 사용할 수 없는 것처럼 보일 수 있습니다. 세 요청은 서로 다른 설정과 경로를 사용할 수 있으므로 구독이 업데이트된다는 이유만으로 모든 DNS 조회가 정상이라고 단정하지 마세요.

시스템 DNS는 현재 네트워크에서 제공하거나 기기에 지정된 조회 설정을 사용합니다. 사용자 지정 DNS는 구성에 설정된 조회 엔드포인트를 사용하고 DNS over HTTPS는 HTTPS로 조회를 전송합니다. 암호화 전송은 조회 경로를 바꾸지만 엔드포인트에 연결할 수 있다고 보장하지 않으며 현재 네트워크에 적합하다는 뜻도 아닙니다. DNS over HTTPS 엔드포인트가 도메인 이름을 사용한다면 초기 조회를 어떻게 하는지도 고려해야 합니다. 아직 설정되지 않은 의존 경로로 조회 요청이 되돌아가는 상황을 만들지 마세요.

기존 구성을 먼저 읽고 한 항목씩 교체

현재 적용 중인 구성을 열어 dns-server 등 관련 설정이 있는지 확인하고, 여러 위치에 이전 변경 사항이 남아 있는지도 살펴보세요. 아래 예시는 [General]과 규칙 섹션의 구성 방식만 보여줍니다. 여기서 system은 시스템 DNS를 사용한다는 뜻이지 모든 네트워크에 적용할 공통 권장 사항은 아닙니다. 기존 파일 끝에 그대로 붙여 넣어 같은 섹션을 중복 생성하지 마세요. 먼저 구성을 파악한 뒤 사본에서 해당 필드만 수정하세요.

[General]
dns-server = system

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

수정한 뒤 요청을 다시 실행하고 캐시의 영향을 확인하세요. 앱이 이전 조회 결과나 기존 연결을 보유할 수 있으므로 설정을 바꿔도 화면에 즉시 반영되지 않을 수 있습니다. 관련 페이지를 닫았다 다시 열고 필요하다면 Shadowrocket 연결을 정상적으로 끊었다가 다시 설정한 뒤 기록을 비교하세요. 조회 서버를 무작정 바꾸며 운에 맡기지 마세요. 해석 가능한 기준을 하나 유지하고, 각 변경이 조회 출처를 바꾼 것인지 요청 경로를 바꾼 것인지 확인하세요.

주소 계열, 로컬 네트워크, 라우팅 일관성 확인

하나의 도메인에서 IPv4와 IPv6 주소가 모두 반환될 수 있습니다. 현재 네트워크에서 특정 주소 계열의 연결이 불안정하면 접속이 되었다 안 되거나 한참 기다린 뒤 성공할 수 있습니다. 실패 기록에 표시된 실제 대상 주소를 살펴보고, 여러 주소가 반환되었다는 사실만으로 오류라고 판단하지 마세요. 원인을 모른 채 특정 주소 계열을 계속 끄지 마세요. 임시 비교를 위해 변경해야 한다면 기존 설정을 기록하고 테스트 후 복원한 뒤 서버와 네트워크가 해당 경로를 지원하는지 확인하세요.

로컬 네트워크 이름은 라우터나 특정 로컬 검색 방식에 의존할 수 있습니다. 원격 DNS로 바꾸면 가정 내 기기 이름을 조회하지 못할 수 있지만 올바른 로컬 주소로 직접 접속하면 작동할 수도 있습니다. 이런 경우 로컬 DNS 조회와 DIRECT 규칙이 서로 맞는지 확인하고 로컬 기기를 프록시로 보내지 마세요. 반대로 대상 조회에서 얻은 주소와 실제 연결 경로가 일치하지 않으면 접속 결과에 영향을 줄 수 있으므로 적용된 규칙과 조회 출처를 함께 확인해야 합니다.

도메인 하나만 실패한다면 먼저 서로 다른 네트워크에서 결과를 비교하고 대상의 도메인, 인증서, 서비스 주소가 변경되었는지 확인하세요. 한 번의 조회 결과만으로 콘텐츠 서비스 상태를 판단하지 마세요. 많은 도메인이 실패하지만 서버 엔드포인트에는 연결할 수 있다면 DNS 엔드포인트 연결 가능 여부와 구성 의존성을 중점적으로 살펴보세요. 필드별 설명은 DNS 설정 안내에서 확인할 수 있습니다. 수정 후에는 일반 웹페이지, 기존 실패 대상, 필요한 로컬 네트워크 리소스를 다시 테스트해 한 종류만 해결된 것은 아닌지 확인하세요.

07 · 백그라운드 작업과 반복 연결

배터리 소모 증가, 기기 발열 또는 백그라운드 활동 증가

먼저 배터리 사용량 화면에 네트워크 트래픽 처리가 Shadowrocket의 활동으로 기록된 경우와 기기에서 실제로 추가 배터리가 소모된 경우를 구분하세요. 네트워크 확장은 전달되는 트래픽을 계속 처리하므로 시스템 통계에서 관련 활동 일부가 앱 사용량에 포함될 수 있습니다. 그렇다고 모든 배터리 변화가 앱 설정 때문인 것은 아닙니다. 총 배터리 감소량, 실제 사용 작업, 화면 켜짐 시간, 네트워크 조건을 함께 비교하세요. 목록에서 특정 앱이 차지하는 비율만 보고 결론 내리지 마세요.

비슷한 작업으로 배터리 기준값 확인

일상에서 반복할 수 있는 사용 시간을 정해 네트워크, 화면 상태, 주요 작업을 기록하세요. 동영상 연속 재생, 파일 동기화, 대기 상태는 트래픽 양이 크게 다르므로 서로 직접 비교할 수 없습니다. 기기 온도, 충전 상태, 무선 신호도 배터리 소모에 영향을 줍니다. 셀룰러 신호가 약하면 통신 자체의 에너지 소모가 늘어날 수 있습니다. 신호가 안정되고 기기 온도가 정상인 환경에서 먼저 관찰한 다음 Shadowrocket 연결과 이상 현상이 동시에 나타나는지 확인하세요.

문제 해결을 시작하자마자 모든 기능을 끄지 마세요. 사진 동기화, 파일 전송, 다른 앱의 백그라운드 요청 등 대량 트래픽이 계속 발생하는지 먼저 확인하세요. 화면을 조작하지 않아도 이런 작업은 현재 연결을 통과할 수 있습니다. 테스트와 관련 없는 작업을 일시 중지하고 네트워크 활동이 줄어드는지 관찰하세요. 줄어든다면 트래픽 출처와 작업 일정을 확인해야 합니다. 데이터가 정상적으로 전달되는 것을 연결이 유휴 상태에서도 과도하게 배터리를 소모하는 것으로 오해하지 마세요.

실패 재시도와 자동 실행 반복 확인

기기를 거의 사용하지 않는데도 계속 뜨거워진다면 연결 기록에서 조회 반복, 잦은 핸드셰이크, 짧은 시간 안에 발생한 다수의 실패가 있는지 확인하세요. 사용할 수 없는 서버, 접속되지 않는 구독 주소, 반복해서 요청하는 앱 인터페이스가 추가 활동을 일으킬 수 있습니다. 가장 자주 실패하는 대상을 찾고 해당 문제를 먼저 해결하세요. 오류 기록을 영구적으로 숨겨 해결하려 하지 마세요. 기록이 줄어도 백그라운드 재시도가 멈춘다는 뜻은 아닙니다. 확인할 근거만 사라질 수 있습니다.

On Demand는 일상적인 네트워크 변경과 실행 조건이 충돌하는지 중점적으로 확인하세요. 기기가 Wi-Fi와 셀룰러 네트워크 사이를 전환하거나 네트워크 로그인 상태가 바뀌면 연결이 반복해서 시작될 수 있습니다. 현재 조건을 기록하고 자동 실행을 잠시 끈 다음 같은 작업을 수동 연결로 관찰하세요. 반복이 사라진다면 조건을 하나씩 다시 적용합니다. 자동 연결이 잦다는 이유만으로 기능이 오작동한다고 단정하지 마세요. 범위가 지나치게 넓거나 서로 번갈아 충족되는 조건을 그대로 실행하고 있을 수도 있습니다.

진단 기능을 유지하면서 불필요한 작업 줄이기

구독 업데이트 주기나 일괄 테스트가 지나치게 잦지 않은지 확인하세요. 자동 업데이트와 테스트에는 네트워크 비용이 발생하며, 페이지를 전환할 때마다 기존 콘텐츠를 다시 받을 필요는 없습니다. 사용 패턴에 맞게 업데이트를 예약하고 문제 해결 중에는 목록 전체를 연속 테스트하지 마세요. 서버 하나를 확인하려면 해당 항목만 테스트하면 됩니다. 진단이 끝나면 임시로 켠 상세 로그를 평소 필요한 수준으로 되돌리고 더 이상 필요하지 않은 진단 파일을 정리해 민감한 기록이 오래 남지 않도록 하세요.

연결 유지, 시간 초과, 프로토콜 관련 매개변수는 기존 서버의 요구 사항을 따르세요. 배터리를 아끼기 위해 극단적인 값으로 설정하는 것은 권장하지 않습니다. 시간 초과가 너무 짧으면 연결을 반복해서 설정하게 되고 유지 연결이 지나치게 잦으면 백그라운드 통신이 늘어날 수 있습니다. 매개변수의 영향은 프로토콜, 원격 서버, 네트워크 환경에 따라 달라지므로 특정 숫자를 그대로 적용하면 안 됩니다. 변경 전에 기존 값을 보관하고 실제 작업과 대기 상태를 관찰하세요. 몇 분 동안 배터리 비율이 달라졌는지만 보지 마세요.

시스템 업데이트, 기기 이전, 대량 파일 동기화와 동시에 배터리 변화가 생겼다면 관련 백그라운드 작업이 끝난 뒤 비교하세요. 기기를 재시동하면 일부 임시 상태를 확인하는 데 도움이 되지만 지속적인 관찰을 대신할 수는 없습니다. 기기가 심하게 뜨거우면 부하가 큰 작업을 멈추고 온도가 정상으로 돌아온 뒤 테스트하세요. 장시간 속도 테스트로 발열을 더하지 마세요. 같은 작업, 안정적인 네트워크, 반복 테스트 중지 상태에서도 문제가 계속되면 연결 빈도와 실패 유형을 정리하고 구성 및 시스템 상태를 추가로 확인하세요.

08 · 구성 차이와 복구 가능한 조치

앱 또는 시스템 업데이트 후 오류 발생

문제가 생기기 전에 업데이트가 있었다고 해서 업데이트가 원인인 것은 아닙니다. 같은 시기에 구독 콘텐츠 변경, 네트워크 전환, 서버 점검, 구성 자동 갱신이 있었을 수도 있습니다. 마지막으로 정상 작동한 시점과 처음 문제가 나타난 시점 사이에 어떤 작업을 했는지 기록해 앱 업데이트, 시스템 업데이트, 구성 업데이트를 구분하세요. 바로 다시 설치하는 것보다 이전 구성과 현재 구성의 차이를 보존하는 편이 더 유용하며, 복구 중 유일하게 작동하는 기록을 잃지 않도록 도와줍니다.

먼저 구입 경로와 호환성 확인

Shadowrocket은 비공개 소스의 상용 앱이며 App Store에서만 구하고 업데이트할 수 있습니다. 구매 및 정품 정보는 다운로드 페이지의 확인 안내에서 확인하세요. 개발자 Shadow Launch Technology Limited, 공식 아이콘, 앱 ID 932747118을 대조하면 됩니다. 시스템 요구 사항은 App Store 페이지의 표기를 기준으로 합니다. 오래된 문서의 시스템 요구 사항으로 현재 기기의 호환성을 판단하지 말고, 앱 구매 기록과 로컬 구성이 저장되어 있는지를 혼동하지 마세요.

앱이 열린다면 먼저 Home에서 선택한 서버, Global Routing 설정, Config에서 적용 중인 구성이 이전과 같은지 확인하세요. 업데이트 후 알림이 표시되면 구체적인 내용을 읽고 조치하세요. 구독 갱신으로 이전에 선택한 항목이 교체된 경우일 수 있습니다. 구성이 있는지 확인한 뒤 연결을 정상적으로 끊었다가 다시 연결하고 기존 테스트 대상으로 확인하세요. 현재 상태를 확인하기 전에 여러 백업을 연달아 가져와 파일과 정책 이름을 더 혼란스럽게 만들지 마세요.

시스템, 앱, 구성 세 계층을 나눠 비교

먼저 연결을 끈 상태에서 기본 네트워크를 확인하고, 시스템 연결이 유지되는지 테스트한 다음 프록시를 통한 실제 접속을 확인하세요. 이렇게 하면 시스템 권한 문제와 규칙 문제를 구분할 수 있습니다. 스위치가 바로 꺼지면 첫 번째 장의 절차를 따르세요. 연결은 유지되지만 Config에서만 실패하면 구성을 우선 비교하세요. 특정 서버가 관련된 모든 설정에서 실패한다면 같은 시기에 매개변수가 바뀌었거나 서비스가 중단되었는지 확인합니다.

구성을 비교할 때는 최근 변경한 DNS, 규칙 순서, 정책 이름, 원격 참조를 중점적으로 살펴보세요. 파일 전체를 처음부터 다시 작성할 필요는 없습니다. 이전 사본은 비교에 활용하되 새 내용을 무조건 덮어쓰지 마세요. 원격 구성은 파일 이름이 같아도 실제 내용이 달라졌을 수 있으므로 읽을 수 있는 로컬 사본을 보관해야 합니다. 특정 필드를 복구한 뒤 문제가 사라졌다면 그 결과가 반복해서 재현되는지 확인하세요. 네트워크가 우연히 복구된 것을 필드 변경의 효과로 착각하지 않도록 합니다.

재구성하거나 다시 설치하기 전에 백업 범위 확인

앱 구매 복원, 서버 항목 복원, 구성 복원은 서로 다른 작업입니다. App Store에서 구매한 앱을 다시 받을 수는 있어도 모든 로컬 항목, 인증 정보, 직접 수정한 내용까지 자동으로 복원되는 것은 아닙니다. 다시 설치하기로 했다면 기존 구독 주소를 계속 사용할 수 있는지, 직접 입력한 서버 매개변수를 안전하게 백업했는지, 구성 사본을 열 수 있는지, 어떤 데이터가 동기화에 의존하는지 확인하세요. 완전한 구성을 보관한 유일한 기기에서 확인 없이 삭제하지 마세요.

iCloud나 파일 내보내기로 백업할 때는 동기화 스위치가 켜져 있는지만 보지 말고 대상 기기 또는 백업 파일에서 실제 내용을 확인하세요. 인증 정보와 구독 주소는 민감하므로 내보낸 파일은 통제된 위치에 보관해야 합니다. 기기 이전 절차는 구성 백업 및 기기 변경 후 복원에서 확인할 수 있습니다. 시스템 VPN 구성을 다시 만들어야 한다면 첫 번째 장의 절차부터 따르세요. 보통 앱 데이터를 전부 지울 필요는 없습니다.

복구 후에는 앱을 열 수 있는지, 시스템 권한이 완료되었는지, 구성이 선택되었는지, 기존 서버를 사용할 수 있는지 확인한 다음 구독 업데이트와 일상적인 대상을 테스트하세요. 각 단계가 통과된 뒤에만 자동 작업을 다시 활성화해 여러 백그라운드 동작이 동시에 발생하지 않도록 합니다. 문제가 계속 재현되면 시스템 환경, 앱에서 확인할 수 있는 관련 설정, 최소 재현 단계, 민감 정보를 제거한 오류를 기록하세요. 문제를 증명하려고 전체 구성을 공개하지 마세요. ‘업데이트 후 고장’이라고만 쓰지 말고 수행한 작업과 결과를 구체적으로 남기세요.

09 · 독립 기기, 구성 공유, 로컬 네트워크

iPhone에서는 정상인데 iPad에서 문제가 발생함

iPhone에서 성공한 결과를 그대로 적용하지 말고 iPad를 별도의 기기로 점검하세요. 두 기기는 서로 다른 Wi-Fi에 연결되거나 다른 DNS 조회 출처를 사용하거나 서로 다른 구성과 서버를 선택했을 수 있습니다. 구독 이름이 같아도 마지막 업데이트 시간과 콘텐츠는 다를 수 있습니다. 먼저 두 기기를 같은 네트워크에 연결한 뒤 표시되는 설정을 항목별로 비교해 차이가 기기 환경에서 생겼는지 구성 자체에서 생겼는지 확인하세요.

구매, 권한, 기기 네트워크 조건 확인

iPad에서 앱을 구하는 방법은 iPad 구매 및 첫 실행을 참고하세요. 구매한 앱의 재다운로드와 지원 범위는 App Store 페이지의 표기를 기준으로 합니다. 시스템 요구 사항도 App Store 페이지의 표기를 기준으로 합니다. 앱이 설치되어 있다고 해서 시스템 VPN 권한까지 완료된 것은 아닙니다. iPhone에서 승인한 권한이 iPad의 기기별 권한을 대신하지 않습니다. 먼저 iPad의 시스템 VPN 페이지를 확인한 다음 스위치가 계속 켜지는지 테스트하세요.

관리 대상 iPad라면 기기 정책에서 해당 연결을 허용하는지도 확인하세요. 셀룰러 모델과 Wi-Fi 전용 기기는 테스트할 수 있는 경로도 다릅니다. 별도의 네트워크가 없어서 교차 테스트를 할 수 없다는 이유로 특정 매개변수가 올바르다고 판단하지 마세요. 사용할 권한이 있는 다른 Wi-Fi에서 비교하고 공용 네트워크는 기기마다 별도로 로그인해야 하는지도 확인할 수 있습니다. iPhone에서 로그인했다고 iPad의 네트워크 세션도 완료된 것은 아닙니다.

전체 구성을 덮어쓰지 말고 항목별로 비교

먼저 Global Routing, 현재 Config, 선택한 서버를 비교한 다음 프로토콜 필드, DNS, 규칙을 확인하세요. 구독 이름은 같지만 서버 목록이 다르다면 한 기기에서 업데이트가 완료되지 않았을 수 있습니다. 항목 이름은 같아도 인증 필드가 다르다면 직접 수정했을 수 있습니다. 비교하는 동안 전체 인증 정보를 메신저로 보내지 말고 각 기기에서 원래 서비스 제공자의 정보와 대조하세요. 차이를 확인한 뒤 해당 항목만 수정하고, iPhone의 로컬 네트워크 전용 규칙을 네트워크 환경이 다른 iPad에 그대로 적용하지 마세요.

화면 방향, 분할 화면, 창 크기가 바뀌면 탐색 메뉴가 다르게 표시될 수 있지만 Config, Home, Settings의 기능이 달라지는 것은 아닙니다. 익숙한 위치에 버튼이 보이지 않으면 검색을 종료하고 편집 상태를 닫은 뒤 현재 메뉴를 확인하세요. 같은 콘텐츠를 반복해서 가져오지 마세요. 목록이 너무 길다면 필터 조건과 그룹이 펼쳐져 있는지도 확인합니다. UI 위치 문제와 서버 통신 오류는 별도로 다뤄야 합니다. 메뉴를 찾지 못했다는 이유만으로 구성이 사라졌다고 판단하지 마세요.

절전 모드 해제 후 복구, 네트워크 전환, 로컬 네트워크 접속 확인

기기를 깨운 뒤에만 문제가 발생한다면 절전 전후 네트워크가 같은지, On Demand가 다시 연결을 시작했는지 먼저 기록하세요. 이전에 열어 둔 페이지를 보는 것보다 새 웹 요청을 시작하는 편이 정확합니다. 기존 페이지에 끊긴 세션이 남아 있을 수 있습니다. 다시 연결한 뒤 문제가 해결되면 네트워크 변경과 자동 실행 조건을 추가로 점검하세요. 화면을 계속 켜 두어 문제를 감추지 마세요. 대기 상태에서는 전원 장의 절차에 따라 반복 연결도 확인해야 합니다. 전면에 표시된 스위치 상태만 보지 마세요.

iPad는 가정용 저장 장치, 화면 전송 기기, 기타 로컬 네트워크 서비스에 자주 사용됩니다. 연결 후 이런 기능에 문제가 생기면 실제로 사용하는 주소와 로컬 네트워크 권한을 확인하고 해당 네트워크 대역이 DIRECT로 연결되는지 살펴보세요. 기기 검색은 브로드캐스트나 로컬 검색 방식에 의존할 수 있어 도메인 규칙 하나만으로 전체 과정을 처리하지 못할 수도 있습니다. 알려진 로컬 주소에 직접 접속할 수 있는지 먼저 확인한 뒤 이름 검색, 앱 권한, 네트워크 전달 문제를 구분하세요. 관련 기능을 모두 DNS 문제로 돌리지 마세요.

구성 동기화도 별도로 확인해야 합니다. 다른 기기에 파일이 나타났다고 현재 Config로 적용된 것은 아닙니다. 서버 항목이 있다고 해서 선택된 것도 아닙니다. 기기를 옮긴 뒤 iPad에서 짧지만 전체 과정을 포함한 검증을 다시 하세요. 구성 선택, 기존 서버 선택, 라우팅 설정 확인, 연결 시작, 기존 테스트 대상 접속 순서로 진행합니다. 모두 통과한 다음 자동 업데이트와 On Demand를 다시 활성화하세요. 문제가 재발하더라도 어느 단계에서 새 조건이 추가되었는지 파악할 수 있습니다.

마지막으로 두 기기에서 같은 대상을 테스트하고 여전히 다른 설정을 기록하세요. 같은 네트워크와 매개변수에서도 iPhone은 정상인데 iPad에서 실패한다면 iPad 자체의 시스템 권한, 조회 결과, 오류 발생 단계를 추가로 살펴보세요. 두 기기에서 모두 실패한다면 공통 네트워크, 서버, 구독을 다시 확인합니다. 일상적인 조작이 익숙하지 않다면 사용 설명서로 돌아가고, 필드의 의미를 모르겠다면 용어 설명서를 참고하세요. 일부 문제를 해결하기 위해 전체 구성을 다시 만들 필요는 없습니다.