Icarus Dedicated Server Not Showing in the Server Browser (Registration & Port Fix)
This is one of the most frustrating Icarus self-hosting problems because nothing looks broken. The dedicated server starts, the console scrolls through a clean boot, the world loads, the log shows no fatal error - and yet the server never appears in the in-game Dedicated Servers browser. Friends search the exact server name and get nothing back. The machine is online, the process is running, but as far as the rest of the world is concerned the server does not exist.
Icarus shares this failure mode with almost every Steam-based survival game, including ARK and Conan Exiles: a server can be perfectly healthy and still be invisible because being listed in the browser is a separate job from running the game. The cross-game pattern is the same. The specific port numbers and parameters below are Icarus-specific.
The symptom in one line
- Server boots fine, log is clean, process is alive.
- It never shows up under the in-game Dedicated Servers tab.
- Friends searching the exact name find nothing.
- Direct connect by IP and port sometimes still works - which is the biggest clue.
How Icarus Server Listing Actually Works
Two completely different things happen when a player joins your server, and they travel over two different ports.
1. The game / connection port (default 17777/UDP). This is the channel the game client uses once it has already decided to connect. It carries movement, world state, voice, and everything else that makes the session playable. If only this port is open, a player who already knows your address can usually still join by direct connect - but they will never find you on their own.
2. The Steam query port (default 27015/UDP). This is the port that makes your server discoverable. Icarus, like other Steam dedicated servers, registers itself with Steam's master server infrastructure and advertises a query endpoint. When a client opens the Dedicated Servers browser, it asks Steam for the list, then sends a lightweight query packet to each server's advertised query port to read back the name, prospect, player count, and ping. If that query never gets a reply, the server is treated as dead and is filtered out of the list - even though the game port is wide open.
So the browser entry is built entirely from the query port, and the playable session runs on the game port. A server can have one working and the other broken, which is exactly why "online but not listed" is so common.
The single most important rule: the query port that the server advertises to Steam must be the same port that is actually open and reachable from the public internet. If the advertised number and the open number disagree by even one digit, the master server hands clients an endpoint that answers nothing, and your server silently drops off the list.
One More Icarus-Specific Precondition: an Active Prospect
Before you start chasing ports, confirm the server is past the lobby. An Icarus dedicated server comes up in a lobby state and only one prospect, outpost, or open-world session runs at a time. Until a prospect is actually loaded and running, the server can sit idle and may not present itself the way you expect in the browser. Make sure a world is loaded, then re-check. If the world is up and the server is still missing, the problem is networking, and the rest of this guide applies.
Ranked: Why an Icarus Server Stays Invisible
These are ordered by how often they are the real cause for self-hosters.
1. The query port is not forwarded or not open
By far the most common cause. The game port (17777/UDP) gets forwarded because that is the number everyone copies first, and the query port (27015/UDP) gets forgotten. Result: the server runs, direct connect works, the browser shows nothing because the discovery query never reaches the box. Both ports must be open on UDP, on both the router and the host firewall.
2. Asymmetric or mismatched port mapping (the advertised port is unreachable)
This is the subtle one, and it bites people who run Icarus in Docker, behind a NAT rule that translates ports, or through any layer that remaps one port number to another. The classic community example: a host maps an external port to a different internal/container port - for instance forwarding host 27017 to container 27015, or running the query service on one number while opening another. The server still advertises the query port it was told to use, so Steam hands clients an address whose port nobody can reach. The session is healthy, the listing is dead.
The fix is to keep the mapping symmetric: the externally reachable query port, the port the server is configured to advertise, and the port your firewall opens must all be the same number. In a Docker compose file that means mapping it straight through rather than translating it:
# Correct - symmetric, advertised port == open port
ports:
- "17777:17777/udp" # game / connection port
- "27015:27015/udp" # Steam query port
# Wrong - host 27017 -> container 27015
# The server advertises 27015 but only 27017 is open on the host,
# so the query the browser sends to 27015 goes nowhere and the
# server never appears in the list.
# - "27017:27015/udp"If you deliberately want a non-default query port, that is fine - but then you must change the port the server advertises as well (via the query-port launch parameter) and open that same number on the firewall. The number must agree at all three layers.
3. The wrong public IP is being advertised
If the host has more than one network adapter, a changed public IP, or sits behind a translation layer that rewrites the source address, Icarus can advertise an address that does not actually route back to the box. The query never arrives, the listing dies. After any network change, confirm the public IP the server is reachable on and bind to a single, clear interface where possible.
4. NAT, double-NAT, and CGNAT
Home and small-office connections increasingly sit behind carrier-grade NAT (CGNAT), where the ISP shares one public address across many customers and you never get a port you can forward. A second router stacked behind the ISP gateway creates the same problem (double-NAT). In both cases UDP cannot be forwarded inbound at all, so neither the game port nor the query port is truly reachable. No amount of router configuration fixes a connection that has no forwardable public port - the server has to move to an address that does.
5. Firewall blocking UDP
Even with forwarding correct, the host firewall (Windows Defender Firewall, ufw, a cloud security group) may silently drop inbound UDP. The rule must allow inbound UDP on both port numbers. On a cloud VM this is two places at once: the OS firewall and the provider's security group.
Workaround: Verify the Server Is Actually Reachable With Direct Connect
Before you tear anything down, prove whether the server is genuinely up. The browser only tests the query port; a direct connection tests the game port. If a direct join works while the browser stays empty, you have confirmed the server and world are healthy and the fault is purely discovery - the query port or the advertised endpoint - not the game itself.
- Have a friend (or a second machine on a different network) attempt to connect directly to your public IP and game port.
- If the direct connection succeeds, the game port is open and the world is fine. Focus all further effort on the query port and what it advertises.
- If even direct connection fails, the game port itself is blocked or the IP is wrong - start from the port-forwarding and NAT items above.
Do not rebuild the world or reinstall. A server that is reachable by direct connect but missing from the browser has a networking problem, not a corrupted save. Reinstalling wastes time and risks the world for no reason.
Diagnostic Checklist
Work down this list in order. Stop at the first item that fails - that is almost always your cause.
| Step | What to confirm | How |
|---|---|---|
| 1 | A prospect/world is actually loaded | Server is past the lobby state, not idle |
| 2 | Both ports are listening on the host | Confirm the game port and query port are bound on UDP locally |
| 3 | The query port is open from the outside | Use an external UDP port test against your public IP and query port |
| 4 | Advertised port == open port | The configured/advertised query port matches the number your firewall and router actually expose - no translation |
| 5 | Correct public IP advertised | One clear interface, current public address, no stale binding |
| 6 | Not behind CGNAT/double-NAT | Confirm you own a forwardable public port at all |
| 7 | Direct connect works | Proves the game port and world are healthy; isolates the fault to discovery |
The decisive test is step 4 combined with step 3: if an external query packet sent to the advertised port gets no reply, that is the entire problem. Either the port is closed, or the number you opened is not the number the server is telling Steam to query.
Why a Dedicated Server Is Worth the Trouble: Persistent Prospects
It is tempting, when discovery fights you, to fall back on the in-game peer-to-peer co-op where one player hosts from their own session. That convenience comes with a real cost. In host-based co-op the world and your prospect live inside the host's game session, so when the host quits, crashes, or loses connection, everyone else is dropped and progress can be lost. A timed prospect is especially unforgiving - lose the host mid-mission and the run can be gone.
A dedicated server keeps the prospect, outpost, or open-world session persistent and independent of any single player. The world keeps existing whether or not the host is online; players come and go without ending the session; long prospects and persistent outposts survive across days. Solving the listing problem once buys you a stable home for your group that fragile peer-to-peer hosting can never match.
How Managed Hosting Removes This Entire Problem
Every cause above is an infrastructure problem, not a gameplay one, and that is exactly the class of problem managed hosting exists to delete. On a properly run host:
- Both ports are pre-opened on routable public addresses - no port forwarding, no firewall rules, no Docker mapping to get wrong.
- The advertised query port always matches the open port because there is no asymmetric translation layer in front of the server.
- There is no CGNAT or double-NAT - the server sits on a real public IP that registers cleanly with Steam.
- Registration is handled, so the server shows up in the browser the way players expect.
- Prospects stay persistent on always-on hardware with backups, so a dropped host never costs you a mission.
Related Icarus Guides
- Icarus Dedicated Server Setup - full install, configuration, and port-forwarding walkthrough.
- Icarus Prospects Hosting - keeping timed missions persistent on a dedicated server.
- Icarus Server Not Showing Fix - the browser search-result-limit angle and quick launch-argument checks.
- Icarus Network Error 65 Fix - the related connect-time network error.
High-Performance Hosting: Supercraft runs Icarus dedicated servers with both ports pre-opened, registration handled, and persistent prospects on always-on hardware - so "online but not listed" never happens to you.
Looking for managed Icarus server hosting? Supercraft runs Icarus dedicated servers with daily backups, instant setup, and 5 region options - ports pre-opened and registration handled. Plans from $5.99/mo.