ブログ

ハイライトできるのは出口です。更新しかできないのは URL です。

ホームの一覧に見えるのは、通常二種類です。スイッチを入れると使うのは、今ハイライトされているレコードだけです。Subscribe はコンテナです。中身は URL で、子レコードは更新のあと現れます。ルール構成は三番目で、この列には出ません。

三つのオブジェクト

互いに置き換えない

Shadowrocket の Type 一覧:Subscribe はコンテナ、他はレコード
追加時、Type の Subscribe はコンテナ、それ以外はレコードです。App Store 掲載画面。端末の版に従ってください。

ハイライト行を替えてもルールは替わりません。ルールを替えてもハイライト行は替わりません。コンテナを更新しても FINAL は変わりません。この三つを「一度の取り込みの三コピー」だと思うと、あとの切り分けはすべて乱れます。欄の説明は オブジェクトConfig にあります。本稿が扱うのは観察上の誤り一つです。一覧が空、または行が多いのを見て、出口がもう用意できた、またはもう壊れたと思うことです。

レコードにはアドレス、ポート、プロトコル、認証、トランスポートがあります。ハイライトできます。「更新」はありません。対向がポートを変えても、ローカルのこの行は自分では変わりません。編集するか、消して作り直すだけです。タイプはこのレコードの身元であり、ラベルではありません。Trojan を選び、パスワードが Shadowsocks のものでも保存はできます。トンネル のハンドシェイクは失敗します。トランスポートはレコード自身のものです。対向が WebSocket なのにローカルが TCP のまま、パス、Host、gRPC サービス名を別セットで埋める。保存はでき、ハンドシェイクはできません。切り分けでは「プロトコルタイプ」と「トランスポート」を独立した点検項にして、アドレスとポートだけ照合しないでください。

SNI、証明書検証をスキップするか、フィンガプリントが、TLS が完了できるかを決めます。証明書はシステム時刻にも依存します。時刻が自動設定でないと、TLS に依存するレコードはまとめて失敗し、行を替えても効きません。レコードが述べるのは出口一つです。ルールは含まず、「繋がったあと自動で別の行に替える」も含みません。一覧プローブのミリ秒は、このホップが今プローブできるかだけを示します。Data を見てください。

コンテナ

保存と更新は二段

コンテナが保存するのは URL です。保存の段では子レコードをダウンロードしません。保存直後、集合は空でもよく、コンテナとしては正常であり、「購読が壊れた」ではありません。取りに行くのは更新です。成功すると戻り内容で子レコードを生成または置換し、その子レコードは普通のレコードと同じくハイライトできます。失敗しても、すでに在る行を失敗のために消しません。見えるのは直前に成功した集合で、期限切れかもしれませんが、まだ在ります。

起動時の更新、バックグラウンド更新は、どちらも「更新」の繰り返しです。バックグラウンドが走れるかは、システムがこのアプリのバックグラウンド更新を許しているか、端末が省電力かにもよります。それは システム の境界であり、コンテナのスイッチが切れているのではありません。更新要求は、そのときのネットワーク経路を通ります。スイッチが失効したレコードに繋がっていると、更新自体も失敗し得ます。ポリシーを Direct にする、または先にスイッチを切るのは、経路を隔離するのであり、URL を直しているのではありません。URL が 404、401、空ファイルを返すと、クライアントは失敗を報告できるだけです。対向のリンクを延長できません。

購読 URL をブラウザで開くと、ウェブページとして見られない内容になることが多いです。クライアントが解析するためのものです。ブラウザがバイトを取れれば、経路は通っており、リンク自体は生きています。ブラウザでも開けないなら、問題はネットかリンクであり、Shadowrocket のパーサではありません。ss://、vmess://、trojan:// は欄を 1 行にまとめます。追加入口へ丸ごと貼ると、UUID を手で写すより誤りが減ります。「サーバーアドレス」の 1 マスへ丸ごと貼ると、通常は URI として解析されません。

スキャンで得られるのは、レコード 1 本のことも、コンテナ URL のことも、構成のダウンロード先のこともあります。保存したあと、ハイライトできるかを見ます。ハイライトでき、欄がホストとポートならレコードです。展開しかできず、中が URL ならコンテナです。サーバー一覧ではなく構成一覧に入ったなら構成です。同じコードを二度スキャンすると、一覧に同じレコードが二本出ることがあります。接続時に使うのはハイライト中の 1 本だけで、重複行は帯域を足さず、選び間違いの機会だけ増やします。

二種類の更新を、一度の操作にしない

サーバーコンテナの更新が更新するのは、一覧の子レコードです。ルール / 構成購読の更新が更新するのは、リストファイルです。URL は似ていても、オブジェクトは一つではありません。コンテナを更新しても FINAL は変わりません。ルールを更新してもハイライト行は変わりません。

たくさんの行

接続時に使うのは 1 行

一覧は多くのレコード、多くのコンテナを許します。接続時に使うのは、今ハイライトされている 1 本だけです。二つのコンテナは自動では負荷分散せず、「プローブ数が最小の行」に自動では替えません。プローブがどれほど小さくても、ハイライトされていなければ、スイッチを入れても使いません。コンテナを消すと、それが生成した子レコードは通常まとめて消えます。今のハイライトがこのコンテナに属するなら、消したあと別の行を選んでからスイッチを入れてください。

コンテナ内の 1 行を手で独立レコードに複製すると、以後の更新はこの複製を動かしません。対向がポートを変えても、複製はついていかず、自分で編集します。それが「1 行を凍結する」と「URL を追い続ける」の取捨です。多くのコンテナはトークンをパスに置きます。スクリーンショット、グループファイル、公開ドライブに出るのは、子レコードへのアクセス権を渡すことです。クライアントは漏洩した URL を無効にしてくれず、対向にリンクを替えろとも伝えません。書き出しバックアップも認証パラメータを含むので、秘密として扱ってください。

アプリは URL の有効期限を延ばせません。サーバー料金を立て替えられません。ハンドシェイク失敗のレコードを使えるようにはできません。システム章では、できないことに分類してあり、見つからない設定項目ではありません。アプリを入れた直後に一覧が空なのも正常です。ストアのライセンスに出口は含まれません。ストア を見てください。

コンテナをレコードとしてハイライトする、またはレコードをコンテナとして更新を待つ、どちらも間違ったオブジェクトを操作します。前者は、出口にできない行を押し、スイッチを入れてもハンドシェイクの対象がありません。後者は、手書きレコードは一覧を下に引いても対向からポートを取ってきません。判定は単純です。この行にホストとポートがあり、現在の出口として選べるか。できるならレコード、できず URL しか見えないならコンテナです。構成ファイルは、別の入口で今チェックされているのがどれかも確認します。三箇所を見てから、「なぜページが元のままか」を話します。