Direct answer

If your server is private, keep Java authentication enabled (`online-mode=true`) and enable the whitelist (`white-list=true`), then verify only intended accounts are listed. Keep the server/proxy updated. If you use a proxy, firewall the backend so only the proxy can reach it. Blocking one scanner IP may reduce that source, but it does not make a public Minecraft port unscannable.

What it means

Publicly reachable Minecraft servers are routinely found by automated scanners. Repeated unknown join attempts do not by themselves mean the server has been hacked, but a private server should still enforce authentication and access control.

If you are a player

  • If you are an invited player, send the owner your exact username and the time of the failed/successful join so they can match it to the log.
  • Do not share server addresses, account tokens, passwords, or private network details in public troubleshooting posts.
  • If you are the unexpected visitor, leave the server unless you have permission to be there.

If you run the server

  1. Confirm `online-mode=true` on a normal standalone Java server. Do not switch authentication off just to stop scanner messages.
  2. Enable the whitelist with `white-list=true`, then use `whitelist list` to verify the allowed accounts.
  3. If you run Velocity or another proxy, make sure the backend is not publicly reachable; restrict it so only the proxy can connect.
  4. Keep Paper/server software, proxy software, plugins, and mods updated from trusted project sources.
  5. Treat repeated malformed login attempts as hostile/untrusted traffic, but distinguish a rejected scan from a successful login. Review the log for whether an unknown account actually joined.
  6. Do not rely on a non-default port as a security boundary. It can reduce noise from simple scanners but does not replace authentication, whitelisting, or firewall rules.

Important notes

  • A rejected connection attempt is not the same as a successful login or compromise.
  • Internet-facing services can be discovered. Security should come from authentication, access control, updates, and network restrictions—not secrecy of the IP/port alone.
Differentiate scans from successful access
  1. A connection attempt or unknown username in a log does not prove account compromise. Check whether the player actually passed authentication and joined.
  2. Keep online-mode authentication enabled on standalone public servers; on Velocity, secure offline-mode backends so only the proxy can reach them.
  3. Use sensible network rate controls and staff monitoring, but avoid banning entire IP ranges without checking for shared-network users.

References

Use the documentation for the exact software and release you run. These sources support the settings or security behavior used in this fix.

Was this article helpful?
Help us improve this article

Tell us what is missing, unclear, outdated, or incorrect. You can also suggest something we should add.

What could we improve?
Do not include passwords, server IPs, or other private information.0 / 1000