A traditional WordPress server architecture looks like this. We have Linux + Apache + MySQL + PHP. This is what we called the LAMP stack.
Adding NGINX as reverse proxy looks like this:
What is Reverse Proxy?
A reverse proxy is a server that sits in front of the web server (Apache, in our case). It works as a front layer facing the client request, protecting the web server being exposed to the client. The reason doing that is because NGINX is a lot faster than Apache in general. We want to off load the work to NGINX so that the Apache can do less. As a result to reduced hardware resources (CPU and memory) and faster response.
The NGINX layer here has few roles:
1. SSL Termination
NGINX will be responsible for handing the SSL connection (Secure Socket Layer). It decrypts request data from client, and pass it to the Apache. This helps to speed up the decryption process in Apache.
2. Data Compression
It is now common practice to compress (gzip, bzip, etc) your response payload to reduce the data transfer size. Nginx will take care of this compression process to off load the burden from Apache.
3. HTTP Handling
Handling the HTTP protocol and handshake will now be done by NGINX. Statistics shows that NGINX can handle HTTP a lot more (2x to 10x) efficiently than Apache.
Why do we still need Apache?
A very common question is that can we use NGINX directly with WordPress? Why do we need to use Apache?
While it is possible to do (WordPress does have an official guideline for this), our suggestion is to keep Apache as the web server for WordPress. The main reason is because of the rewrite rule logic. WordPress has a long history, and it was designed to work well with Apache. The WordPress core and lots of plugins are relying on the .htaccess file to implement rewrite rules.
Using NGINX to replace Apache may result in breaking this rules. Although there are solutions to handle this problem, this is going to add extra handling work time to time. So we suggest to keep the LAMP stack unchanged, but just add an extra reverse proxy layer on top. This is also one of the implementation in Uyond hosting. And we have an extra super high speed caching layer (Varnish) on top of Apache, too. This will be covered in future article.
The NGINX Configuration
The reverse proxy can be set by using proxy_pass directive. Below example will route all the root request to port 8181, which is the port where Apache is listening to.
The ssl settings in the server block will handle the SSL termination. As you can it, when the NGINX proxy to Apache, it’s plain HTTP, instead of HTTPS.
server {
listen locahost:443 ssl http2;
server_name test-domain.com;
ssl_certificate /etc/pki/tls/certs/test-domain.com.bundle;
ssl_certificate_key /etc/pki/tls/private/test-domain.com.key;
ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
ssl_ciphers xxxx;
ssl_prefer_server_ciphers on;
ssl_session_cache shared:SSL:10m;
ssl_session_timeout 60m;
location / {
proxy_pass http://localhost:8181;
}
}You can have a root http section to handle compression.
http {
# Compression gzip
gzip on;
gzip_vary on;
gzip_disable "MSIE [1-6]\.";
gzip_proxied any;
gzip_min_length 512;
gzip_comp_level 6;
gzip_buffers 8 64k;
gzip_types text/plain text/xml text/css text/js application/x-javascript application/xml image/png image/x-icon image/gif image/jpeg image/svg+xml application/xml+rss text/javascript application/atom+xml application/javascript application/json application/x-font-ttf font/opentype;About Uyond Hosting
WordPress is a powerful CMS, and it can perform very well if you do it right. In Uyond, we have done all these for you by default. We guarantee all WordPress on Uyond will have all these configuration done correctly. Check more about our hosting solution for details.
Recent Comments