Usage of the LXC appliance would be a fine way to go. Note that it will require you to use the commandline, but if you read through the info on the appliance page and follow the link to the usage docs, then hopefully it should all "just work".

Having said that, if resource usage isn't a consideration and you're happy to get your hands a bit dirty with config, then use of a reverse proxy (as you mentioned) is also a fine idea.

Nginx is a great option as it really excels at that sort of thing (as well as serving static content), especially in a low resource environment. FWIW our LXC appliance, and many of our appliances which include software which is "self hosting" (i.e. doesn't need a separate webserver) have Nginix running as a frontend, reverse proxying connections to back end servers (within the same VM).

However, it's worth noting that Apache can also be configured to act as a reverse proxy. Apache is a rock solid option (and I would argue is far more versatile and easier to configure than Nginx). Besides, if you are using our WordPress appliance, then it'll already be running! :)

So if you wanted to use Apache as a reverse proxy, one of your WordPress servers (probably the one getting the most traffic) could accept all the connections. If the traffic is for it, it could serve the content as required. If it's for the other server, then it could forward (i.e. reverse proxy) it on to the other server(s).

TurnKey v15.x appliances include Apache 2.4, so the Apache docs are probably the first place to start. TBH, I've never configured it myself, but from a glance, it looks like use of Apache's mod_proxy with a simple reverse proxy config should do the trick.

One thing to keep in mind though is that assuming you are using HTTPS, your "front end" server (the one initially accepting all the connections) will need to terminate the HTTPS connection and forward the content to the "backend" server(s) as plain HTTP. I.e. the "front end" server will need to have HTTPS certificates to cover all FQDNs (fully qualified domain names) that are in use.

The easiest (and least secure) way to resolve that, is to have all traffic between the "front end" server and "back end" server(s) be via HTTP only. So long as all the Apache servers are on the same network and there is no fear of interception of the traffic between the web servers (and/or it's not dealing with anything super sensitive), then that is generally acceptable.

Although it's fair to say that it's far from ideal! To work around that, you can either copy the certificates between the servers (if you use Confconsole's free Let's Encrypt certificates then I would suggest a cron job to auto copy the certs across via sftp/scp). If you have concerns about copying certificates then you can configure the connections between the 2 servers to use self signed HTTPS certificates. But that is a bit more advanced so I won't go into it further here.

You should be able to find plenty more specific info via the internet, although I've got a few pointers for you. It's worth noting that TurnKey v15.x is based on Debian 9/Stretch, so generally anything that relates to Debian 9/Stretch will also apply to TurnKey v15.x. It includes Apache 2.4, so Debian 8/Jessie and/or TurnKey v14.x should be close enough. Anything else you find regarding Apache 2.4 should also work (although please note that the upstream Apache config is laid out a little differently; as is Red Hat/CentOS). Ubuntu is also based on Debian so generally instructions related to that will also be relevant (I'd guess that 16.04 is probably the closest to Stretch; but any release with Apache 2.4 e.g. 18.04 should be close enough).

I hope that gets you headed in the right direction. Please feel free to post back if you need further assistance and/or clarification on anything. Also, when you do get it all set up and working, it'd be great if you could share what you did and how you did it as I'm sure that would be of value to other users.

Good luck! :)