As we've seen in the previous chapters, Nginx works well as a reverse proxy to many modern web environments, such as Node.js and PHP, interfacing directly with those environments with no middleman in between. However, there are also many older technologies that focused on deep integration into Apache HTTPd, and removing Apache from the equation can be non-trivial.
If possible, removing Apache HTTPd is usually the desired approach, for the simple fact that it gives you fewer things to maintain and keep updated. However, given the immense amount of modules for Apache, it's impossible for all of them to be ported, so even if this is not possible, using Nginx and Apache together can still bring benefits for us.
The main purpose of setting up Nginx as a frontend server and giving Apache a backend role is to improve the serving speed. As we established, a lot of requests coming from clients are for static files, and static files are served much faster by Nginx. The overall performance sharply improves on both the client side and the server side.
The good aspect of this approach is how easy it is to set up, as nearly no modification is required when it comes to Apache configuration. All it takes is a simple port change, but that isn't even necessary if you set up Nginx and Apache on different servers. Your setup works as-is, which is particularly useful if you've already spent hours configuring Apache to work with server-side preprocessors, such as PHP, Python, Java, or others.
Adding Nginx as a reverse proxy in front of Apache takes some work, but in a reverse-proxy scenario, it is mostly about telling Nginx which requests it can serve directly and which it needs to proxy to Apache. This is also required if replacing Apache, so in the end, this approach won't add much extra work during setup.
Last but not the least, and this will be further discussed in the last section of this chapter, there may be some issues with control panel software, such as Parallels Plesk, cPanel, and others. These panels are very useful for administrators, as they automate some of the most bothersome tasks, such as adding virtual hosts to the Apache configuration, creating email accounts, configuring the DNS daemon, and many more. The two main issues are:
- These control panels allow you to apply changes on the web server configuration, and based on your changes, they automatically generate valid configuration files for the server. Unfortunately, so far these control panels only offer compatibility with Apache; they do not generate Nginx configuration files. So any changes that you make will have no effect.
- Whether you completely replace Apache with Nginx or go for the reverse proxy mechanism, Nginx usually ends up running on port 80 (and 443 for HTTPS). The control panel software generating configuration files is unaware of this fact and might be stubborn. When generating configuration files, it will systematically reset the Apache port to 80, creating conflicts with Nginx.
Both issues will be discussed again later in the chapter.