サブスクリプションURLとグループの管理
サブスクリプションはサーバーパラメーターをまとめて更新するためのもので、クライアントのログインアカウントではありません。まずサブスクリプショングループにURLを保存して名前を付け、更新を実行します。追加に成功した後も、使うサーバーを選択する必要があります。複数の提供元は別々のグループに保存すると、無効なURLを特定しやすくなり、更新時に手動設定と混同するのを防げます。解析に失敗した場合は、URLの有効期限、応答内容、対応形式を確認してください。クライアントを何度も再インストールする必要はありません。サブスクリプションには通常アクセス情報が含まれるため、ログやスクリーンショットを共有する前にURL全体を隠してください。以下は使用できない形式の例です。
https://subscription.example.com/list?token=xxxx
ルールの順序がマッチ結果を左右する
ルーティングはドメイン、宛先アドレス、ポートなどの条件に応じて通信経路を選び、ルールの順序が最終結果に影響します。明確な例外は、より広い条件のルールより前に置き、参照先のアウトバウンドタグが定義済みか確認してください。ドメインルールとアドレスルールは参照する情報が異なるため、DNSを変更した後はマッチ状況も再確認します。以下の抜粋はプライベートアドレスを直接接続に振り分け、ルール構造を説明するものです。完全な振り分け設定ではなく、DNS設定もすべて含んでいません。他の人のルールを取り込む前に、コアが対応する構文とルールリソースを確認してください。
{
"routing": {
"domainStrategy": "AsIs",
"rules": [
{
"type": "field",
"ip": ["geoip:private"],
"outboundTag": "direct"
}
]
}
}
アプリのプロキシ設定と仮想ネットワークインターフェース
システムプロキシはOSの設定にローカルプロキシアドレスを書き込み、主にその設定に従うアプリに適用されます。TUNは仮想ネットワークインターフェースを使って、ルーティング条件に一致する通信を引き受けます。追加の権限が必要な場合もあります。どちらも接続品質の優劣を示すモードではありません。トラブル時はまず一方だけを選び、他のネットワークツールとの併用を避けてください。以下はローカルSOCKSインバウンドの項目例です。ポート番号は設定例であり、すべての環境で固定ではありません。アプリ側でプロキシを手動設定する場合は、クライアントが実際に待ち受けているアドレス、ポート、プロトコルと一致させてください。
{
"inbounds": [
{
"tag": "local-socks",
"listen": "127.0.0.1",
"port": 10808,
"protocol": "socks",
"settings": {
"auth": "noauth",
"udp": true
}
}
]
}
対応プロトコルは実際に使うコアで確認
クライアントは設定の編集と管理を担い、コアはプロトコル処理を担います。コアを切り替えても、すべての設定が自動変換されるわけではありません。まずプロトコル、伝送方式、セキュリティパラメーターが移行先のコアに対応しているか確認し、生成された設定と起動ログを調べてください。デスクトップではクライアントが提供する選択肢からコアを選べます。Androidの2つのクライアントは異なるコア系統を採用しており、名前だけが違う同じアプリとして扱うべきではありません。以下のログ項目はコア設定の理解に役立ちますが、ログレベルだけで特定サーバーとの互換性は判断できません。
{
"log": {
"loglevel": "warning"
}
}
サブスクリプションを移行し、端末ごとの設定を確認
ここでいう複数プラットフォームへの移行は、サブスクリプションや設定の引き継ぎを指し、クライアントにクラウド同期機能が内蔵されているという意味ではありません。サブスクリプションは端末ごとに追加できますが、ローカルの待受ポート、システムプロキシ、TUNの権限、アプリごとのルールは各プラットフォームで設定し直してください。移行前に元の設定をバックアップし、移行後はサブスクリプションを更新してサーバー1台でテストしてから、ルーティングを戻します。以下は直接接続のアウトバウンドを理解するための設定例です。設定全体を再利用できるかはコアと各項目の対応状況によるため、ファイル拡張子だけでは互換性を判断できません。
{
"outbounds": [
{
"tag": "direct",
"protocol": "freedom",
"settings": {}
}
]
}
追加完了から実際に使える状態へ
サーバー一覧に項目が表示されても、クライアントが設定を読み込んだことしか分かりません。選択中のサーバー、システム時刻、プロキシモード、対象アプリのネットワーク設定も確認してください。ブラウザーでは接続できるのに他のアプリで使えない場合は、そのアプリがシステムプロキシに従うか確認します。すべての通信に失敗する場合は、コアが起動しているか、ログに設定項目のエラーがないか、サブスクリプション内のアドレスとポートが有効かを調べてください。
遅延テストは測定方法を分けて考えましょう。Pingは通常ネットワークの応答を示し、実際の接続遅延はプロキシ経由の接続を測定します。ダウンロード速度は帯域、測定先、時間帯にも左右されます。数値が低くても、実際にアクセスできるとは限りません。初回設定の手順はクイックスタートをご覧ください。OSごとのインストール、権限、ルーティングの詳細は全プラットフォームガイドで確認できます。