An error occurred during a connection to discourse.ubuntu.com. PR_IO_TIMEOUT_ERROR

[corradoventu]

Ubuntu Version: 25.10, 26.04

Desktop Environment: GNOME

Problem Description: frequent errors trying to access:
An error occurred during a connection to discourse.ubuntu.com. PR_IO_TIMEOUT_ERROR

Problem occurs almost always since May 28th from Italy using Firefox

[tea-for-one]

Your situation seems to be similar to the comments in this topic

There is a useful solution in post 37 from @rubi1200

[rubi1200]

A simpler and shorter workaround was also offered here:

I can no longer access these forums via WiFi; only via mobile data

That and a no-cache refresh of the Discourse page (CtrlShiftR in Firefox) is all that’s required, actually; and the refresh is only for the impatient, because after reducing the MTU size, while FF is still trying to connect, it will eventually connect with the changed MTU in a retry. And yes, I’m also affected by this; I only need to do the reverse (set MTU to 1500 again) and FF gets stuck trying to connect, currently. I occasionally do that to see if the issue is resolved, and it works someti…

But I have not tested it so unable to confirm.

[corradoventu]

Strangely, the problem occurs with Ubuntu 25.10, 26.04, 26.10, Debian 14 but not with Ubuntu 24.04. Same PC different partitions.

[peterwhite23]

@corradoventu, I am running up-to-date 24.04 and am affected by this, if it really is the same issue. Maybe there is some subtle difference in your 24.04 installation? Or you just got lucky when trying it with that version, because it seems to be an intermittent thing, although it’s pretty permanent right now for me.

[corradoventu]

On Ubuntu 26.04 Firefox Nightly153.0a1 Firefox Settings> Privacy&security> clear data for specific site … fixed the problem.

[paddylandau]

@corradoventu

the problem occurs with Ubuntu 25.10, 26.04, 26.10, Debian 14 but not with Ubuntu 24.04.

Corrado, run this command on all of your devices:

ip link show | grep -F BROADCAST | grep -Fv NO-CARRIER

The result should show something like this:

3: wlo1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1320 qdisc noqueue state UP mode DORMANT group default qlen 1000

Look at the number after “mtu”. It typically will show a number like 1500 or 1320. Do you notice a difference between the devices?

When Discourse is guarding against the DDOS, it disallows a number greater than 1320, but when it’s more relaxed, it allows a greater number.

[dmxplx]

I have been having the same issue on Chrome and the Android PWA since yesterday.

[Gre0]

@paddylandau

When Discourse is guarding against the DDOS, it disallows a number greater than 1320, but when it’s more relaxed, it allows a greater number.

Thanks! That’s the important point and good to know. I also was affected in the last two days.

Next time, I’ll try changing the MTU to 1320, as recommended by @rubi1200 …

I can no longer access these forums via WiFi; only via mobile data - #52 by peterwhite23

[dmxplx]

It only happens over Wi-Fi, and it’s still happening.

[peterwhite23]

Well, it happens with every network connection that satisfies 1320 < MTU <= 1500, I guess; it’s plain ethernet in my case.

[carlin0]

Debian 14 doesn’t exist yet, perhaps you mean Debian Testing or Sid

[corradoventu]

Sorry, today it happens also with Debian (yes, future 14, now forky/sid):

 corrado@corrado-a6-debian:~$ inxi -Sxc
System:
  Host: corrado-a6-debian Kernel: 7.0.9+deb14-amd64 arch: x86_64 bits: 64
    compiler: gcc v: 15.2.0
  Desktop: GNOME v: 49.5 Distro: Debian GNU/Linux forky/sid
corrado@corrado-a6-debian:~$ 

[dmxplx]

I’m still experiencing connection issues with Discourse on every network except my mobile phone when using a cellular connection. This happens across different IP addresses, devices, and even countries. There must be something wrong, no? … Trying to help.

[Gre0]

@paddylandau

When Discourse is guarding against the DDOS, it disallows a number greater than 1320, but when it’s more relaxed, it allows a greater number.

This info is the important point !

Additionally…did you read this and have you tried to change your MTU from 1500 to 1320 ?

[dmxplx]

With all due respect, if Discourse is behind DDoS protection and this is impacting users, those users should not have to open a terminal just to access a website.

I understand that several people above have tried to provide workarounds, and I appreciate those efforts! Thank you very much.

Is the site behind Cloudflare within the Ubuntu infrastructure, using a reverse proxy, CDN, and WAF?

[dmxplx]

@paddylandau are we having two issues, please?

[dmxplx]

Is the site behind Cloudflare within the Ubuntu infrastructure, using a reverse proxy, CDN, and WAF?

[peterwhite23]

What would be the alternative? Fighting off a DDoS is no trivial exercise, for you must know whom to block. I reckon someone just figured that mobile clients, which always have an MTU <1500, can be easily whitelisted that way. Since many people seem to use their mobile devices to access this platform, that’s not actually such a terrible idea.

It is kind of silly, though, to have the workaround instructions on an unreachable platform. Catch 22 much?

[paddylandau]

@dmxplx

With all due respect, if Discourse is behind DDoS protection and this is impacting users, those users should not have to open a terminal just to access a website.

If we’re going to talk about “should”, you need to start with the gang that “should” not have created the DDOS in the first place.

You can hardly blame Discourse for the problem.

@dmxplx

are we having two issues, please?

I don’t think so. Discourse is having to protect itself against the DDOS, and we are suffering from the impact. Until the gang stops its criminal activity, we have to work around it — for example, right now I’ve had to disable WiFi on my phone to be able to answer.