オブジェクト
一覧で押せるものと、一覧にアドレスだけ置くものは、同じ種類ではありません。
スイッチを入れると使うのは、今ハイライトされているレコードだけです。Subscribe はコンテナです。中身は URL で、子レコードは更新のあと現れます。ルール構成は三番目のオブジェクトで、前二者と並び、互いに置き換えません。
01
三つのオブジェクトは互いに置き換えない
ホームの一覧に見えるのは、通常レコードとコンテナです。ルールファイルは別の入口にあります。ハイライト行を替えてもルールは替わりません。ルールを替えてもハイライト行は替わりません。コンテナを更新しても FINAL は変わりません。この三つを「一度の取り込みの三コピー」だと思うと、あとの切り分けはすべて乱れます。
レコード
出口 1 本
アドレス、ポート、プロトコル、認証、トランスポート。ハイライトできます。「更新」はありません。対向がパラメータを変えても、ローカルのこの行は自分では変わりません。編集するか、消して作り直すだけです。
コンテナ
URL 1 本
保存はアドレスを書くだけで、そのとき子レコードの集合は空でもよいです。取りに行くのは更新です。失敗すると直前に成功した集合を残します。URL が失効したとき、クライアントは直せません。
02
レコード: 欄は対向と同じ一組である必要がある
追加入口はタイプで分かれます。タイプはこのレコードの身元であり、ラベルではありません。Trojan を選び、パスワードが Shadowsocks のものでも保存はできます。トンネル のハンドシェイクは失敗します。UUID、パスワード、暗号方式、alterId といった認証欄は対向と一致させる必要があります。「だいたい同じ」では足りません。
トランスポートはレコード自身のものであり、任意項目ではありません。対向が WebSocket なのにローカルが TCP のまま、対向が TLS を要求するのにローカルが切っている、パス、Host、gRPC サービス名、REALITY 公開鍵とショート ID を別セットで埋める。保存はでき、ハンドシェイクはできません。切り分けでは「プロトコルタイプ」と「トランスポート」を独立した点検項にして、アドレスとポートだけ照合しないでください。
SNI / 対向ホスト名、証明書検証をスキップするか、フィンガプリントが、TLS が完了できるかを決めます。証明書はシステム時刻にも依存します。時刻が自動設定でないと、TLS に依存するレコードはまとめて失敗し、行を替えても効きません。Data を見てください。
レコードが述べるのは出口 1 本です。ルールは含まず、「繋がったあと自動で別の行に替える」も含みません。一覧プローブのミリ秒は、このホップが今プローブできるかだけを示します。Data ページを見てください。
- アドレス
- 対向のホスト名または IP。ここに URI を丸ごと入れると、通常 ss:// としては解析されず、不正なホスト名になります。
- ポート
- 対向が待っているポートです。ウェブのポート、管理パネルのポートを入れると、ハンドシェイクの対象はプロキシプロセスではありません。
- 認証
- パスワード、UUID、ユーザ名。そのタイプが要求する一組です。一つ多い、一つ足りない、別タイプからコピーした、いずれも認証失敗です。
- 転送
- TCP、WebSocket、gRPC などと、パスと Host。タイプと並び、「上級で無視してよい」ではありません。
03
URI はまとめた 1 行であり、アドレスバーではない
ss://、vmess://、trojan://、vless:// はタイプ、認証、トランスポートを 1 行にまとめます。追加入口へ丸ごと貼ると、UUID を手で写すより誤りが減ります。「サーバーアドレス」の 1 マスへ丸ごと貼ると、通常は URI として解析されません。
スキャンで得られるのは、レコード 1 本のことも、コンテナ URL のことも、構成のダウンロード先のこともあります。保存したあと、ハイライトできるかを見ます。ハイライトでき、欄がホストとポートならレコードです。展開しかできず、中が URL で、子レコードは更新のあと現れるならコンテナです。サーバー一覧ではなく構成一覧に入ったなら Config です。
同じコードを二度スキャンすると、一覧に同じレコードが二本出ることがあります。接続時に使うのはハイライト中の 1 本だけで、重複行は帯域を足さず、選び間違いの機会だけ増やします。
04
コンテナ: 保存と更新は二段
保存は URL を端末に書きます。この段では子レコードをダウンロードしません。保存直後に一覧が空に見えるのは、コンテナとしては正常であり、「購読が壊れた」ではありません。
更新は URL で取得します。成功すると戻り内容で子レコードを生成または置換し、その子レコードは普通のレコードと同じくハイライトできます。失敗しても、すでに在る子レコードを失敗のために消しません。見えるのは直前に成功した集合で、期限切れかもしれませんが、まだ在ります。
起動時の更新、バックグラウンド更新は、どちらも「更新」の繰り返しです。バックグラウンドが走れるかは、システムがこのアプリのバックグラウンド更新を許しているか、端末が省電力かにもよります。それは システム の境界であり、コンテナのスイッチが切れているのではありません。
更新要求は、そのときのネットワーク経路を通ります。スイッチが失効したレコードに繋がっていると、更新自体も失敗し得ます。ポリシーを Direct にする、または先にスイッチを切るのは、経路を隔離するのであり、URL を直しているのではありません。URL が 404、401、空ファイルを返すと、クライアントは失敗を報告できるだけです。対向のリンクを延長できません。
購読 URL をブラウザで開くと、ウェブページとして見られない内容になることが多いです。クライアントが解析するためのものです。ブラウザがバイトを取れれば、経路は通っており、リンク自体は生きています。ブラウザでも開けないなら、問題はネットかリンクであり、Shadowrocket のパーサではありません。
サーバーコンテナの更新が更新するのは、一覧の子レコードです。ルール / 構成購読の更新が更新するのは、リストファイルです。URL は似ていても、オブジェクトは一つではありません。コンテナを更新しても FINAL は変わりません。ルールを更新してもハイライト行は変わりません。
05
たくさんの行、使うのは 1 行
一覧は多くのレコード、多くのコンテナを許します。接続時に使うのは、今ハイライトされているレコード 1 本だけです。二つのコンテナは自動では負荷分散せず、「プローブ数が最小の行」に自動では替えません。プローブがどれほど小さくても、ハイライトされていなければ、スイッチを入れても使いません。
コンテナを消すと、それが生成した子レコードは通常まとめて消えます。今のハイライトがこのコンテナに属するなら、消したあと別の行を選んでからスイッチを入れてください。手で追加したレコードは、あるコンテナを消しても消えません。逆に、コンテナから更新された行を、URL から離れて永久に残る複製だと思わないでください。次の更新で書き換えられたり、外されたりします。
コンテナ内の 1 行を手で独立レコードに複製すると、以後の更新はこの複製を動かしません。対向がポートを変えても、複製はついていかず、自分で編集します。それが「1 行を凍結する」と「URL を追い続ける」の取捨です。
06
URL は秘密として扱う
多くのコンテナはトークンをパスに置きます。スクリーンショット、グループファイル、公開ドライブ、ブラウザ履歴に出るのは、子レコードへのアクセス権を渡すことです。クライアントは漏洩した URL を無効にしてくれず、対向にリンクを替えろとも伝えません。
書き出したバックアップ、別の端末へ送るファイルも、認証パラメータを含みます。秘密として扱い、普通の文書として転送しないでください。iCloud 同期が通るのはあなたの Apple ID であり、開発者のサーバーではありません。開発者側にあなたの一覧はありません。Config を見てください。
アプリは URL の有効期限を延ばせません。サーバー料金を立て替えられません。ハンドシェイク失敗のレコードを使えるようにはできません。システム では、できないことに分類してあり、見つからない設定項目ではありません。