Ballyhoot's picture

I'm using proxmox 7.1-7, Turnkey Linux WordPress containers 17.1-1. I have nginx proxy manager in front. No errors in Nginx logs. The issue started when I moved my websites to 17.1 from 16.1. I made the move because I needed php7.4. I still have 1 website on 16.1 and it works fine on all devices. Getting connection refused. Like it can't parse the response. I spun up a brand new container with no plugins installed to test, it does the same thing. I assume it has something to do with TLS. 

Apache System logs show this when an iOS device tries to connect:

Service [webmin] connected remote server from
transfer: s_poll_wait: TIMEOUTclose exceeded: closing
Connection closed: 578 byte(s) sent to TLS, 828 byte(s) sent to socket

Jeremy Davis's picture

I'm not 100% sure, but I suspect that you may be right. One way that you might be able to double check is if you can connect via plain http? (IIRC you should be able to access vanilla http if you explicitly browse to it).

FYI, we use the Mozilla SSL Configuration Generator "Intermediate" settings. It sounds like you might need the "Old" settings (that link should take you to a page that I've pre-filled Apache and OpenSSL versions and selected "old").

The parts from that which you'll want to copy are "SSLCipherSuite" and possibly "SSLProtocol" (you might also want to update "SSLHonorCipherOrder" too). The file on your server that you'll need to edit is /etc/apache2/mods-available/ssl.conf. Once you've updated as desired, then be sure to restart Apache:

systemctl restart apache2

Hopefully that helps?!

Jules_Werne's picture

I have the same problem and tried your instructions. Sadly, it did not work for me. Problem persists.
Gareth Eaton's picture

This seems to be a problem with TurnKey Linux we have had the same problem with all of the install we did using TurnKey Linux, it not just limited to WordPress,  in the end we remove all installs at we did using TurnKey Linux and reinstalled using other means. had no problems since. 
Jeremy Davis's picture

Hi Gareth, thanks for taking the time to share your experience.

Whilst I'm still not sure of the specific cause, as I've mentioned, I'm guessing that the issue is our tightened security defaults (our website is running on an older version of TurnKey that isn't quite so locked down - and obviously our site is working for you). If you experienced the issue with WordPress, I'm not super surprised that you hit this issue on other TurnKey appliances you tested. About 70-80% of the library uses Apache as the webserver and it seems that it's our locked down Apache config (that all apps that use Apache inherit) that is causing you this issue.

Could you please give me some more info about the device(s) that failed? I don't have any Apple devices and it only appears to affect them (or at least I can't reproduce with any of the devices that I have access to)?! Assuming that it's only affecting Apple devices for you too, then I'd be particularly interested in what device in particular and ideally what OS and browser version too. If it affects other devices, if you could please share what they are (and OS and browser versions too ideally). Armed with that info I'm almost certain that I can get to the bottom of this issue.

I will also think about developing a tool to tighten and/or loosen security config so these issues are easier to work around.

You also noted that you went a different path and it "just worked", so I'd also be interested to know what you are using now? Perhaps we should reduce the default security a little to ensure better compatibility?

Jules_Werne's picture

After reinstalling from scratch, I came to the same conclusion and am now trying a different way as well. Thanks for confirming!
Jeremy Davis's picture

Sorry to hear of your ongoing frustration with TurnKey servers. That's certainly not what we're going for!

Thanks too for reporting back (although it sucks that my advice wasn't useful). And apologies that I didn't previously respond to your earlier post (I've been a bit scattered and things have been a bit crazy behind the scenes with my colleague Alon being based in Israel...).

If you could help me out by sharing the same info I asked Gareth for. I.e. the device(s) that failed to connect and what OS & browser versions they have. If you had any success with other devices, please share as much info about them too. If you've also had success with some other server, I'd be interested in what that is/was (so I can compare our config).

The fact that you 3 are the only reports we've had of this issue suggests that it is limited to specific devices and even though my advice didn't help, the fact that defaults seem to work fine for Gareth, suggests to me that I'm on the right track re Apache security being too locked down.

Look forward to any further info you can share so I can try to work this one out. Thanks in advance.

Jeremy Davis's picture

Hi again to all of you.

If any of you have the patience and inclination, I'd be super interested if any of you still have the same issues with the new v18.0 release. They're only available as ISOs at the moment (so would need to be installed to a VM) but it would be interesting to know whether the issue still hits you on the newer release (I suspect so, but it'd be good to be sure).

Also, re-reading through this thread, I note that the OP was using it behind a Nginx reverse proxy. Are either of you guys also trying to do that?

And actually, now I think of it, by chance are any of you using Nginx Proxy Manager? If so, could you please share the Nginx config (that is generated by Nginx Proxy Manager)? I have had another user having similar issues and it was a Nginx config issue. It was easily fixed by manually configuring the reverse proxy. So I'm wondering if perhaps that is the issue for you guys too? (Sorry I didn't think of that sooner). If I can confirm it again and document it a bit better, I'll open a bug report against Nginx Proxy Manager.

Jules_Werne's picture

Hello Jeremy,

I am also behind a Nginx reverse proxy. I can reach the Wordpress-Server through its Network-IP-Address from all sources including Safari on Mac and from my iPhone. However, if I try to access the website through its domain it does not work (Safari on Mac and iPhone). “The network connection was lost”. Other people experience the same problem when trying to access my site.

None of my browsers on iPhone work: Safari (17.0.3), Brave (1.57.2)

On macOS only Safari (16.4) does not work, but Brave does work (1.59.117)

On Windows and Android everything works.

This problem has been persisting for month, my website is only a placeholder, so I didn’t care that much. But now I want to replace it with a real website, so it’s a huge problem.

Which Nginx config do you mean exactly? Sorry, I’m not an expert in these things and I set up my NPM a long time ago with docker compose. Do you need this config or one from inside the container:

version: "3"



    image: jc21/nginx-proxy-manager:latest

    restart: always


      - 80:80

      - 81:81

      - 443:443


      - ./config.json:/app/config/production.json

      - ./data:/data

      - ./letsencrypt:/etc/letsencrypt


      - db


    # if you want pretty colors in your docker logs:



    image: mariadb:latest

    restart: always







- ./data/mysql:/var/lib/mysql


Jeremy Davis's picture

Thanks so much for responding with so much detail Jules, it's really appreciated.

When I asked for the Nginx config I meant the actual Nginx server config i.e. the Nginx config inside the container that NPM generated for your reverse proxy. One of my guesses is that it's missing a directive, or including one that it shouldn't.

It does appear that under specific circumstance (i.e. Apache behind a Nginx reverse proxy with specific config when accessed via Safari) there is a bug in Nginx and/or Apache and/or Safari? Who's problem it is appears to depend on your perspective - see here and here.

If you can easily access the Nginx config (or perhaps NPM has some way to manually set/adjust the config?), then look for the section that should start something like this:

location / {
    proxy_pass https://BACKEND_SERVER_IP:443;

Then within that location block (i.e. after the 'location / {' line and before the closing '}' line) try adding this line:

    proxy_hide_header Upgrade;

Then you'll need to restart Nginx to apply the updated config. Sorry but I have no idea on the best way to do that (if you have cli access into the container; then 'systemctl restart nginx' should do the trick - otherwise, whatever you normally do to to apply new Nginx config).

If that doesn't help, assuming that your site is publicly available, could you please share the domain with me? If you'd rather not post it publicly, please email to support AT If I can access your server, then I can run some (external) tests and gather some more info, I'm not sure it will help, but perhaps...

Another option is to run one of the common SSL testing sites (e.g. SSL Labs) and share the result. TBH, I'm not sure if that will pick up the backend server issues, but worth a try IMO.

One other question, have you connected directly to the server via it's domain name (i.e. before, or without the reverse proxy)? If so, then could you please try clearing all cache and cookies from your browser and try connecting again. (It may not make any difference, but I have a hunch that there may be some old cache from the original connection that may be causing issues?).

Good luck and I look forward to hearing more.

Lewys Martin's picture

By adding "
    proxy_hide_header Upgrade;
   to the custom nginx config portion in nginx proxy manager, the site now appears to be working, does this help determine the cause ? 
Jeremy Davis's picture

Thanks for confirming. I've opened an issue as well, hopefully more people will find there way there/here.

It seems to be a specific issue between an Nginx reverse proxy and Apache backend server. It appears that Nginx directive is required to work around it. Out of interest, here's the relevant NPM issue.

Michael's picture


Thanks for this fix.  My conf file has more than one location section with a similar proxy pass section as well.  I tried inserting the command below to the first section but that didn't fix the problem.  I don't want to keep modifying randomly as I am new to this.  nginx is running on a synology nas via docker container.  Any help would be appreciated, thanks


proxy_hide_header Upgrade;
Jeremy Davis's picture

Hi Michael. Firstly, I've enabled your TurnKey website user account, so please feel free to log in and your posts should be published straight away. (I.e. you shouldn't need to wait for me to publish).

When you say "more than one location section with a similar proxy pass section", how similar? Assuming mostly the same, I'd recommend moving all the config that is common to all your proxies into it's own config snippet file (call it proxy.conf and put it in /etc/nginx/snippets/). Add that 'proxy_hide_header Upgrade;' line this common proxy.conf. Then whenever you want to reuse that proxy conf within a server block, add the line 'include snippets/proxy.conf;'.

Hopefully that is clear enough and makes sense? If you're still a bit confused, check out our default Nginx ssl.conf config snippet file and see how we include that in our default landing page config.

It's perhaps not the best example (as the ssl.conf is only used once in the default landing page). But the point of doing it that way is the same. It allows a shared/default config snippet (in this case for TLS/SSL) that can easily be reused by any site.

If you have additional config for a specific proxy (that is not common), just add that after the include line.

Good luck.

Michael's picture

Thank you Jeremy, I will look into this.  It's all going over my head at the moment but hopefully I can make sense of it.  Thank you.  

Jeremy Davis's picture

Although not sure how much you should be thanking me if it hasn't actually helped yet!

But seriously, you are welcome. And if you need more explanation and/or things aren't working as expected, please do not hesitate to start new thread and we can go as far down the rabbit hole as you want! :)

Add new comment