mihomoでできること｜機能と具体的な使い方

By /

mihomoでできること｜機能と具体的な使い方 の詳細な説明

インターネットは私たちの生活に不可欠な存在ですが、時には検閲、地域制限、プライバシーの懸念、セキュリティリスクなど、さまざまな課題に直面します。これらの課題を解決し、より自由で安全、そして最適化されたネットワーク環境を実現するための強力なツールとして、「mihomo」（旧Clash Premium）があります。

mihomoは、高性能なネットワークプロキシおよびルーティングツールであり、多様なプロトコル、柔軟なルーティングルール、高度な機能を提供します。この記事では、mihomoで何ができるのか、その主要な機能は何か、そしてそれぞれの機能をどのように具体的に使用するのかについて、約5000語の詳細な説明を行います。

目次

  1. はじめに：mihomoとは何か？

    • mihomoの概要
    • mihomoを使う理由
    • この記事の目的

  2. mihomoの核となる技術：プロキシとルーティング

    • プロキシの基本概念
    • mihomoが対応するプロトコル
    • ルーティングの仕組み
    • ポリシーグループの種類

  3. mihomoの主要機能と詳細設定

    • 基本設定：ポート、ログレベル、モード
    • DNS設定：プライバシーとパフォーマンスの向上
      • ローカルDNSと外部DNS
      • DoT/DoH
      • Fake IP
    • プロキシサーバー設定 (proxies): 対応プロトコルの詳細と設定例
      • Shadowsocks (SS)
      • ShadowsocksR (SSR) – 注意点含む
      • VMess
      • VLESS
      • Trojan
      • Hysteria2
      • TUIC
      • Snell
      • HTTP/Socks5
      • Relay (カスケード/多段プロキシ)
    • ポリシーグループ設定 (proxy-groups): サーバー選択の自動化・柔軟化
      • Select (手動選択)
      • URLTest (遅延テストに基づく自動選択)
      • Fallback (フェイルオーバー)
      • LoadBalance (負荷分散)
      • Relay (多段プロキシグループ)
      • Static (静的グループ)
    • ルール設定 (rules): 通信の振り分けを制御
      • ルールの記述形式と優先順位
      • ルールタイプ詳細 (DOMAIN-SUFFIX, DOMAIN-KEYWORD, DOMAIN, IP-CIDR, GEOIP, SRC-IP-CIDR, PROCESS, MATCH, RULE-SET)
      • DIRECT, REJECT, ポリシーグループへの振り分け
    • プロバイダー機能 (proxy-providers, rule-providers): 設定の動的取得・更新
      • Providerの概念とメリット
      • Proxy Providerの設定
      • Rule Providerの設定
    • その他の高度な設定
      • API設定
      • TUN/TProxyモード (システム全体プロキシ) – 注意点含む
      • Mixed Port (HTTP/Socks5統合ポート)
      • Authentication

  4. mihomoの具体的な使い方：シナリオ別設定例

    • シナリオ1：特定の国内外サイトへのアクセス制御
    • シナリオ2：複数のプロキシサーバーを効率的に使い分ける
    • シナリオ3：ゲーム通信の低遅延化と通常通信の安定化
    • シナリオ4：プライバシー保護を最優先した設定
    • シナリオ5：大規模なルールリスト・プロキシリストの管理

  5. mihomoのインストールと実行

    • mihomo本体 (CLI) の入手
    • 設定ファイルの準備
    • コマンドラインでの実行
    • GUIクライアントの利用

  6. mihomoの運用と管理

    • ログの確認
    • API経由での管理
    • WebUIの利用

  7. トラブルシューティングと注意点

    • 設定ファイルエラー
    • 接続問題
    • パフォーマンス問題
    • 互換性の問題
    • セキュリティ上の注意

  8. まとめ：mihomoの可能性

1. はじめに：mihomoとは何か？

mihomoの概要

mihomoは、元々Clash Premiumとして知られていた高性能なネットワークプロキシおよびルーティングコアの後継プロジェクトです。Go言語で開発されており、クロスプラットフォーム対応（Windows, macOS, Linux, Android, iOSなど）を特徴とします。主にCLI（コマンドラインインターフェース）アプリケーションとして動作しますが、多くのサードパーティ製GUIクライアント（Clash Verge, Clash for Windows, ClashX Pro, V2rayNGなど）がmihomoをコアとして利用しており、より使いやすいインターフェースを提供しています。

mihomoの最大の特徴は、その柔軟性と高機能性です。多様なプロキシプロトコルに対応し、高度なルーティングルールやポリシーグループを組み合わせることで、ユーザーの様々なネットワーク利用シナリオに合わせて通信を細かく制御できます。

mihomoを使う理由

mihomoを利用する主な理由は以下の通りです。

  • インターネットの自由: 地域制限されたコンテンツへのアクセスや、インターネット検閲の回避。
  • セキュリティとプライバシーの向上: 通信の暗号化、匿名化、DNSクエリの保護など。
  • ネットワークの最適化: 低遅延プロキシの利用、ゲームやストリーミング通信の安定化、特定の通信のバイパスなど。
  • 高度な制御: アプリケーション、ドメイン、IPアドレス、地域など、様々な条件に基づいた詳細なルーティング設定。
  • 多様なプロトコル対応: Shadowsocks, VMess, VLESS, Trojan, Hysteria2, TUIC, Snellなど、様々なプロキシプロトコルを単一の設定で管理。

これらの理由から、mihomoはネットワークの自由、セキュリティ、パフォーマンスを追求する多くのユーザーに利用されています。

この記事の目的

この記事では、mihomoの主要な機能を網羅的に解説し、それぞれの機能がどのように動作するのか、そしてそれを実現するための具体的な設定方法を、設定ファイル（config.yaml）の記述例を交えながら詳細に説明します。mihomoの利用を検討している方、あるいは既に利用しているが設定方法をさらに深く理解したい方を対象に、約5000語のボリュームでその強力なポテンシャルを余すことなく紹介することを目指します。

2. mihomoの核となる技術：プロキシとルーティング

mihomoの機能は、基本的にプロキシとルーティングという二つの概念に基づいています。

プロキシの基本概念

プロキシ（Proxy）とは「代理」を意味し、ネットワーク通信においてクライアントとサーバーの間に入り、通信を中継する役割を果たします。クライアントは直接目的のサーバーに接続するのではなく、プロキシサーバーに接続要求を送り、プロキシサーバーが代わりに目的のサーバーと通信を行い、その結果をクライアントに返します。

これにより、以下のような効果が得られます。

  • IPアドレスの隠蔽: 目的サーバーからはプロキシサーバーのIPアドレスが見えるため、クライアントの実際のIPアドレスが隠されます。
  • 通信の加工: プロキシサーバーで通信内容を検査、フィルタリング、あるいは暗号化・復号化することができます。
  • 地域制限の回避: 目的サーバーが特定の地域からのアクセスのみ許可している場合でも、その地域に設置されたプロキシサーバーを経由することでアクセス可能になる場合があります。

mihomoは、多様なプロキシプロトコルに対応したクライアントとして機能します。つまり、ユーザーはmihomoを使って、インターネット上の様々なプロキシサーバーに接続し、そのサーバーを経由して通信を行うことができます。

mihomoが対応するプロトコル

mihomoは、現在利用されている主要なプロキシプロトコルの多くに対応しています。これにより、ユーザーは多様なサーバータイプを選択できます。主な対応プロトコルは以下の通りです。

  • Shadowsocks (SS): シンプルで高速な暗号化プロキシプロトコル。
  • ShadowsocksR (SSR): Shadowsocksから派生したプロトコルで、難読化などの機能が追加されています。ただし、開発は停滞しており、推奨されない場合もあります。
  • VMess: V2Rayプロジェクトで開発されたプロトコル。柔軟な設定、認証、暗号化を提供します。TCP、mKCP、WebSocket、HTTP/2など様々なトランスポートに対応します。
  • VLESS: VMessから派生したプロトコルで、認証は行いますが暗号化は任意（TLSで別途暗号化推奨）とし、シンプルさとパフォーマンスを重視しています。TCP、WebSocket、HTTP/2などに対応します。
  • Trojan: TLSプロトコルになりすますことで、検閲回避に特化したプロトコル。HTTPS通信に見えるため、検閲システムから検知されにくい特徴があります。
  • Hysteria2: QUICをベースにしたプロトコル。UDPを利用し、特に低遅延や不安定なネットワーク環境でのパフォーマンスに優れるとされます。帯域幅の管理機能も持ちます。
  • TUIC: 新しいUDPベースのプロトコル。輻輳制御やパケットロス回復メカニズムを持ち、低遅延・高スループットを目指しています。
  • Snell: Shadowsocksに似たシンプルで軽量なプロトコル。特に作者が開発したその他のツール（Ice/NaiveProxyなど）との連携が考慮されています。
  • HTTP/Socks5: 一般的なプロキシプロトコル。HTTPSプロキシやSocks5プロキシサーバーに接続できます。

mihomoの設定ファイルでは、これらのプロトコルごとに、接続先サーバーのアドレス、ポート、アカウント情報、暗号化方式などを詳細に記述します。

ルーティングの仕組み

ルーティングとは、どの通信をどのプロキシサーバー経由で送るか、あるいは直接インターネットに送るか（バイパス）、あるいはブロックするかを決定するプロセスです。mihomoのルーティング機能は非常に強力で、柔軟な「ルールベース」の仕組みを採用しています。

ユーザーはあらかじめ設定ファイルに「ルール」を記述します。mihomoは発生した通信（コネクション）に対して、これらのルールを上から順に評価していきます。そして、最初にマッチしたルールの指示に従って、その通信の宛先を決定します。宛先としては以下のいずれかになります。

  • DIRECT: プロキシを経由せず、直接インターネットに接続します。
  • REJECT: 通信をブロックします。
  • ポリシーグループ: 定義されたポリシーグループに通信を転送し、グループ内の設定（例：遅延テストで最適なサーバーを選択、手動で指定したサーバーを使用）に従って最終的なプロキシサーバーが決定されます。

ルールの記述には、宛先ドメイン、IPアドレス、地理情報、通信を発行したプロセスなど、様々な条件を使用できます。

ポリシーグループの種類

ポリシーグループは、複数のプロキシサーバーや他のポリシーグループをまとめたものです。ルールによって通信がポリシーグループに振り分けられると、グループの設定に基づいて使用するプロキシサーバーが決定されます。mihomoがサポートする主なポリシーグループのタイプは以下の通りです。

  • Select: グループに含まれるサーバーや他のグループの中から、ユーザーが手動で一つを選択します。最も基本的なタイプです。
  • URLTest: グループに含まれるプロキシサーバーに対して定期的に遅延テストを行い、最も遅延が低いサーバーを自動的に選択します。高速なサーバーを自動で選びたい場合に便利です。
  • Fallback: グループに含まれるプロキシサーバーをリスト順にテストし、最初に接続に成功したサーバーを使用します。リストの最初のサーバーが利用できない場合、次のサーバーに自動的に切り替わります（フェイルオーバー）。安定性を重視する場合に有効です。
  • LoadBalance: グループに含まれる複数のサーバーに通信を分散させます。複数のサーバーがある場合に帯域幅を合計したい場合などに利用できます。ただし、実装によってはセッション維持に課題がある場合もあります。
  • Relay: 複数のプロキシサーバーを順番に経由する多段プロキシ（カスケードプロキシ）を設定できます。例えば、「プロキシA」->「プロキシB」のように通信を中継したい場合に利用します。
  • Static: 単純にリストされたサーバーやグループを保持するだけで、独自の選択ロジックは持ちません。他のグループタイプの参照元として使われることが多いです。

ポリシーグループを組み合わせることで、「日本のサイトは日本のサーバー群（URLTest）を経由し、海外の特定サイトは手動選択グループから選び、その他の海外サイトは遅延テストグループ（URLTest）を経由し、国内サイトは直接接続」といった複雑なルーティング戦略を実現できます。

3. mihomoの主要機能と詳細設定

mihomoの機能は、主に設定ファイルであるconfig.yamlに記述されます。このファイルはYAML形式で記述され、mihomoのすべての動作を定義します。以下に、主要な機能とそれに関連するconfig.yamlの設定項目を詳細に解説します。

基本設定：ポート、ログレベル、モード

mihomoが待ち受けるプロキシポートや、ログの詳細度、全体的なルーティングモードなどを設定します。

“`yaml

接続を待ち受けるポート設定

port: 7890 # HTTP プロキシポート (デフォルト)
socks-port: 7891 # Socks5 プロキシポート (デフォルト)

redir-port: 7892 # リダイレクトモード用ポート (Linuxのiptablesなどと連携)

tproxy-port: 7893 # TProxyモード用ポート (Linuxのiptablesなどと連携)

mixed-port: 7894 # HTTP/Socks5 両方を受け付けるポート

LANからの接続を許可するか (true/false)

allow-lan: true

待ち受けアドレス (LAN接続を許可する場合 ‘0.0.0.0’ が一般的)

bind-address: ‘0.0.0.0’

全体的なルーティングモード (rule/global/direct)

rule: ルールに基づいてルーティング (最も一般的)

global: すべての通信をプロキシ経由 (MATCHルールのように振る舞う)

direct: すべての通信を直接接続 (ほとんど使わない)

mode: rule

ログレベル (debug/info/warning/error/silent)

log-level: info

その他の基本設定

authentication: # HTTP/Socks5 プロキシの認証設定 (オプション)

– “user1:pass1”

– “user2:pass2”

“`

  • port, socks-port, mixed-port: mihomoがクライアントからの接続を待ち受けるポートを指定します。通常はこれらのポートをOSのプロキシ設定やアプリケーションのプロキシ設定で指定します。
  • allow-lan, bind-address: allow-lan: trueに設定すると、同じローカルネットワーク内の他のデバイスからmihomoインスタンスに接続できるようになります。bind-addressを0.0.0.0に設定することで、すべてのネットワークインターフェースからの接続を受け付けます。
  • mode: 全体的なルーティングの挙動を決定します。通常はruleに設定し、詳細なルーティングはrulesセクションで定義します。
  • log-level: ログの出力レベルを調整します。問題が発生した場合はdebugに設定すると詳細な情報が得られます。
  • authentication: HTTP/Socks5プロキシに認証を設定したい場合に利用します。ユーザー名とパスワードのペアをリストで指定します。

DNS設定：プライバシーとパフォーマンスの向上

mihomoは独自のDNSサーバー機能を内蔵しており、DNSクエリのルーティングや暗号化、偽装（Fake IP）などを行うことができます。これにより、DNSレベルでの検閲回避、プライバシー保護、パフォーマンス向上などが実現できます。

“`yaml
dns:
enable: true # DNS機能を有効化
listen: 0.0.0.0:53 # DNSクエリを待ち受けるアドレスとポート (通常はUDP 53)
# enhanced-mode: redir-host または fake-ip
# redir-host: ホスト名解決をDNSクエリの応答として返す (標準的)
# fake-ip: 応答として偽のIPアドレスを返し、その後の通信をインターセプト (一部アプリとの互換性向上やパフォーマンス向上)
enhanced-mode: fake-ip

# Fake IP の範囲 (fake-ipモード時必須)
fake-ip-range: 198.18.0.1/16 # RFC6890で予約されたプライベートIP範囲を使用するのが一般的

# 名前解決に使用するDNSサーバーリスト
nameserver:
– 114.114.114.114 # 中国国内向けDNS (例)
– 223.5.5.5 # 中国国内向けDNS (例)
– 1.1.1.1 # Cloudflare (DoT/DoH対応)
– 8.8.8.8 # Google (DoT/DoH対応)

# fallback DNSサーバーリスト (nameserverのサーバー全てで解決できない場合に試す)
fallback:
– tls://1.0.0.1:853 # Cloudflare DoT
– https://8.8.8.8/dns-query # Google DoH
– 8.8.4.4 # Google (非暗号化)

# fallback-filter: fallback DNSを使用する条件
fallback-filter:
geoip: true # GeoIPに基づき、海外IPアドレスへの名前解決を優先的にfallbackで試す
geoip-code: CN # 例: 中国国内からの名前解決はfallbackを使わない (geoip: true と併用)
ipcidr: # 指定したIP範囲への名前解決はfallbackを使わない
– “0.0.0.0/8”
– “10.0.0.0/8”
– “100.64.0.0/10”
– “127.0.0.0/8”
– “169.254.0.0/16”
– “172.16.0.0/12”
– “192.0.0.0/24”
– “192.0.2.0/24”
– “192.31.196.0/24”
– “192.52.193.0/24”
– “192.88.99.0/24”
– “192.168.0.0/16”
– “192.184.0.0/15”
– “199.6.1.1/24”
– “198.51.100.0/24”
– “203.0.113.0/24”
– “240.0.0.0/4”
– “255.255.255.255/32”
domain: # 指定したドメインリストはfallbackを使わない
– “+.lan”

# ドメインに対して名前解決を試みる順序
# default: hosts -> enhanced-mode logic -> nameserver -> fallback
# enhanced-mode: enhanced-mode logic -> nameserver -> fallback
# nameserver-only: nameserver -> fallback
# rule: ルールでDNSサーバーを指定 (高度)
strategy: default

# hosts ファイルのような静的な名前解決エントリ
# hosts:
# ‘example.com’: ‘1.2.3.4’

# DNSルール (特定のドメインの名前解決に使用するDNSサーバーを指定) – strategy: rule の場合に使用
# rules:
# – DOMAIN-SUFFIX,google.com,8.8.8.8
# – GEOIP,CN,114.114.114.114
# – MATCH,fallback # 上記ルールにマッチしない場合はfallbackを使用

“`

  • enable, listen: DNSサーバー機能の有効化と待ち受けポートです。他のアプリケーションにこのポートをDNSサーバーとして指定することで、mihomo経由で名前解決を行うことができます。
  • enhanced-mode: DNS解決のモードを設定します。fake-ipモードは、ドメイン名を直接解決する代わりに、事前に予約されたプライベートIPアドレス（Fake IP）を応答として返します。実際の通信が発生した際に、mihomoがこのFake IPをインターセプトし、元のドメイン名を調べてルーティングを行います。これにより、特にルール評価においてIPアドレス解決の待ち時間を減らし、パフォーマンスを向上させることが期待できます。ただし、一部のアプリケーションで互換性の問題が発生する可能性もあります。
  • fake-ip-range: fake-ipモードで使用する偽のIPアドレスの範囲を指定します。他のネットワークと競合しない範囲（例: 198.18.0.1/16）を使用する必要があります。
  • nameserver: 通常の名前解決に使用するDNSサーバーをリストします。IPアドレスまたはtls://やhttps://で始まるURLでDoT/DoHサーバーを指定できます。
  • fallback: nameserverリストのサーバー全てで名前解決できなかった場合に試す代替DNSサーバーをリストします。通常はnameserverとは異なるサーバー、特にDoT/DoHサーバーを指定してプライバシーを強化します。
  • fallback-filter: fallbackサーバーを使用する条件を細かく制御します。例えば、国内IPへの名前解決ではfallbackを使わない、特定のドメインではfallbackを使わない、といった設定が可能です。geoip: trueは、GeoIP情報に基づき、海外のIPアドレスへの名前解決に対して優先的にfallbackサーバーを使用させるための一般的な設定です。
  • strategy: 名前解決の試行順序を制御します。fake-ipモードを使用する場合はenhanced-modeが推奨されることがありますが、デフォルトのdefaultでも通常は問題ありません。
  • hosts: ローカルのhostsファイルのように、特定のドメインに対するIPアドレスを静的に定義できます。
  • rules: strategy: ruleと組み合わせることで、特定のドメインや条件に対して使用するDNSサーバーを細かく指定できます。これは非常に高度な設定です。

DNS設定は、mihomoの機能の中でも特に重要かつ強力な部分の一つです。適切に設定することで、検閲やトラッキングを防ぎつつ、高速な名前解決を実現できます。

プロキシサーバー設定 (proxies)

proxiesセクションでは、mihomoが接続できる個々のプロキシサーバーの詳細を定義します。プロトコルごとに記述形式が異なります。以下に主要なプロトコルの設定例を示します。

すべてのプロキシ設定に共通する項目：

  • name: このプロキシサーバーの名前（ポリシーグループやルールで参照するために使用）
  • type: プロトコルタイプ (ss, vmess, vless, trojan, hysteria2, tuic, snell, http, socks5, relay)
  • server: 接続先サーバーのホスト名またはIPアドレス
  • port: 接続先サーバーのポート番号

Shadowsocks (SS)

yaml
proxies:
- name: "MySSProxy"
type: ss
server: your_ss_server_address
port: 8443
cipher: aes-265-gcm # または chacha20-poly1305 など
password: your_password
udp: true # UDP プロキシを有効にするか

  • cipher: 暗号化方式を指定します。サーバーと一致させる必要があります。
  • password: 接続パスワードを指定します。
  • udp: Shadowsocks UDPプロキシに対応しているサーバーの場合、これをtrueにすることでUDP通信もプロキシ経由で可能になります（ゲームや一部のビデオストリーミングなどで重要）。

ShadowsocksR (SSR)

SSRは非推奨となることが多いですが、サポートされています。設定項目はより複雑です。

yaml
proxies:
- name: "MySSRProxy"
type: ssr
server: your_ssr_server_address
port: 8443
password: your_password
protocol: origin # プロトコルプラグイン
protocol-param: "" # プロトコルプラグインパラメータ
obfs: plain # 難読化プラグイン
obfs-param: "" # 難読化プラグインパラメータ
cipher: aes-265-cfb
udp: true

SSRの設定はサーバー側の設定と完全に一致させる必要があります。

VMess

VMessは柔軟性が高いプロトコルです。WebSocket + TLS が一般的な構成です。

“`yaml
proxies:
– name: “MyVMessProxy”
type: vmess
server: your_vmess_server_address
port: 443
uuid: your_uuid # ユーザーUUID
alterId: 0 # Alter ID (最近は0が推奨されることが多い)
cipher: auto # “auto” が推奨
udp: true
# トランスポート設定 (例: WebSocket over TLS)
network: ws
tls: true
servername: your_vmess_server_address # TLS SNI
ws-path: “/your_ws_path” # WebSocket パス
ws-headers: # WebSocket ヘッダー (オプション)
Host: your_vmess_server_address

# TCP with TLS の例
# – name: “MyVMessTCPProxy”
# type: vmess
# server: your_vmess_server_address
# port: 443
# uuid: your_uuid
# alterId: 0
# cipher: auto
# udp: true
# network: tcp
# tls: true
# servername: your_vmess_server_address
“`

  • uuid, alterId: サーバー側で設定されたユーザー認証情報です。
  • cipher: 暗号化方式。通常autoで問題ありません。
  • network: トランスポート層のプロトコルを指定します (tcp, kcp, ws, http, quic)。
  • tls: TLSによる暗号化を有効にするか。WebSocketやTCPと組み合わせて安全な通信を確立するために重要です。
  • servername: TLSのServer Name Indication (SNI) を指定します。証明書検証などに使用されます。
  • ws-path, ws-headers: WebSocketトランスポート使用時のパスやカスタムヘッダーを指定します。

VLESS

VLESSはVMessよりもシンプルでパフォーマンスを重視しています。通常、TLSと組み合わせます。

“`yaml
proxies:
– name: “MyVLESSProxy”
type: vless
server: your_vless_server_address
port: 443
uuid: your_uuid
udp: true
# トランスポート設定 (例: WebSocket over TLS)
network: ws
tls: true
servername: your_vless_server_address
ws-path: “/your_ws_path”

# reality 設定 (実験的な機能)
# – name: “MyVLESSRealityProxy”
# type: vless
# server: your_vless_server_address
# port: 443
# uuid: your_uuid
# udp: true
# network: tcp
# tls: true
# servername: your_reality_servername
# reality-opts:
# public-key: your_reality_public_key
# short-id: your_reality_short_id # 16進数
“`

VLESSの設定はVMessと似ていますが、Alter IDがありません。RealityはVLESSプロトコルの拡張機能で、より高度な難読化技術を利用します。

Trojan

TrojanはTLSに偽装するプロトコルです。

yaml
proxies:
- name: "MyTrojanProxy"
type: trojan
server: your_trojan_server_address
port: 443
password: your_password
udp: true
tls: true # Trojanは常にTLSを使用
servername: your_trojan_server_address
alpn: # オプション: ALPN 設定
- http/1.1

Trojanの設定は比較的シンプルで、サーバー、ポート、パスワード、TLS関連の設定が主です。

Hysteria2

Hysteria2はUDPベースの新しいプロトコルです。

yaml
proxies:
- name: "MyHysteria2Proxy"
type: hysteria2
server: your_hysteria2_server_address
port: 443
password: your_password
udp: true # Hysteria2はUDPベース
tls: true
servername: your_hysteria2_server_address
alpn: # オプション: ALPN 設定
- h2
- http/1.1
# オプション: 帯域幅制限 (上り/下り)
# up: 100 Mbps
# down: 500 Mbps

Hysteria2はUDPプロトコルを使用するため、udp: trueは常に必要です。帯域幅制限などのオプションも設定可能です。

TUIC

TUICもUDPベースの新しいプロトコルです。

yaml
proxies:
- name: "MyTUICProxy"
type: tuic
server: your_tuic_server_address
port: 443
password: your_password
uuid: your_uuid # または certificate
udp: true # TUICはUDPベース
tls: true
servername: your_tuic_server_address
alpn:
- h3
# オプション: バージョン指定
# version: 5

TUICはパスワードまたはUUIDで認証を行います。

Snell

Snellはシンプルで軽量なプロトコルです。

yaml
proxies:
- name: "MySnellProxy"
type: snell
server: your_snell_server_address
port: 443
psk: your_pre_shared_key # 事前共有キー
udp: true
tls: true
# オプション: バージョン指定
# version: 4

Snellは事前共有キー（PSK）で認証を行います。

HTTP/Socks5

一般的なHTTP/Socks5プロキシサーバーに接続する場合です。

“`yaml
proxies:
– name: “MyHTTPProxy”
type: http
server: your_http_proxy_address
port: 8080
# オプション: 認証
# username: your_username
# password: your_password

  • name: “MySocks5Proxy”
    type: socks5
    server: your_socks5_proxy_address
    port: 1080
    udp: true
    # オプション: 認証
    # username: your_username
    # password: your_password
    # オプション: TLS (Socks5 over TLS)
    # tls: true
    # servername: your_socks5_proxy_address
    “`

HTTPプロキシは通常TCPのみ、Socks5プロキシはTCPとUDP（UDP Associate）に対応します。認証情報やTLS設定も可能です。

Relay (カスケード/多段プロキシ)

relayタイプは、既存のプロキシを複数経由する多段プロキシを設定する場合に使用します。

“`yaml
proxies:
– name: “ProxyA”
type: ss
… # ProxyA の設定
– name: “ProxyB”
type: vmess
… # ProxyB の設定

# ProxyA -> ProxyB の順に経由する Relay プロキシ
– name: “Relay_A_via_B”
type: relay
# 経由するプロキシをリスト順に指定
proxies:
– ProxyA
– ProxyB
# RelayタイプはUDPをサポートしません
# udp: true # <- これは書かない
“`

relayタイプは、プライバシーをさらに強化したい場合や、特定のネットワーク経路を構築したい場合に利用できます。ただし、パフォーマンスは低下しやすい傾向があります。

ポリシーグループ設定 (proxy-groups)

proxy-groupsセクションでは、複数のプロキシサーバーや他のポリシーグループをまとめた「ポリシーグループ」を定義します。ルールはこのポリシーグループに対して通信を振り分けます。

すべてのポリシーグループに共通する項目：

  • name: このポリシーグループの名前（ルールや他のグループから参照）
  • type: グループのタイプ (select, urltest, fallback, loadbalance, relay, static)
  • proxies: このグループに含まれるプロキシサーバーまたは他のポリシーグループの名前のリスト

Select

手動でグループ内のサーバーを選択する場合。最も基本的なグループタイプです。

“`yaml
proxy-groups:
– name: “Proxy”
type: select
# グループに含まれるプロキシサーバーまたは他のグループの名前リスト
proxies:
– “MySSProxy”
– “MyVMessProxy”
– “Direct” # 後述の Direct グループも含まれる
– “Reject” # 後述の Reject グループも含まれる

# Direct と Reject は通常 Static グループとして定義される
– name: “Direct”
type: direct # Direct は特別な Static グループタイプ
proxies: [] # Direct グループにはプロキシは含まれない

  • name: “Reject”
    type: reject # Reject は特別な Static グループタイプ
    proxies: [] # Reject グループにはプロキシは含まれない
    “`

DirectとRejectは、特別なstaticグループであり、それぞれ直接接続とブロックを表します。これらもポリシーグループとして扱われるため、selectグループなどに含めることができます。

URLTest

グループ内のサーバーに対して定期的に遅延テストを行い、最も遅延が低いサーバーを自動選択します。

yaml
proxy-groups:
- name: "AutoSelectProxy"
type: urltest
proxies:
- "Tokyo_SS"
- "Osaka_VMess"
- "Seoul_Trojan"
# URLTest の設定
url: http://www.gstatic.com/generate_204 # テストに使用するURL (応答が204 No ContentであるURLが推奨)
interval: 300 # テスト間隔 (秒)
timeout: 5000 # テストタイムアウト (ミリ秒)

urltestタイプは、多数のプロキシサーバーがあり、常に最適なサーバーを選びたい場合に非常に便利です。ただし、定期的なテストはサーバーに負荷をかける可能性があります。

Fallback

グループ内のサーバーリストを上から順に試行し、最初に接続できたサーバーを使用します。フェイルオーバー（冗長化）に役立ちます。

yaml
proxy-groups:
- name: "StableProxy"
type: fallback
proxies:
- "Primary_VMess"
- "Secondary_SS"
- "Emergency_Trojan"
# Fallback の設定
url: http://www.gstatic.com/generate_204
interval: 300
timeout: 5000

fallbackタイプは、安定性を重視し、メインのサーバーがダウンした場合に自動的にバックアップサーバーに切り替えたい場合に適しています。

LoadBalance

グループ内のサーバーに通信を分散させます。帯域幅の合計を増やしたい場合などに有効です。

yaml
proxy-groups:
- name: "LoadBalancedProxy"
type: loadbalance
proxies:
- "ServerA"
- "ServerB"
- "ServerC"
# LoadBalance の設定
url: http://www.gstatic.com/generate_204
interval: 300
timeout: 5000
# 負荷分散方式 (round-robin/least-connectionなど - mihomoでサポートされる方式を確認)
# strategy: round-robin # このオプションは mihomo でサポートされているか要確認

LoadBalanceの具体的な動作（例えば、セッション単位かコネクション単位か、セッション固定の有無など）は実装に依存します。mihomoでは主にラウンドロビン方式が採用されることが多いようです。

Relay (グループ)

このタイプのrelayグループは、proxiesセクションで定義したrelayプロキシとは異なり、ポリシーグループとして機能します。これは、例えば「海外サイトは地域選択グループを経由する」->「地域選択グループで選ばれたサーバー」->「特定のプロキシサーバー（例：自宅の固定IPプロキシ）」のように、グループと個別のプロキシを組み合わせて多段プロキシを設定する場合に利用できます。

“`yaml
proxy-groups:
– name: “OverseasRegionSelect”
type: urltest
proxies:
– “US_Server”
– “JP_Server”

# OverseasRegionSelect グループで選択されたサーバーを経由し、さらに HomeProxy を経由する
– name: “OverseasViaHome”
type: relay
proxies:
– OverseasRegionSelect
– HomeProxy # これは proxies セクションで定義された単一のプロキシ名

“`

Static

他のグループタイプやルールから参照される、単なるプロキシやグループのリストを保持するグループです。DirectとRejectはこのタイプです。

yaml
proxy-groups:
- name: "MyServers"
type: static
proxies:
- "Server1"
- "Server2"
- "Server3"
# Static グループにproxies以外の設定 (url, intervalなど) は記述しない

ルール設定 (rules)

rulesセクションは、mihomoのルーティングの中核をなす部分です。ここには、通信をどのポリシーグループ（またはDIRECT/REJECT）に振り分けるかを決定するための条件とアクションのペアをリスト形式で記述します。

“`yaml
rules:
# ルールは上から順に評価される。最初にマッチしたルールが適用される。
# 記述形式: 条件,値,アクション[,追加パラメータ]

# 例: 特定のドメインを直接接続
– DOMAIN-SUFFIX,cn,DIRECT # 中国国内のドメインは直接接続
– DOMAIN-SUFFIX,example.com,DIRECT # example.com およびサブドメインは直接接続
– DOMAIN,google.com,Proxy # google.com は Proxy グループへ (DOMAIN はサブドメインを含まない)
– DOMAIN-KEYWORD,facebook,Proxy # ドメイン名に “facebook” を含むものは Proxy グループへ

# 例: 特定のIPアドレス/範囲を直接接続またはブロック
– IP-CIDR,192.168.1.0/24,DIRECT # ローカルネットワークは直接接続
– IP-CIDR,10.0.0.0/8,DIRECT
– IP-CIDR,127.0.0.1/32,DIRECT
– IP-CIDR,1.2.3.4/32,REJECT # 特定のIPをブロック
– IP-CIDR6,::1/128,DIRECT # IPv6 ローカルホスト

# 例: 地域情報 (GeoIP) に基づく振り分け
– GEOIP,CN,DIRECT # CN (中国) のIPアドレスは直接接続
– GEOIP,US,Proxy # US (米国) のIPアドレスは Proxy グループへ
– GEOIP,LAN,DIRECT # LAN IP は直接接続 (IP-CIDR ローカルIPリストと同等)

# 例: プロセス名に基づく振り分け (Windows, macOS, Linux でサポート)
# – PROCESS-NAME,firefox.exe,Proxy # Firefoxからの通信は Proxy グループへ (Windows)
# – PROCESS-NAME,Safari,Proxy # Safariからの通信は Proxy グループへ (macOS)
# – PROCESS-NAME,chrome,Proxy # Chromeからの通信は Proxy グループへ (Linux)
# – PROCESS-PATH,/Applications/MyApp.app/*,Proxy # アプリケーションパスで指定 (macOS)

# 例: ポート番号に基づく振り分け
# – DST-PORT,53,Proxy # 宛先ポートが53 (DNS) の通信は Proxy グループへ
# – SRC-PORT,22,REJECT # 送信元ポートが22 (SSH) の通信はブロック (非推奨, 誤動作の可能性)

# 例: RULE-SET を参照
# – RULE-SET,lan,DIRECT # 外部のルールセットファイル “lan.yaml” で定義されたルールを適用

# 例: すべての他の通信に対する最終ルール
# ルールリストの最後に記述する必要がある
– MATCH,Proxy # 上記どのルールにもマッチしない通信は全て Proxy グループへ

“`

  • ルールの優先順位: ルールはリストの上から順に評価されます。最初にマッチしたルールが適用されるため、より具体的なルール（例: DOMAIN,google.com,Proxy）を一般的なルール（例: DOMAIN-SUFFIX,com,Proxy）よりも先に記述する必要があります。通常、MATCHルールはリストの最後に記述され、どのルールにもマッチしない「デフォルト」の挙動を定義します。
  • ルールタイプ: DOMAIN-SUFFIX, DOMAIN-KEYWORD, DOMAIN, IP-CIDR, GEOIP, PROCESS-NAMEなど、通信の様々な属性に基づいて条件を指定できます。
  • アクション: マッチした場合に実行するアクションを指定します。DIRECT (直接接続), REJECT (ブロック), ポリシーグループの名前（指定したポリシーグループへ振り分け）のいずれかです。

rulesセクションは、mihomoの動作をカスタマイズする上で最も重要な部分です。目的に応じて様々なルールを組み合わせることで、非常に詳細なルーティング制御が可能になります。

プロバイダー機能 (proxy-providers, rule-providers)

プロバイダー機能は、プロキシサーバーリストやルールリストを外部のURLから動的に取得・更新するための機能です。これにより、手動で設定ファイルを編集する手間を省き、最新のリストを維持できます。

Proxy Provider

外部のURLからプロキシサーバーのリストをYAMLまたはBase64形式で取得し、プロキシグループ内で参照できるようにします。

“`yaml
proxy-providers:
MyRemoteProxies: # プロバイダー名
type: http # 取得元タイプ (http, file)
url: “http://example.com/proxies.yaml” # プロキシリストを提供するURL
interval: 3600 # 更新間隔 (秒)
# path: ./providers/proxies.yaml # ローカルファイルの場合のパス
# health-check: # ヘルスチェック設定 (オプション)
# enable: true
# url: http://www.gstatic.com/generate_204
# interval: 300

proxy-groups:
– name: “AutoSelectFromProvider”
type: urltest
# プロバイダー名を reference プレフィックス付きで指定
proxies:
– &MyRemoteProxies # プロバイダー全体を参照

# あるいは、プロバイダー内の特定のプロキシを参照 (非推奨、プロバイダーは全体参照が一般的)
# – name: “ManualSelectFromProvider”
# type: select
# proxies:
# – MyRemoteProxies.ProxyName1 # プロバイダー名.プロキシ名
# – MyRemoteProxies.ProxyName2

“`

Proxy Providerは、多数のサーバーを頻繁に変更する場合や、購読サービスなどで提供されるプロキシリストを利用する場合に便利です。intervalで指定した間隔で自動的にリストを更新します。health-checkを設定することで、プロバイダー内のプロキシサーバーが利用可能か自動でチェックできます。

Rule Provider

外部のURLからルールリストをYAML形式で取得し、rulesセクション内で参照できるようにします。

“`yaml
rule-providers:
MyRemoteRules: # プロバイダー名
type: http
url: “http://example.com/rules.yaml” # ルールリストを提供するURL
interval: 86400 # 更新間隔 (秒)
# path: ./providers/rules.yaml # ローカルファイルの場合のパス
# behavior: domain / ipcidr / classical
# behavior は、提供されるルールの種類に応じて設定。通常は classical。
# classical: DOMAIN, IP-CIDR, GEOIP, MATCH など混在
# domain: DOMAIN, DOMAIN-SUFFIX, DOMAIN-KEYWORD のみ
# ipcidr: IP-CIDR, GEOIP のみ
behavior: classical

rules:
# RemoteRules プロバイダーのルールを組み込む
– RULE-SET,MyRemoteRules,Proxy # MyRemoteRules で定義されたルールを評価し、マッチしたら Proxy グループへ
# または、RemoteRules で定義されたアクションを使用
# – RULE-SET,MyRemoteRules,ノード名またはポリシーグループ名 # ← プロバイダーファイル内でアクションが定義されている場合

# その他のローカルで定義したルール
– DOMAIN-SUFFIX,local.lan,DIRECT
– MATCH,DIRECT # プロバイダーのルールにもマッチせず、ローカルのルールにもマッチしない場合は直接接続
“`

Rule Providerは、巨大なドメイン/IPリストに基づくルーティングや、コミュニティが提供する最新の検閲回避ルールなどを利用するのに役立ちます。behaviorは提供されるルールリストの内容に合わせて設定します。rulesセクション内でRULE-SETタイプを使用してプロバイダーを参照します。

その他の高度な設定

API設定

mihomoはHTTP APIを提供しており、外部から設定の変更、統計情報の取得、接続リストの確認などを行うことができます。多くのGUIクライアントはこのAPIを使用してmihomoコアを制御しています。

yaml
api:
enable: true # API を有効化
listen: 127.0.0.1:9090 # 待ち受けアドレスとポート (セキュリティのため通常はローカルホストのみ)
secret: "your_api_secret" # APIアクセス用のシークレットキー (設定必須)

APIを有効にする場合は、secretに安全なパスワードを設定し、listenアドレスを必要に応じて制限することが重要です。

TUN/TProxyモード

mihomo本体は基本的にHTTP/Socks5プロキシとして動作しますが、tunやtproxy設定（OSによってサポート状況が異なる）を組み合わせることで、システム全体の通信を透過的にmihomo経由にルーティングできます。これにより、プロキシ設定に対応していないアプリケーションの通信もmihomoで制御できるようになります。ただし、これらの設定はOSのネットワークスタックに深く関わるため、設定がより複雑になり、管理者権限が必要になる場合があります。多くのGUIクライアントは、このTUN/TProxy機能を利用して「システムプロキシ」機能を提供しています。

“`yaml

tun モード設定例 (macOS, Windows, Linux)

tun:

enable: true

stack: system # または gvisor

dns-hijack:

– 0.0.0.0:53

auto-route: true # 自動でルーティングテーブルを変更するか (通常 true)

auto-detect-interface: true # インターフェースを自動検出するか

strict-route: false # Strict route mode

tproxy モード設定例 (Linux のみ)

tproxy:

enable: true

listen: 0.0.0.0:7893 # TProxy 用ポート (iptables と連携)

udp: true # UDP TProxy を有効化

“`

これらのモードは高度な設定であり、OSのネットワーク設定（例: Linuxのiptables）と連携して動作します。具体的な設定方法はOSや利用するGUIクライアントによって異なります。

Mixed Port

mixed-portを設定すると、指定した単一のポートでHTTPプロキシとSocks5プロキシの両方の接続を受け付けるようになります。これは、クライアント側で両方のプロトコルをサポートしている場合に、設定を簡略化できます。

“`yaml

既に基本設定のセクションで記述済み

mixed-port: 7894

“`

Authentication

authenticationを設定すると、mihomoが待ち受けるHTTP/Socks5プロキシポートに対して認証を要求できます。

“`yaml

既に基本設定のセクションで記述済み

authentication:

– “user1:pass1”

– “user2:pass2”

“`

4. mihomoの具体的な使い方：シナリオ別設定例

ここでは、mihomoの主要機能を組み合わせた具体的な利用シナリオと、それに合わせた設定例（config.yamlのスニペット）を紹介します。

シナリオ1：特定の国内外サイトへのアクセス制御

目的:
* 一般的な国内サイトへのアクセスは直接接続で高速化。
* 海外の特定のウェブサイト（例: Twitter, Facebook, Googleなど）へのアクセスはプロキシ経由。
* その他の海外サイトはデフォルトでプロキシ経由。
* 広告ドメインをブロック。

必要な機能:
* 複数のプロキシサーバー (proxies)
* 手動選択可能なポリシーグループ (proxy-groups – Select)
* ドメイン、IP、地域、特定のリストに基づくルール (rules – DOMAIN-SUFFIX, GEOIP, RULE-SET, MATCH)
* ブロック用ポリシーグループ (proxy-groups – Reject)

設定例 (config.yaml スニペット):

“`yaml

基本設定 (ポート, DNSなど省略)

…

proxies:
# ここに利用可能なプロキシサーバーを定義
– name: “MyOverseasProxy1”
type: ss
server: us.example.com
port: 8443
cipher: aes-256-gcm
password: password1
udp: true

  • name: “MyOverseasProxy2”
    type: vmess
    server: jp.example.com
    port: 443
    uuid: your-uuid-2
    network: ws
    tls: true
    servername: jp.example.com
    ws-path: /path2
    udp: true

proxy-groups:
# ユーザーが手動で選択する主要なプロキシグループ
– name: “Proxy”
type: select
proxies:
– “MyOverseasProxy1”
– “MyOverseasProxy2”
– “DIRECT” # 直接接続オプションも選択肢に入れる
# – “AutoSelectOverseas” # 後述の自動選択グループも選択肢にできる

# ブロック用グループ (固定)
– name: “REJECT”
type: reject
proxies: []

# 直接接続用グループ (固定)
– name: “DIRECT”
type: direct
proxies: []

rules:
# 広告ドメインをブロック (外部 Rule Provider を参照)
# 広告ドメインの Rule Provider を別途設定する必要があります (下記参照)
# – RULE-SET,Ads,REJECT

# 中国国内のIPアドレスは直接接続 (GeoIP データベースが必要)
– GEOIP,CN,DIRECT

# ローカルネットワークは直接接続
– GEOIP,LAN,DIRECT
– IP-CIDR,127.0.0.0/8,DIRECT
– IP-CIDR,192.168.0.0/16,DIRECT
– IP-CIDR,10.0.0.0/8,DIRECT
– IP-CIDR,172.16.0.0/12,DIRECT

# 例: 特定の海外サイトは Proxy グループへ
– DOMAIN-SUFFIX,twitter.com,Proxy
– DOMAIN-SUFFIX,facebook.com,Proxy
– DOMAIN-SUFFIX,google.com,Proxy
– DOMAIN-SUFFIX,youtube.com,Proxy
# 他にもプロキシ経由したい特定のドメインをリストアップ

# 例: 中国以外のIPアドレスへの通信はデフォルトで Proxy グループへ
# (GEOIP,CN,DIRECT で先に中国国内IPは除外されている前提)
– GEOIP,OTHER,Proxy # OTHER は CN 以外の全ての国/地域を指す特別なキーワード

# 上記ルールにマッチしない、かつ GEOIP,OTHER にもマッチしない (主に国内サイト) は直接接続
– MATCH,DIRECT
“`

この設定では、まずGeoIP情報を使って国内IP（中国含む）へのアクセスをDIRECTに振り分けます。次に、特定の海外ドメイン（Twitterなど）をProxyグループへ振り分けます。GEOIP,OTHER,Proxyルールは、それまでのルールにマッチせず、かつ国内IPでもない通信（つまり、特定の海外サイト以外でGeoIPデータベースにある海外IP）をProxyグループへ送ります。最後にMATCH,DIRECTで、GeoIPデータベースにないIPや、上記どのルールにもマッチしない通信をすべて直接接続に戻します。

シナリオ2：複数のプロキシサーバーを効率的に使い分ける

目的:
* 海外サイトへのアクセスに、複数の利用可能なプロキシサーバーの中から自動で最も高速なサーバーを選択したい。
* もし自動選択されたサーバーが利用できなくなった場合、自動で別のサーバーに切り替えたい。
* 特定の目的（例: ストリーミング）には別のサーバー群を使用したい。

必要な機能:
* 複数のプロキシサーバー (proxies)
* 遅延テストに基づく自動選択ポリシーグループ (proxy-groups – URLTest)
* フェイルオーバーポリシーグループ (proxy-groups – Fallback)
* 手動選択可能なポリシーグループ (proxy-groups – Select)
* ドメイン/IPなどに基づくルーティングルール (rules)

設定例 (config.yaml スニペット):

“`yaml

基本設定 (ポート, DNSなど省略)

…

proxies:
# ここに利用可能な様々なプロキシサーバーを定義
– name: “JP-Server-1”
type: vmess
…
– name: “US-Server-A”
type: ss
…
– name: “SG-Server-X”
type: trojan
…
– name: “StreamingServer”
type: vless
… # ストリーミングに適したサーバー

proxy-groups:
# 全般的な海外アクセス用自動選択グループ
– name: “OverseasAutoSelect”
type: urltest
proxies:
– “JP-Server-1”
– “US-Server-A”
– “SG-Server-X”
url: http://www.gstatic.com/generate_204
interval: 300

# 安定性を重視したフェイルオーバーグループ (バックアップとして)
– name: “BackupProxy”
type: fallback
proxies:
– “US-Server-A” # URLTestで選ばれたものがダメならこれを試す
– “SG-Server-X” # それもダメならこれを試す
– “DIRECT” # 最終手段として直接接続

# ストリーミング用手動/自動選択グループ (目的別)
– name: “StreamingProxy”
type: select # あるいは type: urltest でも良い
proxies:
– “StreamingServer”
– “OverseasAutoSelect” # ストリーミング用がない場合、汎用グループを使う
– “DIRECT”

# ユーザーが全体的なルーティングを選択するグループ
– name: “Policy”
type: select
proxies:
– “OverseasAutoSelect” # デフォルトの海外アクセス
– “BackupProxy” # 安定性重視
– “StreamingProxy” # ストリーミング用
– “DIRECT” # 直接接続
– “REJECT” # ブロック

# ブロック用グループ (固定)
– name: “REJECT”
type: reject
proxies: []

# 直接接続用グループ (固定)
– name: “DIRECT”
type: direct
proxies: []

rules:
# 広告/マルウェアドメインをブロック (Rule Provider参照)
# – RULE-SET,AdsMalware,REJECT

# ローカルネットワークは直接接続
– GEOIP,LAN,DIRECT
– IP-CIDR,127.0.0.0/8,DIRECT
# … その他のローカル/国内IPルール

# ストリーミングサイトは StreamingProxy グループへ
– DOMAIN-SUFFIX,netflix.com,StreamingProxy
– DOMAIN-SUFFIX,hulu.com,StreamingProxy
– DOMAIN-SUFFIX,primevideo.com,StreamingProxy
# … 他のストリーミングサイト

# 中国国内のサイトは直接接続
– GEOIP,CN,DIRECT

# それ以外の海外サイトは Policy グループへ (ユーザーが選択したポリシーが適用される)
– GEOIP,OTHER,Policy # OR MATCH,Policy (Depends on whether you want to use GeoIP for all other traffic)

# 最終的なデフォルトルール (上のルールにマッチしない、主に国内通信がここにくる)
– MATCH,DIRECT
“`

この設定では、OverseasAutoSelectグループが最も遅延の低いサーバーを自動で選び、BackupProxyグループはフェイルオーバーを提供します。ストリーミングサイトには専用のStreamingProxyグループを使用できます。Policyグループは、ユーザーがこれらの選択肢（自動選択、バックアップ、ストリーミング、直接接続、ブロック）の中から自由に切り替えるためのインターフェースとなります（これは通常GUIクライアントで操作します）。

シナリオ3：プライバシー保護を最優先した設定

目的:
* すべてのインターネット通信を信頼できるプロキシサーバー経由で行う。
* DNSクエリも暗号化されたプロトコル（DoT/DoH）で保護する。
* ローカルネットワークや一部の特定の通信は直接接続を許可する。

必要な機能:
* 信頼できるプロキシサーバー (proxies)
* 全ての通信をプロキシに送るルール (rules – MATCH)
* 高度なDNS設定 (dns – enable, listen, nameserver, fallback, DoT/DoH, fallback-filter)
* ローカルネットワークや特定の通信をバイパスするルール (rules – GEOIP, IP-CIDRなど)

設定例 (config.yaml スニペット):

“`yaml

基本設定 (ポートなど省略)

…

dns:
enable: true
listen: 0.0.0.0:53
enhanced-mode: fake-ip # または redir-host
fake-ip-range: 198.18.0.1/16

# 信頼できる DoT/DoH サーバーを優先
nameserver:
– tls://1.1.1.1:853 # Cloudflare DoT
– https://8.8.8.8/dns-query # Google DoH
– 8.8.8.8 # Google (非暗号化をフォールバックとして)

# 名前解決に失敗した場合のフォールバック (別の信頼できる DoT/DoH)
fallback:
– tls://1.0.0.1:853 # Cloudflare Secondary DoT
– https://1.1.1.1/dns-query # Cloudflare DoH

# 特定の名前解決はフォールバックを使わない
fallback-filter:
geoip: true # 海外IPの名前解決は fallback 優先 (ここでは nameserver/fallback 全て信頼できる前提なので必須ではないが、例として)
ipcidr:
– “0.0.0.0/8”
– “10.0.0.0/8”
# … その他のローカルIP範囲
domain:
– “+.lan” # ローカルドメインは fallback 使わない

strategy: default
# hosts: # ローカルhostsエントリ (オプション)
# ‘mycompany.local’: ‘192.168.1.100’

proxies:
# 全ての通信を任せる信頼できるプロキシサーバー
– name: “PrivacyProxy”
type: vless # 例: TLS と WebSocket を使用する VLESS
server: trust.example.com
port: 443
uuid: your-reliable-uuid
network: ws
tls: true
servername: trust.example.com
ws-path: /mypath
udp: true

# フォールバック用プロキシ (オプション、信頼できるサーバーが複数ある場合)
# – name: “BackupPrivacyProxy”
# type: trojan
# server: trust2.example.com
# port: 443
# password: password

proxy-groups:
# プライバシー保護を担う主要グループ (単一またはFallback/URLTestグループ)
– name: “SecureProxy”
type: select # 複数の信頼できるサーバーがあれば Fallback や URLTest も良い
proxies:
– “PrivacyProxy”
# – “BackupPrivacyProxy”

# 直接接続用グループ
– name: “DIRECT”
type: direct
proxies: []

# ブロック用グループ (オプション)
– name: “REJECT”
type: reject
proxies: []

rules:
# ローカルネットワークは直接接続 (必須)
– GEOIP,LAN,DIRECT
– IP-CIDR,127.0.0.0/8,DIRECT
# … その他のローカルIP範囲

# 特定の国内サービスなど、プロキシを経由したくないドメインやIPがあればここに追記
# – DOMAIN-SUFFIX,banksite.com,DIRECT
# – IP-CIDR,1.2.3.4/32,DIRECT

# それ以外の全ての通信は SecureProxy グループへ
– MATCH,SecureProxy
“`

この設定では、DNSクエリをまずDoT/DoHサーバーで試行し、必要に応じて非暗号化DNSや別のDoT/DoHサーバーにフォールバックします。ルーティングに関しては、ローカルネットワークや明示的に指定したバイパス対象以外の全ての通信をSecureProxyグループに振り分けます。SecureProxyグループには、信頼できる単一または複数のプロキシサーバーを設定します。これにより、ほぼ全てのインターネット通信が暗号化され、プロキシサーバーを経由することになります。

シナリオ4：ゲーム通信の低遅延化と通常通信の安定化

目的:
* 特定のオンラインゲームの通信を、低遅延に特化したプロキシサーバー経由で行う。
* ウェブブラウジングやダウンロードなどの通常通信は、別の安定したプロキシサーバーまたは自動選択グループ経由で行う。
* ゲーム通信のUDPパケットもプロキシ経由にする。

必要な機能:
* 低遅延・UDP対応プロキシサーバー (proxies)
* 安定性重視プロキシサーバーまたはグループ (proxies, proxy-groups – Fallback/URLTest)
* プロセス名、宛先IP/ポート、またはRule Providerに基づくルーティングルール (rules – PROCESS-NAME, IP-CIDR, DST-PORT, RULE-SET)

設定例 (config.yaml スニペット):

“`yaml

基本設定 (ポート, DNSなど省略)

…

proxies:
# 低遅延ゲーム用プロキシ (UDP対応が必須)
– name: “GamingProxy”
type: hysteria2 # 例: 低遅延に強いとされる Hysteria2
server: game.example.com
port: 443
password: game-pass
udp: true
tls: true
servername: game.example.com
# 帯域幅制限など、サーバー設定に応じたオプション

# 通常通信用プロキシ (安定性重視)
– name: “StableProxy”
type: vless # 例: 安定した VLESS with WS+TLS
server: stable.example.com
port: 443
uuid: stable-uuid
network: ws
tls: true
servername: stable.example.com
ws-path: /stable
udp: true # UDPも可能なら有効に

# または、通常通信用自動選択グループに使用する複数のサーバー
# – name: “GeneralServer1”
# type: ss
# …
# – name: “GeneralServer2”
# type: trojan
# …

proxy-groups:
# 通常通信用グループ (Fallback または URLTest)
– name: “GeneralTraffic”
type: fallback # または urltest
proxies:
– “StableProxy”
# – “GeneralServer1”
# – “GeneralServer2”
url: http://www.gstatic.com/generate_204
interval: 300

# ゲーム用グループ (通常は GamingProxy 単体)
– name: “GamingGroup”
type: select # または static
proxies:
– “GamingProxy”
# – “GeneralTraffic” # ゲームサーバーが使えない場合、通常通信用を使うオプション

# ユーザーが全体的なルーティングを選択するグループ
– name: “Policy”
type: select
proxies:
– “GamingGroup” # ゲーム用
– “GeneralTraffic” # 通常通信用
– “DIRECT” # 直接接続
– “REJECT” # ブロック

# 直接接続用グループ
– name: “DIRECT”
type: direct
proxies: []

# ブロック用グループ (オプション)
– name: “REJECT”
type: reject
proxies: []

rules:
# ローカルネットワークは直接接続
– GEOIP,LAN,DIRECT
– IP-CIDR,127.0.0.0/8,DIRECT
# … その他のローカルIPルール

# ゲームのプロセス名を指定して GamingGroup へ振り分け
# – PROCESS-NAME,gamelauncher.exe,GamingGroup # Windows
# – PROCESS-NAME,gameclient,GamingGroup # Linux/macOS
# – PROCESS-PATH,/Applications/Game.app/*,GamingGroup # macOS アプリパス

# 特定のゲームサーバーIPアドレスや範囲を GamingGroup へ
# ゲームの公式ドキュメントやパケットキャプチャでIPを調べる
# – IP-CIDR,1.2.3.4/32,GamingGroup
# – IP-CIDR,5.6.7.0/24,GamingGroup

# 特定のゲームで使用される宛先ポートを GamingGroup へ
# – DST-PORT,12345,GamingGroup # 例: UDP 12345 番ポート

# 特定のゲームドメインを GamingGroup へ
# – DOMAIN-SUFFIX,game-server.com,GamingGroup
# – DOMAIN,game-login.net,GamingGroup

# ゲーム関連の Rule Provider を参照 (コミュニティ提供など)
# Rule Provider でゲーム関連のドメイン/IPリストを取得
# – RULE-SET,GameRules,GamingGroup

# 上記ゲーム関連ルールにマッチしない、その他の通信は GeneralTraffic グループへ
# 通常はこのルールをゲーム関連ルールの直後に置くか、最終ルールとしてMATCHを使う
– MATCH,GeneralTraffic # 全ての他の通信は通常トラフィックとして扱う
“`

この設定では、まずGamingProxyを定義し、それをGamingGroupというポリシーグループに入れます。GeneralTrafficグループは、安定性を考慮してFallbackやURLTestタイプの通常通信用プロキシ群をまとめます。Policyグループはユーザーがゲーム用と通常通信用を切り替えるためのグループです。

ルーティングルールでは、PROCESS-NAMEやゲームサーバーのIP-CIDR、DST-PORT、DOMAINなど、特定のゲーム通信を識別するためのルールを優先的に配置し、それらをGamingGroupへ振り向けます。これらのルールは上から順に評価されるため、ゲーム通信が他のルール（例: GEOIP,OTHER,GeneralTraffic）よりも先にマッチするように配置します。最後にMATCH,GeneralTrafficルールですべての他の通信をGeneralTrafficグループに送ります。udp: trueをゲーム用プロキシに設定し、かつmihomoがUDPプロキシをサポートしている必要があります。

シナリオ5：大規模なルールリスト・プロキシリストの管理

目的:
* 手動での設定ファイル編集を減らし、大量のプロキシサーバーや複雑なルーティングルールを効率的に管理したい。
* 最新の広告ブロックリストや検閲回避ルールを自動的に取得・適用したい。
* プロキシリストを購読サービスから取得したい。

必要な機能:
* Proxy Provider (proxy-providers)
* Rule Provider (rule-providers)
* これらのProviderを参照するポリシーグループとルール (proxy-groups, rules – RULE-SET)

設定例 (config.yaml スニペット):

“`yaml

基本設定 (ポート, DNSなど省略)

…

Proxy Provider 設定

proxy-providers:
MySubscriptionProxies: # プロバイダー名
type: http
url: “https://myproxyprovider.com/subscribe/abcdef123” # サブスクリプションURL
interval: 3600 # 1時間ごとに更新
health-check: # ヘルスチェックで死活監視
enable: true
url: http://www.gstatic.com/generate_204
interval: 300

MyPrivateProxies: # 自前のプロキシリストファイル
type: file
path: ./private_proxies.yaml # 設定ファイルからの相対パスまたは絶対パス
interval: 86400 # 1日ごとに更新 (ファイルの更新頻度に合わせて)
# ファイルの内容例:
# – name: “PrivateServer1”
# type: ss
# …
# – name: “PrivateServer2”
# type: vmess
# …

Rule Provider 設定

rule-providers:
AdBlockRules: # 広告ブロックルール
type: http
url: “https://myrulesource.com/adblock.yaml” # 広告ブロックルールリストURL
interval: 86400 # 1日ごとに更新
behavior: classical # または domain

GfwListRules: # 検閲回避ルール (GfwList形式など)
type: http
url: “https://myrulesource.com/gfwlist.yaml” # GfwList形式ルールリストURL
interval: 86400
behavior: classical # または domain

proxy-groups:
# サブスクリプションのプロキシ群から自動選択
– name: “SubscriptionAutoSelect”
type: urltest
# Proxy Provider を参照 (& プレフィックス)
proxies:
– &MySubscriptionProxies
url: http://www.gstatic.com/generate_204
interval: 300

# 自前プロキシ群から手動選択
– name: “MyProxies”
type: select
# Proxy Provider を参照
proxies:
– &MyPrivateProxies
# 自前プロキシとサブスクリプションプロキシを混ぜることも可能
# – &MySubscriptionProxies

# 主要なポリシーグループ (ユーザーが選択)
– name: “Policy”
type: select
proxies:
– “SubscriptionAutoSelect” # サブスクリプションプロキシ (自動)
– “MyProxies” # 自前プロキシ (手動)
– “DIRECT” # 直接接続
– “REJECT” # ブロック

# 直接接続用グループ
– name: “DIRECT”
type: direct
proxies: []

# ブロック用グループ (固定)
– name: “REJECT”
type: reject
proxies: []

rules:
# 広告ブロックルールを適用 (ルールリストの最初に配置)
– RULE-SET,AdBlockRules,REJECT # AdBlockRules にマッチしたら REJECT グループへ

# ローカルネットワークは直接接続
– GEOIP,LAN,DIRECT
– IP-CIDR,127.0.0.0/8,DIRECT
# … その他のローカルIPルール

# GfwList のルールを適用
– RULE-SET,GfwListRules,SubscriptionAutoSelect # GfwListRules にマッチしたら SubscriptionAutoSelect グループへ

# 中国国内のサイトは直接接続 (GfwList の後に配置することで、検閲サイト以外は直接接続)
– GEOIP,CN,DIRECT

# それ以外の全ての通信は Policy グループへ
– MATCH,Policy
“`

この設定では、proxy-providersで購読URLとローカルファイルのプロキシリストを定義します。これらのプロバイダーはproxy-groupsで&ProviderNameのように参照され、URLTestやSelectグループに組み込まれます。rule-providersでは、外部の広告ブロックリストと検閲回避リストを定義します。rulesセクションでは、RULE-SET,ProviderName,Actionのようにこれらのルールプロバイダーを参照します。広告ブロックルールはリストの先頭に配置し、それにマッチした通信はREJECTグループに送られます。次にローカル/国内通信をDIRECTに振り分け、その後にGfwListRulesを参照して、検閲対象サイトをSubscriptionAutoSelectグループに送ります。それ以外の通信は、最終的にMATCH,Policyルールでユーザーが選択したポリシーグループに振り分けられます。

これにより、大量のプロキシやルールリストを個別に設定ファイルに記述する手間が省け、リスト提供元が更新されれば自動的に最新の状態を反映できるようになります。

5. mihomoのインストールと実行

mihomo本体はコマンドラインツールです。インストールと実行の基本的な手順は以下の通りです。

mihomo本体 (CLI) の入手

mihomoのバイナリはGitHubのリリースページで提供されています。お使いのOSとアーキテクチャに合ったバイナリをダウンロードしてください。ファイル名は通常mihomo-<os>-<arch>.gzまたは.zipのような形式です。解凍するとmihomo（またはmihomo.exe）という実行ファイルが得られます。

設定ファイルの準備

mihomoはconfig.yamlという名前の設定ファイルを読み込みます。このファイルは手動で作成するか、mihomoと互換性のあるツール（例: Clash for Windows, ClashX ProのGUI設定、オンラインのサブスクリプション変換ツールなど）で生成します。前述の各機能説明を参考に、目的に合わせたconfig.yamlを作成します。

設定ファイルは、mihomo実行ファイルと同じディレクトリ、または専用のデータディレクトリに配置します。

コマンドラインでの実行

mihomoの基本的な実行コマンドは以下の通りです。

“`bash

設定ファイルが実行ファイルと同じディレクトリにある場合

./mihomo

設定ファイルが別のディレクトリにある場合 (-d オプションでディレクトリを指定)

例: 設定ファイルが ~/.config/mihomo/config.yaml の場合

./mihomo -d ~/.config/mihomo/

特定の設定ファイルを指定する場合 (-f オプション)

例: ~/.config/mihomo/my_custom_config.yaml を使う場合

./mihomo -d ~/.config/mihomo/ -f my_custom_config.yaml

ヘルプを表示

./mihomo -h
“`

mihomoを起動すると、指定されたポートでHTTP/Socks5プロキシとして待ち受けを開始します。多くの場合はバックグラウンドで実行するか、システムサービスとして登録して利用します。

GUIクライアントの利用

mihomoのCLI操作や設定ファイル編集は初心者にはハードルが高いかもしれません。幸い、mihomoをコアとして利用する多くの優れたGUIクライアントが存在します。これらのクライアントは、設定ファイルの編集、プロキシサーバーの選択、接続状況の確認、ログ表示などをグラフィカルに行うことができます。

主要なGUIクライアントの例：

  • Windows: Clash Verge, Clash for Windows (開発終了・後継はClash Vergeなど), V2rayNG (mihomoコアもサポート)
  • macOS: ClashX Pro, Clash Verge
  • Linux: Clash Verge
  • Android: Clash for Android (開発終了・後継はclash_for_android_forkなど), V2rayNG (mihomoコアもサポート)
  • iOS: Clash (App Storeから削除), Stash, Shadowrocket (一部機能)

これらのクライアントを使用する場合、通常はクライアントがmihomoコアを内蔵または別途ダウンロードし、GUI上で設定を編集するとクライアントが内部的にconfig.yamlを生成・管理してmihomoコアを起動します。

6. mihomoの運用と管理

mihomoを効果的に利用するためには、その状態を把握し、必要に応じて管理することが重要です。

ログの確認

mihomoは起動中にログを出力します。このログは、接続状況、ルーティングの判断、エラー情報などを確認する上で非常に重要です。デフォルトでは標準出力に表示されますが、-dオプションでデータディレクトリを指定した場合、そのディレクトリ内にmihomo.logのような名前でログファイルが保存されることがあります（挙動はバージョンや起動方法による）。問題が発生した場合は、log-levelをdebugに設定してログを確認すると、原因特定に役立ちます。

API経由での管理

前述のAPI設定が有効になっている場合、外部からmihomoの状態を取得したり、操作したりできます。例えば、現在の設定、プロキシサーバーの遅延テスト結果、アクティブな接続リスト、ログ内容などをAPI経由で取得できます。多くのGUIクライアントはこのAPIを利用して動作しています。curlコマンドや専用のツールを使ってAPIを直接操作することも可能です。

WebUIの利用

mihomoコアは、デフォルトではWebUIを提供しません。しかし、一部のGUIクライアントは内蔵WebUIを提供したり、mihomoのAPIを利用するサードパーティ製のWebUIプロジェクトも存在します。これらのWebUIを使用すると、ブラウザからmihomoの状態確認や簡易的な設定変更が可能です。GUIクライアントに付属しているWebUI機能や、オープンソースで開発されているmihomo互換のWebUI（例: yacd, clash-dashboardなど）を利用できます。API設定のlistenアドレスとsecret情報を使ってWebUIからmihomoに接続します。

7. トラブルシューティングと注意点

mihomoは強力ですが、設定が複雑なためトラブルが発生することもあります。

  • 設定ファイルエラー (YAML構文エラー): config.yamlはYAML形式です。インデントやスペルミス、コロン : の不足などは一般的なエラーです。YAMLlintのようなツールで構文チェックを行うか、GUIクライアントのエディタ機能を利用するとエラーを防ぎやすくなります。mihomo起動時にエラーが表示されるので、その内容を確認して修正してください。
  • プロキシサーバーの問題: 接続しようとしているプロキシサーバー自体がダウンしている、設定が間違っている（アドレス、ポート、パスワード、UUIDなど）、サーバー側のファイアウォールでブロックされている、などの可能性があります。サーバー提供者に確認するか、別のサーバーを試してください。URLTestグループの遅延テスト結果もサーバーの状態を判断するのに役立ちます。
  • ルールの競合・意図しないルーティング: ルールは上から順に評価されるため、ルールの順序が意図しないルーティングを引き起こすことがあります。例えば、特定のサイトを直接接続したいのに、その前にすべての海外通信をプロキシに送るルールがあると、直接接続ルールに到達しません。ログでどのルールがマッチしたかを確認し、ルールの順序や条件を見直してください。
  • DNS設定の問題: DNSサーバーの設定ミス、Fake IP モードの互換性問題、DNSルールの設定ミスなどが考えられます。log-levelをdebugにしてDNSクエリのログを確認すると、問題特定の手がかりになります。
  • パフォーマンス問題: プロキシサーバー自体の速度制限、サーバーとmihomo間のネットワーク遅延、mihomoの負荷、不適切なルール設定（例: 不必要なプロキシ経由）などが原因でパフォーマンスが低下することがあります。URLTestでサーバーの遅延を確認したり、シンプルな設定で速度を比較したりして原因を切り分けてください。UDPプロキシが必要なアプリケーションでTCPプロキシを使用している場合も遅延の原因となります。
  • OSや他のソフトウェアとの干渉: ファイアウォール、アンチウイルスソフト、他のVPN/プロキシソフトウェアなどと競合する可能性があります。これらのソフトウェアの設定を確認したり、一時的に無効にして問題が解決するか試したりしてください。
  • セキュリティリスク: 信頼できないプロキシサーバーを使用すると、通信内容が盗聴されたり、悪用されたりするリスクがあります。信頼できるプロキシサーバーのみを使用してください。また、APIにパスワードを設定しない、allow-lanを意図せず有効にする、などの設定ミスはセキュリティリスクを高めます。

8. まとめ：mihomoの可能性

mihomoは、単なるプロキシクライアントを超えた、高度なネットワーク制御ツールです。多様なプロトコル対応、柔軟なルーティングルール、強力なDNS機能、動的な設定更新を可能にするプロバイダー機能など、その機能は多岐にわたります。

これらの機能を使いこなすには、config.yamlの構造や各設定項目の意味を理解する必要があり、ある程度の学習コストは伴います。しかし、その学習に見合うだけの強力なメリットを提供します。インターネットの自由を享受したい、オンラインプライバシーを強化したい、特定のアプリケーションやサービスへの通信を最適化したいなど、様々なニーズに対してmihomoは柔軟に応えることができます。

CLIツールとしてのmihomo本体に加え、多くの使いやすいGUIクライアントが登場していることも、mihomoエコシステムの成熟を示しています。これらのクライアントを利用することで、高度なmihomoの機能をより手軽に利用開始できるでしょう。

インターネット環境が常に変化し、新たな課題が登場する中で、mihomoのような柔軟で高性能なツールはますますその重要性を増しています。この記事で紹介した機能と具体的な使い方が、mihomoの強力なポテンシャルを理解し、ご自身のネットワーク環境をより良くするための助けとなれば幸いです。

参考文献 (mihomo/Clash関連):

  • mihomo GitHub Repository: https://github.com/MetaCubeX/mihomo (公式ソースコード・リリース)
  • Clash Configuration File Documentation (mihomoの設定もほぼ共通): https://wiki.metacubex.one/config/ (mihomo互換コア向けの非公式ドキュメント)
  • 各種プロトコル（VMess, VLESS, Trojanなど）の公式ドキュメントや解説記事

(注: mihohoはClash Premiumのフォークであり、設定ファイルの形式や機能の多くはClashと互換性があります。古いClash関連のドキュメントも参考になる場合がありますが、最新のmihomo固有の機能や変更点については、mihomoプロジェクトの公式情報やmihomo互換コア向けのドキュメントを参照することが推奨されます。)

コメントする

メールアドレスが公開されることはありません。 ※ が付いている欄は必須項目です

上部へスクロール