Wie viel Latenz kommt durch Entfernung dazu?

Licht legt in Glasfaser rund 200 km pro Millisekunde zurück, und Routen verlaufen nie gerade – eine brauchbare Faustregel ist also etwa 1 ms Round-Trip pro 100 km. Deutschland–Finnland sind etwa 20–25 ms, Europa–US-Ostküste 80–100 ms, Europa–Ostasien 200–250 ms.

Spielt der Serverstandort für eine Website eine Rolle?

Weniger als gedacht, wenn ein CDN die statischen Dateien ausliefert – es bedient Besucher aus ihrer Nähe. Für die erste HTML-Antwort, API-Aufrufe und alles Dynamische zählt er aber weiterhin, also stell den Server in die Nähe der meisten deiner Nutzer.

Was zählt bei einem Trading-Bot?

Die Entfernung zu den API-Servern der Börse, nicht zu dir. Miss die Round-Trip-Zeit von einem Server zu genau dem API-Endpunkt, den dein Bot aufruft; für Arbitrage zählen wenige Millisekunden, für einen Bot, der ein paar Mal am Tag handelt, fast nichts.

Wo stehen die Server von EQVPS?

In Deutschland und Finnland, und du wählst den Standort bei der Bestellung. Das passt gut für Nutzer und Dienste in Europa, im Nahen Osten sowie für europäische Börsen und APIs. Sitzen die meisten deiner Nutzer in Asien oder Amerika, bringt ein europäischer Server 80–250 ms mehr – dann sind wir ehrlich gesagt nicht die richtige Wahl.

Wie teste ich die Latenz vor der Bestellung?

Ping oder mtr einen bekannten Server in derselben Stadt von dort, wo deine Nutzer sind, und prüf per Traceroute, wo die API gehostet ist, von der du abhängst. Nach der Bestellung misst du direkt auf dem VPS mit curl-Timing – das zeigt DNS, Verbindung, TLS und Gesamtzeit getrennt.

VPS-Standort wählen für niedrige Latenz

Leute vergleichen stundenlang vCPU-Zahlen und stellen den Server dann auf den falschen Kontinent. Für alles Interaktive – eine Shell, eine API, ein Spiel, einen Bot, der mit einer Börse spricht – zählt der Standort oft mehr als die Hardware. Die gute Nachricht: Latenz ist vor allem Physik, du kannst sie also vorhersagen und messen, bevor du zahlst.

Die Physik in einer Zeile

Licht legt in Glasfaser etwa 200 km pro Millisekunde zurück. Kabel verlaufen nicht schnurgerade, und jeder Router kostet etwas, deshalb lautet eine solide Faustregel: etwa 1 ms Round-Trip pro 100 km realer Entfernung.

Strecke	Typischer Round-Trip
Innerhalb einer Stadt	1–3 ms
Frankfurt ↔ Helsinki	20–25 ms
Mitteleuropa ↔ London	10–20 ms
Europa ↔ US-Ostküste	80–100 ms
Europa ↔ US-Westküste	140–170 ms
Europa ↔ Singapur / Tokio	160–250 ms

Keine CPU der Welt repariert einen Round-Trip von 200 ms. Sitzen deine Nutzer in Tokio, fühlt sich ein Server in Deutschland langsam an, egal wie schnell er ist.

Was „nah“ heißt, hängt von der Aufgabe ab

Eine Website oder API. Nah an der Mehrheit deiner Nutzer. Ein CDN versteckt Entfernung bei statischen Dateien, aber die erste HTML-Antwort, Logins, API-Aufrufe und alles Dynamische reisen weiterhin zum Ursprungsserver.

Ein Trading-Bot. Nah an den API-Servern der Börse – nicht an dir. Wo du sitzt, ist egal; der Bot spricht hunderte Male am Tag mit der Börse. Für Arbitrage zählt jede Millisekunde; für einen Bot mit einer Handvoll Orders am Tag machen 30 ms keinen Unterschied. Mehr dazu in VPS mit niedriger Latenz für Trading-Bots.

Ein KI-Agent, der Modell-APIs aufruft. Der Standort spielt kaum eine Rolle. Ein Modell braucht Sekunden für die Antwort; 30 ms Netzwerk sind Rauschen. Entscheide nach Preis und Datenschutz.

Ein Gameserver. Nah an den Spielern. Alles unter ~60 ms fühlt sich für die meisten Spiele gut an; kompetitive Shooter wollen deutlich weniger.

Remote-Desktop und SSH. Nah an dir. Tippen bei 150 ms Latenz ist eine Qual.

Selbst messen

Prüf von deinem eigenen Rechner oder einem Server in der Nähe deiner Nutzer den Pfad zu einem Kandidaten:

mtr -rwc 50 example.com

mtr zeigt jeden Hop mit Verlust und Latenz – viel nützlicher als ein einzelner Ping, weil du siehst, wo die Verzögerung entsteht.

Miss vom VPS aus den Dienst, von dem du tatsächlich abhängst, aufgeschlüsselt nach Phasen:

curl -o /dev/null -s -w 'dns %{time_namelookup}s  connect %{time_connect}s  tls %{time_appconnect}s  total %{time_total}s\n' \
  https://api.example.com/health

connect entspricht grob einem Netzwerk-Round-Trip, tls kommt mit dem Handshake dazu, und total enthält die Verarbeitungszeit des Servers. Wenn connect 2 ms und total 900 ms beträgt, ist nicht die Entfernung dein Problem.

Wo EQVPS hineinpasst

Unsere Server stehen in Deutschland und Finnland, und du wählst den Standort bei jeder Bestellung. Das deckt Nutzer in ganz Europa gut ab, den Nahen Osten ordentlich und europäische Börsen und API-Endpunkte sehr gut. Finnland liegt ein paar Millisekunden weiter von Westeuropa entfernt und etwas näher an Skandinavien und dem Baltikum; für die meisten Aufgaben passt beides.

Ehrlich gesagt: Wir haben keine Standorte in Asien oder Amerika. Wenn deine Nutzer dort sitzen, bringt ein Server in Europa 80–250 ms pro Round-Trip mit – dann hoste näher an ihnen.

Die Kurzfassung

Entscheide, mit wem der Server am meisten spricht – Nutzer, eine Börse, eine API, du.
Stell ihn in die Nähe davon und rechne mit ~1 ms pro 100 km.
Miss mit mtr und curl -w, statt einer Karte zu vertrauen.
Bezahl keine schnellere CPU, um ein Entfernungsproblem zu lösen.

Wenn du für denselben Server zwischen NAT und eigener IP schwankst, ist das eine eigene Frage – hier ist der Ein-Fragen-Test.