The Isle Evrima Server erscheint nicht im Serverbrowser: Ursachen und Lösung

Läuft dein The Isle Evrima Server, antwortet sogar RCON, und findet ihn trotzdem niemand im Serverbrowser, liegt das so gut wie nie an der Game.ini. In den Fällen, die wir bisher auseinandergenommen haben, war es immer eine von drei Ursachen: EOS-Zugangsdaten, die beim Server nicht ankommen, ein lückenhafter Zertifikatsspeicher unter Windows oder ein QueryPort, der nicht zu dem Port passt, auf dem der Server wirklich lauscht. Den schnellsten Hinweis liefert LogHttp=Verbose in der Engine.ini. Ohne diese Logkategorie bleibt genau der Schritt unsichtbar, an dem es hakt.

Getestet haben wir alles mit Evrima 0.21.784 auf einem Windows Server unter KVM, Stand September 2026.

Die drei häufigsten Ursachen auf einen Blick

Ursache	Woran du es erkennst	Lösung
EOS-Zugangsdaten fehlen oder kommen nicht an	EOS-Login scheitert oder die Registrierung startet nie	Zugangsdaten in die Engine.ini schreiben und dort prüfen
Unvollständiger Root-Zertifikatsspeicher unter Windows	libcurl error: 60 im Log	Root-Zertifikate per certutil -generateSSTFromWU importieren
QueryPort weicht vom Game-Port ab	Server ist sichtbar, der Beitritt endet mit Connection TIMED OUT	QueryPort auf den Game-Port setzen

Betrifft das auch meinen RespawnHost-Server?

Die drei Ursachen stammen aus Windows-Installationen, die jemand selbst betreibt, etwa auf einem eigenen Root-Server oder VServer. Auf unseren The Isle Servern ist das schon abgefangen:

Punkt	Bei RespawnHost
EOS-Zugangsdaten	Stehen seit der Installation in der Engine.ini
Zertifikatsspeicher	Kein Thema, unsere Server laufen unter Linux
QueryPort	Wird bei jedem Start automatisch auf deinen Game-Port gesetzt
Updates	Laufen beim Neustart automatisch, solange „Automatische Updates“ unter Startup aktiv ist

Taucht dein Server trotzdem nicht auf, geh so vor:

1. Warte nach dem Start ein paar Minuten. Direkt nach dem Hochfahren kennt die Serverliste deinen Server noch nicht. Warum das so ist, steht im nächsten Abschnitt.
2. Prüf, ob deine Spielversion zur Serverversion passt. Nach einem Evrima-Patch reicht ein Neustart im Panel, dann holt sich der Server das Update.
3. Trag im Dateimanager LogHttp=Verbose in die Datei TheIsle/Saved/Config/LinuxServer/Engine.ini ein (wie in Schritt 1), starte neu und such dann in TheIsle/Saved/Logs/TheIsle.log nach runtime/update.
4. Hilft das alles nicht, melde dich beim Support und häng die Logdatei an.

Wie kommt ein Evrima Server in die Serverliste?

An dieser Stelle biegen die meisten Anleitungen falsch ab. Die Serverliste von Evrima hängt nämlich nicht an der klassischen EOS-Session. Der Weg dorthin hat zwei Stufen.

Stufe 1: Anmeldung bei Epic Online Services

Beim Start meldet sich der Server bei Epic Online Services an. Im Log sieht das so aus:

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.

Das ist reine Authentifizierung. Ob der Server in der Liste landet, verrät dir ein erfolgreicher Login noch nicht.

Stufe 2: Registrierung über die API von The Isle

Danach spricht der Server einen eigenen HTTPS-Dienst an, der zwischen Spiel und EOS sitzt. In unseren Logs tauchen dabei zwei Adressen auf:

Endpunkt	Methode	Was passiert
api.warphosting.com.au/v1/servers/official/check	POST	Prüft, ob der Server als offizieller Server gilt. Für Community-Server spielt das keine Rolle, die Antwort ist 18 Byte groß.
api.warphosting.com.au/v1/runtime/update	POST	Heartbeat alle 10 Sekunden und damit der eigentliche Statusbericht

Der Heartbeat meldet sich mit User-Agent: TheIsleServer/1.0 und schickt jedes Mal rund 164 Byte JSON.

Woran erkenne ich, ob mein Server gelistet ist?

Am Antwortcode auf /runtime/update:

Antwortcode	Bedeutung
404	Das Backend kennt den Server nicht, er ist nicht gelistet.
202	Die Registrierung ist angenommen, der Server steht in der Liste.

Nach einem Neustart kommen meist fünf oder sechs 404er, dann springt die Antwort auf 202. Das ist auch die Erklärung für die oft genannten zwei bis fünf Minuten, bis ein Server im Browser erscheint.

Für die Fehlersuche heißt das: LogOnlineSession, LogRedpointEOSSessions und LogRedpointEOSCore erfassen diese Anfragen allesamt nicht. Wer nur diese Kategorien auf Verbose stellt, sieht nach dem EOS-Login gar nichts mehr und hält den Server schnell für eingefroren.

Wie finde ich die Ursache?

Die Befehle sind für Windows und PowerShell geschrieben. Alle Pfade gehen von einer Installation unter C:\GameServers\theisle aus. Pass sie an deinen Ordner an.

Schritt 1: Logging einschalten

Trag in TheIsle\Saved\Config\WindowsServer\Engine.ini Folgendes ein (unter Linux liegt die Datei im Ordner LinuxServer):

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

Der wichtigste Eintrag ist LogHttp=Verbose. Danach startest du den Server neu.

Schritt 2: Läuft der Prozess überhaupt?

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

Du solltest zwei Prozesse sehen: den Wrapper TheIsleServer und TheIsleServer-Win64-Shipping.

Schritt 3: Arbeitet der Server oder hängt er?

$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 ist die bisher verbrauchte Prozessorzeit in Sekunden. Ein leerer Gateway-Server mit 30 Hz braucht in 30 Sekunden grob ein bis zwei Sekunden CPU-Zeit. Bleibt der Wert exakt stehen, hängt der Prozess.

Schritt 4: Registrierungsstatus prüfen

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

Schneller geht ein Gesundheitscheck nicht: 202 heißt gelistet, 404 heißt nicht registriert.

Schritt 5: Warum scheitert die Registrierung?

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

Hier steht der konkrete Fehler. Die häufigsten Treffer erklären wir weiter unten.

Schritt 6: Lauscht der Server auf den richtigen Ports?

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

Die erste Zeile prüft den Game-Port, die zweite Warteschlange und RCON, jeweils mit den Standardwerten. Hast du andere Ports eingetragen, nimm deine. Steht in der Game.ini ein eigener QueryPort, prüf ihn gleich mit, zum Beispiel mit Get-NetUDPEndpoint -LocalPort 7777,7778. Warum das so wichtig ist, steht bei Ursache 3.

Ursache 1: EOS-Zugangsdaten kommen nicht an

Symptom: Der Server läuft, aber der EOS-Login schlägt fehl, oder die Registrierung startet gar nicht erst.

Ohne die EOS-Zugangsdaten läuft kein Evrima-Server. Das schreibt auch der Entwickler in seinem Steam-Beitrag zum Server-Hosting. Er nennt dort zwei Wege: zwei -ini:-Argumente im Startbefehl oder zwei Zeilen in der Engine.ini. Wir raten klar zur Engine.ini.

So machst du es richtig

Trag die Zugangsdaten in die Engine.ini ein:

[EpicOnlineServices]
DedicatedServerClientId=xyza7891gk5PRo3J7G9puCJGFJjmEguW
DedicatedServerClientSecret=pKWl6t5i9NJK8gTpVlAxzENZ65P8hYzodV8Dqe5Rlc8

Das sind öffentliche Werte, die alle Evrima-Server gemeinsam nutzen. Geheim ist daran nichts, der Entwickler veröffentlicht sie selbst. Der Vorteil gegenüber der Kommandozeile: Du kannst in der Datei nachsehen, ob der Wert wirklich drinsteht.

Und warum nicht über die Kommandozeile?

So sieht die Variante im Startbefehl aus:

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

Grundsätzlich kann das funktionieren. Aktuelle Unreal-Versionen werten mehrere -ini:-Argumente nacheinander aus, und Epic dokumentiert zusätzlich eine Form mit nur einem Argument und kommagetrennten Paaren:

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

Ältere Engine-Versionen haben allerdings nur das erste -ini:Engine: gelesen. Dann kommt die ClientId an und das Secret nicht. In einem unserer Fälle kamen die Werte über die Kommandozeile nicht an, und von außen sieht man das eben nicht. Mit der Engine.ini kann dir das nicht passieren.

Ursache 2: Unvollständiger Zertifikatsspeicher unter Windows

Das war unser aufwendigster Fall, und ohne LogHttp findet man ihn praktisch nicht.

Symptome

• Der Server startet sauber, die Map lädt, der GameMode wird initialisiert
• Der EOS-Login klappt
• RCON auf Port 8888 antwortet einwandfrei
• Im normalen Log steht keine einzige Fehlermeldung
• Es gibt kein CreateSession und keine Registrierung
• Auch nach 30 Minuten taucht der Server nicht auf

Was steht im Log?

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 löst auf, die TCP-Verbindung steht, und der TLS-Handshake läuft bis zur Certificate-Nachricht. Dann bricht der Server ab, weil er die Zertifikatskette nicht bis zu einer vertrauenswürdigen Root zurückverfolgen kann.

Woher kommt das?

Frisch aufgesetzte Windows-Server-Images haben oft einen unvollständigen Root-Store. Fehlende Root-Zertifikate lädt Windows eigentlich bei Bedarf von ctldl.windowsupdate.com nach. Ist diese Adresse gesperrt oder lief der Abgleich nie, fehlt die Kette. api.warphosting.com.au liegt hinter Cloudflare, die Kette endet je nach Edge-Server bei Let’s Encrypt oder bei Google Trust Services.

Der EOS-Login klappt trotzdem, weil er über andere Endpunkte mit einer anderen Kette läuft. Genau das macht den Fehler so verwirrend.

So behebst du es

Öffne PowerShell als Administrator:

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

Der erste Befehl lädt die aktuelle Liste vertrauenswürdiger Root-Zertifikate von Windows Update, der zweite importiert sie in den Speicher des Computers. Danach startest du den Server neu.

Hat es geklappt?

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

Kommt eine Pydantic-Fehlermeldung zurück, dass im Body ein Feld fehlt, ist alles in Ordnung. Das ist ein HTTP 422 aus der Anwendung, TLS hat also funktioniert. PowerShell wirft bei 4xx-Antworten grundsätzlich eine Exception, deshalb sieht es nur wie ein Fehler aus.

Kommt dagegen ein Trust-Fehler, hat der Import nicht gegriffen. Dann prüfst du, ob die Root-Zertifikate da sind:

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

Und was ist mit der cacert.pem?

In gepackten Builds liegt normalerweise keine lose cacert.pem auf der Platte, libcurl greift dann auf den Windows-Root-Store zurück. Ob bei dir doch eine herumliegt, findest du so heraus:

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

Ist die Datei älter als etwa 2021, fehlt ihr ISRG Root X1. Dann legst du eine aktuelle Fassung von curl.se darüber. Zieh vorher eine Kopie der alten Datei. Beim nächsten validate über SteamCMD wird sie allerdings wieder überschrieben.

Ursache 3: QueryPort passt nicht zum gebundenen Port

Symptom: Der Server ist im Browser sichtbar, beim Beitreten kommt aber das hier:

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

Oder du bekommst die Meldung „Data Acquisition Failed“.

Woher kommt das?

Der Server meldet der API den Wert aus QueryPort als seine Verbindungsadresse. Gebunden hat er aber nur den Game-Port aus ?Port=. Stehen dort unterschiedliche Werte, bekommt der Client eine Adresse, auf der niemand antwortet, und läuft nach 20 Sekunden in den Timeout.

In unserem Fall stand QueryPort=7778 in der Game.ini und ?Port=7777 im Startbefehl. Get-NetUDPEndpoint zeigte nur 7777 als gebunden, der Client wollte sich aber mit 7778 verbinden.

So behebst du es

Setz den QueryPort in der Game.ini auf den Game-Port aus dem Startbefehl:

QueryPort=7777

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

Ob es passt, prüfst du mit:

Get-NetUDPEndpoint -LocalPort 7777

Welche Ports braucht The Isle Evrima?

Üblich sind diese Standardwerte. Was du in der Game.ini oder im Startbefehl einträgst, geht vor.

Port	Protokoll	Zweck
7777	UDP	Spiel, laut mehreren Anleitungen auch die Serverabfragen
10000	TCP	Warteschlange (QueuePort), nur bei bQueueEnabled=true
8888	TCP	RCON (RconPort), nur bei bRconEnabled=true

Beim QueryPort widersprechen sich die Quellen allerdings. Mehrere Anleitungen und Server-Tools legen ihn auf den Game-Port, eine Troubleshooting-Seite verlangt dagegen ausdrücklich einen eigenen Port. Unsere Beobachtung spricht für den Game-Port: Gebunden war immer nur ein UDP-Port, und auch unsere eigenen Server laufen mit QueryPort gleich Game-Port.

Referenz: Pfade, Startbefehl und Firewall

Pfade

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 rotiert die Logdatei bei jedem Start: Die alte Datei wandert nach TheIsle-backup-<Zeitstempel>.log. Such deshalb am besten gleich über alle Logs:

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

Startbefehl

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

Starte über die TheIsleServer.exe im Hauptordner und nicht direkt über die Shipping-Binary. Die Wrapper-Exe übergibt den Projektpfad korrekt.

Batch-Datei mit Auto-Update und Neustart

@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

Das -beta evrima ist Pflicht. Ohne diesen Parameter installiert SteamCMD den alten Legacy-Build. Die App-ID ist 412680, der anonyme Login reicht.

Firewall in der 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

Die Regel für die Warteschlange brauchst du nur, wenn sie aktiv ist, die für RCON nur, wenn du von außen per RCON zugreifen willst. Achte außerdem auf das Profil. Eine Regel, die nur für „Privat“ gilt, greift nicht, wenn Windows die Verbindung als „Öffentlich“ einstuft:

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

Läuft die VM unter KVM hinter libvirt-NAT, prüf zusätzlich das DNAT auf dem Host. Dort muss UDP 7777 weitergeleitet werden, bei aktiver Warteschlange auch TCP 10000:

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

Mit Bridged Networking fällt dieser Schritt komplett weg.

Welche Meldungen im Log sind harmlos?

Meldung	Einordnung
LogSteamShared: Warning: Steam Dedicated Server API failed to initialize.	Normal. Die Serverliste läuft über EOS und die API von The Isle, nicht über Steam.
LogDLSS: NVIDIA NGX DLSS requires an NVIDIA RTX series graphics card	Normal auf einem Server ohne Grafikausgabe.
LogNavigationDataBuild: AgentMaxStepHeight ... not high enough in steep slopes	Kosmetisch, betrifft nur die Qualität des Navmesh.
LogBlueprintUserMessages: Failed to find console variable 'r.RayTracing...'	Normal ohne RHI.
404 auf /runtime/update direkt nach dem Start	Erwartbar. Nach etwa einer Minute sollte die Antwort auf 202 wechseln.

Checkliste, wenn dein Server unsichtbar bleibt

1. Select-String ... -Pattern "runtime/update" | Select -Last 1 ausführen: Steht dort 202 oder 404?
2. Bei 404 LogHttp=Verbose setzen, neu starten und nach libcurl error suchen.
3. Bei error 60 die Root-Zertifikate mit certutil -generateSSTFromWU holen und importieren.
4. Server sichtbar, aber der Beitritt scheitert: QueryPort mit der Ausgabe von Get-NetUDPEndpoint abgleichen.
5. Timeout mit RemoteAddr:<Port>: Genau dieser Port muss gebunden und weitergeleitet sein.
6. „Data Acquisition Failed“ trotz korrekter Ports: bQueueEnabled=false testen.
7. Die Version im Browser mit deiner Client-Version vergleichen. Weichen sie ab, filtert der Browser den Server heraus.
8. Stimmt alles und klappt es trotzdem nicht, klick mehrmals auf Connect. Die API dazwischen hat gelegentlich Aussetzer.

Was noch offen ist

• Die Pfade /v1/servers/official/check und /v1/runtime/update stammen aus unseren eigenen Logs. Offiziell dokumentiert sind sie nicht.
• Ob /servers/official/check für die Registrierung mit Code 200 antworten muss oder nur eine Nebenabfrage ist, konnten wir nicht abschließend klären. Der Name und die 18 Byte große Antwort sprechen für eine reine Statusabfrage.
• Warum die Zugangsdaten in einem unserer Fälle über die Kommandozeile nicht ankamen, ist offen. Aktuelle Unreal-Versionen werten mehrere -ini:-Argumente eigentlich aus.
• Welcher Port wofür zuständig ist, ändert sich offenbar zwischen den Builds, und beim QueryPort widersprechen sich die Anleitungen. Unsere Beobachtungen gelten für 0.21.784.
• „Data Acquisition Failed“ tritt laut mehreren Hosting-Anleitungen seit dem Update vom Dezember 2025 gehäuft auf und kann auch korrekt registrierte Server treffen. Ein Konfigurationsfehler muss also nicht dahinterstecken.

Häufige Fragen

Wie lange dauert es, bis ein neuer The Isle Server im Browser erscheint? Meist zwei bis fünf Minuten, weil die ersten Heartbeats nach dem Start noch mit 404 beantwortet werden.

Heißt ein erfolgreicher EOS-Login, dass mein Server gelistet ist? Nein, gelistet ist er erst, wenn /runtime/update mit 202 antwortet.

Muss ich die EOS-Zugangsdaten geheim halten? Nein, der Entwickler veröffentlicht sie selbst, und alle Evrima-Server nutzen dieselben Werte.

Warum steht kein Fehler im Log, obwohl der Server fehlt? Die Registrierung erscheint erst im Log, wenn LogHttp=Verbose gesetzt ist.

Ist die Warnung „Steam Dedicated Server API failed to initialize“ ein Problem? Nein, die Serverliste läuft über EOS und die API von The Isle, nicht über Steam.

Muss ich bei einem RespawnHost-Server etwas an der Engine.ini ändern? Nein, EOS-Zugangsdaten und QueryPort richten wir automatisch ein.

Was RespawnHost empfiehlt

Stell LogHttp=Verbose gleich bei der Einrichtung ein und schau nach jedem Neustart einmal nach runtime/update. Steht dort 202, ist alles gut, und du sparst dir das Rätselraten. Trag die EOS-Daten in die Engine.ini ein und leg den QueryPort auf den Game-Port. Wer sich den ganzen Aufwand sparen will, nimmt einen The Isle Server bei RespawnHost. Dort ist das von Anfang an so eingerichtet.

Quellen

• Afterthought auf Steam: Update #5 Server Hosting Information & RCON Support, 13. Juli 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
• Eigene Reproduktion auf Windows Server unter KVM, September 2026