The Isle Evrima Server Not Showing in the Server Browser: Causes and Fixes

If your The Isle Evrima server is running, RCON even answers, and still nobody can find it in the server browser, the Game.ini is almost never to blame. In every case we have taken apart so far it came down to one of three causes: EOS credentials that never reach the server, an incomplete certificate store on Windows, or a QueryPort that doesn’t match the port the server actually listens on. The quickest clue comes from LogHttp=Verbose in Engine.ini. Without that log category, the exact step that fails stays invisible.

We tested all of this with Evrima 0.21.784 on Windows Server under KVM, as of September 2026.

The three most common causes at a glance

Cause	How you notice it	Fix
EOS credentials missing or not arriving	EOS login fails or registration never starts	Put the credentials in Engine.ini and check them there
Incomplete root certificate store on Windows	libcurl error: 60 in the log	Import root certificates with certutil -generateSSTFromWU
QueryPort differs from the game port	Server is visible, joining ends in Connection TIMED OUT	Set QueryPort to the game port

Does this affect my RespawnHost server?

All three causes come from Windows installs that people run themselves, for example on their own dedicated server or VPS. On our The Isle servers they are already taken care of:

Item	At RespawnHost
EOS credentials	Written to Engine.ini during installation
Certificate store	Not an issue, our servers run on Linux
QueryPort	Set to your game port automatically on every start
Updates	Installed automatically on restart as long as automatic updates are enabled under Startup

If your server still doesn’t show up, work through this:

1. Give it a few minutes after starting. Right after boot the server list doesn’t know your server yet. The next section explains why.
2. Check that your game version matches the server version. After an Evrima patch, a restart in the panel is enough for the server to pull the update.
3. In the file manager, add LogHttp=Verbose to TheIsle/Saved/Config/LinuxServer/Engine.ini (as shown in step 1), restart, then search TheIsle/Saved/Logs/TheIsle.log for runtime/update.
4. If none of that helps, contact support and attach the log file.

How does an Evrima server get into the server list?

This is where most guides go wrong. The Evrima server list does not depend on the classic EOS session. Getting listed takes two stages.

Stage 1: Logging in to Epic Online Services

On startup, the server logs in to Epic Online Services. In the log it looks like this:

LogRedpointEOSIdentity: DedicatedServer: Performed Login on dedicated server.
LogRedpointEOSIdentity: Local user 0 is now signed in as (dedicated server)
LogOnlineSubsystemRedpointEOS: Broadcasting 'OnLoginComplete' event for local user 0.

That is authentication and nothing more. A successful login tells you nothing about whether the server will end up in the list.

Stage 2: Registering with The Isle’s API

Next, the server talks to a separate HTTPS service that sits between the game and EOS. Two addresses show up in our logs:

Endpoint	Method	What it does
api.warphosting.com.au/v1/servers/official/check	POST	Checks whether the server counts as an official server. Irrelevant for community servers. The response is 18 bytes.
api.warphosting.com.au/v1/runtime/update	POST	Heartbeat every 10 seconds, the actual status report

The heartbeat identifies itself with User-Agent: TheIsleServer/1.0 and sends about 164 bytes of JSON each time.

How do I know whether my server is listed?

By the response code on /runtime/update:

Response code	Meaning
404	The backend doesn’t know the server. It is not listed.
202	Registration accepted. The server is in the list.

After a restart you usually get five or six 404s before it flips to 202. That is also the reason behind the often quoted two to five minutes before a server appears in the browser.

For troubleshooting this means that LogOnlineSession, LogRedpointEOSSessions and LogRedpointEOSCore don’t capture these requests at all. If you only set those categories to Verbose, you see nothing after the EOS login and it’s easy to think the server has frozen.

How do I find the cause?

The commands below are written for Windows and PowerShell. All paths assume an install in C:\GameServers\theisle, so adjust them to your folder.

Step 1: Turn on logging

Add this to TheIsle\Saved\Config\WindowsServer\Engine.ini (on Linux the file lives in the LinuxServer folder):

[Core.Log]
LogHttp=Verbose
LogOnline=Verbose
LogOnlineSession=Verbose
LogOnlineSubsystemRedpointEOS=Verbose

LogHttp=Verbose is the one that matters most. Restart the server afterwards.

Step 2: Is the process running at all?

Get-Process *TheIsle* | Select Name,Id,StartTime

You should see two processes: the wrapper TheIsleServer and TheIsleServer-Win64-Shipping.

Step 3: Is the server working or stuck?

$p = (Get-Process -Name TheIsleServer-Win64-Shipping).Id
(Get-Process -Id $p).CPU
Start-Sleep 30
(Get-Process -Id $p).CPU
Get-Process -Id $p | Select @{n='RAM_GB';e={[math]::Round($_.WorkingSet64/1GB,2)}}

CPU is the accumulated processor time in seconds. An empty Gateway server at 30 Hz uses roughly one to two seconds of CPU time in 30 seconds. If the value doesn’t move at all, the process is hung.

Step 4: Check the registration status

cd C:\GameServers\theisle
Select-String -Path .\TheIsle\Saved\Logs\TheIsle.log -Pattern "runtime/update" | Select -Last 1

There is no faster health check: 202 means listed, 404 means not registered.

Step 5: Why does registration fail?

Select-String -Path .\TheIsle\Saved\Logs\TheIsle.log -Pattern "libcurl error|completed with code|Starting POST"

This shows you the actual error. We cover the most common hits below.

Step 6: Is the server listening on the right ports?

Get-NetUDPEndpoint -LocalPort 7777 -ErrorAction SilentlyContinue
Get-NetTCPConnection -LocalPort 10000,8888 -State Listen -ErrorAction SilentlyContinue

The first line checks the game port, the second the queue and RCON, all with their default values. If you set other ports, use yours. If your Game.ini has its own QueryPort, check that too, for example with Get-NetUDPEndpoint -LocalPort 7777,7778. Cause 3 explains why that matters.

Cause 1: EOS credentials don’t arrive

Symptom: The server runs, but the EOS login fails or the registration request never happens.

An Evrima server won’t run without its EOS credentials. The developer says so in their Steam post about server hosting, and names two ways to set them: two -ini: arguments in the start command or two lines in Engine.ini. We clearly recommend Engine.ini.

The right way

Put the credentials in Engine.ini:

[EpicOnlineServices]
DedicatedServerClientId=xyza7891gk5PRo3J7G9puCJGFJjmEguW
DedicatedServerClientSecret=pKWl6t5i9NJK8gTpVlAxzENZ65P8hYzodV8Dqe5Rlc8

These are public values shared by every Evrima server. There is nothing secret about them, the developer publishes them. The advantage over the command line: you can open the file and see whether the value is really there.

Why not use the command line?

This is what the start command variant looks like:

.\TheIsleServer-Win64-Shipping.exe -Port=7777 `
  "-ini:Engine:[EpicOnlineServices]:DedicatedServerClientId=xyza..." `
  "-ini:Engine:[EpicOnlineServices]:DedicatedServerClientSecret=pKWl..." -log

In principle that can work. Current Unreal versions process several -ini: arguments one after another, and Epic also documents a form with a single argument and comma separated pairs:

-ini:Engine:[Section1]:Key1=Value1,[Section2]:Key2=Value2

Older engine versions, however, only read the first -ini:Engine:, in which case the ClientId arrives and the secret doesn’t. In one of our cases the values didn’t arrive through the command line, and you simply can’t see that from the outside. With Engine.ini that can’t happen to you.

Cause 2: Incomplete certificate store on Windows

This was our most involved case, and without LogHttp you will practically never find it.

Symptoms

• The server starts cleanly, the map loads, the GameMode initializes
• The EOS login succeeds
• RCON on port 8888 answers without problems
• Not a single error message in the normal log
• No CreateSession and no registration
• The server still isn’t listed after 30 minutes

What does the log say?

LogHttp: Warning: request failed, libcurl error: 60 (SSL peer certificate or SSH remote key was not OK)
LogHttp: Warning: libcurl info message cache 0 (Host api.warphosting.com.au:443 was resolved.)
LogHttp: Warning: libcurl info message cache 8 (TLSv1.3 (IN), TLS handshake, Certificate (11):)
LogHttp: Warning: libcurl info message cache 9 (TLSv1.3 (OUT), TLS alert, unknown CA (560):)
LogHttp: Warning: libcurl info message cache 10 (SSL certificate problem: unable to get local issuer certificate)
LogHttp: Warning: POST https://api.warphosting.com.au/v1/servers/official/check completed with reason 'Other' after 0.02s

DNS resolves, the TCP connection is up, and the TLS handshake gets as far as the Certificate message. Then the server gives up because it can’t trace the certificate chain back to a trusted root.

Where does this come from?

Freshly deployed Windows Server images often ship with an incomplete root store. Windows normally fetches missing root certificates on demand from ctldl.windowsupdate.com. If that address is blocked or the sync never ran, the chain is missing. api.warphosting.com.au sits behind Cloudflare, and depending on the edge server the chain ends at Let’s Encrypt or Google Trust Services.

The EOS login still works because it uses different endpoints with a different chain. That is exactly what makes this error so confusing.

How to fix it

Open PowerShell as administrator:

certutil -generateSSTFromWU C:\roots.sst
Import-Certificate -FilePath C:\roots.sst -CertStoreLocation Cert:\LocalMachine\Root

The first command downloads the current list of trusted root certificates from Windows Update, the second imports it into the computer’s store. Then restart the server.

Did it work?

Invoke-WebRequest https://api.warphosting.com.au/v1/servers/official/check -Method POST -UseBasicParsing

If you get a Pydantic error back about a missing field in the body, everything is fine. That is an HTTP 422 from the application, so TLS worked. PowerShell always throws an exception on 4xx responses, which is why it only looks like an error.

If you get a trust error instead, the import didn’t take. Check whether the root certificates are there:

Get-ChildItem Cert:\LocalMachine\Root | Where-Object { $_.Subject -match "ISRG|GTS Root|DigiCert Global Root" } | Select Subject,NotAfter

What about cacert.pem?

Packaged builds usually don’t have a loose cacert.pem on disk, so libcurl falls back to the Windows root store. To check whether one is lying around anyway:

Get-ChildItem C:\GameServers\theisle -Recurse -Filter "cacert.pem" -ErrorAction SilentlyContinue

If the file is older than about 2021, it lacks ISRG Root X1. In that case drop a current version from curl.se on top of it, but make a copy first. The next SteamCMD validate will overwrite it again, though.

Cause 3: QueryPort doesn’t match the bound port

Symptom: The server is visible in the browser, but joining gives you this:

Client Disconnected
UNetConnection::Tick: Connection TIMED OUT. Closing connection.. Elapsed: 20.01
RemoteAddr: <public IP>:7778
UniqueId: INVALID, PC: NULL, Owner: NULL

Or you get “Data Acquisition Failed” instead.

Where does this come from?

The server registers the value from QueryPort with the API as its connection address. What it actually binds, though, is only the game port from ?Port=. If those values differ, the client gets an address where nobody answers and runs into a 20 second timeout.

In our case the Game.ini had QueryPort=7778 and the start command had ?Port=7777. Get-NetUDPEndpoint showed only 7777 as bound, but the client tried to connect to 7778.

How to fix it

Set the QueryPort in Game.ini to the game port from the start command:

QueryPort=7777

.\TheIsleServer.exe "/Game/TheIsle/Maps/Game/Gateway/Gateway?Port=7777" -log

Check it with:

Get-NetUDPEndpoint -LocalPort 7777

Which ports does The Isle Evrima need?

These are the usual defaults. Whatever you put in Game.ini or the start command takes precedence.

Port	Protocol	Purpose
7777	UDP	Game, and according to several guides the server queries as well
10000	TCP	Queue (QueuePort), only with bQueueEnabled=true
8888	TCP	RCON (RconPort), only with bRconEnabled=true

Sources disagree on the QueryPort, though. Several guides and server tools put it on the game port, while one troubleshooting page explicitly asks for a separate port. What we saw points to the game port: only one UDP port was ever bound, and our own servers also run with QueryPort equal to the game port.

Reference: paths, start command and firewall

Paths

C:\GameServers\theisle\TheIsle\Saved\Config\WindowsServer\Game.ini
C:\GameServers\theisle\TheIsle\Saved\Config\WindowsServer\Engine.ini
C:\GameServers\theisle\TheIsle\Saved\Logs\TheIsle.log
C:\GameServers\theisle\TheIsle\Saved\PlayerData\

Unreal rotates the log on every start, and the old file becomes TheIsle-backup-<timestamp>.log. So it’s best to search across all logs:

Select-String -Path .\TheIsle\Saved\Logs\*.log -Pattern "..."

Start command

cd C:\GameServers\theisle
.\TheIsleServer.exe "/Game/TheIsle/Maps/Game/Gateway/Gateway?Port=7777" -log

Start through TheIsleServer.exe in the root folder, not the shipping binary directly. The wrapper passes the project path correctly.

Batch file with auto update and restart

@echo off
title The Isle Evrima Server
:StartServer
echo (%time%) Checking for updates...
start /wait C:\steamcmd\steamcmd.exe +force_install_dir C:\GameServers\theisle +login anonymous +app_update 412680 -beta evrima validate +quit
echo (%time%) Starting server...
start /wait C:\GameServers\theisle\TheIsleServer.exe "/Game/TheIsle/Maps/Game/Gateway/Gateway?Port=7777" -log
echo (%time%) Server stopped. Restarting in 60 seconds...
timeout /t 60
goto StartServer

-beta evrima is mandatory. Without it SteamCMD installs the old Legacy build. The app ID is 412680, and an anonymous login is enough.

Firewall inside the VM

New-NetFirewallRule -DisplayName "TheIsle Game UDP" -Direction Inbound -Protocol UDP -LocalPort 7777 -Action Allow
New-NetFirewallRule -DisplayName "TheIsle Queue TCP" -Direction Inbound -Protocol TCP -LocalPort 10000 -Action Allow
New-NetFirewallRule -DisplayName "TheIsle RCON TCP" -Direction Inbound -Protocol TCP -LocalPort 8888 -Action Allow

You only need the queue rule if the queue is enabled, and the RCON rule only if you want to reach RCON from outside. Also watch the profile. A rule that only applies to “Private” won’t take effect if Windows classifies the connection as “Public”:

Get-NetFirewallRule -DisplayName "TheIsle*" | Select DisplayName,Enabled,Direction,Profile

If the VM runs under KVM behind libvirt NAT, also check the DNAT on the host. UDP 7777 has to be forwarded there, and TCP 10000 too if the queue is enabled:

iptables -t nat -L PREROUTING -n -v | grep -E "7777|10000|8888"

With bridged networking you can skip this step entirely.

Which log messages are harmless?

Message	What it means
LogSteamShared: Warning: Steam Dedicated Server API failed to initialize.	Normal. The server list runs through EOS and The Isle’s own API, not Steam.
LogDLSS: NVIDIA NGX DLSS requires an NVIDIA RTX series graphics card	Normal on a headless server.
LogNavigationDataBuild: AgentMaxStepHeight ... not high enough in steep slopes	Cosmetic, only affects navmesh quality.
LogBlueprintUserMessages: Failed to find console variable 'r.RayTracing...'	Normal without an RHI.
404 on /runtime/update right after startup	Expected. It should switch to 202 after about a minute.

Checklist when your server stays invisible

1. Run Select-String ... -Pattern "runtime/update" | Select -Last 1: do you see 202 or 404?
2. On 404, set LogHttp=Verbose, restart and search for libcurl error.
3. On error 60, fetch the root certificates with certutil -generateSSTFromWU and import them.
4. Server visible but joining fails: compare the QueryPort with the output of Get-NetUDPEndpoint.
5. Timeout with RemoteAddr:<port>: that exact port has to be bound and forwarded.
6. “Data Acquisition Failed” even though the ports are right: try bQueueEnabled=false.
7. Compare the version shown in the browser with your client version. If they differ, the browser filters the server out.
8. Everything is correct and it still fails: click Connect a few times. The API in between has the occasional hiccup.

Still unclear

• The paths /v1/servers/official/check and /v1/runtime/update come from our own logs. They are not officially documented.
• We couldn’t fully confirm whether /servers/official/check has to return 200 for registration or whether it’s just a side request. The name and the 18 byte response suggest a plain status query.
• Why the credentials didn’t arrive through the command line in one of our cases is still open. Current Unreal versions should process several -ini: arguments.
• Which port does what seems to change between builds, and guides disagree on the QueryPort. Our observations apply to 0.21.784.
• According to several hosting guides, “Data Acquisition Failed” has become more frequent since the December 2025 update and can hit correctly registered servers too. So it isn’t necessarily a configuration problem.

Frequently asked questions

How long does it take for a new The Isle server to appear in the browser? Usually two to five minutes, because the first heartbeats after startup are still answered with 404.

Does a successful EOS login mean my server is listed? No, it is only listed once /runtime/update answers with 202.

Do I have to keep the EOS credentials secret? No, the developer publishes them, and every Evrima server uses the same values.

Why is there no error in the log even though the server is missing? The registration only shows up in the log once LogHttp=Verbose is set.

Is the warning “Steam Dedicated Server API failed to initialize” a problem? No, the server list runs through EOS and The Isle’s own API, not Steam.

Do I need to change Engine.ini on a RespawnHost server? No, we set up the EOS credentials and the QueryPort automatically.

What RespawnHost recommends

Set LogHttp=Verbose right when you set the server up and check for runtime/update once after every restart. If it says 202, you’re fine and there’s no guesswork. Put the EOS credentials in Engine.ini and set the QueryPort to the game port. If you’d rather skip all of this, get a The Isle server at RespawnHost, where it’s set up that way from the start.

Sources

• Afterthought on Steam: Update #5 Server Hosting Information & RCON Support, July 13, 2022
• XGamingServer Docs: The Isle Evrima Server Config
• Game Host Bros: Troubleshooting Your The Isle Evrima Server
• Epic Games: Configuration Files in Unreal Engine
• Microsoft Learn: Configure trusted roots and disallowed certificates
• Our own reproduction on Windows Server under KVM, September 2026