EU Gateways – Persistent Rubberbanding + Packet Loss Near Origin (WinMTR if required)

To the person who dismissed this thread because I used an LLM to help analyze my issues: Yes, I used ChatGPT.

Why? Because while I do have an IT background, network infrastructure—especially at this scale—isn’t my area of expertise. I’m not a network engineer, and I lack the specialized knowledge to diagnose issues like packet loss in a game’s backend or peering disputes between providers. Tools like ChatGPT help bridge that gap for players who *want* to provide useful feedback but don’t have a CCNA certification.

That said, I’ve always been transparent about my testing and repeatedly offered to share my data — I just wasn’t comfortable posting raw logs publicly in a forum where personal details (like IPs) are exposed for anyone to see.

Dismissing an entire thread because someone used an LLM to articulate their findings isn’t just unhelpful—it’s counterproductive. The goal here is to solve a problem that affects many players, not to gatekeep based on how someone phrases their analysis.

With that out of the way: Below is the actual data—WinMTR logs, test conditions, and a clear breakdown of where the issue lies. No speculation, just facts.



To summarize:


I’ve conducted controlled tests to identify the source of the persistent lag spikes and rubberbanding in Path of Exile 2 (EU gateways). Below are the key findings from WinMTR logs captured during active spikes.

I also can provide further data via PM.

---

WinMTR Data (March 13, 2026)
Test conditions:
- Captured during active in-game lag spikes (EU Frankfurt gateway).
- Confirmed on two independent Telekom connections.
- No issues in other games or services.

Critical hops:
Hop 1-10 (Telekom/Cloudflare Edge): 0-1% loss, normal latency (30-40 ms).
Hop 11-12: No response from host (100% loss).
Hop 13 (188.42.187.111, servers.com): 3% loss, avg. 58 ms, max. 1479 ms.
Hop 14 (173.233.129.236, GGG server): 3% loss, avg. 59 ms, max. 1698 ms.

Interpretation:
Packet loss begins behind Cloudflare, specifically in the servers.com → GGG origin segment. This aligns with earlier observations:
- Spikes occur every ~30-50 seconds (suggesting periodic backend tasks).
- Spike amplitude decreases when character inventory is cleared (suggesting state serialization issues).

---

Questions for GGG:
1. Are there known peering issues between Cloudflare and servers.com in Frankfurt?
2. Is the router 188.42.187.111 overloaded or affected by ACLs?
3. Are periodic backend tasks (e.g., character state sync) executed every ~30-50 seconds?
4. Does database performance scale with character inventory size?

---


I forgot if I already mentioned it: I tested with mobile connection (LTE/5G): Zero issues. Same character, same location, same time.




Also the complete WinMTR-Log:

|------------------------------------------------------------------------------------------|
| WinMTR statistics |
| Host - % | Sent | Recv | Best | Avrg | Wrst | Last |
|------------------------------------------------|------|------|------|------|------|------|
| XX.XXX.XX.XXX - 0 | 984 | 984 | 0 | 0 | 4 | 0 |
| fritz.box - 0 | 982 | 982 | 2 | 27 | 1912 | 3 |
| p3e9bf286.dip0.t-ipconnect.de - 0 | 982 | 982 | 5 | 33 | 2031 | 15 |
| m-ef2-i.M.DE.NET.DTAG.DE - 0 | 982 | 982 | 7 | 33 | 1984 | 11 |
| 80.150.168.185 - 0 | 982 | 982 | 6 | 32 | 1951 | 10 |
| cloudflare-gw.cr0-muc1.ip4.gtt.net - 1 | 978 | 977 | 6 | 38 | 1953 | 35 |
| 172.68.108.7 - 0 | 982 | 982 | 7 | 36 | 1999 | 10 |
| 104.23.220.53 - 0 | 982 | 982 | 6 | 32 | 1750 | 10 |
| 104.23.220.15 - 0 | 982 | 982 | 7 | 33 | 1953 | 7 |
| 104.23.220.35 - 0 | 982 | 982 | 6 | 33 | 1982 | 10 |
| No response from host - 100 | 198 | 0 | 0 | 0 | 0 | 0 |
| No response from host - 100 | 198 | 0 | 0 | 0 | 0 | 0 |
| 188.42.187.111 - 3 | 894 | 871 | 32 | 58 | 1479 | 49 |
| 173.233.129.236 - 3 | 890 | 866 | 31 | 59 | 1698 | 54 |
|________________________________________________|______|______|______|______|______|______|
WinMTR v0.92 GPL V2 by Appnor MSP - Fully Managed Hosting & Cloud Provider

"

Hurkenschuß#3111 wrote:

Dismissing an entire thread because someone used an LLM to articulate their findings isn’t just unhelpful—it’s counterproductive. The goal here is to solve a problem that affects many players, not to gatekeep based on how someone phrases their analysis.

You've still completely missed the point.

If you had blood tests performed and were concerned about one or two of the numbers, you wouldn't book a doctor's appointment, leave the blood tests at home, explain to the qualified medical professional what text an internet chatbot strung together, and offer to bring the blood test results with you the next time you attended an appointment. You would bring the tests, and you would ask the doctor to interpret them for you. Because that's their area of expertise.

Nobody's gatekeeping, nor is anyone dismissing you and / or your post because of your comparative ability to perform an analysis. Indeed - nobody had asked for or expected one at all.

"

Hurkenschuß#3111 wrote:

I just wasn’t comfortable posting raw logs publicly in a forum where personal details (like IPs) are exposed for anyone to see.

I mean - that's fair; the concern is very understandable.

But you could've just posted saying you're having trouble while playing, you had run an MTR, and asked if it includes either your IP address or any otherwise sensitive data (it contains neither).

---

If you tell an LLM the current subject of conversation is something you know little about, for the rest of that conversation it will tailor its responses accordingly. When you're speaking with subject matter experts, what ChatGPT had said in that context won't be helpful to them - it will just come across as patronising. Please try to understand how frustrating it is to have spent years getting a degree and then years (or decades) gaining experience only to have people constantly opening tickets with ChatGPT's attempts at explaining the basics of that particular topic.

It is actively driving away from public-facing jobs altogether. It is infuriating.

I get the impression that my input isn't wanted here, which is a shame. I’ve posted the MTR log with local IPs redacted, and I won’t argue about prejudices regarding the use of LLMs to fill gaps in analysis.

That said, if anyone is still interested in solving this issue, I’m happy to help with clear instructions on what additional tests I could run beyond the data I’ve already provided.

For the record: This doesn’t seem to be just a Europe/Telekom issue. The internet is full of posts from players experiencing the same problems. In my opinion, this is a game-breaking issue that should be addressed with high priority if GGG wants the game to remain successful.

I’ll step back from this thread now, but if GGG or anyone technical wants to work on a solution, I’m available for direct collaboration. Just let me know what data or tests would help.

Seems like I'm not finished:

Since yesterday afternoon, the persistent lag spikes (30-50 second intervals, packet loss at servers.com hops) have vanished. Here’s why this is significant:

1. Correlation with PoE1 League Start (ExileCon):

PoE1’s new league launched on March 12, 2026.
Many players migrated to PoE1, reducing load on PoE2’s EU servers.
Result: The periodic backend congestion (likely database commits/character state syncs) resolved itself due to lower player counts.

2. Technical Context:

My earlier WinMTR logs showed packet loss starting at 188.42.187.111 (servers.com), not in Telekom or Cloudflare’s network.
The spikes occurred at fixed intervals (~30-50s), matching typical backend task schedules (e.g., session persistence).
Mobile data (LTE/5G) worked flawlessly—suggesting the issue was path-specific (Telekom → servers.com → GGG) and load-dependent.

3. Implications:

This strongly suggests the problem was server-side scalability, not routing or ISP issues.
If spikes return when PoE2 player counts rise again, GGG should investigate:

Backend task scheduling (e.g., reduce frequency or optimize database commits).
Peering between Cloudflare and servers.com (packet loss at 188.42.187.111).
Load distribution across EU clusters (why does PoE1’s launch alleviate PoE2 lag?).

4. Next Steps:

I’ll continue monitoring. If spikes reappear, I’ll compare WinMTR logs pre-/post-league launch for further evidence.
If GGG’s network team wants to collaborate, I’m happy to provide additional data (Wireshark, timestamped tests).

Final Thought:

This isn’t about assigning blame—it’s about identifying a scalability bottleneck that affects gameplay. The fact that reduced server load fixed the issue is a valuable clue. Hopefully, this helps GGG prioritize backend optimizations for PoE2’s long-term stability.

i tested again today to see if it's going better.

it was somehow worse than ever, but i've recently played a lot and gained more and more items which could be a reason to bloat the playerstate.



Here is the winMTR-log:

|------------------------------------------------------------------------------------------|
| WinMTR statistics |
| Host - % | Sent | Recv | Best | Avrg | Wrst | Last |
|------------------------------------------------|------|------|------|------|------|------|
| XX.XX.X.XX - 0 | 566 | 566 | 0 | 0 | 5 | 0 |
| fritz.box - 0 | 566 | 566 | 2 | 31 | 1015 | 4 |
| p3e9bf286.dip0.t-ipconnect.de - 0 | 566 | 566 | 5 | 34 | 1048 | 11 |
| m-ef2-i.M.DE.NET.DTAG.DE - 0 | 566 | 566 | 7 | 35 | 1044 | 8 |
| 80.150.168.185 - 0 | 566 | 566 | 6 | 34 | 1039 | 7 |
| cloudflare-gw.cr0-muc1.ip4.gtt.net - 0 | 566 | 566 | 6 | 39 | 1065 | 35 |
| 172.68.108.5 - 0 | 565 | 565 | 7 | 41 | 1390 | 8 |
| 172.68.109.119 - 0 | 566 | 566 | 6 | 33 | 1063 | 12 |
| 172.68.109.159 - 0 | 566 | 566 | 6 | 35 | 1172 | 8 |
| 172.68.109.122 - 0 | 566 | 566 | 6 | 34 | 1049 | 21 |
| No response from host - 100 | 115 | 0 | 0 | 0 | 0 | 0 |
| No response from host - 100 | 115 | 0 | 0 | 0 | 0 | 0 |
| No response from host - 100 | 115 | 0 | 0 | 0 | 0 | 0 |
| xe-2-2-0-466.cr4-mrs1.ip4.gtt.net - 3 | 513 | 499 | 19 | 46 | 973 | 31 |
| 23.111.243.101 - 0 | 565 | 565 | 20 | 49 | 1360 | 28 |
| 69.41.174.151 - 0 | 566 | 566 | 19 | 48 | 1180 | 22 |
|________________________________________________|______|______|______|______|______|______|
WinMTR v0.92 GPL V2 by Appnor MSP - Fully Managed Hosting & Cloud Provider

thing is, if i ask diffrent AI-models, they come to the same conclusion.

GGG, please check:

Why does Telekom traffic route through overloaded GTT nodes?
Can you optimize peering with GTT for EU players?

Why this matters:
This explains why some players have spikes, others don’t—it’s routing-dependent.
Fixing this would resolve lag for all Telekom customers (and possibly others on GTT paths).


My path (Telekom):
Hop 11–12: No response from host (100% packet loss).
Hop 13: xe-2-2-0-466.cr4-mrs1.ip4.gtt.net (3% loss, 973 ms worst-case latency).
Hop 15: 69.41.174.151 (GGG server, 0% loss but 1180 ms worst-case latency).

Root Cause:
The problem occurs between Hop 11 and Hop 13 (xe-2-2-0-466.cr4-mrs1.ip4.gtt.net).

"

Hurkenschuß#3111 wrote:

My path (Telekom):
Hop 11–12: No response from host (100% packet loss).
Hop 13: xe-2-2-0-466.cr4-mrs1.ip4.gtt.net (3% loss, 973 ms worst-case latency).
Hop 15: 69.41.174.151 (GGG server, 0% loss but 1180 ms worst-case latency).

Root Cause:
The problem occurs between Hop 11 and Hop 13 (xe-2-2-0-466.cr4-mrs1.ip4.gtt.net).

As you have noted, the Path of Exile server you are connecting to is the final hop. The way WinMTRs are correctly interpreted is by looking at that line for signs of a problem, and then working backwards through the log to establish where those problems first emerge.

"

Hurkenschuß#3111 wrote:

| 69.41.174.151 - 0 | 566 | 566 | 19 | 48 | 1180 | 22 |

We can see that 566 echo requests were sent to the server, and 566 responses were received from the server - thus, we can rule out packet loss as it does not affect your connection to it.

As you have yourself observed, there is a 'worst' ping of 1,180 ms to the server.

Working backwards through the log, the excessively 'worst' ping first emerges on hop #2;

"

Hurkenschuß#3111 wrote:

| Host - % | Sent | Recv | Best | Avrg | Wrst | Last |
|------------------------------------------------|------|------|------|------|------|------|
| XX.XX.X.XX - 0 | 566 | 566 | 0 | 0 | 5 | 0 |
| fritz.box - 0 | 566 | 566 | 2 | 31 | 1015 | 4 |

Leaving to one side the fact that there is no benefit whatsoever in redacting a private IP address as it can only be utilised by someone who has already gained access to your network - at which point you have bigger problems, and discovering any devices on the network would be trivial with or without the private IP address - we can see a 'worst' ping of 1,015 ms to hop #2.

As there is no appreciable difference in severity between 1,015 ms and 1,180 ms and the latter technically worse 'worst' ping is very significantly further away from you, thereby justifying the trivial increase in latency - we can conclusively determine that your problem is with hop #1, hop #2, or lies with the connection between the two (e.g. a cable).

"

Sarno#0493 wrote:

Working backwards through the log, the excessively 'worst' ping first emerges on hop #2;

"

Hurkenschuß#3111 wrote:

| Host - % | Sent | Recv | Best | Avrg | Wrst | Last |
|------------------------------------------------|------|------|------|------|------|------|
| XX.XX.X.XX - 0 | 566 | 566 | 0 | 0 | 5 | 0 |
| fritz.box - 0 | 566 | 566 | 2 | 31 | 1015 | 4 |

To offer a counterexample, here is a WinMTR I have just run against a London-based instance server;


|------------------------------------------------------------------------------------------|
| WinMTR statistics |
| Host - % | Sent | Recv | Best | Avrg | Wrst | Last |
|------------------------------------------------|------|------|------|------|------|------|
| 192.168.0.1 - 0 | 10 | 10 | 1 | 1 | 8 | 1 |
| 109.255.178.1 - 0 | 10 | 10 | 9 | 13 | 21 | 9 |
| 109.255.255.254 - 0 | 10 | 10 | 8 | 12 | 20 | 11 |
| ie-dub01a-rc1-ae-31-0.aorta.net - 0 | 10 | 10 | 9 | 14 | 25 | 9 |
| ie-dub01a-ri1-ae-63-0.aorta.net - 0 | 10 | 10 | 8 | 14 | 19 | 8 |
| No response from host - 100 | 2 | 0 | 0 | 0 | 0 | 0 |
| 162.158.36.21 - 0 | 10 | 10 | 10 | 15 | 25 | 12 |
| 172.68.199.120 - 0 | 10 | 10 | 8 | 15 | 21 | 12 |
| 172.64.220.6 - 0 | 10 | 10 | 9 | 15 | 21 | 9 |
| 172.68.199.123 - 0 | 10 | 10 | 8 | 13 | 21 | 16 |
| No response from host - 100 | 2 | 0 | 0 | 0 | 0 | 0 |
| No response from host - 100 | 2 | 0 | 0 | 0 | 0 | 0 |
| 188.42.187.33 - 0 | 10 | 10 | 20 | 25 | 33 | 23 |
| 173.233.129.68 - 0 | 10 | 10 | 20 | 26 | 32 | 23 |
|________________________________________________|______|______|______|______|______|______|
WinMTR v0.92 GPL V2 by Appnor MSP - Fully Managed Hosting & Cloud Provider


It only ran for 10 echo requests per device as I'm not actually attempting to diagnose any problems.

You can see that there were no four-digit pings showing up anywhere. I live in Dublin, Ireland, and so the 'worst' ping of 32 ms to the server itself is after my traffic has made a round trip to another country (albeit not a massive geographical distance away).

"

Hurkenschuß#3111 wrote:

I get the impression that my input isn't wanted here, which is a shame.

You've encountered a separate issue, beyond the final part of the route and server stability. You have already been pointed out the problem at the beginning of the route.
You must resolve this issue before moving on.

"

Hurkenschuß#3111 wrote:

Bufferbloat test result: Grade A

Wonderful. Try using pingplotter for clarity.


If you love LLM

"

Google LLM wrote:

fritz.box - 0 | 566 | 566 | 2 | 31 | 1015 | 4 |

In the context of online gaming, here is a breakdown of your stats:
Packet Loss (0%): Good. Your commands reach the server, but the timing is the issue.
Avg Ping (31ms): Decent. This is a playable baseline for most shooters or MOBAs.
Max Ping (1015ms): Critical. A 1-second delay is a massive "lag spike."
Percentage of Spikes (~2-3%): Roughly 1 in every 50 actions will be delayed.
The Gaming Experience:
Micro-freezes: You will experience "teleporting" or "rubber-banding" (moving forward, then snapping back).
Input Lag: Occasionally, your abilities or shots will fire 1 second after you click.
Inconsistency: Even with 0% loss, the high Jitter (4ms) and 1s spikes make competitive play (CS, Valorant, Apex) very frustrating.
Bottom line: Your connection is stable for downloads, but unreliable for high-level gaming due to these periodic 1-second stalls.