Fixing "Connection timed out" and "Connection refused: getsockopt" in Minecraft

Read the error first

getsockopt is not a cause. It is the name of the socket call the JVM's networking code happened to be making when the connection died, and Java appends it to whichever IOException fired. It tells you where in the network stack the failure surfaced, not why. Two entirely different problems produce the exact same getsockopt text.

What actually matters is the word in front of it, and the two you will see mean opposite things:

• "Connection timed out" means a packet went out and nothing came back. No answer at all, from anyone.
• "Connection refused" means a machine on the other end answered immediately and actively rejected the connection.

One is silence. The other is a reply. They point at different parts of the path between your client and the server, so the fix depends entirely on which one you have.

"Timed out": nothing answered

The client sent a connection request and waited until it gave up without hearing back. That happens anywhere along the path where a packet can go in and nothing comes out, which is more places than "the server is down."

Fix one: check whether the server is actually online

This is the first thing to rule out, and you do not need to guess. Server status pings the address the same way your client does and reports whether anything answered, along with the version and player count if it did. If it reports no answer at all, the timeout is real and the problem is on the server side or the network between you.

Fix two: your ISP or the server's ISP is blocking inbound traffic

A residential internet connection is not guaranteed a real public IP address. Many ISPs put customers behind Carrier-Grade NAT (CGNAT), sharing one public address across many households. If the server is hosted on a connection like that, no port forward on the home router can fix it, because the address players are told to connect to was never actually routed to that router. Ask the ISP directly whether the connection has a dedicated public IP. If not, the practical fix is a tunneling service that exposes the server through its own address instead of the ISP's, or paying for a static IP if the ISP offers one.

Fix three: a firewall is dropping the packets, not rejecting them

A firewall configured to drop traffic discards it silently, producing no reply and therefore a timeout, which is different from a firewall that rejects it with an explicit response. Router firewalls and Windows Firewall both default to dropping unsolicited inbound traffic. Open the server's port on both the router's port forwarding rules and the host machine's own firewall; if either one is still closed, the symptom looks identical to the server being offline.

Fix four: the address you're using is wrong or stale

Home internet connections commonly have a dynamic IP that changes over time. An address that worked last month may belong to someone else's connection now. If you are connecting by IP rather than a domain, confirm it against what the server owner is currently giving out. If you are using a domain, confirm its DNS record actually points at the current address; server status resolves the address fresh on every check, so it will surface a stale record.

Fix five: your own security software is silently blocking Java

This one is client-side. Windows Defender and third-party antivirus and security suites can block an application's outbound connections without telling you, and Java's javaw.exe gets caught by this more often than most because it is not a browser or a familiar named program. Add an exception for Java in the firewall and antivirus settings, or temporarily disable the suite to confirm it is the cause before configuring a permanent exception.

"Refused": something answered and said no

The other machine's network stack received the connection attempt and returned an immediate rejection, a TCP reset. This happens fast, not after a wait, and it means the host is reachable. The problem is what is or is not listening there.

Fix six: wrong port, or nothing listening on that port

Java Edition's default port is 25565. If the server runs on a different port, everyone connecting has to include it explicitly, address:port, and a client that omits it will be refused by whatever generic service, or nothing, is listening on 25565 instead. Bedrock Edition is not a different port on the same server, it is an entirely separate protocol on its own port, 19132 over UDP by default. Trying to reach a Java server on the Bedrock port, or the reverse, is refused for the same reason: nothing at that address speaks that protocol. See Geyser crossplay setup if you need both editions to join the same server.

A proxy setup adds a second place this can go wrong: the proxy's own port must be open and forwarded, not the backend server's port, since players never connect to the backend directly. See setting up a Velocity proxy network for how that's structured.

Fix seven: right address, wrong machine

A refusal also happens when the connection reaches a real, reachable host, but not the one running the server. Shared hosting, a reverse proxy pointed at the wrong internal address, or a DNS record left over from a server that has since moved to a different machine all produce this. The IP resolves, something is there, and it is not what you expect. Confirm with server status what is actually answering at that address before assuming the server itself is broken.

The case that looks like the server is down and is not

A self-hoster tests their server, and it works perfectly from a device on the same network using the LAN IP, something like 192.168.1.50. Then they try their public IP or their domain from that same network, to see what a real player would see, and get exactly this error. Their first assumption is always that the server crashed or the forward broke. It did not.

This is NAT loopback, also called hairpinning: your own router sending a request back in through your own public IP, from inside your own network. Plenty of consumer routers simply do not support it. The request leaves the device, hits the router, and the router has no rule for routing a public-facing address back to a machine on its own LAN, so it drops or mishandles it. Depending on the router this shows up as a timeout or a refusal, which is why it gets misdiagnosed as either.

The server was never unreachable. It only looked that way from the one vantage point that routers most often get wrong.

Fix: use the LAN IP when connecting from inside the same network. The public IP or domain only has to resolve correctly for players connecting from outside your network, which is what it will actually be used for. Testing loopback specifically is not necessary; testing from an outside connection, or with server status, is what actually confirms the server is reachable to the people who matter.

A VPN changes what your router sees

An active VPN, on either the client or the machine hosting the server, routes traffic through a virtual network interface. A port forward rule on the router points at the machine's normal network interface. The VPN's interface is not that one, so the rule the router is holding never fires, and the connection times out or is refused depending on how the router handles traffic it has no rule for.

This looks identical to a broken port forward because, from the router's point of view, it is one: the traffic simply is not arriving on the interface it was configured to watch.

Fix: disable the VPN on whichever end has one and test again. If the VPN needs to stay on, the forwarding rule has to be rewritten to target the VPN's virtual adapter specifically, which most consumer routers cannot do and most VPN providers do not support for inbound traffic in the first place.

Working through it in order

1. Read the exact text: timed out or refused. They point at different problems.
2. Check server status. If it gets no answer either, the problem is real and not specific to you.
3. Timed out: check the server is online, then CGNAT, then firewall drop rules, then the address itself, then your own client-side security software.
4. Refused: check the port matches what the server actually listens on, and that the address resolves to the right machine.
5. Self-hosting and it fails only from inside your own network: it is NAT loopback, not an outage. Use the LAN IP locally.
6. A VPN running on either end: disable it and test again before looking anywhere else.