Ubuntu で TUN＋systemd を選ぶ理由

「環境変数のプロキシ」だけでは協力しないアプリが残ります。TUN はカーネルが仮想インターフェースへトラフィックを渡す発想に近く、ブラウザや CLI の体感が揃いやすい一方、ルート競合（Docker、別 VPN、社内ネットワーク）など運用課題も表に出ます。

systemd は「端末で一度起動」を「サービスとして再現可能」に変えます。再起動後の自動起動、失敗時の再起動、ログの一元化はサーバー用途で特に重要です。概念図は TUN モード解説 を参照し、本稿はパス・権限・ユニットに絞ります。

ℹ 要点：手動実行は成功するのに systemd だけ失敗する場合、まず -d パス・実行ユーザー・capabilities の三つを揃えて比較してください。

Ubuntu は netplan、NetworkManager、systemd-resolved が同居しがちで、「端末では動くのにサービスだけおかしい」症状が環境差として出ることがあります。同じユーザー・同じ -d で前景実行と systemd を並べると、カーネル不具合と設定不一致を切り分けやすくなります。クライアント選定は クライアントの選び方 も参考にしてください。

コアバイナリの配置と更新

アーキテクチャに合った単一バイナリを /usr/local/bin/mihomo など固定パスへ配置し、実行権限とバージョン表示を確認します。アップグレードでパスを変えない運用（シンボリックリンク）が systemd の ExecStart を楽にします。setcap を使うなら更新後に capability を再確認してください。

config.yaml と作業ディレクトリの一致

代表的なユーザー配置は ~/.config/mihomo/config.yaml 周辺です。専用ユーザーでサービス化する場合、所有者不一致で「手動は読めるがサービスだけ失敗」が起きがちです。システム直下（/etc/mihomo/ 等）にまとめると方針は明確になりますが、権限管理はより厳格に。購読 URL にトークンがある場合はリポジトリへ載せず、ファイル権限を絞ってください。運用習慣は 購読とノード管理 と併読すると安定します。

YAML で TUN（透過プロキシ）を有効化

tun.enable: true に加え、stack や auto-route、auto-detect-interface はコアのバージョン文書に従います。auto-route は便利ですが、他 VPN やブリッジと競合することがあります。DNS は TUN 単体では完結せず、fake-ip やルールと整合が取れないと「一部ドメインだけ失敗」に見えます。ルール分流のベストプラクティス と FAQ の DNS 説明 を合わせて読んでください。

YAML 断片（バージョンに合わせて調整） 
tun:
  enable: true
  stack: system
  auto-route: true
  auto-detect-interface: true
  dns-hijack:
    - any:53

/dev/net/tun と CAP_NET_ADMIN

/dev/net/tun を開けない場合は権限が第一疑いです。root 実行は簡単ですが攻撃面が広がります。専用ユーザー＋ setcap、または systemd の AmbientCapabilities 付与が一般的です。どちらを選んでも「なぜこの権限が必要か」をメモに残してください。

⚠ リモート注意：誤ったルートは SSH を切断します。コンソールを確保し、まず検証環境で試してください。

systemd ユニット：自動起動とログ

ユーザユニットは ~/.config/systemd/user/、システムは /etc/systemd/system/ です。After=network-online.target で起動競合を減らし、Restart=on-failure を推奨します。WorkingDirectory と mihomo -d は同一を指すようにしてください。

ユーザサービス例（パスは環境に合わせる） 
[Unit]
Description=Mihomo (Clash Meta)
After=network-online.target
Wants=network-online.target

[Service]
Type=simple
WorkingDirectory=%h/.config/mihomo
ExecStart=/usr/local/bin/mihomo -d %h/.config/mihomo
Restart=on-failure
RestartSec=3
AmbientCapabilities=CAP_NET_ADMIN CAP_NET_BIND_SERVICE
CapabilityBoundingSet=CAP_NET_ADMIN CAP_NET_BIND_SERVICE

[Install]
WantedBy=default.target

検証：インターフェースとポリシールーティング

起動後は ip link で TUN 相当のインターフェースを確認し、ip rule / ip route で意図したポリシールーティングかを見ます。ルールが誤っているとトンネルが生きていても宛先がズレます。ルール分流 と突き合わせてください。

コンテナや snap など分離ランタイムはホストとは別ネットワーク名前空間を使うため、「ホストでは動くがコンテナだけ失敗」が起きやすいです。TUN 以前に名前空間/ブリッジを疑うと早いです。

journalctl で見る典型エラー

まず最初の ERROR を読みます。ローカルとリモートは症状が似ます。timeout/TLS ログの読み方 の層別思考がそのまま使えます。「手動だけ成功」なら環境変数・作業ディレクトリ・ユーザー ID を行単位で比較してください。

上流 OSS と配布チャネルの分離

Mihomo / Clash Meta 系は OSS として追跡しやすい一方、一般ユーザー向けの入手経路はサイトのダウンロードページを主にし、GitHub Release は変更履歴やソース確認の補助として切り分けると混乱が減ります。

まとめ

Ubuntu で Clash Linux を運用する鍵は パス・権限・サービス化 の三点が揃うことです。TUN は強力ですが DNS/ルールとセットで考え、systemd はそれを「再現可能な運用」に変えます。GUI が必要でも設定ディレクトリを共有する場合は、二重起動でポートや TUN を奪い合わないよう注意してください。

→ Clash を無料ダウンロードして、より扱いやすいクライアント体験から始めましょう。サーバーで詰めたルールをデスクトップでも一貫して保てます。