Automatic fixes against blocking

mikan watches whether real clients can reach each protocol. If a port gets blocked along the way, the panel moves the protocol to a free HTTPS port. If the REALITY camouflage site stops working, it picks a new one near the server. Clients get the changes with their next subscription update (apps refresh it hourly), and until then the “Auto” group in the app routes around the broken connection.

Where to turn it on

Settings → General → Automatic fixes, two switches:

• “Move to another port when it is blocked”;
• “Replace the camouflage site when it stops working”.

The same switches are in each connection’s settings. If a switch is off in the general settings, it has no effect on the connection.

How the panel knows a protocol is blocked

Every 5 minutes the panel looks at devices from the last 30 minutes. Only devices that try all connections themselves count: for example, Clash apps with an auto-select group. A client with a single link doesn’t count.

A device is considered cut off from a connection if:

• the connection is in its subscription, and the device refreshed the subscription after the connection last changed;
• it reaches the node’s other connections, including ones on the same network type (TCP or UDP);
• it reached this connection before;
• nobody from the same subnet (/24 for IPv4, /64 for IPv6) can reach it right now.

A protocol is declared blocked when cut-off devices come from at least two different networks and make up at least a quarter of the devices that do reach it. One network is never enough: it could be a second VPN on the device or a home router that filters the port. The state must hold for 30 minutes before the panel changes anything. A node needs at least three enabled connections to be assessed.

What the panel does

1. If the REALITY camouflage site fails the check, it changes the site.
2. Otherwise it moves the port.
3. If the new port didn’t help within an hour, it changes the site too.

The same change is repeated at most once every 6 hours, and no more than three automatic changes per connection within 48 hours. If that wasn’t enough either, the panel reports that the protocol itself is probably blocked: try another one.

The new port is a random free one from the fallback list: 2053, 2083, 2087, 2096, 2443, 3443, 4443, 5443, 6443, 7443, 8443, 9443, 10443, 11443, 12443. Ports the node’s connections left in the last 7 days are skipped. A Hysteria2 port range is not moved automatically.

The new site is searched in the same /24 network as the node: up to 16 candidates with TLS 1.3, HTTP/2 and X25519 whose DNS name points to that address. The panel’s and nodes’ own domains are not used, nor are sites that failed the check in the last day. The camouflage site is checked every 15 minutes, and after three failures in a row it is changed.

Busy port

Separately from blocking, every 15 seconds the panel checks whether another program, such as nginx or Caddy on 443, has taken a connection’s port. If so, the connection moves to the first free fallback port, on the panel server and on nodes. This also depends on the “Move to another port” switch but doesn’t wait for two networks. A cascade relay moves the same way.

When automatic fixes don’t work

• A connection behind a proxy: the port and site don’t change, otherwise the proxy would lose its clients. See Behind a proxy.
• Hysteria2 with a port range.
• One-key protocols: Shadowsocks-2022, Sudoku, Snell.
• The switch is off in the settings or on the connection.

Where you see it

In the connection list: “Devices that cannot reach it: N of M”, “Port changed automatically” and “Camouflage site changed automatically” with the reason. Every change is written to the audit log. The notifications “Autotune changed a connection” and “Autotune could not restore a connection” arrive in Telegram if an admin chat is connected, see Alerts.