Nginx not reachable by browsers, but Nextcloud still working

[pi-rat]

Hello,

 

I’m facing yet another strange problem, and I am posting it here as well, because I think it could be OS related.

 

Some details about my server:

 

• Armbian 26.2.1 trixie
• Nginx
• Nextcloud (latest)
• MariaDB
• Letsencrypt (updated 3 weeks ago)

 

 

Until a few days ago, every browser on any of my devices could call the web gui of my server and Nextcloud presented its login page. Then, after the latest OS update, suddenly browsers tell my they can’t connect to the server, but every synching app on any of devices still work perfectly! And I can even access my files on the server by using FolderSync’s¹ internal file browser.

 

It is just the browsers that can’t connect any more, no matter which browser, no matter which device! There is no error message in the appropriate log files, neither in the system log, nor in Nextcloud’s own log, and the message that the browsers present is simply some variation of “I can’t connect to server”. No specific reason, no error code.

 

This is more than strange to me. I would get it if synching apps would have stopped working as well, but that is not the case. Does any one have an explanation for this mystery? If you need more information, just let my know!

 

Many thanks in advance!

 

(¹ Synching app on Android.)

Edited 6 hours ago by pi-rat

[eselarm]

52 minutes ago, pi-rat said:

I can’t connect to server

Here your debugging activity will need to start. There is an awful lot of things unknown, to others on this forum but more important, also to yourself. It could already be that your server (Armbian) has nothing to do with it, but that it is the info in your router (even caching stuff) that has refreshed, simply because you probably restarted, so something was not 'reset proof'. I have seen many of such things myself in my house/home networking and in conjunction with various ISP's (also mobile4G). Which made me use my own (open-source) router instance for example, so I can at least check all what is needed in such case as you have.

 

But it might be simple, you can use wget (do 'man wget' first to see all options) to mimic browser behavior and that should already say something. If docker etc is involved, make sure you understand all (virtual) networking, it can get very complex. I haven't seen potentially disturbing things from Armbian 26.2.1, but I removed/blocked also several things, like no netplan.io, that at least works on Debian Trixie based installs. There have been lots of security related updates in Debian recently, so make sure you log and see changes to packages (edit listchanges.conf)

Edited 5 hours ago by eselarm

[bedna]

I assume you are talking about local connection here, not from the internet, so it's ngiinx webserver you are talking about, not nginx-reverse-proxy?

Can you at least ping the ip of the server?

 

Syncing apps might not connect over http or https (or rather, they probably don't), which your browser does. Are you sure letsencrypt works properly and it's not just your browsers refusing to connect over https due to missing/miss-configured ssl certificates?

Does forcing http connection at least give you some response?

 

As for using wget to test: "wget --spider <url>" should get you some info.

It should look something like this for correct setup using https:

(enter url without http or https, I have redacted url and ip for obvious privacy reasons)

$ wget --spider <your_url_here>
Prepended http:// to '<redacted>'
URL transformed to HTTPS due to an HSTS policy
Spider mode enabled. Check if remote file exists.
--2026-05-23 14:48:27--  https://<redacted>
Loaded CA certificate '/etc/ssl/certs/ca-certificates.crt'
Resolving <redacted> (<redacted>)... xxx.xxx.xxx.xxx
Connecting to <redacted> (<redacted>)|xxx.xxx.xxx.xxx|:443... connected.
HTTP request sent, awaiting response... 200 OK
Length: 0
Remote file exists and could contain further links,
but recursion is disabled -- not retrieving.

 

But as eselarm said above, we need way more information to be able to help.

Edited 1 hour ago by bedna
showing port 443 (https) is ok