1 なぜ「そのまま貼る」と失敗するのか
Clash 系クライアント(Clash Verge Rev、FlClash、Mihomo 単体など)は、設定の中心を YAML(またはそれに準ずる宣言的記法)で表します。一方、商用プロバイダーがダッシュボードに表示する購読リンクは、しばしば「ノード一覧を Base64 でまとめたテキスト」や「1 行 1 ノードの共有形式」として配布されます。クライアントが期待するのは proxies: 配下の型付きオブジェクトか、リモートから取得する proxy-providers 用の Clash 方言付きファイルですから、中身が噛み合わずインポートエラーになるのは自然な結果です。
ここで必要になるのが、購読の中身をパースし、Clash が解釈できるフィールドへ写像する変換レイヤです。コミュニティで広く使われてきた実装が SubConverter(およびそのフォーク群)で、入力として購読 URL や単一ノード URI、出力として clash ターゲットの設定断片や完全プロファイルを返す、という役割分担になっています。2026 年現在も、新しいトランスポート(REALITY や Hysteria2 など)への追従はコアとコンバータのバージョン次第なので、Mihomo など利用中の実行環境のリリースノートと合わせて更新頻度を確認する習慣が欠かせません。
一部の GUI クライアントは、購読 URL を貼った時点で内部で同様の変換を抱えており、ユーザーから見ると「何もしなくても動く」場合があります。それでもトラブル時に中身を検証したり、ルールセットとマージしたりするには、変換後の YAML をファイルとして扱えるようにしておくと自由度が段違いです。以降の節では、自前もしくは信頼できる境界内で SubConverter を動かし、生成物を Clash に渡すまでの王道を追います。
2 よくある購読リンクの「中身」のイメージ
Shadowsocks の購読は、しばしば ss:// で始まる行の集合か、それらを Base64 化してまとめたプレーンテキストです。パスワードやメソッドがエンコードされているため、人間が読むよりデコードして検証する方が早いです。V2Ray 系では vmess:// や vless:// の JSON を Base64 した URI、あるいはサブスクリプション API が JSON 配列を返すパターンがあります。Trojan は trojan:// の後にパスワードとホスト、ポート、クエリで TLS/SNI/ALPN 等を載せるのが一般的です。
Clash/Mihomo が欲しいのは、例えば type: ss や type: vmess、type: trojan にマッピングされたキー値です。変換ツールはここでプロトコルごとのフィールド名の差異(旧来の命名や省略形)を吸収します。ただし、プロバイダー側が独自拡張している場合、コンバータが未対応だとノードが落ちたり、一部パラメータがデフォルトに丸められたりします。生成後は必ずノード数と代表ノードのサーバ名・ポートが期待通りかを目視し、怪しい行があればプロバイダーのドキュメントと突き合わせてください。
text/plain のテキストか、短い JSON です。Clash が直接読めるのは、変換後に得られた Clash 方言の断片か、それをホストした HTTPS 上のファイルです。
3 SubConverter:API とパラメータの骨格
典型的な自己ホスト構成では、SubConverter が HTTP サーバとして起動し、クエリパラメータで「元購読の URL」「出力ターゲット(clash 等)」「追加のルールテンプレ有無」などを受け取ります。元 URL はそのままクエリに載せると長さや記号の都合で壊れやすいため、URL エンコードした文字列を渡すパターンが定番です。エンコードし忘れると、変換結果が空だったり一部ノードだけ欠ける原因になりがちです。
実際のエンドポイント名やパラメータ名はビルドやプリセットで微妙に異なるため、利用するバイナリの README か設定例を一次情報として参照してください。概念図として、次のような「プレースホルダ」で捉えると運用がブレにくいです(実サーバのパスは環境に合わせて読み替えてください)。
# Example pattern (replace host and query keys per your SubConverter build)
GET https://subconverter.example/sub?target=clash&url=ENCODED_SUBSCRIPTION_URL
target=clash は古典的な Clash 出力を指します。Mihomo/Clash Meta 向けに clash.meta 相当のターゲット名を別途用意しているフォークも多く、REALITY や新しい UDP オプションを落とさず渡したい場合はそちらを選ぶのが安全です。クライアントが Premium/Meta どちらの方言を前提にしているかは、使用中のアプリのドキュメントを確認してください。
4 自前ホスト:Docker か単体バイナリか
購読 URL には認証トークンが含まれることが多く、第三者が運営する無料のオンライン変換サイトにそのまま貼ると、サーバ側ログに平文が残るリスクがあります。可能なら 自分のマシンや VPS のループバック で SubConverter を起動し、変換要求がインターネットに流出しない閉じた経路に閉じ込めるのが望ましいです。Docker Compose で公式イメージやメンテされているフォークを引き、ローカルだけにポートをバインドするのは再現性が高く、チーム内で手順を共有しやすいです。
最小の運用イメージ
コンテナまたはバイナリを起動したら、ブラウザや curl でローカルエンドポイントにテストリクエストを送り、返ってきた YAML の先頭に proxies: があるか、エラー JSON になっていないかを確認します。うまくいったら、そのローカル URL を一時的に Clash の proxy-providers の url: に載せるか、生成物をファイルに保存して path: で読み込みます。後者は購読更新のたびに再フェッチが必要になる点をトレードオフに、オフライン検証や差分レビューがしやすい利点があります。
proxy-providers:
airport:
type: http
url: "https://YOUR_CONVERTER/sub?target=clash&url=ENCODED_ORIGINAL"
path: ./providers/airport.yaml
interval: 3600
health-check:
enable: true
url: https://www.gstatic.com/generate_204
interval: 600
proxy-groups:
- name: Proxy
type: select
use:
- airport
上記は説明用の断片です。実際には rules: や dns:、既存の DNS まわりのベストプラクティスと整合を取った全体設定の中に埋め込んでください。Linux サーバで Mihomo を常駐させる場合は、systemd ユニットと最小 YAMLの記事とあわせて読むと、変換済み購読の置き場所と権限まで一気に決めやすくなります。
5 クライアント側:インポートと更新周期
GUI クライアントでは「プロファイルのダウンロード」や「購読管理」画面から URL を登録します。ここで渡すのはプロバイダー素の URLでも変換済み URLでも構いませんが、後者を使う場合は SubConverter が常に到達可能であること、TLS 証明書が有効であること、Basic 認証をかけているならクライアント側の対応可否を確認してください。更新間隔はプロバイダーの推奨(例:毎日 1 回)と健康チェックの負荷のバランスで決めるのが現実的です。
Windows で Clash Verge Rev を初めてセットアップする場合は、インストールと権限まわりを先に済ませてから購読を足すと、プロファイルの再読み込みや TUN 試行までスムーズです。Android で FlClash を使う読者は、購読インポートと VPN 権限の章で、URL scheme やクリップボードからの取り込み動線を確認するとよいでしょう。
変換結果をローカルファイルとして保存する運用では、プロバイダーがノードを差し替えたタイミングで手動またはスクリプトから SubConverter を叩き直し、差分を Git で追う、といった方法もあります。自動更新に任せきると設定ミスに気づきにくいので、月に一度は代表ノードのレイテンシとルールのヒット状況をログから点検する癖をつけると安心です。
6 セキュリティ:鍵・ログ・サプライチェーン
購読 URL 自体が秘密情報です。チャットに貼らない、スクリーンショットに写さない、公開リポジトリにコミットしない、は最低ラインです。SubConverter を自前で動かす場合も、アクセスログを残すリバースプロキシの向き先や、クラウドのロードバランサのログ設定まで含めて「どこに平文が残るか」を洗い出してください。社内共有が必要なら、VPN 内の限定ホストからだけ到達できるようにし、認証を二重化するのが無難です。
サプライチェーン面では、Docker イメージやバイナリを署名付きリリースやチェックサム付きの公式チャネルから取得し、タグを固定して予期せぬ自動更新で壊れないようにします。フォークを選ぶ場合はコミット履歴と Issue の活発さをざっと見て、メンテが止まっていないか判断材料にしてください。オンラインの公開変換サービスをどうしても使う場合は、利用規約とデータ保持ポリシーを読み、テスト用のダミー購読で挙動だけ確かめる、といった段階的な露出の仕方を推奨します。
7 トラブルシューティング
- ノードがゼロになる: 元購読の URL エンコード漏れ、期限切れトークン、プロバイダーの IP 制限が典型です。ブラウザで購読を開き、中身が取得できるか先に切り分けます。
- 一部プロトコルだけ消える: SubConverter のターゲットが Meta 拡張に非対応なビルドである可能性があります。
clash.meta系ターゲットへ切り替え、バージョンを上げます。 - TLS エラーや SNI 不一致: 変換は成功していても、実接続で証明書検証に失敗することがあります。サーバ側のドメイン設定とクライアントの
sni/servernameが一致しているか、中間機器がデタラメな証明書を差し込んでいないかを確認します。 - 更新しても古いまま:
proxy-providersのキャッシュや、クライアント側のプロファイルキャッシュが残っていることがあります。手動更新、pathファイルの削除、再起動の順で試します。 - 遅い・不安定: 変換サーバではなく出口ノード側の混雑であることが多いです。健康チェック URL や実測でセレクタを切り替え、ルールで国内 CDN を DIRECT に戻すなど、別レイヤの最適化も検討します。
8 まとめ
SS/V2Ray 系/Trojan の購読を Clash YAML に落とし込む作業は、単なる「形式変換」ではなく、のちのルール設計や DNS ポリシー、健康チェックまで含めたプロキシ設定パイプラインの入口です。SubConverter を自分の管理下に置き、エンコードとターゲット名を正しく扱い、生成物を proxy-providers や GUI の購読欄へ接続すれば、同じワークフローをデスクトップとサーバで再利用しやすくなります。
クライアントによっては内部変換で摩擦の少ないオンボーディングが用意されている一方、トラブル時の可観測性とカスタムルールとのマージでは「ファイルとしての YAML」が依然として強いです。同じエコシステムの中で GUI とヘッドレスを行き来するなら、変換結果の置き場と更新ポリシーを先に決めておくと長期的なメンテが楽になります。
安定したビルドの入手と各 OS 向けの導線は ダウンロードページから辿れます。変換後の設定を実機に載せる前に、テストプロファイルで接続と DNS の挙動だけでも短時間確認する習慣をつけると、想定外のルール衝突を早めに防げます。