How to Set Up RCON on a Minecraft Server

RCON is how something that is not a person runs a command on your Minecraft server. A Discord bot that posts when a player joins, a status page that polls the player count, a script that runs save-all before a backup — they all need a way in, and on Java Edition the long-standing answer is RCON.

It is also, by design, one of the least defended things you can switch on. This guide covers the three server.properties keys that control it, what the protocol actually does on the wire, why it must never face the open internet, how to connect a client, and — the part worth reading before any of the rest — whether RCON has anywhere to listen on a rented server at all.

Every key on this page is documented in full in Minecraft server.properties: The Complete Reference; this guide is the practical companion to that section.

Bedrock Edition has no RCON, at all

This is a Java Edition feature. Bedrock Dedicated Server does not implement it — the Minecraft Wiki lists "Doesn't support remote console (RCON), which allows sending commands remotely from external sources" among the software's limitations, and there are no enable-rcon, rcon.port or rcon.password keys in a Bedrock server.properties. If you are on Bedrock, the panel Console is the whole story; see Minecraft Bedrock server.properties: The Complete Key Reference.

First: Do You Actually Need It?

The panel's Console tab already gives you authenticated, logged command access from anywhere you can open a browser, and the Schedules tab already runs commands on a timer. Between them they cover most of what people reach for RCON to do. Before enabling a second, weaker access path, check that you are not about to rebuild something you have:

RCON earns its place when something outside the panel needs to talk to the server programmatically. For everything else, the panel is both easier and safer.

The Three Keys

RCON is configured entirely in server.properties, and it is off by default.

enable-rcon=true
rcon.port=25575
rcon.password=a-long-random-string
broadcast-rcon-to-ops=true

Two behaviours are worth stating plainly because they are safeguards rather than bugs.

A blank password disables RCON. The Minecraft Wiki's server.properties reference says so — "If the password is blank and rcon is enabled, it will not start as a safeguard" — and the server's own code agrees: on startup it logs No rcon password set in server.properties, rcon disabled! and does not open a socket. There is no such thing as passwordless RCON.

An out-of-range port disables it too, with Invalid rcon port {} found in server.properties, rcon disabled! in the log.

When it does start, you get one line, and it is the line to look for:

[Server thread/INFO]: RCON running on 0.0.0.0:25575

0.0.0.0 there means every interface. Unless server-ip is set — and on a rented server it should stay empty — RCON binds as widely as the game does. That is the whole security problem in one line of log output.

enable-rcon changes need a restart

Nothing in server.properties applies to a running server. Edit the file, then restart from the panel. If the RCON running on line does not appear in the console afterwards, RCON did not start, and the reason will be printed right next to where that line should have been.

Does RCON Have Anywhere to Listen Here?

This is the question most RCON guides skip, and on a shared-hosting plan it decides whether any of the above will work.

Your server does not own the whole machine. It owns the ports allocated to it, which are listed on the panel's Network tab, and only those ports are published outside the container — the daemon publishes a binding for each allocated port and nothing else. Setting rcon.port to a number your server does not hold produces a server that starts, logs RCON running on 0.0.0.0:25575 quite happily, and is unreachable from outside, because nothing forwards that port to it.

So the sequence is:

1. Open the Network tab and look at what your server holds besides the game port.
2. If there is a spare allocation, set rcon.port to that port number.
3. Restart, and confirm the RCON running on line names the port you expect.
4. Connect using the IP from the Network tab plus that port — not the game port.

Many Minecraft servers here hold only their game port

Plans differ, and allocations are assigned when the server is created rather than added by you — the panel does not offer a way to claim an extra port yourself. If the Network tab shows a single allocation, RCON has nowhere reachable to bind, and you need an additional allocation before any of this works. That is a support ticket, not a config change. Do not work around it by pointing rcon.port at your game port; the game already holds that port on TCP, and RCON will fail to bind with Unable to initialise RCON on 0.0.0.0:25565.

One useful detail: each allocation is published for both TCP and UDP. So a spare port you were given for something UDP-shaped — a query port, a Geyser listener you no longer use — is equally usable for RCON, which is TCP. A port is a port once it is allocated to you.

What RCON Actually Is

Understanding the protocol is what makes the security advice land, and it is short.

RCON is not a Minecraft invention. The Minecraft Wiki describes it as "a TCP/IP-based protocol that allows server administrators to remotely execute commands", introduced in Java Edition Beta 1.9 Prerelease 4, and "an implementation of the Source RCON protocol for Minecraft" — the same protocol Valve's dedicated servers use, which is why so many general-purpose game-server tools already speak it.

Every packet has the same four-field shape:

Integers are little-endian, which is the opposite of the main Minecraft protocol and the first thing people get wrong when writing their own client.

The exchange is equally short. The client connects and sends a type 3 packet whose payload is the password. If it matches, the server replies with the same request ID — note that the reply's type is 2, not 3. If it does not match, the server replies with request ID -1. After a successful login the client sends type 2 packets containing commands, and the server answers with type 0 packets containing whatever the command printed. Responses longer than 4096 bytes are split across several packets, and there is no explicit end marker, which is why clients written by hand often truncate long output like list on a busy server.

Those constants are not folklore — they are named in the server's own code as SERVERDATA_AUTH (3), SERVERDATA_EXECCOMMAND (2), SERVERDATA_RESPONSE_VALUE (0), SERVERDATA_AUTH_RESPONSE (2) and SERVERDATA_AUTH_FAILURE (-1), exactly matching the Source protocol they came from.

Why It Must Never Face the Internet

Three properties, and each one is bad on its own.

It is plaintext. There is no TLS, no handshake, no key exchange. The Minecraft Wiki's own page opens with a warning that "it is dangerous to expose RCON ports to the internet. RCON is not encrypted and can be a subject to man-in-the-middle attacks," and its server.properties reference repeats it: "All data sent between the client and the server (including the rcon password) can be intercepted. Ideally, only connect to rcon from localhost." The password crosses the wire in the clear on the very first packet, every single time a client connects.

There is no lockout. Reading the server's implementation, a failed login sends the auth-failure packet and then goes straight back to reading the next packet on the same connection. There is no attempt counter, no delay, no ban. One open socket can try passwords for as long as it likes.

A successful login is total. The command source RCON creates runs at the server's highest permission set — internally the owner tier, the same ceiling as op level 4. op, deop, ban, stop, whitelist off, anything a plugin registers: all of it. There is no read-only RCON and no way to scope a session.

Anyone with the address, port and password owns the server

Not "can run some commands" — owns it. Treat the RCON password as a production credential: long and random, never reused, never pasted into a screenshot or a Discord channel, rotated whenever someone with access leaves. And prefer a client that connects from a machine you control over a hosted service you hand the password to.

That combination is the reason the practical rule everyone converges on is localhost or a trusted private network only. On shared hosting there is no localhost you can reach from outside, so the honest position is: if you enable RCON on a public allocation, you are accepting that its password is the only thing between the internet and full control of your world, and that the password is transmitted in clear text.

If you genuinely need remote command access from a fixed place, the mitigation worth asking for is an IP restriction on that allocation, so that only your bot's address can reach the port. Ask through a ticket; it is not something the panel exposes.

Connecting a Client

Once RCON is running and the port is allocated, any Source-RCON client works. The wiki maintains a list of implementations across a dozen languages; the ones people reach for most are:

• mcrcon — a tiny C command-line client, ideal for scripts and cron jobs.
• Node.js, Python, Go, Rust and Java libraries, several of them listed on the wiki's RCON page, for writing your own bot.
• General game-panel tools that already speak Source RCON, since Minecraft's implementation is the standard one.

All of them need exactly three things: the IP from the Network tab, the RCON port, and the password. A quick shape check with a command-line client looks like this:

mcrcon -H 203.0.113.10 -P 25575 -p 'your-rcon-password' 'list'

A successful run prints the command's output. A wrong password produces an authentication failure rather than a timeout — which is a useful diagnostic, because it proves you reached the right port.

Plugins can see RCON commands

On Paper and Spigot, a command arriving over RCON fires a distinct event with a RemoteConsoleCommandSender that exposes the connecting socket address. Permission and logging plugins can therefore treat RCON as its own sender rather than as the console — useful if you want an audit trail of what your bot has been doing.

The Modern Alternative: the Management Protocol

If you are on a recent Minecraft version, RCON is no longer the only option, and it is no longer the best one. Minecraft now ships a server management protocol: JSON-RPC 2.0 over a WebSocket, authenticated with a bearer token, TLS-encrypted by default. It is configured by the management-server-* keys in server.properties, all documented in Minecraft server.properties: The Complete Reference.

It is a genuinely different design. Rather than "send a command string, get console text back", it exposes typed methods and pushes notifications. The method set covers most of what a bot actually wants — allowlist and ban management, operators, kicking players, saving and stopping the server, gamerules and a broad set of server settings — and the server pushes events such as players joining and leaving rather than making you poll for them.

The trade-offs, honestly:

• For: encrypted by default, token-authenticated, structured responses instead of screen-scraped console text, and event notifications.
• Against: it is much newer, so the client-library ecosystem is thin next to RCON's decade of tooling; TLS means the server needs a keystore configured or it will refuse to start; and it still needs an allocated port on this platform, exactly like RCON.

If you are writing the integration yourself, it is worth the look. If you are plugging in an existing bot, that bot almost certainly speaks RCON and nothing else.

What Goes Wrong

• No RCON running on line in the console. RCON did not start. The reason is logged in the same place: a blank password, an out-of-range port, or Unable to initialise RCON on … if something else already holds that port.
• The line appears but nothing can connect. The port is not one your server holds. Compare rcon.port against the Network tab.
• Connection refused. Nothing is listening — RCON is off, or the server is stopped. A refusal is the useful failure: it proves you have the right machine.
• Connection times out. You have the wrong address or port entirely. See Minecraft Players Can't Connect: Every Error Message Explained, which draws the refusal-versus-timeout distinction in detail.
• Authentication fails with a password you are sure is right. Check for a trailing space or a smart quote in server.properties, and confirm the server was restarted after the edit.
• Long command output is cut off. Responses fragment at 4096 bytes and there is no end-of-response marker; the client has to handle reassembly. Some minimal clients do not.
• Commands appear twice in chat for operators. That is broadcast-rcon-to-ops=true doing its job. Set it to false if a bot running frequent commands is spamming your staff.
• Your edit did nothing. server.properties is read at startup only. Restart.

Sources

All checked 19 August 2026.

• The Minecraft Wiki's RCON page, for the protocol origin, packet format, packet types and fragmentation behaviour
• The Minecraft Wiki's server.properties reference, for the defaults and the blank-password safeguard
• The Minecraft Java Edition server jar itself (release 26.2), whose net.minecraft.server.rcon package supplied the Source protocol constants, the startup log strings, the bind behaviour, the absence of any login-attempt limit and the permission level granted to an authenticated session
• The Minecraft Wiki's Bedrock Dedicated Server limitations list, for the absence of RCON on Bedrock
• Paper's API source, for the RCON-specific command sender and event
• Pterodactyl Wings' allocation handling, for how allocated ports are published for a container

What to Read Next

• Minecraft server.properties: The Complete Reference — every key on this page, plus the query, JMX and management-server settings
• Minecraft Scheduled Restarts and Server Automation — the panel-native way to run commands on a timer
• Minecraft Server Commands: The Complete Op & Admin List — what you can actually send once connected
• Minecraft Op Permission Levels: 0 to 4 Explained — the permission tiers RCON sits above
• How to Use Your Server Panel — the Network tab, where your allocated ports live
• Minecraft Players Can't Connect: Every Error Message Explained — refusals, timeouts and what each one proves
• Minecraft Bedrock server.properties: The Complete Key Reference — why none of this applies to Bedrock
• How to Set Up LuckPerms Permissions for Minecraft — the right tool for giving humans scoped access

Made with 💜 by GameServerKings