PR_END_OF_FILE_ERROR - What happened?

Hi there,

I am currently lost, I cannot connect to my manjaro nextlcoud server (which was running until yesterday). Firefox tells me that the error PR_END_OF_FILE_ERROR occured. Looking at the server, status for nginx, php-fpm and mariadb seem to be alright (status active), reloading them does not change the behaviour.

What seems strange though is the RAM usage, which is unusally low. It’s in the range of 200 to 300 MB, normally (when the nextlcoud instance is running) , it is more in the region of 1 GB.

PHP commands for occ are working though, so I can enable and disable maintenance mode for Nextcloud. :thinking:

In case someone has an idea where to start searching in order to fix this, I would highly appreciate any hint.

Thank you so much!


not always same problem …
nexlcloud is with https ?
no problem with chromium ? so it’s not a server error …

if server: we can read nginx logs (journalctl with nginx)

Yes, Nextcloud is only served via https and unavailable on all devices, so it most likely is a server issue.

I tried looking at the logs, but it seems rather unspectacular for something that is not working…

journalctl -u nginx.service --since today
Oct 09 20:32:16 server systemd[1]: Starting A high performance web server and      a reverse proxy server...
Oct 09 20:32:33 server systemd[1]: Started A high performance web server and a reverse proxy server.
Oct 09 20:56:00 server systemd[1]: Reloading A high performance web server and a reverse proxy server.
Oct 09 20:56:00 server nginx[834]: 2020/10/09 20:56:00 [notice] 834#834: signal process started
Oct 09 20:56:00 server systemd[1]: Reloaded A high performance web server and a reverse proxy server.

I get this error quite often. In my case it is related to my VPN and bypassing it for certain domains.

I haven’t looked into it too much, but I have configured a few domains to bypass my VPN. When the browser first sends the request for one of these domains, I think, my VPN client sees that domain and tries redirecting it. Always on the very first connect attempt it is dropped. Subsequent requests always work without problems. The PR_END_OF_FILE_ERROR usually means the browser cannot establish a secure connection. It’s almost always related to a VPN.

If you don’t use a VPN, try creating a new firefox profile.

This is almost certainly an issue on the server, not the client side.

I’m not using VPN and all devices are unable to connect to the server (which is running Manjaro).

Hm, maybe it’s not the server itself after all:

nginx is configured to channel all http requests to the external https-domain. I just tried my internal IP address in Internet explorer and it was transferred to the external domain, so this seems to be working.

Trying the external IP address in Internet Explorer, I actually see my Nextcloud, indicating that it is not called via a trusted domain. (After ignoring a certificate issue, since my SSL certificate is valid only for the domain as I do not have a static IP.)

This made me check the domain via, which seems to be working. At least it received an A rating and shows that TLS1.2 is supported. There are some handshake issues, but I think only for old versions of Firefox or browsers that I do not use.

Also it reports the correct IP external IP address for my home server as well as other details, e.g. nginx version and so on. So the connection from domain to external IP to internal device and services on the device seems complete to me. I am really struggeling to understand what could be happening that causes the issue…

Just for reference an excerpt from the ssllabs report

edit 2: It’s even weirder than that. Adding the external and internal IP to the trusted domains of my Nextcloud instance, I can actually reach the Nextcloud and login without any problems (after ignoring the issue that the certificate is not valid for the IP address).

Out of curiosity, can you curl the domain and enable full verbose output? It might yield an error that the browser is hiding.

1 Like

Dear Twifty,

I tried curl on the domain and it seemed alright (thanks for the tip, I did not know that command) and “magically fixed it”.

–verbose showed successful handshakes
–location (did something different than I expected :joy:) prompted some html content which seemed like the standard login page for Nextcloud

So I went back to the browser and there it was! I have no idea why and how, but it’s back.

The two things I actually did today on the server side:

  • Change the CNAME for the domain to a new DNS host at (although the IP for the old host was correct, I just wanted to make sure) (obviously not a change on the acutal server but at my domain provider. I guess this takes some time to “kick-in”, TTL was 3600s I think, which could coincide with the server being back in the end.)
  • add the internal and external IP to the trusted domain (will remove them though, as they are not part of the SSL certificate)

As the IP was already correct before and the trusted domains should not influence the actual connection to the server I don’t believe that one of those things actually made the difference, but maybe someone with more knowledge will correct me or at least it can provide some indication for others with a similar problem. :wink:

I wonder if it had anything to do with the SSL verification process in Firefox and making the request first through curl somehow installed something on your system?

1 Like

No, I don’t think curl actually fixed something locally on my PC as I had the problem on all devices (mobile, Windows, Linux).

I just remembered that TTL was 3600s for the CNAME entry (edited my post above accordingly). This could actually fit regarding the time the server was back. But still I do not understand why.

Glad you got it fixed. Networking can be a real finicky topic.