My proxied site too slow

[tpatriksztg]

Hello,
when the CloudFlare proxy is on for my domain, the website is very very slow and the CloudFlare anti ddos JS challange just stucked on loading and changing ray id. If I turn off the proxy everything is good and fast. This problem started a few days ago.
Any ideas or there are some CF problem?

[fritex]

@tpatriksztg

the website is very very slow

Could it be due to SSL/TLS settings?
May I ask how did you measure it and where, if so?

@tpatriksztg

CloudFlare anti ddos JS challange just stucked on loading

May I ask what is your Security Level option selected?
Do you have any custom-made Firewall Rules applied, like country blocking (or challenging), or even JS challange of everyone (each request)?
Have you checked if you enabled the “I am under an attack!” option maybe?
How about Browser Integrity Check option?

Have you tried accessing via a new Web browser, or a private window, or via VPN connection, or even cellular data (mobile data like LTE …)?
Is it always the same?

How about reseting your home router?

[tpatriksztg]

I’ve been using Cloudflare for 2 years and I haven’t changed the settings since then, it just got slow a few days ago.

I did not measure it, it is completely visible, the pages loading so slow.

Could it be due to SSL/TLS settings?
May I ask how did you measure it and where, if so?
SSL/TLS setting: Full

Security level: Medium
Browser Integrity Check: on
I have firewall rules: country block
JS challange for example.com/admin page

I did not try “I am under an attack”.
I tried Firefox, Chrome on Windows and Safari on MacOS but everything is same.

[sandro]

@tpatriksztg

SSL/TLS setting: Full

You’ve had a security issue for two years then.

Why you should choose Full Strict, and only Full Strict

Unencrypted & unverified connections Imagine you open Paypal and suddenly get that warning [image] Would you continue? Probably not. For decades leaders in IT security have advocated that people upgrade their sites from unencrypted HTTP to secure HTTPS. And for a reason, everything you send via an HTTP connection is sent in plain text and can be intercepted at any point between you and the server. Equally, you’d probably not proceed if you got such a warning, right? [image] That’s when th…

[tpatriksztg]

Thanks, I will change to Strict.

I tried two different ISP with different PC, but the page loading still slow and JS challange still stucked and only changing ray id.

[tpatriksztg]

When I ping my website I have some request timeout from the CF.

I think the problem is that I am and my site from Europe, but my site behind American CF proxy, not European.

PING forum.example.com (172.67.207.36): 56 data bytes
Request timeout for icmp_seq 0
Request timeout for icmp_seq 1
64 bytes from 172.67.207.36: icmp_seq=2 ttl=54 time=150.949 ms
64 bytes from 172.67.207.36: icmp_seq=3 ttl=54 time=151.108 ms
Request timeout for icmp_seq 4
64 bytes from 172.67.207.36: icmp_seq=5 ttl=54 time=159.253 ms
Request timeout for icmp_seq 6
64 bytes from 172.67.207.36: icmp_seq=7 ttl=54 time=163.464 ms
64 bytes from 172.67.207.36: icmp_seq=8 ttl=54 time=167.417 ms
64 bytes from 172.67.207.36: icmp_seq=9 ttl=54 time=178.143 ms
Request timeout for icmp_seq 10
Request timeout for icmp_seq 11
Request timeout for icmp_seq 12
Request timeout for icmp_seq 13
64 bytes from 172.67.207.36: icmp_seq=14 ttl=54 time=152.836 ms
64 bytes from 172.67.207.36: icmp_seq=15 ttl=54 time=158.212 ms
^C
--- forum.example.com ping statistics ---
16 packets transmitted, 8 packets received, 50.0% packet loss
round-trip min/avg/max/stddev = 150.949/160.173/178.143/8.746 ms

[sandro]

Have you tried a different connection as @fritex earlier mentioned?

The ICMP timeouts you are experiencing definitely should not be and the timings are relatively long as well. My assumption would be there’s some odd routing going on.

Peering - Why don't I reach the closest datacenter to me?

Why don’t I reach the closest datacenter to me? Cloudflare is an anycast network, so where you are routed is determined by peering with ISPs. The shortest path geographically isn’t always possible due to peering agreements. If you request a site hosted on Cloudflare from home: The domain resolves to a Cloudflare IP Your browser sends an HTTP request to that IP Your ISP’s routers consult their routing table and route the packets upstream to their transit provider ( COSTS MONEY ) The packets …

What’s the domain?

[tpatriksztg]

@sandro

Have you tried a different connection as @fritexvz earlier mentioned?

I tried only ping my sites from 2 different VPS server from the same country where I am from, but pinging from VPS no timeout.
My friend tried from different ISP, he said the loading time was slow, and the JS challange stucked too.

My domains:
https://.com
https://.hu/

I tried to turn off the firewall rules, but the loading time not faster.

[sandro]

Can you post the output of these two URLs?

https://_.com/cdn-cgi/trace
https://_.hu/cdn-cgi/trace

[tpatriksztg]

fl=71f745
h=xxxxx.com
ip=94.27.204.171
ts=1630344344.213
visit_scheme=https
uag=Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/14.1.2 Safari/605.1.15
colo=FRA
http=http/2
loc=HU
tls=TLSv1.3
sni=plaintext
warp=off
gateway=off

fl=71f159
h=xxxxxx.com
ip=94.27.204.171
ts=1630344301.3
visit_scheme=https
uag=Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/14.1.2 Safari/605.1.15
colo=FRA
http=http/2
loc=HU
tls=TLSv1.3
sni=plaintext
warp=off
gateway=off

fl=71f487
h=xxxxx.hu
ip=94.27.204.171
ts=1630344309.027
visit_scheme=https
uag=Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/14.1.2 Safari/605.1.15
colo=FRA
http=http/2
loc=HU
tls=TLSv1.3
sni=plaintext
warp=off
gateway=off

[sandro]

You seem to routed via the German datacenter, but that should still not explain such a latency.

Could you post the output of the following command?

traceroute _.hu

[tpatriksztg]

traceroute to xxxxxxx.hu (104.21.51.38), 64 hops max, 52 byte packets
 1  192.168.1.254 (192.168.1.254)  2.545 ms  1.253 ms  1.146 ms
 2  145.236.238.209 (145.236.238.209)  16.251 ms  16.120 ms  16.295 ms
 3  te0-1-0-18.core0-szeged.net.telekom.hu (84.1.66.86)  24.519 ms  24.533 ms
    te0-1-0-18.core0-zalaegerszeg.net.telekom.hu (84.1.66.84)  24.779 ms
 4  145.236.133.24 (145.236.133.24)  24.157 ms
    81.183.3.101 (81.183.3.101)  23.594 ms
    81.183.3.73 (81.183.3.73)  24.392 ms
 5  81.183.3.107 (81.183.3.107)  28.192 ms
    81.183.3.91 (81.183.3.91)  24.973 ms
    80.157.204.37 (80.157.204.37)  30.849 ms
 6  217.239.41.146 (217.239.41.146)  26.204 ms
    80.157.204.37 (80.157.204.37)  34.822 ms
    217.239.41.146 (217.239.41.146)  27.259 ms
 7  217.239.41.146 (217.239.41.146)  31.057 ms  30.915 ms
    62.159.61.127 (62.159.61.127)  27.887 ms
 8  62.159.61.127 (62.159.61.127)  30.745 ms * *
 9  * 195.122.183.210 (195.122.183.210)  306.148 ms *
10  195.122.183.210 (195.122.183.210)  130.273 ms
    104.21.51.38 (104.21.51.38)  112.146 ms  110.665 ms

Jesus, 300 ms from Germany… It’s not normal.

[sandro]

Seems to be something on the German network.

Which just reminded me of Speed issue for Hungarian Telekom users. It seems there’s some issue with the Hungarian-German routing.

I’d probably continue the discussion over there, so that it is in one place.

[tpatriksztg]

Yeah, maybe Hungarian Telekom problem again, they had issue with German OVH datacenter connection too.

@sandro can you please delete my domain names from your comments? thanks

[sandro]

Done.

Overall it will be difficult to say where exactly the issue is and even Cloudflare might not be able to do so if it is a peering/routing issue of ISPs, but the main thread will hopefully clarify that.

[tpatriksztg]

Thanks for your help!