mihomo Subscription Template

mihomo (formerly Clash Meta) is a core from the Clash family. It accepts a subscription in YAML format and builds the config from it itself: it picks local ports, DNS, and the operating mode. Important to remember: only Meta cores support VLESS+Reality (mihomo, clash-meta); classic Clash Premium will not understand such a subscription.

YAML structure

Section	Why
`mixed-port`	a local port for HTTP and SOCKS at the same time
`allow-lan`, `mode`, `log-level`	basic operating modes
`dns`	the core DNS resolver
`proxies`	the server list (one per inbound)
`proxy-groups`	selection groups: automatic or manual
`rules`	routing rules

Proxies

The proxies block mirrors the parameters of your inbound in Xray. Example for VLESS+Reality+Vision:

proxies:
  - name: "MyServer-Reality"
    type: vless
    server: 203.0.113.10
    port: 443
    uuid: 11111111-2222-3333-4444-555555555555
    udp: true
    network: tcp
    tls: true
    flow: xtls-rprx-vision
    servername: www.microsoft.com
    client-fingerprint: chrome
    reality-opts:
      public-key: REALITY_PUBLIC_KEY
      short-id: "ab12"

The fallback VLESS+WS+TLS option for older cores differs in transport:

proxies:
  - name: "MyServer-WS"
    type: vless
    server: 203.0.113.10
    port: 443
    uuid: 11111111-2222-3333-4444-555555555555
    udp: true
    network: ws
    tls: true
    servername: sub.example.com
    client-fingerprint: chrome
    ws-opts:
      path: /ws
      headers:
        Host: sub.example.com

mihomo field	Value for VLESS
`type`	always `vless`
`server`, `port`	address and port from `vnext`
`uuid`	the user `id`
`udp`	enable UDP transmission
`network`	`tcp` for Reality, `ws` for WebSocket
`tls`	`true` in both cases
`flow`	`xtls-rprx-vision` for Reality
`servername`	SNI (the camouflage domain)
`client-fingerprint`	TLS fingerprint, usually `chrome`
`reality-opts`	`public-key` and `short-id` for Reality
`ws-opts`	`path` and the `Host` header for WebSocket

warning

uuid is user credentials. Do not publish the YAML and do not forward it in public chats: whoever receives it connects to your server as you.

Proxy-groups

Groups decide which server to use. url-test automatically picks the fastest one, select gives a manual choice:

proxy-groups:
  - name: AUTO
    type: url-test
    url: https://www.gstatic.com/generate_204
    interval: 300
    tolerance: 50
    proxies:
      - MyServer-Reality
      - MyServer-WS
  - name: PROXY
    type: select
    proxies:
      - AUTO
      - MyServer-Reality
      - MyServer-WS

tip

Keep both select and AUTO in the group, along with the individual servers: if the automatic check fails, the user can switch manually.

Rules

A minimal set of rules passes the local network directly and everything else through the proxy:

rules:
  - GEOIP,LAN,DIRECT
  - MATCH,PROXY

The rule list is expanded as needed: routing rules in the panel are described in Routing Rules.

Substitution from the Xray config

If you have a client Xray config, the fields map to mihomo one to one:

Xray (client JSON)	mihomo
`outbounds[].settings.vnext[].address`	`server`
`outbounds[].settings.vnext[].port`	`port`
`outbounds[].settings.vnext[].users[].id`	`uuid`
`users[].flow`	`flow`
`streamSettings.network`	`network`
`streamSettings.security`	`tls: true` + `reality-opts`
`realitySettings.serverName`	`servername`
`realitySettings.publicKey`	`reality-opts.public-key`
`realitySettings.shortId`	`reality-opts.short-id`
`realitySettings.fingerprint`	`client-fingerprint`
`wsSettings.path`	`ws-opts.path`
`wsSettings.headers.Host`	`ws-opts.headers.Host`

For example, a fragment of a client config

{
  "outbounds": [
    {
      "protocol": "vless",
      "settings": {
        "vnext": [
          {
            "address": "203.0.113.10",
            "port": 443,
            "users": [{ "id": "11111111-2222-3333-4444-555555555555", "flow": "xtls-rprx-vision" }]
          }
        ]
      },
      "streamSettings": {
        "network": "tcp",
        "security": "reality",
        "realitySettings": {
          "serverName": "www.microsoft.com",
          "publicKey": "REALITY_PUBLIC_KEY",
          "shortId": "ab12",
          "fingerprint": "chrome"
        }
      }
    }
  ]
}

turns into exactly the first proxy from the example above.

How it reaches the client

Do not give the user a single shared JSON config: it would have to hard-code the local ports and DNS of a specific app. Give out a subscription link instead — then each app builds the config for itself. Clients of the Clash/mihomo/Stash family request YAML themselves: the subscription server determines the format from the User-Agent header and additionally reports the auto-update interval with the Profile-Update-Interval header.

note

The same subscription works everywhere: mihomo gets YAML, while Xray-core clients get base64 with links. There is no need to split subscriptions by client.

YAML structure​

Proxies​

Proxy-groups​

Rules​

Substitution from the Xray config​

How it reaches the client​

What's next​