연결됨만으로는 규칙이 동작하지 않습니다.

시스템이 VPN 구성을 추가하라고 요청합니다. 허용하면 설정의 VPN 목록에 Shadowrocket이 나타납니다. 운영체제가 개인 VPN을 인가하는 절차이지, 노드 제공자 로그인도, 이 앱 계정도 아닙니다. 앱에는 계정 시스템이 없습니다. 거부하면 가상 NIC가 만들어지지 않고 스위치가 붙을 대상이 없습니다. 나중에 시스템 설정에서 이 구성을 지우거나 스크린 타임 / MDM이 VPN을 막으면 스위치를 다시 쓸 수 없고 재인가가 필요합니다. 재설치하면 이 시스템 구성이 사라지는 경우가 있어 「갑자기 연결이 안 된다」처럼 보입니다. 권한이 사라진 것이지 레코드가 만료된 것이 아닙니다.

인가 대상은 기기 위 확장입니다. 그다음 행선지는 고른 레코드와 현재 정책이 정합니다. 스토어 라이선스가 덮는 것은 여기까지입니다. 앱이 시스템 VPN을 요청할 수 있다는 층입니다. 출구는 포함되지 않습니다. 개발자와 일회 구매 범위는 스토어에서 확인합니다. 하이라이트 행이 없는 채로 스위치를 켜는 결과는 버전에 따릅니다. 「선택하지 않아도 연결된다」에 기대지 마세요. 목록에는 출구로 쓸 수 있는 레코드가 필요합니다. 오브젝트를 보세요.

상태 표시줄에 VPN 아이콘이 있고 스위치가 켜져 있으면 확장이 동작 중입니다. 그때도 연결은 DIRECT로 판정되어 셀룰러나 Wi-Fi 원래 경로로 나가고, 하이라이트한 레코드를 전혀 거치지 않을 수 있습니다. 그래서 「이미 연결됐다」를 「모든 요청이 노드로 들어갔다」로 쓰면 안 됩니다. 바이트가 레코드에 들어갔는지는 Data의 두 카운터로 보고, 규칙이 호스트를 직통에 남겼는지는 규칙으로 봅니다.

스위치가 깜빡이며 반복해서 돌아가면 확장이 안정적으로 뜨지 못한 것입니다. 흔한 원인은 현재 레코드 핸드셰이크 실패(유형, 전송, 인증서, UUID가 대향과 불일치)이거나, 시스템에 쓸 수 있는 VPN 구성이 없는 것입니다. 레코드를 바꾸기 전에 정책이 Direct가 아닌지 확인하세요. Direct에서는 터널이 켜진 채로 대향 핸드셰이크를 하지 않습니다. 스위치가 돌아가는 것과 「노드가 죽었다」는 다른 실패입니다. 정책과 레코드는 따로 고릅니다. 레코드를 바꿔도 Config / Proxy / Direct는 바뀌지 않고, 정책을 바꿔도 하이라이트 행은 바뀌지 않습니다. 둘 다 틀려도 화면은 연결됨으로 남을 수 있습니다.

Config / Proxy / Direct는 현재 구성 전체를 덮고, 규칙 한 줄보다 먼저 보입니다. 답하는 것은 트래픽이 터널에 들어간 뒤 규칙을 물을지입니다. Config: 각 연결을 현재 규칙 파일에 넘깁니다. 도메인, IP, GEOIP는 여기서 계산됩니다. 일상 분기는 이 항목입니다. Proxy: 규칙은 관여하지 않습니다. 송신은 모두 하이라이트 중인 레코드로 갑니다. 「규칙이 틀린 것인지」 「이 레코드 자체의 핸드셰이크나 전달이 실패한 것인지」를 가릅니다. Proxy에서 열리고 Config에서 안 열리면 규칙을 보고, 둘 다 안 열리면 레코드나 대향을 봅니다. Direct: 규칙은 관여하지 않습니다. 송신은 모두 시스템 원래 경로입니다. 아이콘은 켜진 채로 둘 수 있습니다. 전달을 뺀 뒤 이 기기 자체에 망이 있는지를 가릅니다. Captive Portal, 인터넷 뱅킹, 기기 LAN은 Direct로 먼저 떨어져야 끝나는 경우가 많습니다.

연결이 터널에 들어간 뒤 대략 이 순서로 처리합니다. 정책이 Direct면: 시스템 원래 경로로 되돌리고 규칙은 묻지 않으며 현재 레코드와 핸드셰이크하지 않습니다. 정책이 Proxy면: 규칙은 묻지 않고 하이라이트 중인 레코드로 보냅니다. 핸드셰이크가 실패하면 이 단계에서 멈춥니다. 정책이 Config면: 현재 구성의 목록을 위에서 맞춰 DIRECT / PROXY / REJECT를 얻습니다. DIRECT는 원래 경로로 돌아가고 REJECT는 버리며 PROXY는 현재 레코드로 갑니다. 리라이트가 켜져 있으면 요청이 이미 보인 뒤에 URL이나 헤더를 바꿉니다. 리라이트를 보세요. 분기 결과를 거슬러 다시 쓰지 않습니다. 맞춤 앞뒤에서 이름 해결이 어느 단계에 일어나는지가 규칙이 이름을 볼지 주소를 볼지를 정합니다. DNS를 보세요.

UDP와 TCP 모두 터널에 들어가지만, 모든 레코드 유형이 UDP를 똑같이 전달하지는 않습니다. 어떤 앱이 UDP에서만 실패하면(게임, 일부 통화) 먼저 그 레코드가 지원을 선언했는지 보고, 다음으로 규칙이 포트로 REJECT하지 않았는지 봅니다. 대조는 Direct → Proxy → Config 순으로, 한 번에 움직이는 것은 정책뿐입니다. Config 아래에서 FINAL을 고치면서 레코드도 바꾸는 것은 대조가 아닙니다. 전개는 매뉴얼 터널 장입니다.

「연결됨」은 목록 프로브와 함께 읽히는 일도 많습니다. 프로브가 통과하면 「경로 전체가 통했다」고 생각하고, 빨간색이면 「기기에 망이 없다」고 생각합니다. 둘 다 틀립니다. 프로브가 묻는 것은 이 홉뿐입니다. Direct라면 프로브가 빨개도 페이지는 원래 경로로 열립니다. Config에서 호스트가 DIRECT면 프로브가 빨개도 그 사이트가 열리는 것은 정상입니다. 문장을 셋으로 나눕니다. 터널이 있는지, 이 홉이 프로브되는지, 이번 방문이 어느 쪽을 탔는지. 첫째는 스위치, 둘째는 밀리초, 셋째는 Data입니다. 규칙이 들어가는 것은 셋째 문장뿐이고, 정책이 Config일 때만입니다. 셋째에서 Proxy가 오르는데 페이지가 실패하면 문제는 이미 터널 층을 떠났습니다. 대향, 이름 해결, 그 App 자신의 정책을 보세요. 셋째가 Direct만 오르면 정책이 Direct인지, 규칙이 먼저 DIRECT로 썼는지를 돌아가 보세요. 스위치 자체는 이 두 질문에 답하지 못합니다.