구성은 문서입니다. 레코드는 출구입니다. 같은 한 번의 붙이기가 아닙니다.

구성 파일은 기기 위 문서입니다. 흔한 내용은 일반 옵션(DNS, IPv6, 포트 등), 규칙 목록, 때로는 리라이트와 복호화 호스트 목록입니다. 서버 레코드는 파일에 나올 수도, 앱의 서버 목록에만 살 수도 있으며 가져오기 방식에 따릅니다. 「앱을 넣으면 쓸 수 있는 출구가 따라온다」고 가정하지 마세요. 스토어 라이선스에 서버는 없습니다.

손글씨나 가져온 파일의 규칙 구간 문법은 규칙입니다. 리라이트 구간은 리라이트입니다. DNS 관련 옵션은 DNS입니다. 세 블록은 같은 문서에 있어도 실행 시에는 세 메커니즘입니다. 먼저 분기하고, 필요하면 리라이트하며, 이름 해결 방침은 줄곧 관통합니다.

ss://를 통째로 「구성 URL」에 붙이거나 구성 파일을 「서버 주소」에 붙이면 오브젝트의 칸이 틀립니다. 저장은 됩니다. 그다음 실패를 「노드가 안 된다」로 설명할 수 없습니다.

앱은 여러 구성을 동시에 저장하고 각각에 이름을 붙일 수 있습니다. 현재 구성을 바꾸면 목록과 옵션이 함께 바뀝니다. FINAL 두 개가 겹치는 것이 아니고, 「이쪽 GEOIP와 저쪽 도메인 줄」이 자동으로 합쳐지지도 않습니다.

구성을 바꿔도 안 바뀌는 것은 지금 하이라이트된 레코드, 스위치가 켜졌는지, Data 카운터 숫자입니다. 그래서 「새 목록으로 바꿨는데 페이지가 그대로」처럼 보일 수 있습니다. 정책이 실제로는 Proxy라 엔진이 새 파일을 읽지 않은 것입니다. 먼저 정책을 보고, 그다음 고른 것이 어느 것인지 보세요.

두 구성이 같은 출처를 구독하고 새로고침 시각만 다르면 목록에 「거의 같은」 파일이 둘인 것처럼 보입니다. 지금 체크된 하나가 기준입니다. 하나를 편집해도 다른 하나에 쓰이지 않습니다. 다만 실제로 같은 구독 URL을 가리키고 다음 새로고침이 로컬 수정을 덮으면 예외입니다.

가져오기 경로는 보통 파일, 클립보드, URL입니다. URL형 구성은 서버 컨테이너와 같습니다. 저장하는 것은 주소이고, 가져오기가 성공해야 대향 내용으로 로컬 문서를 바꿉니다. 실패 때는 직전에 성공한 파일을 남기고, 실패 때문에 규칙을 비우지 않습니다.

열 때 업데이트, 백그라운드 업데이트는 이 가져오기의 반복입니다. 백그라운드는 시스템이 이 앱의 백그라운드 새로고침을 허용하는지도 봅니다. 시스템을 보세요. 새로고침은 그때의 네트워크 경로를 탑니다. 스위치가 만료된 레코드에 붙어 있으면 구성 구독 자체도 실패할 수 있습니다. 정책을 Direct로 바꾸거나 스위치를 먼저 끄는 것은 경로를 격리하는 것입니다.

내보내기로 얻는 것은 규칙, 옵션, 파일에 적은 인증 정보를 담은 문서입니다. 비밀로 다루세요. 다른 기기에 보내기 전에는 안에 비밀번호와 UUID가 있다고 가정하세요.

가져온 목록은 FINAL과 GEOIP를 먼저 읽고 쓸지를 정합니다. 저자는 자기 출구에 맞춰 씁니다. 한곳의 노드용으로 쓴 목록을 다른 곳의 노드에 씌우면 무관한 요청이 대량으로 노드에 들어가고, 반대면 지명되지 않은 트래픽이 모두 직통입니다. 규칙 페이지 「가져온 파일」을 보세요.

계정 시스템은 없습니다. 개발자 서버는 당신의 목록을 보관하지 않습니다. iCloud를 허용하면 같은 Apple ID 기기끼리 구성과 레코드를 동기화할 수 있습니다. Apple 계정 동기화이지 Shadowrocket 계정이 아닙니다.

동기화가 충돌할 때 같은 구독형 구성을 두 기기에서 동시에 크게 편집하지 마세요. 다음 새로고침은 여전히 URL 반환값을 기준으로 하고 로컬 수정은 덮입니다. 목록을 얼리려면 구독하지 않는 로컬 파일로 내보낸 뒤 그것을 편집하세요.

iCloud를 끄거나 Apple ID를 바꿔도 개발자에게 「로그아웃」이 자동으로 가지 않습니다. 원래 없기 때문입니다. 기기 파일은 앱을 지우거나 문서를 지울 때까지 남습니다. 앱을 지우면 백업하지 않은 구성도 가져갑니다. 스토어 앱을 다시 넣어도 iCloud나 자신의 내보내기가 남아 있지 않으면 노드는 돌아오지 않습니다.