Table of Contents
- How Eaglercraft Servers Work
- WebSocket vs HTTP: Why Browsers Need a Bridge
- How to Find Servers
- Joining with an IP Address
- Hosting Your Own Server
- Lag and Connection Troubleshooting
- Rules, Moderation and Safety
- FAQ
How Eaglercraft Servers Work
Multiplayer in Eaglercraft is the part that confuses people most, and the confusion almost always comes from one missing fact: a server that works perfectly for desktop Minecraft players may be completely invisible to you in a browser.
A normal Minecraft server listens on a TCP port, protocol 25565, and speaks the game's own binary protocol. A browser is not allowed to open raw TCP sockets, and it cannot speak that protocol even if it could. So an Eaglercraft-compatible server has two halves: the normal Java world running underneath, and a bridge process on top that accepts the WebSocket connections a browser is permitted to make, then translates everything in both directions. Players on a native client connect to the Java side; browser players connect to the bridge; both end up in the same world.
That is why the server list you see for Eaglercraft is not the same as the list of popular Minecraft servers, and why adding a famous server's IP to your client will usually get you nothing but a timeout. If the network does not run the bridge, there is no path in from a browser.
WebSocket vs HTTP: Why Browsers Need a Bridge
Two different protocols are involved in playing in a browser, and mixing them up causes most "it just will not connect" reports.
- HTTP or HTTPS serves the page. The client HTML and the asset pack are ordinary web files. They can come from a website, a school intranet, a USB stick or your own disk. This half only has to deliver bytes.
- WebSocket carries the game. Once you click join, the client opens a persistent WebSocket connection to the server's bridge and the whole session runs through it. This is a live, two-way, always-open channel, which a normal HTTP request cannot provide.
The consequence that bites everyone: if the client page was loaded over HTTPS, the browser will refuse an insecure WebSocket to the same server. Mixed content rules kill it silently or with a vague error. Either load the client from a plain HTTP page, or make sure the server offers a secure WebSocket on a port your browser accepts, typically 443.
How to Find Servers
There is no central authority, so discovery happens in a few predictable places.
- Server lists built for the browser client. Dedicated listing sites publish addresses with a version tag and a player count. Check the version tag first, because a 1.12.2 address will not accept a 1.8.8 client.
- Community hubs and forums. The project's own communities and Discord servers have channels where people advertise worlds. These skew smaller, friendlier and more moderated than the big lists.
- Any hosted client page. Most client pages ship with a pre-filled server list. It is the fastest way to see what is alive right now.
- People you already know. The most reliable option by far. A friend running a world for six people will be online, stable and free of the ad-heavy nonsense that plagues public lists.
Joining with an IP Address
- Open Multiplayer in the client. You will see a server list, usually empty or pre-filled depending on the build.
- Add a server. Give it any name you like, then paste the address. The format is host or IP, optionally followed by a colon and a port, for example play.example.net or 203.0.113.10:8081.
- Check the version. If the client is 1.8.8 and the server advertises 1.12.2, stop there. Version mismatches fail at the handshake and the error message will not tell you why.
- Connect and read the failure. An instant refusal usually means the wrong protocol or a blocked mixed-content request. A slow timeout means the address is wrong, the port is closed or the server is offline.
- Re-enter the address manually if you copied it. Invisible whitespace from a forum post is a genuinely common cause of failure.
Hosting Your Own Server
Self-hosting is the best answer for a group of friends, and it removes every discovery problem at once. The shape of the setup:
- Run the Java world. A 1.8.8 Paper or Spigot server on a machine with a couple of gigabytes of RAM free. This is the same server software you would run for desktop players.
- Add the bridge. Install the browser-compatible server plugin and run its companion process, which opens the WebSocket port that browser clients connect to. The bridge and the Java server must be the same game version.
- Open the ports and route them. The WebSocket port has to be reachable from the internet. For a small private world, a tunnel that terminates TLS and gives you a public hostname on port 443 is usually easier and safer than exposing a home IP directly.
- Serve the client yourself if you want. Hosting your own HTML client and asset pack next to the server keeps the version matched and lets you control caching and offline access.
- Test from outside your network. Use mobile data, not wifi, or you will be testing a path your friends cannot use.
Lag and Connection Troubleshooting
| Symptom | Most likely cause |
|---|---|
| Instant refusal on connect | Insecure WebSocket from an HTTPS page, or a version mismatch |
| Timeout after 10 to 30 seconds | Wrong address or port, server offline, firewall blocking |
| Connects, then disconnects immediately | Whitelist, ban list or an outdated bridge process |
| Playable but rubber-banding | Distance to the server, or a client running at very low FPS |
| Everyone lagging at once | Server CPU or too much loaded terrain, not your connection |
Beyond the table, the fixes that reliably work: choose a server in your own region, lower your render distance so the client stops stalling on chunk updates, close background tabs and downloads, and test with a wired connection. Note that a low local frame rate looks exactly like network lag when you are moving around, because your client is simply failing to send updates in time.
Rules, Moderation and Safety
Public browser servers are a mixed bag, and it pays to be a little careful. Practical rules for 2026:
- Never reuse a real password. Server accounts are local to that server and are not protected by the security practices you would expect from a commercial service.
- Do not share personal details in chat. Many of these servers are populated by school-age players and are moderated lightly or not at all.
- Remember the legal position. These servers run an unauthorised client. Do not host commercially, do not charge for access and do not claim affiliation with Mojang or Microsoft.
FAQ
Can I join a normal Minecraft server from the browser?
No. The server has to run the browser-compatible bridge software, because browsers cannot open the raw connection a vanilla server expects. Popular desktop servers are almost never reachable this way.
Why does my connection fail when the client page uses HTTPS?
Mixed content. A secure page is not allowed to open an insecure WebSocket. Use a server that offers a secure socket on port 443, or load the client over plain HTTP.
Do I need to port forward to host?
Not necessarily. A tunnel service can expose your local server on a public hostname with TLS on port 443, which is friendlier to browsers and avoids publishing your home IP. Port forwarding also works but requires exposing the port yourself.
How many players can a small server hold?
For a home machine, a handful comfortably: five to ten players on modest hardware, more if the world is small and the render distance is low. The bridge adds overhead on top of the Java server, so budget for it.
Are the server lists safe?
They are directories, not services. Use them to find an address, but verify the version and the region, avoid anything that asks you to download a program, and never enter credentials that matter.