Nginx is an open-source web server, it was initially developed by Igor Sysoev and released in October 2004. In Nginx, gzip compression can significantly reduce the size of transmitted data to website visitors.

Modern web browsers support GZIP compression by default. However, we need to configure our server to serve the compressed resources to our website visitors properly. Without a proper configuration, it could make your server load higher and even slower. This article will show you how to improve website performance using GZIP and Nginx on Ubuntu 22.04.

Prerequisites

• Ubuntu 22.04
• SSH access with root privileges or a regular system user with sudo privileges

What is GZIP Compression

GZIP or GNU zip is an open-source algorithm for file compression. GZIP compresses your website resources, such as Javascript and CSS files, while serving requests to the web browsers. It compresses text files effectively, while image files are not compressed because they have some built-in compression.

How to Enable GZIP Compression

To enable compression in Nginx, simply include the following directives in your nginx.conf file, or comment them out if you already have the lines.

gzip on;
gzip_vary on;
gzip_comp_level 6;
gzip_types text/plain text/css application/json application/javascript text/xml application/xml application/xml+rss text/javascript;

Save and close the file, then verify Nginx for any syntax errors:

$ sudo nginx -t

You should get the following output:

nginx: the configuration file /etc/nginx/nginx.conf syntax is ok
nginx: configuration file /etc/nginx/nginx.conf test is successful

Next, restart the Nginx service using the following command:

$ sudo systemctl restart nginx

Then check the status.

$ sudo systemctl status nginx

You should see the following output:

● nginx.service - A high performance web server and a reverse proxy server
Loaded: loaded (/lib/systemd/system/nginx.service; enabled; vendor preset: enabled)
Active: active (running) since Mon 2022-09-19 17:51:13 WIB; 1s ago
Docs: man:nginx(8)
Process: 1249555 ExecStartPre=/usr/sbin/nginx -t -q -g daemon on; master_process on; (code=exited, status=0/SUCCESS)
Process: 1249574 ExecStart=/usr/sbin/nginx -g daemon on; master_process on; (code=exited, status=0/SUCCESS)
Main PID: 1249579 (nginx)
Tasks: 3 (limit: 4532)
Memory: 4.4M
CGroup: /system.slice/nginx.service
├─1249579 nginx: master process /usr/sbin/nginx -g daemon on; master_process on;
├─1249580 nginx: worker process
└─1249581 nginx: worker process

Sep 19 17:51:12 home systemd[1]: Starting A high performance web server and a reverse proxy server...
Sep 19 17:51:13 home systemd[1]: Started A high performance web server and a reverse proxy server.

The following are explanations of our directives to enable and configure gzip in nginx.

gzip on;

The directive above should be turned on to enable gzipping of responses.

In gzip_type directive, you can add another MIME type because, by default, Nginx compresses responses only with MIME type text/thml.

gzip_types text/plain text/css application/json application/javascript text/xml application/xml application/xml+rss text/javascript;

To set gzip compression level, you can add gzip_comp_level directive. The value should be between 1 and 9. The higher the value, the higher the compression. Please note that the most compressed data usually requires more work to compress or decompress, so if you have it set fairly high on a busy website, you may see the difference in your CPU usage.

gzip_comp_level 6;

Another directive, gzip_vary is optional. It is used to enable or disable inserting the “Vary: Accept-Encoding” response header. This header inform the browsers if the client can handle the compressed version of the website or not, especially when your Nginx server is behind CDN or another reverse caching server. If gzip_vary is enabled, you will see vary: Accept-Encoding in the header response, like the following.

HTTP/2 200 
server: nginx
date: Mon, 19 Sep 2022 10:25:15 GMT
content-type: text/html
content-length: 14512
last-modified: Sat, 22 Jan 2022 13:53:28 GMT
vary: Accept-Encoding
etag: "61ec0c58-38b0"
accept-ranges: bytes

Since compression happens at runtime, it can add considerable processing overhead, which can negatively affect your server performance. You can lower your gzip_comp_level if you think your CPU usage is abnormally higher after enabling gzip in Nginx.

How to Verify GZIP is working?

There are several ways to verify whether the gzip compression is working or not. You can use an online tool like Google PageSpeed Insights to check it, or use your browser’s developer tools, or even simply use the curl shell command as follow:

$ curl -I -H 'Accept-Encoding: gzip,deflate' https://www.rosehosting.com/

The command above will show you an output like this:

HTTP/2 200 
server: nginx
date: Mon, 19 Sep 2022 09:52:28 GMT
content-type: text/html
last-modified: Sat, 22 Jan 2022 13:53:28 GMT
etag: W/"61ec0c58-38b0"
content-encoding: gzip

As we can see in the output, the website is compressed using gzip (content-encoding: gzip).

Compare GZIP and Plain Text

After enabling gzip compression, you can compare the files transmitted by nginx to you by simply running these commands.

$ curl -s --output uncompressed https://www.rosehosting.com/
$ curl -s --output compressed -H 'Accept-Encoding: gzip,deflate' https://www.rosehosting.com/

Then, run ‘ls -lh’ or ‘ll -h’ command to see the file size.

As seen above, the compressed file has a lower file size. The lower the file size, the faster your website is and the higher number of concurrent visitors your server can handle.

Congratulations! You have successfully improved your website performance using gzip and Nginx on Ubuntu 22.04.

Of course, if you are one of our Ubuntu Hosting customers, you don’t have to improve your website performance using gzip and Nginx yourself – simply ask our admins, sit back, and relax. Our admins will improve your website performance using gzip and Nginx for you immediately without any additional fee, along with many useful optimizations that we can do for you. Improving your website performance using gzip and Nginx is not just about the installation; we can help you with optimizing your website if you have a VPS with us.

If you liked this post about how to improve your website performance using gzip and Nginx on Ubuntu 22.04, please share it with your friends on the social networks using the share buttons below, or simply leave a comment in the comments section. Thanks.

The post Improve Website Performance Using gzip and Nginx on Ubuntu 22.04 appeared first on LinuxHostSupport.

In today’s tutorial, you will learn how to set up Nginx as a reverse proxy for Apache, using Debian 11 OS. Make sure to follow the official documentation, if any issues arise in the meantime.

Prerequisites

• Server running Debian 11
• Root access to the server

Updating system and installing dependencies

Before starting, it’s hugely important to have your system up-to-date. So, you can run the following commands on your server to update it:

 apt-get update -y; apt-get upgrade -y 

After the system is updated, you need to install the dependencies:
apt-get install gnupg2 curl -y

Installing and configuring Apache

In this part, we’ll proceed with the Apache installation and configuration to run on port 8000. First of all, you need to install it with this command:
apt-get install apache2 -y

Once it’s installed, you need to edit the port from 80 to 8000 on the following files:
nano /etc/apache2/ports.conf
From: Listen 80
To: Listen 8000

nano /etc/apache2/sites-enabled/000-default.conf
From: 80
To: 8000

Now, we’ll restart apache to apply the changes:

systemctl restart apache2

And once it’s restarted, you should see the default page on the following link:
http://your-ip:8000

Installing and configuring Nginx.

Now, since we already have our Apache up and running on port 8000, we need to set up our Nginx as the reverse proxy to run on port 80 and proxy the traffic to port 8000. First of all, let’s install Nginx with:
apt-get install nginx -y

Then, once the installation is done, we need to empty the default vhost, so you can run this command:
echo "" > /etc/nginx/sites-enabled/default

After that, just open it and paste this content to redirect the accesses from port 80 (Nginx)
to 8000 (Apache2):

server {
    listen 80 default_server;
    index index.php index.html index.htm;
    location / {
        proxy_pass http://localhost:8000;
        proxy_set_header Host $http_host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
    }
}

Then just save the file and check the Nginx for any syntax error with this command:
nginx -t

Next, just reload the Nginx service to apply our changes:
systemctl restart nginx

Now, once you access your IP address, you’ll be accessing your Nginx and being proxied to the Apache2 service.

And that’s it. You have successfully installed Nginx as a Reverse Proxy for Apache on Debian 11. Of course, if you have any Linux VPS hosting with us, you don’t need to do this installation. Our admins are available 24/7/365 to help you with those steps.

You will gain all the free benefits of fully managed hosting, including premium customer support, free and unlimited site migration, 99.99% uptime guaranteed, and many other features for your increased satisfaction.

The post How to Set Up Nginx as a Reverse Proxy For Apache on Debian 11 appeared first on LinuxHostSupport.

If you are seeing a 502 bad gateway error on a website, it means that the origin server sent out an invalid response to another server that acted as a gateway or proxy. It can be a tricky investigation to locate what and where is the process which caused the issue. However, there are some general troubleshooting steps that you can follow to get it solved.

For example, if you use Nginx as the webserver and you encounter this issue, it could be that Nginx is unable to communicate with the upstream server, this upstream server could be PHP-FPM or other application that you want to access through Nginx, like Odoo, NodeJS, etc.

How to Fix 502 Gateway Error in Nginx

First, you need to investigate your Nginx server block and check what the upstream server is.

For example, we have a WordPress website at blog.yourdomain.com, and this is the Nginx server block configuration.

According to the configuration, as shown in the picture above, the website’s PHP files are processed by fastcgi running on port 9000.

To check what is running on port 9000, we can issue this shell command:

$ sudo netstat -pltn | grep 9000

or

$ sudo lsof -i :9000

If a process is running on port 9000, you should see something like this after invoking the shell command.

If the shell command does not print anything on the screen, then the process is dead. This is why you see the 502 bad gateway error when accessing your WordPress website.

The next step is to find what pservice should run on port 9000, you can run this command:

$ sudo grep -rl 9000 /etc

As we can see in the picture, it seems that php-fpm7.2 should run to process the PHP files.

In the latest CentOS and Ubuntu, you can invoke this command to see where the process should be run from:

$ sudo systemctl list-unit-files | grep fpm

or

$ sudo systemctl -l | grep -i fpm

If the process is stopped, this is most likely because your server has run out of memory, although you can try to restart it by running this command:

$ sudo systemctl start php7.2-fpm

But, if you see that php-fpm process is running, it means php-fpm could not respond in time and Nginx is unable to communicate with it, hence the issue.

To solve this php-fpm issue, we can tweak Nginx and PHP-FPM configurations.

Increase the timeouts and buffers between NGINX and PHP-FPM.

Increasing the buffers and timeouts gives NGINX / PHP-FPM space to work, particularly if you have any heavy PHP scripts. In the HTTP or location block of your NGINX site configuration, add the following to increase buffers and timeouts:

location {
…
   fastcgi_buffers 8 16k;
   fastcgi_buffer_size 32k;
   fastcgi_connect_timeout 60;
   fastcgi_send_timeout 300;
   fastcgi_read_timeout 300;
}

Change PHP-FPM configuration

PHP-FPM can be configured to listen on a file or tcp/ip as a socket. If you configure php-fpm to listen on tcp/ip as a socket, you would want to switch to a file because theoretically the file saved on a disk could be accessed faster.

To do this, in your PHP-FPM configuration file, you need to change the following: listen = 127.0.0.1:9000

to this: listen = /var/run/php7.2-fpm.sock

You can choose whatever the socket name is, just remember and make sure your Nginx is configured to connect to the socket file

After making the changes, you need to adjust your Nginx server block as well. In your Nginx server block, change this line

fastcgi_pass 127.0.0.1:9000; to fastcgi_pass unix:/var/run/php7.2-fpm.sock;

Then, check your Nginx configuration with nginx -t and reload both Nginx and php-fpm services.

$ sudo systemctl reload nginx
$ sudo systemctl reload php7.2-fpm

If the PHP-FPM processes are running but you are seeing the 502 error message, then you would need to tine tune your PHP-FPM’s process management to utilize the available memory on the server properly.

There are three process manager options you can choose from.

static – a fixed number of child processes, i.e the value of pm.max_children dynamic – the number of child processes are set dynamically ondemand – children will be forked when new requests will connect

By default, the dynamic process manager is activated, if you use this process manager and see a similar message below in the PHP-FPM log:

WARNING: [pool nnnnn] seems busy (you may need to increase pm.start_servers, or pm.min/max_spare_servers), spawning 64 children, there are 8 idle, and 79 total children

then this can trigger the 502 error message on your site, you need to adjust the pm.start_servers, or pm.min/max_spare_servers values to get this fixed. Or, use ‘ondemand’ instead of ‘dynamic’. The ‘ondemand’ will be more efficient, although you need to calculate them based on your server’s amount of RAM, how much a PHP-FPM process consumes memory, etc.

With ‘static’ as the process manager, you will keep everything sitting in memory, traffic spikes will only cause fewer spikes to your CPU, this will make your CPU average lower, but RAM usage may be higher.

If your website is using another application and connected to Nginx as the reverse proxy and you see the 502 error message, most likely the application behind Nginx is down.

The picture above tells us that Nginx is connected to an Odoo instance on port 8069. We can check whether Odoo is running or not, by running the netstat command as mentioned earlier in this blogpost.

$ sudo netstat -pltn | grep 8069

or

$ sudo lsof -i :8069

If none of the above commands print anything, then it means Odoo is down. You need to check the service name and then start it.

$ sudo systemctl -l | grep -i odoo

$ sudo systemctl start odoo

To further investigate why Odoo or PHP-FPM is down, we can run this command:

$ sudo dmesg -T | egrep -i 'killed process'

It might print something like this:

[Tue Jul 13 22:59:47 2021] Out of memory in UB 1644: OOM killed process 27128 (phyton3) score 0 vm:6107440kB, rss:113576kB, swap:0kB

It means your server is running out of memory, you would need to tweak your Odoo configuration. You can check one of our Odoo related posts at How to Speed up Odoo – RoseHosting or contact our support team if you have a server with us.

Of course, you don’t need to get troubled with your server if you have a managed VPS hosting with us – in which case, our technical support team will help you investigate and solve this 502 Bad Gateway issue immediately. They are available 24/7 and can cater to any questions or requests.

PS. If you liked this post, feel free to share it with your friends by using the social media share shortcuts below, or simply leave a comment. Thanks.

The post How To Fix “502 Bad Gateway” Error In Nginx appeared first on LinuxHostSupport.

What is URL Redirect?

URL Redirect or also known as URL Forwarding, is a technique to redirect a domain name or an URL from a location to another. The common use for this redirection is when a page on your site has a good SEO ranking, and you need to change it for a specific reason. For example, you are switching from a CMS to another, this will make your URL structure changed. So, in order to keep your existing SEO rank of a page, you can redirect/forward the old URL to the new ones.

Difference Between 301 and 302 Redirect

301 Redirect

HTTP 301 status code means that a page has been permanently moved to another location. For example, you have a page at http://domainone.com/contactus/ and you want to redirect it to the newly developed one at http://domainone.com/contact-us/. If you want to keep your SEO ranking, you need to make 301 redirect. If you used 302 redirect, search engines will keep the old page indexed, and think your new page as duplication.

302 Redirect

HTTP 302 status code means that a page has been temporarily moved to another location. For example, you have a contact page at http://domainone.com/contact-us/ and you are redesigning it. To avoid your visitors from seeing the unfinished page, you can make a 302 redirection to another page, or even to the main page.

In this guide, we will discuss and show you how to create temporary and permanent redirects with nginx.

Redirect page

Place the following code into your nginx server block to permanently redirect https://www.domainone.com/how-to-create-redirection.html to https://www.domainone.com/how-to-create-redirection-with-nginx.html

if ( $request_filename ~ how-to-create-redirection.html ) {
       rewrite ^ https://www.domainone.com/how-to-create-redirection-with-nginx.html permanent;
}

If you want to make it temporary, simply replace “permanent” with “redirect”

Now, if you have a list of URLs to redirect, it is better to use a map. Please note that the map definition should be placed ourside of the server block.

map $request_uri $new_uri {
     include redirections.conf;
}

server {
      listen 80;
      hostname domainone.com www.domainone.com;
      rewrite ^ http://domaintwo.com$request_uri? permanent;
}

In the redirections.conf file, you can write something like:

/old-url /new-url;
/contactus /contact-us;
/old.html /new.html;

Also, don’t for get to end each lina with a character “;”

Redirect domain

For example, you want to redirect your domainone.com to domaintwo.com, we can do this in nginx configuration file:

server {
      listen 80;
      hostname domainone.com www.domainone.com;
      rewrite ^ http://domaintwo.com$request_uri? permanent;
}

As you can see the above line tell nginx to permanently redirect the http://domainone.com and http://www.domainone.com to http://domaintwo.com. If you want to make it temporary, simply replace the “permanent” part in rewrite line with “redirect”

Or, you can also do the redirection using the following configuration:

server {
      listen 80;
      hostname domainone.com www.domainone.com;
      return 301 http://domaintwo.com$request_uri;
}

Please note that the two options are correct, but “return 301” directive is better than “rewrite”, it also faster. For more information about “return” and “rewrite” directives, please check nginx official documentation at https://www.nginx.com/resources/wiki/start/topics/tutorials/config_pitfalls/?highlight=rewrite#taxing-rewrites

Next, if you want to redirect all http traffic to https, you can do the following:

server {
      listen 80;
      hostname domainone.com www.domainone.com;
      return 301 https://domainone.com$request_uri;

}

With the above configuration, your http version of your domainone.com and www.domainone.com will be permanently redirected to https://domainone.com
When a visitor type https://www.yourdomainone.com on his web browser, your server will response to it and serve the website to the visitor. It means your server is serving https in both www and non www version of your domain. This is bad for SEO, you will want to choose the final URL, with www or without www.

We need to define a separate server block for the www version.

server {

      listen 443 ssl;
      server_name www.domainone.com;
      return 301 https://example.com$request_uri;
}

The full configuration would be:

server {
      listen 80;
      hostname domainone.com www.domainone.com;
      return 301 https://domainone.com$request_uri;
}

server {
      listen 443 ssl;
      server_name www.domainone.com;
      return 301 https://example.com$request_uri;
}

server {
      listen 443 ssl;
      server_name domainone.com;

      root /var/www/domainone.com;
      index index.html index.php index.nginx-debian.html;

      ssl_certificate /etc/letsencrypt/live/domainone.com/fullchain.pem;
      ssl_certificate_key /etc/letsencrypt/live/domainone.com/privkey.pem;

      location / {
         try_files $uri $uri/ index.php;
      }

[......]
[......]
[......]

}

Do not forget to issue “nginx -t” command after editing your nginx configuration files, then restart the service.

With completing this tutorial, you should know how to create temporary and permanent redirects with Nginx.

Of course, you don’t need to get troubled with your server if you are one of our server support services client – in which case, our technical support team will help you in creating temporary and permanent redirects with Nginx. They are available 24/7, and can cater to any questions or requests.

PS. If you liked this post, feel free to share it with your friends by using the social media share shortcuts below, or simply leave a comment. Thanks.

The post How To Create Temporary and Permanent Redirects with Nginx appeared first on LinuxHostSupport.

Aside from using a fast, SSD-powered VPS, you can also do some other tweaks and settings to speed up your website, like enabling gzip compression in Nginx.

Here we’ll discuss one method that will increase the transfer speed by reducing the size of the files with compression. This method will also bring up the benefit of reducing the bandwidth that is used in this process and will make the hosting cheaper to the owner (ie, you can use a hosting plan with fewer resources. The best part about – it’s easy to do and it will only take you a few minutes.

In this article, we’ll share with you how to do the above with the Nginx gzip module. As it is stated this module will help you to compress your files with the gzip compression method. It is known that this method will reduce the size of the transmitted files by half or in some cases even more.

How to enable it?

SSH into your server, and edit your nginx configuration:

[user]$ nano /etc/nginx/nginx.conf

Add or edit the following lines:

gzip on;
gzip_comp_level 2;
gzip_http_version 1.0;
gzip_proxied any;
gzip_min_length 1100;
gzip_buffers 16 8k;
gzip_types text/plain text/html text/css application/x-javascript text/xml application/xml application/xml+rss text/javascript;

# Disable for IE < 6 because there are some known problems
gzip_disable "MSIE [1-6].(?!.*SV1)";

# Add a vary header for downstream proxies to avoid sending cached gzipped files to IE6
gzip_vary on;

Test the configuration and fix errors (if any are shown):

nginx -t

Restart Nginx and verify that gzip is working properly.

service nginx restart

How to test if gzip compression is working in Nginx? Run the following curl command:

[user]$curl --header "Accept-Encoding: gzip,deflate,sdch" -I http://your-domain-name.com/
HTTP/1.1 200 OK
Server: nginx
Date: Fri, 14 Apr 2017 09:59:38 GMT
Content-Type: text/html; charset=UTF-8
Connection: keep-alive
Keep-Alive: timeout=60
Link: <http://your-domain-name.com/wp-json/>;
Content-Encoding: gzip

If you see Content-Encoding: gzip, that means your page was served using the Nginx gzip Module.

Another way to test this is using an online gzip test. There are many “gzip checkers” out there, so use whichever one you want. You can even check and verify if gzip is enabled using multiple methods, including curl and several online tools.

That’s it. Your server should now be configured to use gzip compression and your websites should be noticeably faster.

Of course, you don’t have to do any of this if you use one of our Service Configuration & Optimization Services, in which case you can simply ask our expert Linux admins to enable gzip compression for you. They are available 24×7 and will take care of your request immediately.

PS. If you liked this post, please share it with your friends on the social networks using the buttons on the left or simply leave a reply below. Thanks.

The post How to enable GZIP compression in Nginx appeared first on LinuxHostSupport.