Smart Proxy Group

The Smart proxy group type uses adaptive weight-based node selection. Instead of simple round-robin or manual ordering, it continuously tracks each node’s real-world performance — latency, connection success rate, traffic volume — and automatically routes connections to the best available node.

---

Configuration

# Optional: global LightGBM settings (top-level in config)
lgbm-auto-update: true
lgbm-update-interval: 72
lgbm-url: "https://github.com/vernesong/mihomo/releases/download/LightGBM-Model/Model.bin"

proxy-groups:
  - name: Smart Group
    type: smart
    proxies:
      - Proxy A
      - Proxy B
      - Proxy C
    policy-priority: "Premium:0.9;SG:1.3"
    uselightgbm: false
    collectdata: false
    sample-rate: 1
    prefer-asn: true
    tolerance: 50

---

Parameters

Group-level parameters

Parameter	Type	Default	Description
type	string	—	Must be smart
policy-priority	string	""	Regex-based priority adjustments for node names
uselightgbm	bool	false	Enable ML-based weight prediction via LightGBM
collectdata	bool	false	Collect training data to CSV for custom model training
sample-rate	float	1	Data collection rate, range 0–1 (1 = 100%)
prefer-asn	bool	false	Prioritise ASN lookup during node selection
tolerance	int	0	Latency difference in ms within which nodes count as equal when the group falls back to latency order; see tolerance
smart-collector-size	int	100	Max size of the data collection file in MB

Global LightGBM parameters (top-level)

Parameter	Type	Default	Description
lgbm-auto-update	bool	false	Automatically refresh the LightGBM model
lgbm-update-interval	int	72	Model refresh interval in hours
lgbm-url	string	—	URL to download the Model.bin file from

---

policy-priority

Adjusts the selection weight of nodes whose names match a regex pattern. Values below 1 lower priority; values above 1 raise it.

policy-priority: "Premium:0.9;SG:1.3"

In this example, nodes matching Premium have their weight multiplied by 0.9 (lower priority), while nodes matching SG get a 1.3 multiplier (higher priority). Multiple rules are separated by ;.

---

tolerance

Latency tolerance in milliseconds, from 0 to 65535. Not set or 0 means no tolerance.

The group normally picks nodes by the weights it has learned for a site. When it has too few such nodes, for example for a site it has not seen yet, it adds the remaining nodes in order of their latency from the health check (url / interval of the group). tolerance affects only this order:

• nodes whose latency differs by no more than tolerance count as equal and keep their order from the proxies list;
• without it, nodes are sorted strictly by latency, so two nodes with 41 and 43 ms can swap places after every check.

policy-priority is applied first: a node with a higher priority stays ahead regardless of tolerance. Nodes the group suspects of being blocked for the site always go last.

# strictly by latency (default)
tolerance: 0

# nodes within 50 ms of each other are equal, the order in proxies decides
tolerance: 50

# a larger margin: the first nodes of the list are kept unless they are much slower
tolerance: 150

---

How it works

Weight calculation

The group continuously scores each node using five factors:

• Connection success rate — successful vs. failed attempts; recent failures carry more weight.
• Connection performance — connection establishment time and round-trip latency.
• Usage statistics — upload/download volume and session duration.
• Time decay — weights decay for nodes that haven’t been used recently.
• Connection type — separate scoring tracks for UDP and TCP connections.

All metrics are normalised into a base weight, then adjusted by policy-priority rules and ASN-specific tables. Weights are updated using weighted averaging. If a node’s quality degrades by more than 30%, its cache entry is flushed.

Node selection

Selection follows this priority order:

1. Domain-based history — if the destination domain has been seen before, the node with the best historical performance for that domain is preferred.
2. ASN-based history — if no domain history exists, the node’s past performance for the destination’s Autonomous System is used.
3. Pre-calculated cache — hot domains are pre-scored in memory (LRU) and on disk for fast lookup.
4. Round-robin fallback — used when historical data is insufficient; random exploration prevents local optima.

Historical data is retained for 14 days. Expired entries are pruned automatically.

Failure handling

When a node exceeds its failure threshold, its weight is penalised. Recovery is gradual — weights are partially restored at 5, 10, 15, and 30-minute intervals, preventing a temporary outage from permanently blacklisting a node.

---

Machine Learning (LightGBM)

Enabled by default in Prizrak-Box

The built-in templates included in the app use uselightgbm: true by default.

When uselightgbm: true, the group uses a pre-trained LightGBM model to predict node weights instead of the rule-based system.

Model file location:

• ~/.config/mihomo/Model.bin

Collecting training data

Enable collectdata: true to write connection metrics to ~/smart_weight_data.csv.

Use sample-rate to reduce collection overhead — e.g. sample-rate: 0.1 records 10% of connections.

The collected CSV can be used to train a custom model with LightGBM 3.3.5.