Very long loading times or page not accessible at all with Telekom Germany

Very long loading times via Telekom Deutschland

When I access my own websites that run via Cloudflare via my PC’s standard connection (LAN → router, i.e. no wifi), they load extremely slowly and sometimes incompletely. That’s for the backend and frontend.

As soon as I activate a VPN (ProtonVPN) and load my pages via the VPN, everything is back to normal. No matter which city (Berlin/Frankfurt) or which country (DE/NL/CH etc.) I use as the VPN access point!

I have done a lot of research and read about “peering problems” between Deutsche Telekom and Cloudflare.

Is there still no solution? Is it possible to exclude the Telekom from the cloudflare routing somehow?

It is NOT alone between Deutsche Telekom and Cloudflare, but between Deutsche Telekom and many other networks.

I believe that would be a question you should ask AS3320 Deutsche Telekom about.

Including asking them about the ETA for when they want to deliver proper quality to their paying customers (e.g. you).

Can you elaborate on what exactly you mean with “exclude the Telekom from the cloudflare routing”, and what exactly you would be expecting from it?

Thanks for the hint and clarification.

I mean whether it is somehow possible NOT to run all calls from the Telekom network through the Cloudflare proxy but to route them directly to the hosting (at Hostinger). Or would the Pro plan make a difference/improve things? Is there any experience with this?

We run a busy online store and are currently having massive problems with all visitors who are customers of Telekom. We are therefore naturally keen to enable Telekom customers to place orders in the online store. This is hardly possible, especially in the evening hours, and customers are calling us to say that the website/online store is not loading.


Or could be Argo Smart Routing a solution? Does it change anything belonging Telekom? Are they any experiences?

I would suppose such granularity (if available at all) would be tied to an Enterprise plan, where you get things tailored to what exactly you need.

That said, I don’t think I’ve heard of a such possibility directly with Cloudflare on it’s own though.

If you’re willing to run your own DNS servers, - you can attempt to make such granularity happen together with a Business plan:

Your own DNS servers will then determine whether the traffic should be routed to Cloudflare or not, such as e.g. if the source of the DNS query appears to be originating from AS3320 Deutsche Telekom, or the source of the DNS query appears to be from Germany (DE), or similar criteria.

However, if your customers are using DNS resolvers such as e.g., or other anycasted DNS resolvers, that are NOT passing the EDNS Client Subnet of the query to your DNS servers, and at the same time, that AS3320 Deutsche Telekom takes them to a different country than Germany (DE), such as Netherlands (NL), United Kingdom (GB), or similar, then this kind of set up would fail as well, as the criteria you may have set for the direct routing wouldn’t be met here.

You would likely be able to mitigate it for a lot of your customers, but it may not end up on fixing it for all of them, depending on the individual customer’s network set up.

I have heard that the Pro plan and above may be able to improve the routing for *AS3320 Deutsche Telekom, but it won’t be anything that I personally would see as being guaranteed though.

If you insist on testing out one of them, the Pro plan might be able to give a more “fixed” cost than Argo Smart Routing, as it is usage based.

In the end, it it is AS3320 Deutsche Telekom’s routing policy, and how they are doing their things that define where you end up, when the traffic originates from their network.

So it is important to note that even if the Pro, or Argo Smart Routing maybe will provide the good routing you’re seeking for AS3320 Deutsche Telekom users today, it isn’t impossible that tomorrow could be a different story.

Taking up one or more additional costs for something that will maybe work, will maybe work for a limited time, or maybe not at all wouldn’t be a decision that I would personally recommend.


Simplify it a bit, with:


In addition to the above (AS3320) in Source ASN, you may also want to include the subsidiaries of AS3320:

AS48951 TSI-IAS (T-Systems)
AS5483 Magyar Telekom
AS5391 Croatian Telecom
AS6855 Slovak Telecom
AS12713 OTEGlobe
AS9050 Telekom Romania
AS8412 T-Mobile Austria
AS13036 T-Mobile CZ
AS12912 T-Mobile Poland
AS5588 GTS
AS6821 Makedonski Telekom
AS8585 Crnogorski Telekom
AS5603 Telekom Slovenije
AS6878 Open Telekom Cloud / OTC

And then you create an Unproxied (:grey:) / DNS-only record, that is a duplicate of your existing one, like this:

Type: AAAA
Name: shop, or
IPv6 address: 100::
Proxy status: :orange: Proxied.

Type: AAAA
Name: shop-dtag, or
IPv6 address: 100::
Proxy status: :grey: Unproxied / DNS-only.

And then make sure that you configure your shop system (at Hostinger), to accept requests for both and

Preferably, make sure the shop system (at Hostinger) is also making the “internal” links towards (rather than, if the user is currently on

Assuming the connectivity from AS3320 Deutsche Telekom is good enough so that the users can retrieve the redirection, … the customers originating from AS3320 Deutsche Telekom will now be sent to, which goes directly to your Hostinger server.

Thanks a lot for the detailled descriptions and informations! Will check on that.

Can confirm the problem. ISP: AS5483 Magyar Telekom
Since February, all free plans are routed to New York instead of Austria (this is another interesting story, we have a CF DC in our country (BUD), but Telekom goes to Deutsche Telekom → Austria (VIE) instead…)
Free plan websites are basically unreachable between 19:00-0:00, because on top of the 150ms ping the speed is only a few kilobytes.
Only Pro and above plans are routed to Austria now, but since a few weeks these are also unusable between 19:00-0:00 due to high packet loss, so we can’t use services like Discord… CF IPv6 is unaffected by this, but Discord and many big sites are IPv4 only…

This topic was automatically closed 2 days after the last reply. New replies are no longer allowed.