TypeError: NetworkError when attempting to fetch resource.

Support
1

Hi there

when connecting to OGS, got the following error message
Unknown speed rapid, cannot check challenge, please try again. (mostly)
TypeError: NetworkError when attempting to fetch resource. (occasionally)

and a sign of no signal showing on the top right corner:
Untitled

any ideas?

I have no issues using other internet resources

2
1 Like
3

I have also started to notice network errors frequently lately.
Try to reload page. Some times it helps.

4

Fetch API is not a websocket connection. It is a plain HTTP(S) request.

I believe problems is in how OGS handles requests. It is not a network related issue.

1 Like
5

Thanks for the reply.

I have tried all 3 options, the problem remains the same: “Unknown speed rapid,xxxxxx”

6

and yes, I am on BT

1 Like
7

There may be some limits on BT side. But this is very unlikely.

CF status doesn’t report any issues in UK. You have no issues using other internet resources. So the problem is definitely on OGS side.

Please rollback to CF. I strongly believe it is the most reliable.

8

set it back to CF

9

OGS used to work fine on my network, it is just recently (a few weeks back) that it has problems.

10

Are you able to test this against LHR ipv6 forward proxies:

The connection reliably stalls via CF only. It has nothing to do with OGS specifically AFAICT, but something either in LHR forward proxies, or I guess it’ts feasible BT could be doing something weird for ipv6 only and for CF peering only, but that sounds pretty tenuous.

Anyway, it’s just not correct that CF is the most stable path for BT users, the CF path is in fact 100% broken for any connection that still needs to send requests more than 20s into the connection.

1 Like
11

OP got

It is an ordinary HTTPS (HTTP over TLS) request. It is not a websocket.

If you have issues with ipv6 try to disable it. But it is definitely not related to ipv6. I saw network errors on OGS. I use ipv4.

P. S. provider cannot distinguish between websocket or non websocket connection over HTTPS. Transmission is fully encrypted. Provider does not see headers or any data. The only exposed is addresses and domain name in SNI. Persistent TCP connection on 80/443 does not mean usage of websocket. Since http 1.1 there is a keep alive mechanism allows a single TCP connection to remain open for multiple HTTP requests. OGS supports http 2 and http 3. Both allow multiple concurrent requests/responses to be multiplexed over a single connection. There is no way for provider to detect websocket.

12

Yes, the OP problem is definitely unrelated to the network issue, I’m not sure what’s going on with that. I just responded to you to let you know that the connections through CF are definitely broken for websockets, so you shouldn’t advise people to switch to CF.

But the OGS connections via CF are definitely terminated by CF and then proxied to OGS from CF, the response headers contain a bunch of CF stuff:

HTTP/1.1 200 OK
Date: Tue, 03 Jun 2025 22:33:48 GMT
Content-Type: text/html; charset=utf-8
Transfer-Encoding: chunked
Connection: keep-alive
Server: cloudflare
Nel: {"success_fraction":0,"report_to":"cf-nel","max_age":604800}
Cf-Ray: 94a2a77fbc444e9a-LHR
Vary: Accept-Encoding
X-Powered-By: Express
Etag: W/"4086-VgfDihXBHXeNoU1Dm8F5bWj1eVY"
Cf-Cache-Status: DYNAMIC
Report-To: {"endpoints":[{"url":"https:\/\/a.nel.cloudflare.com\/report\/v4?s=ObIIiTM71BXGuTZzC6A5inYlSGGVCaLQkw5%2BhlrdAJY25MeGjgi%2FYt1L%2BjPnyPFsR6B1c%2FQenSyeBBsHcuAD0wdqyNcIo7h3DlRowgMRzRt4hDxWgYpTlBIDeQJyhudQEXVYIhGp%2Bg2E8zU%3D"}],"group":"cf-nel","max_age":604800}
alt-svc: h3=":443"; ma=86400
server-timing: cfL4;desc="?proto=TCP&rtt=5842&min_rtt=3696&rtt_var=2269&sent=24&recv=8&lost=0&retrans=0&sent_bytes=21060&recv_bytes=443&delivery_rate=3899084&cwnd=252&unsent_bytes=0&cid=f5b1c759f765ad00&ts=5037&x=0"

And you are right that the problem isn’t specific to websockets, it’s just ipv6 connections to any of online-go.com IPs, from BT (but I suspect just anyone terminating in LHR):

online-go.com.		300	IN	AAAA	2606:4700:20::681a:24
online-go.com.		300	IN	AAAA	2606:4700:20::681a:124
online-go.com.		300	IN	AAAA	2606:4700:20::ac43:4912

The connections just stall after 20s (no more TCP packet payloads get through and there are a bunch of retransmission attempts from both server to client and client to server). It just only really affects websockets, because they expect to be able to send/receive after 20s while most other connections have sent/received all their content by that point.

1 Like
13

Can you check if ipv6 connections to any other destinations stay alive after 20s from BT?

14

Yes, all other connections I’ve been able to test are fine. Even connecting to any other CF IPs (eg: 2606:4700:20::681a:23 rather than 2606:4700:20::681a:24) is fine. Connecting to these specific IPs from elsewhere is also fine.

So as far as I can tell it’s just these specific CF IPs, when you connect from BT (or if my suspicion is correct, anywhere that terminates in LHR) that the connections stall.

15

May be I was wrong.
This may be CF issue.

This looks like very suspicious. There is only last 3 bits difference. :grin:

I sent a very silly question to CF about maintaining tcp over different routes to different edge endpoints. I do not believe I am lucky enough to get a response. But there is a chance.

1 Like
16

I got a response from CF

2 Likes
17

Does this look like AI to anyone else, or am I just paranoid?

1 Like