Can't Connect to a Minecraft Server but Your Internet Works? Here's Why

If web pages load fine but Minecraft keeps dropping you back to the server list, the problem is almost never "your internet" — it's one layer below that: a firewall quietly blocking Java, a stale DNS record, a mistyped port, or the server simply being offline. Your browser proves the line works, not that one specific game route does. The fastest way to find out which layer is broken is a single split test before you change any settings: try a second server you know is good, pulled from the live rankings or the full server list. If that one connects, the trouble is tied to the first server or the address you saved for it; if the second one fails too, the problem is on your own machine or network, and the rest of this is about narrowing it down.

Run the split test first

The split test does most of the work here, because it cuts the list of suspects in half in about thirty seconds. A known-good second server — a big, clearly-populated one from the rankings — tests your client, your account, your firewall, and your route all at once. Connect to it and the original server is the thing that's wrong; fail on it and you've moved the search onto your own setup.

The cleaner version of the same test swaps the network instead of the server. Connect the PC to a phone hotspot and retry the same address. If it works on the hotspot but not your home Wi-Fi, the culprit is on that home network — a wedged router route, an ISP-level block, or a stale DNS cache. If it still fails on the hotspot, the problem is local to the machine (a firewall, a wrong address, a version gap) or the server is genuinely down. Doing these two tests first keeps you from rewriting firewall rules for a server that was just restarting.

Read the exact error — each one points at a different layer

The red text matters, but only the short phrase after the colon. Each one fails at a different stage, so the suffix tells you where to look.

"Connection timed out"

io.netty.channel.AbstractChannel$AnnotatedConnectException: Connection timed out: no further information: means your client sent a connection request and nothing ever answered — no refusal, just silence. That's a network-path problem, a firewall dropping the packet, or the host being fully offline. The full walkthrough lives in the connection timed out guide, but the headline is that silence points outward, at the route or the host, not at your install.

"Connection refused"

java.net.ConnectException: Connection refused: no further information: is the opposite — a machine did answer, and it actively turned you away. That fast "no" almost always means the server process isn't running, or it's listening on a different port than the one you connected to. Refused is nearly always server-side; you reached the box, but nothing was bound to that port.

"No route to host"

io.netty.channel.AbstractChannel$AnnotatedConnectException: No route to host: no further information: means your machine couldn't find a path to the server's IP at all, before any port comes into play — usually a dead or changed IP, a network-level block, or your own connection being impaired. The no route to host guide breaks the routing layer down further.

"Unknown host"

Unknown host, with java.net.UnknownHostException underneath, is a DNS failure: the address never resolved to an IP. The host couldn't be looked up, which means a typo in the hostname, a domain whose DNS record is broken, or a stale entry cached on your machine. This is the one a DNS flush actually fixes — more on that below.

"Outdated client!" / "Outdated server!"

Outdated client! Please use 26.2 means your side is behind and needs to match the server's drop; Outdated server! I'm still on 26.1 means the server is behind, which is what you usually see right after you've updated your own game. Client and server must share the same network protocol number to connect — 26.1 is protocol 775, 26.2 is protocol 776 — and a newer client is not backward-compatible. This is a version gap, not a network error, and no firewall or DNS step will touch it.

"Connection reset" and read timeouts

Connection reset and Internal Exception: io.netty.handler.timeout.ReadTimeoutException are different in kind: you did connect, and then the link broke mid-session. That's the server crashing, restarting, or lagging hard at the moment you joined, so retrying a minute later often just works once it settles.

The two silent culprits: firewall and DNS

When the split test points at your own machine, these two cause the most "internet works but Minecraft doesn't" cases, because neither prints a useful message.

A firewall or antivirus blocking Java is the big one. Windows Defender Firewall or third-party AV can block javaw.exe — the Java runtime that actually opens the connection — with no visible warning at all; your packet just never leaves. Fix it by allowing Java through the firewall: open "Allow an app through firewall" in Windows Defender Firewall and make sure javaw.exe is checked for both private and public networks. It usually shows up in that list as Java(TM) Platform SE binary, and the file itself sits at something like C:\Program Files\Java\<version>\bin\javaw.exe, though modern launchers often bundle their own JRE, so the exact folder varies by install. Temporarily switching the antivirus off to test is a quick way to confirm it's the cause before you write a permanent allow rule — just turn it back on after.

A stale DNS record is the other silent one, and it's the fix for Unknown host. Your machine cached an old or wrong IP for the server's domain, so lookups fail or point nowhere. Open Command Prompt as administrator and run ipconfig /flushdns to clear the cache so the next lookup is fresh; if that doesn't take, follow it with ipconfig /release and ipconfig /renew to pull a new lease. Flushing only helps when a bad record was actually cached, so treat it as a cheap step rather than a guaranteed fix — and verify the result with nslookup <server-address> to confirm it resolves and ping <server-address> to confirm the host answers.

When the address or the version is the real problem

Re-copy the address rather than typing it from memory. A single wrong character, a trailing space, or the wrong port reads as a failure to connect every time. Java uses host:port with a default port of 25565, and you only add :port when the listing names a non-default one — pasting a Bedrock-style 19132 onto a Java address points your client at a port nothing is listening on. Every listing shows the exact address to copy, so pull it straight from there.

If the error is a version gap, you have two honest options as a player: install the matching client version through a launcher profile, or wait for the server to update. You cannot fix it by adding ViaVersion to someone else's server — multi-version bridging is the owner's choice, not something a connecting player can switch on. Because Paper's 26.2 builds are still experimental, a lot of plugin servers are deliberately sitting on 26.1, so check the listing's version before assuming the gap is a mistake. The 26.1 server list and the 26.2 list — note the dotted form — let you filter to servers that match the client you're actually running.

When it's the server, not you

If the second test server connects, the listing shows the original live with players, and your address and port match exactly, then it's the host's side — a brief restart, an overload, or a network hiccup you can't reach from the client. A server that times out or refuses for everyone is offline, restarting, or overloaded, and that's not your fault to fix. Confirm it through the server's own status page or Discord, and lean on the fact that other servers work for you. If your home route looks wedged — pages load but one game path won't — power-cycling the modem and router (off about thirty seconds, back on) clears a bad NAT or routing state and sometimes frees exactly that stuck path.

FAQ

I'm on a Mac (or Linux) — what's the DNS flush command?

The ipconfig commands are Windows-only. On macOS, open Terminal and run sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder to clear the cache. Most Linux setups use systemd-resolved, where resolvectl flush-caches does the job; many distros keep no persistent DNS cache at all, in which case there's nothing to flush and you should look at the resolver or the raw IP instead. After any of these, confirm with nslookup <server-address> that the name resolves before retrying.

Bedrock won't connect even though my internet's fine — same steps?

Mostly, but Bedrock is a separate stack: it talks UDP on default port 19132, not Java's TCP 25565, so a firewall rule or port forward that only covers TCP won't help it. "Unable to connect to world" usually means that UDP port isn't reachable, and "Can't resolve hostname" is Bedrock's version of a DNS failure. If you're connecting to a Geyser server that bridges Bedrock to Java, the owner can run geyser connectiontest <ip> <port> from the console to check reachability — but that's an owner-side diagnostic, not something a player runs.

How do I know whether it's actually DNS before I start flushing?

Run nslookup <server-address>. If it returns an IP, DNS is working and flushing won't help — move on to firewall or route. If it fails or returns something stale, that's your sign. The other quick confirmation is to connect using the server's raw IP instead of its hostname: if the IP works and the name doesn't, the name resolution is the broken part, and flushing the cache or switching your resolver to 1.1.1.1 or 8.8.8.8 is the fix.

I have a VPN running — could that be it?

Yes, often. VPNs and proxies reroute your traffic and can break the connection outright, and some servers actively block known VPN IP ranges, which surfaces as a timeout or a refusal. Turn it off and retry as one of your first machine-side checks — it's a faster test than chasing firewall rules. If the connection works with the VPN off, you've found it; if you need the VPN for other reasons, you'll have to choose between it and that particular server.