No Moonraker connection: a real diagnosis order

Updated 30 October 2026

"No Moonraker connection. Please check Moonraker status and / or refresh." is Fluidd's message for a lost connection to Moonraker, the API server between the web interface and Klipper. Moonraker is either not running, not reachable at that address, or refusing your computer, and refreshing fixes none of those.

The http://192.168.0.106:7125 in front of the message is not part of the error. Fluidd prints the address it tried above the message text, so yours will show your own printer. Its Refresh button only reloads the page, and Reconnect only tries the same connection again. Mainsail words its dialog differently, but these checks apply to it too.

Start with one test

From the computer showing the error, run this with your own address, or open the URL in a browser:

curl http://192.168.0.106:7125/server/info
ResultWhat it meansGo to
JSON containing klippy_stateMoonraker is fine and reachableStep 3 for cors_domains, then step 6
UnauthorizedMoonraker is running and refusing your IPStep 3
Connection refusedThe machine answers, but nothing is listening on that portSteps 1 and 2
Timeout or no routeWrong IP, printer off, or a network problemStep 5

Fluidd's own FAQ uses the same first test. The commands below assume a standard Debian-based install, as in Moonraker's documentation. Firmware images made by printer vendors may use other paths.

1. Is the service running

Connect to the printer's host over SSH.

systemctl status moonraker
sudo journalctl -xe -u moonraker.service

Look for active (running). If it is restarting in a loop, look for a Python traceback in the journal.

A common cause is an update that broke dependencies. In the GitHub issue with this exact error, Moonraker's maintainer suspected dependencies that failed to install after an update. Running the install script fixed it for the reporter:

~/moonraker/scripts/install-moonraker.sh
sudo systemctl restart moonraker

That issue is from 2022. It is one report, not a guaranteed fix. Read your own traceback first.

2. Is it on port 7125

ss -tln | grep 7125

You should see a line in the LISTEN state. Moonraker's defaults are port 7125 on all IPv4 interfaces. A different port or host in the [server] block overrides that:

grep -A3 '^\[server\]' ~/printer_data/config/moonraker.conf

Rinkhals on Anycubic printers. Rinkhals builds have shipped Moonraker on ports other than 7125, so check that [server] block if the default does not connect.

Behind nginx. Fluidd usually reaches Moonraker through nginx. In the same GitHub issue, nginx's fluidd-error.log showed connect() failed (111: Connection refused) while connecting to upstream for 127.0.0.1:7125. That line means nginx is working and Moonraker is not listening.

3. Check trusted_clients and cors_domains

These two settings do different jobs, and both live in the [authorization] section of ~/printer_data/config/moonraker.conf.

  • trusted_clients says which client IP addresses may use the API.
  • cors_domains says which web origins a browser page may call from. CORS is off unless you set it.

Mainsail's documentation gives this pattern. Add your own range to the entries already in your file, and do not remove the others:

[authorization]
trusted_clients:
    192.168.0.0/24
cors_domains:
    *.lan
    *.local
    *://my.mainsail.xyz

Then restart:

sudo systemctl restart moonraker

Four mistakes to check for:

  • A range must end in 0. 192.168.0.0/24 is valid, and it covers 192.168.0.1 to 192.168.0.254. 192.168.0.106/24 is not, because the last segment of an IPv4 range must be 0.
  • Trust the client, not the printer. The entry has to cover the machine making the request: your computer, or the bridge if software connects for you.
  • force_logins: True overrides this list once at least one user exists.
  • Wildcards have limits. *.local works. A wildcard in the top-level domain, such as http://my-printer.*, is rejected.

Trusted clients get full API access, so keep the range to your printer network. Moonraker's documentation reserves cors_domains: * for client developers. It also says to prefer IP ranges over domain names, because a failed DNS lookup makes the authorisation check fail.

If you use the hosted Fluidd or Mainsail site, that site's address has to be in cors_domains. Mainsail's is shown above.

4. Read the log

tail -n 50 ~/printer_data/logs/moonraker.log

Mainsail's documentation describes what to look for after a refused connection: the end of the log shows the client IP that tried to connect, with Message: Unauthorized. That tells you exactly which address to add. Compare it with your range. If your computer has two networks, it may not be the IP you expected.

Moonraker also reports its own problems. The warnings and failed_components lists in /server/info show errors from start-up and operation, once you can reach it.

5. Has the IP changed

If the test timed out, the printer may simply have a new address. Addresses handed out by a router's DHCP can change after a reboot. You cannot SSH to an address you do not know, so look in your router's client list first. If you have a screen or keyboard on the printer's host, this works too:

hostname -I

Then reserve the address in the router, so it stays the same.

With several printers this one gets costly. A printer with a new address looks exactly like a dead one, so reserve addresses for all of them on day one.

6. Moonraker works, so check Klipper

Moonraker can be healthy while Klipper is not. Read these two fields from /server/info: klippy_connected and klippy_state.

klippy_stateMeaningWhat to do
readyKlipper is readyKlipper is not the problem. Go back to step 3 for cors_domains
startupStill startingWait and check again
disconnectedMoonraker has no connection to KlipperCheck the Klipper service and the socket path
errorKlipper hit an error during start-upRead klippy.log, then fix the config
shutdownEmergency stop or critical errorFind the cause, then do a firmware restart

The Klipper log is usually at ~/printer_data/logs/klippy.log.

tail -n 50 ~/printer_data/logs/klippy.log
sudo service klipper restart

For disconnected, the socket path has to match on both sides. Moonraker's klippy_uds_address must point to the same file Klipper is given with -a in /etc/default/klipper, for example ~/printer_data/comms/klippy.sock.

To clear a shutdown, run FIRMWARE_RESTART in the console, or use the API:

curl -X POST http://192.168.0.106:7125/printer/firmware_restart

This also resets the micro-controllers. A plain RESTART does not clear their error state.

What we see from the software side

We connect to printers over this same API from our own bridge. Two limits from that work are worth stealing if you script against Moonraker:

  • We treat no answer within 10 seconds as offline. Checking /server/info from another machine on the same network tells you whether the fault is in the network or in your code.
  • We allow up to five minutes for a file upload. When large files fail to start, a slow Wi-Fi link to the printer is the usual cause, and a cable or a closer access point fixes it.

For the wider picture, see what a print farm involves. For connecting Moonraker to Rackrew, the manual is Klipper / Moonraker setup.