Issue between Cloudflare and BELL network in Toronto, ON

Website, Application, Performance
1

Hi there,
We are experiencing an issue on our website https://eggsmedia.com on BELL networks in Toronto, ON.
It’s not loading the logo, the website is extremely slow, etc.
We have a Bell network in our household and we tested also on some phones by using Bell network mobile data.
Everywhere else (different networks) website works just perfectly fine.

When we turn on the DEVELOPMENT mode in Cloudflare everything is perfect.
If we PAUSE the Cloudflare same issue occurs.

So, there is something between BELL network here in Toronto and Cloudflare :confused:
I tried to call Bell to see if they can clear the cache or do whatever but still didn’t hear back from them. Also Cloudflare support didn’t help us.

Any suggestions?

2

Anyone? Nothing? Huh :confused:

3

Lets start with these commands then.

nslookup eggsmedia.com
ping eggsmedia.com
nslookup www.eggsmedia.com
ping www.eggsmedia.com

powershell "$t=Get-Date; Invoke-RestMethod -Uri https://eggsmedia.com/ -Headers @{'Accept-Encoding' = 'gzip, deflate, br'} | Out-Null; Write-Output \"$((Get-Date).Subtract($t))\""

powershell "$t=Get-Date; Invoke-RestMethod -Uri https://eggsmedia.com/wp-content/uploads/2019/10/eggsmedia-logo-white.png -Headers @{'Accept-Encoding' = 'gzip, deflate, br'} | Out-Null; Write-Output \"$((Get-Date).Subtract($t))\""

Whats their output when you run them on that network?

4

Hello Sandro,
Thank you for getting back, please see below (I had to separate .com from eggsmedia because it’s not allowing me to post more than 2 links):

C:>ping eggsmedia .com

Pinging eggsmedia .com [104.31.70.68] with 32 bytes of data:
Reply from 104.31.70.68: bytes=32 time=25ms TTL=55
Reply from 104.31.70.68: bytes=32 time=24ms TTL=55
Reply from 104.31.70.68: bytes=32 time=25ms TTL=55
Reply from 104.31.70.68: bytes=32 time=23ms TTL=55

Ping statistics for 104.31.70.68:
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 23ms, Maximum = 25ms, Average = 24ms

C:>nslookup www.eggsmedia .com
Server: mynetwork
Address: 192.168.2.1

Non-authoritative answer:
Name: www.eggsmedia .com
Addresses: 104.31.70.68
104.31.71.68

C:>ping www. eggsmedia .com

Pinging www.eggsmedia .com [104.31.70.68] with 32 bytes of data:
Reply from 104.31.70.68: bytes=32 time=23ms TTL=55
Reply from 104.31.70.68: bytes=32 time=26ms TTL=55
Reply from 104.31.70.68: bytes=32 time=23ms TTL=55
Reply from 104.31.70.68: bytes=32 time=24ms TTL=55

Ping statistics for 104.31.70.68:
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 23ms, Maximum = 26ms, Average = 24ms

C:>
C:>powershell “t=Get-Date; Invoke-RestMethod -Uri https://eggsmedia.com/ -Headers @{'Accept-Encoding' = 'gzip, deflate, br'} | Out-Null; Write-Output \"((Get-Date).Subtract($t))”"
00:00:00.5781736

C:>
C:>powershell “t=Get-Date; Invoke-RestMethod -Uri https://eggsmedia.com/wp-content/uploads/2019/10/eggsmedia-logo-white.png -Headers @{'Accept-Encoding' = 'gzip, deflate, br'} | Out-Null; Write-Output \"((Get-Date).Subtract($t))”"

5

You didnt post the output of the last command, but so far it looks okay. You resolve the right address and the site downloads swiftly.

6

It’s not giving me anything on the last command…

7

Maybe a quoting issue. Try again

powershell "$t=Get-Date; Invoke-RestMethod -Uri https://eggsmedia.com/wp-content/uploads/2019/10/eggsmedia-logo-white.png -Headers @{'Accept-Encoding' = 'gzip, deflate, br'} | Out-Null; Write-Output \"$((Get-Date).Subtract($t))\""
8

C:>powershell “$t=Get-Date; Invoke-RestMethod -Uri https://eggsmedia.com/wp-content/uploads/2019/10/eggsmedia-logo-white.png -Headers @{‘Accept-Encoding’ = ‘gzip, deflate, br’} | Out-Null; Write-Output "$((Get-Date).Subtract($t))"”
Invoke-RestMethod : The remote server returned an error: (522) Origin Connection Time-out.
At line:1 char:14

  • … t=Get-Date; Invoke-RestMethod -Uri https://eggsmedia.com/wp-content/u …
  •             ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    • CategoryInfo : InvalidOperation: (System.Net.HttpWebRequest:HttpWebRequest) [Invoke-RestMethod], WebException
    • FullyQualifiedErrorId : WebCmdletWebResponseException,Microsoft.PowerShell.Commands.InvokeRestMethodCommand

00:00:15.9525091

9

So this works

powershell "$t=Get-Date; Invoke-RestMethod -Uri https://eggsmedia.com/ -Headers @{'Accept-Encoding' = 'gzip, deflate, br'} | Out-Null; Write-Output \"$((Get-Date).Subtract($t))\""

but this returns a 522?

powershell "$t=Get-Date; Invoke-RestMethod -Uri https://eggsmedia.com/wp-content/uploads/2019/10/eggsmedia-logo-white.png -Headers @{'Accept-Encoding' = 'gzip, deflate, br'} | Out-Null; Write-Output \"$((Get-Date).Subtract($t))\""
10

It seems yeah.
There is one thing about the logo. It was not caching properly through WP Rocket and through custom PHP plugin we made command “not to cache” the logo. Now I am not sure is that causing some of the issues.
But these “issues” are appearing only on specific network in Toronto (BELL network). That’s why I don’t understand anything at this point…

11

Can you open https://eggsmedia.com/cdn-cgi/trace on that network, as well as on one where you dont experience the issue?

Whats the output?

12

NETWORK WITH ISSUE
fl=16f264
h=eggsmedia.com
ip=70.24.163.242
ts=1584558758.841
visit_scheme=https
uag=Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:74.0) Gecko/20100101 Firefox/74.0
colo=IAD
http=http/2
loc=CA
tls=TLSv1.3
sni=plaintext
warp=off

CLOUDFLARE UNDER DEVELOPMENT MODE (THE ONLY WAY TO AVOID ISSUE):
fl=16f229
h=eggsmedia.com
ip=70.24.163.242
ts=1584559518.681
visit_scheme=https
uag=Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:74.0) Gecko/20100101 Firefox/74.0
colo=IAD
http=http/2
loc=CA
tls=TLSv1.3
sni=plaintext
warp=off

13

That is the same network. You said it behaves differently on another network.

Anyhow, these requests went via the Washington PoP and if you say development mode makes a difference, it shouldnt be the datacentre per se.

Actually, enabling development mode shouldnt fix the issue but rather the other way round, as you wont cache anything in that case.

I am afraid, at this point it might be best to open a support ticket. Support should be able to look into this and tell why a non-cached request works, but cached requests dont.

14

Ok, thank you for trying to help us. Appreciate :wink:

15

This topic was automatically closed after 14 days. New replies are no longer allowed.