Krypto-Trading mit niedriger Latenz: Serverstandorte der Börsen, reale API-Latenz und wo Sie Ihren Bot hosten sollten Samstag, der 7. November 2026 – Posted in: Arbitrage Software, cryptoarbitrage software

Was niedrige Latenz im Krypto-Trading bedeutet

Kurze Antwort: Krypto-Trading mit niedriger Latenz bedeutet, die Zeit zwischen einer Preisänderung an einer Börse und dem Eintreffen Ihrer Order bei der Matching-Engine dieser Börse zu verkürzen. Der größte Teil dieser Zeit ist physische Entfernung: Die großen Börsen betreiben ihre Engines in bestimmten Cloud-Regionen, überwiegend in Tokio, Singapur und Hongkong, und ein Bot, der auf einem anderen Kontinent gehostet wird, liegt 150 bis 250 Millisekunden hinter einem Bot direkt neben der Engine. Der zweitgrößte Teil ist vermeidbarer Overhead: kalte Verbindungen, REST-Polling, eine schlecht synchronisierte Uhr und langsamer Code.

Im Forex-Handel dreht sich Latenz um einige bekannte Rechenzentren in London, New York und Tokio sowie um die Liquiditätsbrücken der Broker. Bei Krypto sieht das Bild anders aus. Es gibt keinen gemeinsamen Börsen-Campus: Jede Börse wählt ihre eigene Cloud-Region, die meisten laufen auf öffentlicher Cloud-Infrastruktur, und ihre APIs liegen in der Regel hinter Content Delivery Networks (CDNs), die die Börse nah erscheinen lassen, obwohl sie es nicht ist. Das macht die Messung zugleich einfacher (Sie können für den Preis eines Abendessens einen Server in derselben Cloud-Region mieten) und irreführender (die naheliegenden Tests messen das Falsche).

Wie wichtig Latenz ist, hängt von der Strategie ab:

Wenn Ihr Vorteil aus langsamen strukturellen Lücken stammt, etwa bei Funding-Rate-Arbitrage oder bei Transfers, die durch Auszahlungsgebühren und Netzwerkbestätigungszeiten begrenzt sind, benötigen Sie aus diesem Leitfaden nichts außer einem stabilen Server. Wenn Sie Preisunterschiede zwischen Orderbüchern handeln, entscheidet die Latenz darüber, ob Sie ausgeführt werden oder hinterherlaufen.

Das Latenzbudget: wohin die Millisekunden gehen

"Latenz" ist keine einzelne Zahl. Eine Order, die auf eine Marktbewegung reagiert, durchläuft eine Kette von Schritten, und jeder Schritt kostet Zeit. Wenn Sie in Budgets denken, erkennen Sie, welche Teile Sie ändern können und welche nicht.

Das Muster ist eindeutig: Die beiden Faktoren, die Sie kontrollieren und die in zehn oder hunderten Millisekunden gemessen werden, sind wo Ihr Server steht und ob Ihre Verbindungen warm sind. Alles andere gehört entweder der Börse oder ist gering, wenn die Software vernünftig geschrieben ist. Deshalb konzentriert sich der Rest dieses Leitfadens auf Standort und Messung.

Wo Krypto-Börsen ihre Matching-Engines betreiben

Börsen veröffentlichen den genauen Standort ihrer Matching-Engines selten, doch die meisten laufen in der öffentlichen Cloud, und die Region lässt sich aus Latenzmessungen aus vielen Cloud-Regionen ableiten. Unabhängige Messungen, die 2026 von Dritten veröffentlicht wurden, stimmen für die meisten großen Handelsplätze überein. Die Tabelle fasst die öffentlich berichteten Regionen zusammen. Betrachten Sie sie als Ausgangspunkt für Ihre eigenen Tests, nicht als Garantie: Börsen ziehen um (BitMEX etwa soll seine Engine 2025 von Dublin nach Tokio verlegt haben).

Daraus ergeben sich zwei praktische Schlussfolgerungen. Erstens: Tokio kommt einem zentralen Handelsplatz für Krypto am nächsten: Ein Server dort liegt wenige Millisekunden von Binance und mehreren anderen großen Handelsplätzen entfernt, etwa 25 ms in eine Richtung von Hongkong und etwa 35 ms in eine Richtung von Singapur. Zweitens: Jede Strategie, die eine asiatische Börse mit Coinbase oder einem europäischen Handelsplatz kombiniert, hat zwischen den beiden Engines eine physikalische Untergrenze von 70 bis 120 ms in eine Richtung, ganz gleich, was Sie mit Ihrem eigenen Server tun.

Das Hosting eines Servers in einem bestimmten Land ändert nichts daran, welche Börsen Sie nutzen dürfen. Halten Sie sich an die Nutzungsbedingungen jeder Börse und an die Vorschriften Ihrer eigenen Rechtsordnung; nutzen Sie niemals Server oder VPNs, um geografische Beschränkungen zu umgehen.

Die CDN-Falle: warum Ping täuscht

Der häufigste Fehler besteht darin, die Latenz mit ping oder mit der Zeit für den Aufbau einer TCP-Verbindung zum API-Hostnamen zu messen. Fast jede große Börse stellt ihre öffentlichen REST- und WebSocket-Endpunkte hinter ein CDN oder einen Cloud-Load-Balancer mit Edge-Standorten auf der ganzen Welt. Wenn Sie sich aus Europa oder Nordamerika mit api.binance.com verbinden, beantwortet ein Edge-Knoten in einer nahegelegenen Stadt Ihren TCP-Handshake, nicht die Matching-Engine in Tokio. Der Handshake dauert wenige Millisekunden; danach leitet der Edge-Knoten Ihre Anfrage über das Backbone des Anbieters an den eigentlichen Ursprungsserver weiter, und dort vergeht die Zeit.

Ein Ping von 5 ms zu einem Börsen-Hostnamen kann also mit einer realen Anfragezeit von 150 ms einhergehen. Aussagekräftig sind nur Werte, die den Weg zum Ursprungsserver einschließen: die Time to First Byte einer echten API-Antwort über eine bereits offene Verbindung, die Verzögerung zwischen dem eigenen Ereignis-Zeitstempel der Börse und Ihrer Empfangszeit am WebSocket sowie die Zeit vom Senden einer Order bis zum Erhalt ihrer Bestätigung.

Gemessen von BJF Trading Group am 7. November 2026 von einem Webserver in Montreal (Leaseweb), öffentliche Zeit-Endpunkte, zwei Durchläufe mit je einer kalten und 20 warmen Anfragen pro Börse.

Was wir von einem Server in Montreal gemessen haben

Um den Effekt mit realen Zahlen statt mit Herstellerangaben zu zeigen, haben wir einen kleinen Test von dem Webserver in Montreal aus durchgeführt, der diese Website hostet. Für acht Börsen wurde jeweils eine Verbindung geöffnet, eine Anfrage gesendet (kalt) und anschließend 20 weitere Anfragen über dieselbe Keep-Alive-Verbindung gesendet (warm), mit vier Anfragen pro Sekunde; der gesamte Durchlauf wurde zweimal wiederholt. Als Endpunkt diente jeweils der öffentliche Serverzeit-Aufruf der Börse, der kaum Arbeit verursacht, sodass das Ergebnis nahezu reine Transport- plus Gateway-Zeit ist.

Aus diesem kleinen Test ergeben sich vier Lehren:

• Die Verbindungszeit ist hinter einem CDN bedeutungslos. OKX beantwortete den TCP-Handshake in 3 bis 4 ms, doch jede echte Anfrage dauerte etwa 170 ms, weil die Arbeit in Hongkong stattfindet.
• Die Rangfolge folgt der Geografie. Coinbase (US-Ostküste) ist von Montreal aus am schnellsten, Kraken (Europa) an zweiter Stelle, und die asiatischen Börsen liegen gebündelt bei 150 bis 225 ms. Von Tokio aus wäre die Reihenfolge umgekehrt.
• Kalte Verbindungen sind teuer. Ohne nahegelegenen Edge überquert jeder Handshake-Roundtrip den Pazifik: Die erste Anfrage an Gate.io dauerte etwa 0.7 Sekunden, die folgenden etwa 0.18 Sekunden. Ein Bot, der erst beim Erkennen eines Signals eine neue Verbindung öffnet, hat bereits verloren.
• Die Ausreißer zählen. Der Median von Bybit lag bei 225 ms, doch jede zehnte Anfrage dauerte mehr als 400 ms. Ein Arbitrage-Leg ist nur so schnell wie seine langsamen Fälle; achten Sie daher immer auf p90 und p99, nicht nur auf den Median.

Diese Zahlen beschreiben einen Webserver an einem Nachmittag, kein Trading-Setup, und sie enthalten die Gateway-Verarbeitung jeder Börse. Sie sind keine Rangliste der Börsen. Ihr Zweck ist es, die Größenordnung der Effekte zu zeigen: Geografie und Verbindungshandhabung machen mehr als 90% der Verzögerung aus, die ein entfernter Bot erfährt.

Schritt für Schritt: Börsenlatenz richtig messen

Eine aussagekräftige Messung können Sie von jedem Server aus innerhalb einer Stunde reproduzieren. Die folgende Methode empfehlen wir vor der Wahl einer Hosting-Region und nach jeder Änderung an Ihrer Infrastruktur.

Für Schritt 2 reicht zum Einstieg ein einfaches curl. Durch das Wiederholen der URL verwendet curl eine einzige Verbindung erneut; die erste Zeile ist die kalte Anfrage, die übrigen sind warm:

curl -s –rate 4/s -w "%{num_connects} %{time_connect} %{time_starttransfer}\n" -o /dev/null URL -o /dev/null URL -o /dev/null URL

Für die Schritte 4 und 5 benötigen Sie einige Codezeilen in der Sprache Ihres Bots, denn die Messung muss über dieselbe Client-Bibliothek, denselben JSON-Parser und dieselben Verbindungseinstellungen laufen wie der Live-Handel. Eine Zahl, die ein anderes Werkzeug liefert, sagt etwas über dieses Werkzeug aus.

WebSocket-Marktdaten und Uhrensynchronisation

Für alles Zeitkritische sollten Marktdaten aus WebSocket-Streams stammen, nicht aus REST-Polling. Eine Polling-Schleife, die das Orderbuch alle 200 ms abfragt, fügt im Durchschnitt 100 ms Wartezeit hinzu, bevor sie eine Änderung überhaupt sieht, zusätzlich zur Anfragezeit, und sie verbraucht Rate-Limit-Budget, das Sie für Orders benötigen. Ein WebSocket-Stream überträgt jedes Update, sobald die Börse es veröffentlicht. Die Details zu Streams, lokalen Orderbüchern und Sequenzprüfungen behandelt unser Leitfaden zur Anbindung an Krypto-Börsen-APIs für Arbitrage; hier konzentrieren wir uns auf das Timing.

Feed-Lag messen

Die meisten WebSocket-Nachrichten von Börsen tragen einen von der Börse gesetzten Zeitstempel: eine Ereigniszeit, eine Tradezeit oder eine Nachrichtenzeit, meist in Millisekunden. Ziehen Sie ihn von Ihrer lokalen Empfangszeit ab, und Sie erhalten den Feed-Lag, der die interne Veröffentlichungsverzögerung der Börse und den Netzwerkweg umfasst. Erfassen Sie ihn pro Stream, nicht nur als Durchschnitt: Depth-Snapshots, inkrementelle Orderbuch-Updates und Trade-Streams können sich unterschiedlich verhalten, und aggregierte Streams, die alle 100 ms veröffentlichen, zeigen ein Sägezahnmuster.

Warum die Uhr wichtig ist

Einweg-Messungen sind nur so gut wie die Übereinstimmung zwischen Ihrer Uhr und der der Börse. Geht Ihre Serveruhr 15 ms nach, erscheint jeder Feed-Lag 15 ms besser, als er ist. Betreiben Sie auf einem Cloud-Server chrony mit dem Zeitdienst des Anbieters und prüfen Sie chronyc tracking: Ein Offset von etwa einer Millisekunde ist eine solide Grundlage für den Vergleich von Regionen. Viele Börsen bieten zudem einen Serverzeit-Endpunkt; ein Vergleich mit Ihrer Uhr unter Berücksichtigung der Hälfte des gemessenen Roundtrips liefert eine grobe Gegenprüfung. Order-Endpunkte, die ein Empfangsfenster akzeptieren (ein maximal zulässiges Alter des Anfrage-Zeitstempels), lehnen Orders außerdem ab, wenn Ihre Uhr abdriftet – ein weiterer Grund, sie synchron zu halten.

Den Orderweg separat messen

Der Feed-Lag zeigt Ihnen, wie alt Ihre Sicht auf den Markt ist. Der Order-Roundtrip zeigt Ihnen, wie lange es dauert, darauf zu reagieren. Beide unterscheiden sich häufig: Order-Anfragen durchlaufen Authentifizierung, Rate-Limit-Abrechnung und Risikoprüfungen, die ein Marktdaten-Stream nicht durchläuft. Einige Börsen, darunter Binance, bieten einen Order-Test-Endpunkt, der eine signierte Order validiert, ohne sie an die Matching-Engine zu senden; er misst den Netzwerk- und Gateway-Anteil. Wo die Börse die Ordereingabe über eine WebSocket- oder FIX-Sitzung anbietet, messen Sie auch diese, denn eine persistente Sitzung vermeidet den Overhead pro Anfrage.

Die Hosting-Region für Arbitrage zwischen zwei Börsen wählen

Für eine einzelne Börse ist die Antwort einfach: Mieten Sie einen Server in derselben Cloud-Region wie ihre Engine. Arbitrage zwischen zwei Börsen ist ein Geometrieproblem, denn die Engines stehen an verschiedenen Orten, und Sie können nur neben einer von ihnen sein.

Nehmen wir eine Hedge-Arbitrage zwischen Binance (Tokio) und Bybit (Singapur). Der Roundtrip zwischen den beiden Regionen beträgt etwa 70 ms, also rund 35 ms in eine Richtung. Betrachten Sie die wichtigsten Optionen:

Die Roundtrips sind ungefähre typische Werte zwischen öffentlichen Cloud-Regionen; prüfen Sie die aktuellen Werte Ihres Anbieters zwischen Regionen und messen Sie von Ihren eigenen Servern aus.

Die entscheidende Beobachtung: Die Information muss immer die Entfernung zwischen den beiden Börsen überwinden. Bewegt sich der Preis an Binance und das veraltete Angebot liegt an Bybit, sieht ein Server in Tokio die Bewegung sofort, und seine Order reist 35 ms nach Singapur; ein Server in Singapur erhält die Bewegung 35 ms später, und seine Order kommt sofort an. Die Summe ist dieselbe. Was sich ändert, ist welcher Teil der Kette wartet und damit, welche Überlegung die Wahl leiten sollte:

• Hosten Sie neben dem Handelsplatz, an dem die Order gewinnen muss. Hängt Ihr Gewinn davon ab, ein Angebot an einer Börse vor anderen Tradern zu treffen, konkurrieren Sie dort, wo über diese Warteschlange entschieden wird. Die Informationen über die andere Börse treffen dort für alle gleich schnell ein, aber Ihre Order muss nicht reisen.
• Platzieren Sie den Hedge im tieferen Orderbuch. Das Leg, das seine Börse später erreicht, sollte das sein, das am wenigsten empfindlich auf einige Millisekunden reagiert: das liquidere Orderbuch, in dem sich der Hedge-Preis wahrscheinlich kaum bewegt.
• Kennen Sie den Ausführungsstatus schnell. Wenn Sie neben der Börse stehen, an der Teilausführungen häufig sind, können Sie den Hedge auf Basis genauer Informationen dimensionieren, was das ungesicherte Risiko verringert.
• Teilen Sie nur auf, wenn es sich lohnt. Zwei Prozesse, einer pro Region, können jeweils ein lokales Orderbuch führen und lokal reagieren, müssen sich aber über dieselbe 70-ms-Verbindung abstimmen. Das erhöht Komplexität und Fehlerquellen und lohnt sich vor allem für professionelle Setups.

Für Strategien über drei oder mehr asiatische Handelsplätze ist Tokio wegen der Zahl großer Börsen dort meist das praktische Zentrum. Bei Paaren mit einem US-amerikanischen oder europäischen Handelsplatz dominiert das interkontinentale Leg, und die Strategie muss 70 bis 120 ms in eine Richtung tolerieren, was einen reinen Geschwindigkeitswettbewerb ausschließt und größere, länger bestehende Lücken begünstigt.

Wie Latenz zu Geld wird

Ein Preisunterschied zwischen zwei Orderbüchern ist kein fester Preis. Andere Trader sehen ihn ebenfalls, Market Maker aktualisieren ihre Kurse, und die Lücke verschwindet innerhalb einer Zeit, die vom Asset und vom Handelsplatz abhängt. Eine einfache Denkweise: Nehmen Sie an, dass jede Gelegenheit eine zufällige Zeit mit einer durchschnittlichen Lebensdauer besteht, und fragen Sie, wie wahrscheinlich es ist, dass sie noch existiert, wenn Ihre Order ankommt.

In diesem Modell beträgt die Wahrscheinlichkeit, dass eine Lücke nach einer Reaktionszeit von L Millisekunden noch besteht, exp(−L / τ), wobei τ die durchschnittliche Lebensdauer der Lücke ist. Die Ergebnisse für drei Reaktionszeiten, die grob einem Server in derselben Region (5 ms), in einer benachbarten Region (40 ms) und auf einem anderen Kontinent (150 ms) entsprechen:

Verknüpfen wir das nun mit Geld. Angenommen, eine Strategie findet 200 Signale pro Tag mit einem Nettovorteil von 0.10% bei einem Trade über 5,000 USDT, also 5 USDT pro erfasstem Signal, und ein verpasstes Signal kostet im Durchschnitt 1.5 USDT, weil ein Leg ausgeführt wurde und wieder aufgelöst werden muss. Für Lücken mit einer Lebensdauer von 200 ms:

Die Zahlen sind hypothetisch, doch die Schlussfolgerung ist robust: Wird ein Bot von einem anderen Kontinent in die richtige Region verlegt, kann sich das Ergebnis derselben Strategie vervielfachen, während der Wechsel aus einer benachbarten Region in dieselbe Region eine kleinere, aber dennoch spürbare Verbesserung bringt. Es zeigt auch die Grenze: Bei Lücken, die eine Sekunde oder länger bestehen, spielt Latenz kaum eine Rolle, und Gebühren, Slippage und Bestände entscheiden über das Ergebnis. Bevor Sie in Infrastruktur investieren, prüfen Sie, wie lange die Lücken, die Sie handeln, tatsächlich bestehen; mit dem kostenlosen Krypto-Arbitrage-Scanner können Sie reale Preisunterschiede zwischen Börsen live beobachten.

Colocation, VPS und was für unabhängige Trader realistisch ist

Bei Forex und Aktien bedeutet Colocation, Rackfläche im selben Rechenzentrum wie die Server der Börse oder des Brokers zu mieten, und die wichtigsten Standorte sind bekannt (siehe unseren Leitfaden zu Forex-Arbitrage-VPS und Colocation-Standorten). Bei Krypto ist das Äquivalent für die meisten Trader einfach ein virtueller Server in derselben Cloud-Region wie die Börse. Da die Engine selbst in dieser Cloud läuft, ist ein Server in derselben Region bereits ein bis zwei Millisekunden von ihr entfernt, für Kosten von einigen zehn Dollar im Monat.

Innerhalb einer Region kann die Availability Zone einen weiteren Unterschied von Bruchteilen einer Millisekunde ausmachen. Das spielt nur eine Rolle, wenn Sie bei den liquidesten Paaren mit professionellen Market Makern konkurrieren, und ein Test lohnt sich erst, nachdem Sie die größeren Punkte behoben haben: Region, warme Verbindungen, WebSocket-Daten und Ihren eigenen Code. Die allgemeinen Grundsätze, wie schnell ein Server sein muss und warum niedrige Latenz wichtiger ist als hohe Spezifikationen, behandelt der Artikel wie schnell Ihr VPS für Arbitrage sein muss.

Latenz in Ihrer eigenen Software

Sobald der Server am richtigen Ort steht, sind die verbleibenden Verzögerungen überwiegend selbst verursacht. Die üblichen Verursacher, in der Reihenfolge, in der wir sie antreffen:

• Verbindungen bei Bedarf öffnen. Halten Sie REST-Verbindungen mit einem Connection-Pool aktiv, senden Sie regelmäßig eine leichte Anfrage, damit inaktive Verbindungen nicht geschlossen werden, und bauen Sie WebSocket-Verbindungen proaktiv vor Ablauf der maximalen Sitzungsdauer der Börse neu auf.
• Polling statt Streaming. Nutzen Sie WebSocket-Marktdaten und, sofern verfügbar, Ordereingabe über WebSocket oder FIX.
• Aufwendige Arbeit im kritischen Pfad. Logs auf die Festplatte schreiben, große JSON-Nachrichten Feld für Feld parsen oder bei jedem Update das gesamte Orderbuch neu berechnen – all das kostet Millisekunden. Erledigen Sie vor dem Senden der Order nur das Nötigste und verschieben Sie den Rest.
• Rate-Limit-Strafen. Ein Bot, der das Gewichtslimit für Anfragen überschreitet, wird abgewiesen oder vorübergehend gesperrt, was unendlicher Latenz gleichkommt. Planen Sie Anfragen pro Börse und drosseln Sie vor dem Limit, nicht danach.
• Garbage Collection und CPU-Konkurrenz. Auf einem kleinen geteilten VPS können andere Mieter und Speicherbereinigungspausen zu zufälligen Zeitpunkten einige zehn Millisekunden hinzufügen. Das zeigt sich im p99, nicht im Durchschnitt.
• Sequenzielles Senden der Legs. Sind beide Legs eines Hedges unabhängig, senden Sie sie parallel, statt auf die erste Bestätigung zu warten.

Die VIP Crypto Arbitrage Software von BJF Trading Group verbindet sich über deren native APIs mit zentralisierten Spot- und Futures-Börsen und läuft auf einem Server Ihrer Wahl, sodass die Standortprinzipien dieses Leitfadens direkt darauf anwendbar sind. Zur Logik latenzgetriebener Strategien selbst lesen Sie unseren Leitfaden zur Latenzarbitrage, und für das Gesamtbild börsenübergreifender Strategien die Übersicht zur Krypto-Arbitrage.

Risiken und Grenzen

• Latenz ist für sich allein kein Vorteil. Geschwindigkeit hilft nur, wenn die Strategie nach Gebühren, Slippage und Bestandskosten profitabel ist. Ein schneller Bot mit negativem Vorteil verliert nur schneller Geld.
• Standorte ändern sich. Börsen verlegen Engines und wechseln CDN-Anbieter. Eine Region, die letztes Jahr richtig war, ist es heute vielleicht nicht mehr; messen Sie regelmäßig neu.
• Messungen sind lokal. Unsere Zahlen aus Montreal und jede veröffentlichte Tabelle beschreiben einen Ort und einen Moment. Nur Messungen von Ihrem eigenen Server mit Ihrer eigenen Software sind für Ihre Entscheidungen gültig.
• Unter Stress dominieren Verzögerungen auf Börsenseite. In heftigen Märkten reihen Gateways Anfragen in Warteschlangen ein, und Bestätigungen verlangsamen sich für alle. Ihre Strategie muss das verkraften, etwa indem sie die Positionsgröße begrenzt, wenn die Bestätigungszeiten steigen.
• Das Wettrüsten endet nie. Bei den liquidesten Paaren investieren professionelle Firmen weit mehr in Geschwindigkeit, als ein unabhängiger Trader kann. Suchen Sie nach Lücken, die lange genug für Ihr Setup bestehen, statt um die kürzesten zu konkurrieren.
• Compliance. Der Serverstandort ändert nichts an Ihrer rechtlichen Situation. Nutzen Sie nur Börsen und Produkte, die Ihnen zur Verfügung stehen, und beachten Sie die API-Bedingungen und Rate-Limits.

Häufige Fragen

Dieser Artikel dient Bildungszwecken und stellt keine Finanzberatung dar. Die Latenzwerte in der Montreal-Tabelle wurden von BJF Trading Group am 7. November 2026 von einem Server aus gemessen und sind keine Rangliste der Börsen; die Regionsangaben beruhen auf öffentlich berichteten Messungen Dritter und können sich ändern. Als illustrativ oder ungefähr gekennzeichnete Zahlen und Diagramme sind Modelle und typische Werte, keine Messungen einer bestimmten Börse oder eines bestimmten Traders.