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?

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.

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 turnkeylinux.org. 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.

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.

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.

Hi Ben. FYI I deleted your other post as it was essentially the same. Also if you want to be able to post without waiting for me to publish it and/or start a new thread (for any other issues, or general feedback, etc), please feel free to sign up and let me know and I will enable your user account ASAP.

Regarding the issue you're hitting - as I'm pretty sure I mentioned previously - unfortunately I don't have any iOS devices, so I can't test myself. Although if images are missing, then I would expect that there are explicit errors occurring in your browser. I assume you're using Safari? And assuming that on iOS it is possible to enable "web developer tools" then enable that and check for what errors are occurring and post back. It may not help me to know exactly how to resolve them, but it will be more info - which is always good IMO. And my googlefu is pretty strong so we may be able to find some fix/workaround! :)

I had the same problem.  For something truly "turnkey" I ended up downloading an older version and then updating everything was the image was flashed.  It has been working great so far.

Hey Jeremy,

I was able to fix my issue by placing the website behind Cloudflare.

I am using Strict SSL, with NPM, and your turnkey image works excellently (100%).

Thank You.