Troubleshooting

Test Connection fails, but I can log in to the router myself

Test Connection is not a ping. It opens a real session and reads the system information, so it fails whenever any part of that chain does not work — which is the point, but it does mean the failure could be one of several things.

Check, in this order:

• The port. The manager uses the port on the device form, not the one you happen to use in your terminal.
• The RouterOS user's group policies. A group without ssh and read cannot answer the read, even though the password is right. For REST devices the group also needs rest-api.
• Any address restriction on the RouterOS user. If the account is limited to certain source addresses, the manager's address has to be one of them — and that is the container's address as the router sees it, which is not always the host's.
• The service itself on the router: SSH enabled for SSH devices, www-ssl or www for REST devices.

The error text returned by the test is the router's own, so it is worth reading rather than skipping.

I set the device to REST — why does it still want SSH?

By design. The manager reads over SSH for every device and only sends writes over the configured method. MikroTik's REST API leaves an entry in /user/active roughly every ten minutes that is never cleaned up; left running long enough those entries exhaust the router's session slots. SSH creates one session that disappears on disconnect.

If SSH is unavailable on a REST device the read falls back to REST, so nothing breaks — but the device works better with SSH reachable, and your firewall rules should allow it.

The router has a self-signed certificate — is that the problem?

No. The manager accepts self-signed certificates on REST connections deliberately, because that is what a RouterOS box ships with. A failing REST device is failing for some other reason; work through the checklist above.

A device shows "Not accessible" but it is clearly up

That badge means exactly that: the device is up. It appears when the poll failed and the management port still accepted a TCP connection — the manager probes the SSH and API ports specifically to tell this case apart from a box that is really down, which would show a red Offline instead.

In practice this is the RouterOS session wedge: the router keeps forwarding traffic and answering on the network, but its management session subsystem stops responding, so nothing can query it — often not Winbox or a fresh SSH login either. The manager cannot fix that from the outside, and reports it honestly instead of showing the device as dead.

Worth knowing: the badge is also a webhook event, so you can be told about a wedged device rather than discovering it later.

Readings have stopped changing

Two different faults look identical on screen, and they are worth separating before you investigate:

• Polling is failing. The device badge will have changed too. Start from the device, not from the browser.
• The live connection is down. Badges look normal but nothing moves, and a page reload shows fresh values that then freeze again. That is the WebSocket, not the router — see the next section.

By default a device is polled every 60 seconds. A device with its own poll interval set on the device form uses that instead.

The interface loads through my reverse proxy, but nothing updates live

This is the most common reverse-proxy mistake. The manager pushes status changes, command output and upgrade progress over a WebSocket at /ws. If the proxy does not forward the WebSocket upgrade, everything renders correctly on load and then never changes.

Any proxy needs to pass the upgrade through. For plain nginx that means:

location /ws {
    proxy_pass http://<manager-host>:3000;
    proxy_http_version 1.1;
    proxy_set_header Upgrade $http_upgrade;
    proxy_set_header Connection "upgrade";
    proxy_set_header Host $host;
}

If you run SWAG, this is a complete working file — save it as /config/nginx/proxy-confs/manager.subdomain.conf and change the address to your own. SWAG's bundled proxy.conf carries the upgrade headers, which is why the block below does not repeat them:

## Place in SWAG at: /config/nginx/proxy-confs/manager.subdomain.conf
## Replace 192.0.2.10 with the host running the manager.
## In the SWAG container environment set: SUBDOMAINS=manager  VALIDATION=http

server {
    listen 443 ssl;
    listen [::]:443 ssl;
    http2 on;

    server_name manager.*;

    include /config/nginx/ssl.conf;

    # Configuration backups and firmware uploads are not small.
    client_max_body_size 0;

    location / {
        include /config/nginx/proxy.conf;
        include /config/nginx/resolver.conf;

        set $upstream_app 192.0.2.10;
        set $upstream_port 3000;
        set $upstream_proto http;
        proxy_pass $upstream_proto://$upstream_app:$upstream_port;
    }

    # Without this location the interface loads and then never updates.
    location /ws {
        include /config/nginx/proxy.conf;
        include /config/nginx/resolver.conf;

        set $upstream_app 192.0.2.10;
        set $upstream_port 3000;
        set $upstream_proto http;
        proxy_pass $upstream_proto://$upstream_app:$upstream_port;
    }
}

Or take the file directly: manager.subdomain.conf.

Add to Home Screen works, but the app shows a browser error page when the manager is unreachable

The offline shell needs a secure context. Over plain HTTP on a LAN address the browser does not merely refuse to register the service worker — the API for it is absent, which is a normal deployment rather than a fault. The icon and the full-screen window still work; what you do not get is the cached interface.

Serve the manager over HTTPS and the shell appears. Note that this only ever caches the interface: no API response is cached, so every reading on screen is live either way.

An SNMP device shows much less than the others

Expected. Over SNMP the manager reads version, uptime, CPU load, memory, board name and model, serial number, current and upgradeable firmware, temperature, voltage, power consumption, identity, the interface list with neighbours, and traffic counters.

Commands, upgrades and backups are not available over SNMP at all — an SNMP-only device is a monitoring target. If you need the rest, give the device an SSH or REST method; SNMP can stay on as a supplementary source.

A PoE switch shows its draw but no budget bar

RouterOS reports how much power is going out, but never how much the switch is allowed to deliver — that figure is a datasheet property, so the manager keeps a table of it per model. If your board is not in that table, you get the measured draw and no bar, which is deliberate: borrowing a similar model's ceiling would look exactly like a real reading.

Switches powered from an external supply need one more thing: their limit is a current, so the budget is that current multiplied by a voltage. The device usually reports the voltage itself; where it does not, tell the manager which power supply the switch runs on and it takes the voltage from there.

The PoE-out supply field in the device form lists MikroTik's supplies by name — 18POW, 24HPOW, 48POW, 48V2A96W, MTP250 and the rest — and takes a plain volts-and-amps pair for anything else. That is also what gives routers with PoE-out a budget at all: their ceiling depends on the brick, so without one there is nothing honest to draw.

The budget does not match the figure on the product page

Usually because the product page figure assumes something your unit does not have. A CRS320-8P-8B has 963 W of PoE capability but a 600 W supply in the box, so with one PSU fitted the manager shows 600 W; fit the second and it reads the change from the device itself. A CRS112-8P is rated 2.8 A, which is 78 W on a 28 V supply and about 74 W on 53 V — the same switch, different ceiling, and the manager uses the voltage the device actually reports.

Some models also have a limit the total does not show. A CRS328-24P is three independent groups of eight ports at 150 W each, so the card draws a bar per group: a switch comfortably under its 450 W total can still run one group out of power.

A supply smaller than the board can lower the ceiling too. A CRS112-8P on 57 V would pass nearly 80 W by its own current limit, but not through a 70 W adapter, and the card says which of the two it is showing. An RB5009UPr+S+IN is a third case: MikroTik publishes a 130 W total and states that the board keeps 20 W for itself, so with the 96 W adapter it ships with, 76 W is what remains for the ports. Fit a larger supply and it climbs to its 130 W limit. With no supply named, the manager assumes the bundled one and says so on the card.

Power consumption on a PoE switch changed after updating to 1.71.0

It was wrong before and is right now. On boards that publish no overall consumption sensor, the old reading fell through to the PoE-out figure, so a switch delivering 28 W of PoE reported 28 W as its own consumption while the board was really drawing about 60 W. The two are separate readings now — power consumption is the board, and the PoE figure lives on the PoE Budget card.

History recorded before the update keeps the old values, so the graph steps at the point you updated. Nothing was rewritten.

A tab on the device page is empty

Usually the hardware simply does not have that feature. A router with no wireless has no wireless clients; a board with no health sensors reports no temperature or voltage; a CHR has neither a routerboard section nor health readings. The manager asks and shows what comes back, so an absent feature reads as an empty section.

The distinction that matters: an empty section with the rest of the page populated is almost always missing hardware. A page where everything is empty is a connection problem — start at the top of this page.