Community

Blog Events Webinars Tutorials Forum
  1. Blog
  2. Events
  3. Webinars
  4. Tutorials
  5. Forum
Create Account
×
Community Blog Setting up and Troubleshooting Your Nginx Server on Alibaba Cloud

Setting up and Troubleshooting Your Nginx Server on Alibaba Cloud

In this tutorial, you will be setting up and also troubleshooting an NGINX HTTP server on an Alibaba Cloud ECS.

By Alex Mungai Muchiri, Alibaba Cloud Community Blog author

When it comes to choosing a reliable HTTP server. One of your best bets is with NGINX's offerings. They offer HTTP servers with good performance and reliability that feature reverse proxies as well as IMAP/POP3 proxies. They are good solution given their reliable and good performance, simple setup, useful features, and resource optimization.

Alibaba Cloud has a variety of features optimized to ensure that your NGINX web server runs smoothly. In this tutorial, we will be looking at how to troubleshoot your HTTP server to make sure everything's doing well. As a general rule, you should ensure that you download NGINX from the official package repositories or use the packages in the official repository for the best performance.

Prerequisites

In this tutorial, you will be using the following items:

  • An Alibaba Cloud ECS instance that is installed with Ubuntu 16.04
  • NGINX HTTP server installed
  • A user with sudo privileges
  • A service e.g. PHP running on your NGINX server

Procedure

Follow the steps outlined below to set up and troubleshoot your NGINX server running on an Alibaba Cloud ECS.

Installing the Nginx Server

The Ubuntu's repositories contain an official NGINX package, and it follows that accessing the package is the best method to install NGINX. Run the command below on your terminal

sudo apt update
sudo apt install nginx -y

Once it is installed, we should start it and then enable it:

sudo systemctl start nginx
sudo systemctl enable nginx

Next, use below commands to verify the Nginx service status:

sudo systemctl status nginx
sudo systemctl is-active nginx

Doing Some Basic Troubleshooting

Checking for Syntax Errors and Warnings

This step involves running a few checks to detect any such errors and warnings. Run the command below:

sudo service nginx configtest

You'll 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

The test will indicate any problems in the file and respective lines for your action. See below:

sudo service nginx configtest

You'll get the following output:

"worker_connections" directive is not allowed here in /etc/nginx/nginx.conf:12
nginx: configuration file /etc/nginx/nginx.conf test failed

Furthermore, you can determine the availability of service command in your system by running a -t switch test on your configuration files like so:

sudo nginx -t

Checking the Status of the NGINX Server

This step will check if your NGINX service is active and running. Run the command below:

sudo service nginx status
* nginx is running

Run the command below to check systemd service status

sudo service nginx status

You'll get the following output:

   nginx.service - LSB: Stop/start nginx
   Loaded: loaded (/etc/init.d/nginx; bad; vendor preset: enabled)
   Active: active (running) since Tue 2018-09-18 10:22:09 EAT; 20s ago
     Docs: man:systemd-sysv-generator(8)
  Process: 2281 ExecStop=/etc/init.d/nginx stop (code=exited, status=0/SUCCESS)
  Process: 2295 ExecStart=/etc/init.d/nginx start (code=exited, status=0/SUCCESS)
    Tasks: 2 (limit: 512)
   CGroup: /system.slice/nginx.service
           ©À©¤2303 nginx: master process /usr/sbin/nginx -c /etc/nginx/nginx.con
           ©¸©¤2304 nginx: worker process                   

Sep 18 10:22:12 ubuntu systemd[1]: Starting LSB: Stop/start nginx...
Sep 18 10:22:12 ubuntu systemd[1]: Started LSB: Stop/start nginx.

For further status checks, you may also run the checks

sudo /etc/init.d/nginx status
sudo systemctl status nginx.service

Responding to the Virtual Host Configuration Error

If there are instances where there are errors in the virtual host configuration, you can inspect the server_name section for errors:

server {
¡­ file content
server_name example.com www.example.com;
¡­ file content
}

Responding to the Too Many Open Files Error

This error is caused by having the maximum number of files open by NGINX cause makes NGINX unable to open more new files. To stop the fail message and fix the issue, access the /etc/nginx/nginx.conf file and access the worker_rlimit_nofile and worker_connections like so:

worker_processes 2;
worker_rlimit_nofile 8192;
events {
worker_connections 4096;
}

Responding to Virtual Root Errors

If you get such an error, you can inspect the root directive to see if the proper root is configured:

server {
¡­ file content
root /usr/share/nginx/html;
¡­ file content
}

Some More Advanced Troubleshooting

Checking the Port Status

NGINX servers use port 443 and 80, and therefore, they need to be enabled if we have a firewall configured on the server. The commands below will open the ports for traffic:

sudo ufw allow 80/tcp
sudo ufw allow 443/tcp

In this check, we try to inspect the status of listening ports on out server by running the ss ¨Cltn command, whose output should look like this:

State      Recv-Q Send-Q        Local Address:Port          Peer Address:Port 
LISTEN     0      128                       *:80                       *:*     
LISTEN     0      128                       *:443                      *:*

Then, to further inspect ports 80 and 443, the default ports, run the lsof like so:

sudo lsof -P -n -i :80 -i :443 | grep LISTEN

You'll get this output then:

nginx   2136  root    6u  IPv4  11099      0t0  TCP *:80 (LISTEN)
nginx   2136  root    7u  IPv4  11100      0t0  TCP *:443 (LISTEN)
nginx   2139 nginx    6u  IPv4  11099      0t0  TCP *:80 (LISTEN)
nginx   2139 nginx    7u  IPv4  11100      0t0  TCP *:443 (LISTEN)

Checking the Working Status of your NGINX Server

The aim of this next procedure is to check if your NGINX server is working fine to process requests using the curl request. To check localhost, run the command below:

curl -i http://127.0.0.1/nginx_status

The output of this command will look like this:

HTTP/1.1 200 OK
Server: nginx/1.11.1
Date: Tue, 18 Sep 2018 10:17:22 GMT
Content-Type: text/plain
Content-Length: 97
Connection: keep-alive

Active connections: 2
server accepts handled requests
3 3 3
Reading: 0 Writing: 2 Waiting: 0

Inspect the NGINX Server Logs

Next, you can also inspect the main log files for errors. Run the command below:

sudo tail -f /var/log/nginx/access.log /var/log/nginx/error.log

You could also inspect log paths by searching for access_log and error_log like so:

egrep -r "(access|error)_log" /etc/nginx/*

The output will be as follows:

/etc/nginx/nginx.conf:error_log /var/log/nginx/error.log warn;
/etc/nginx/nginx.conf:access_log /var/log/nginx/access.log main;

Inspect Files for Permissions and Access from the NGINX Sever

Run the command below:

namei -om /usr/share/nginx/html/index.html

Then, your output will look like this:

f: /usr/share/nginx/html/index.html
drwxr-xr-x root root /
drwxr-xr-x root root usr
drwxr-xr-x root root share
drwxr-xr-x root root nginx
drwxr-xr-x root root html
-rw-r--r-- root root index.html

Reload Nginx to Apply Changes

Reloading Nginx will stop working processes when running services complete and apply your configuration changes. It is always preferable to restarting the processes since that may lead to shutdown of running requests. To reload the server, run the service command below:

sudo service nginx reload

For a restart, you can run the service command below:

sudo service nginx restart

Activating the Debug Mode if Log Information Insufficient

For the most part, you will have an enabled virtual host in the /etc/nginx/nginx.conf. file. Change the directive for the log level to debug like so:

server {
¡­ file content
error_log /var/logs/nginx/error.log debug;
¡­ file content
}

To ensure that all results processed are written in the error_log, enable the rewrite_logdirective by running the command below:

server {
¡­ file content
error_log /var/logs/nginx/error.log notice;
rewrite_log on;
¡­ file content 
}

Then, after this, the debug_connection will help if you need to debug connections from definite clients. As discussed before, NGINX runs events, and this use case can be accessed in the /etc/nginx/nginx.conf like so:

events {
debug_connection 127.0.0.1;
}

You could even go deeper to locations blocks specified in the error.log like so:

server {
¡­ file content
error_log /var/logs/nginx/error.log notice;
rewrite_log on;
location /broken-stuff {
error_log /var/logs/nginx/broken-stuff-error.log debug;
}
¡­ file content
}

Inspecting DNS configurations

DNS resolution is not the first priority on most systems. The /etc/hosts file is the first stop for a view of the DNS records. Run the command below:

host -t A exampleURL.com

Your output will look like this:

exampleURL.com has address 104.16.63.34
exampleURL.com has address 104.16.64.34

To run a detailed DNS resolution, run the command below:

dig -t A +trace exampleURL.com

The output from the command should be similar to what you see below:

; <<>> DiG 9.10.3-P4-Ubuntu <<>> -t A +trace exampleURL.com
;; global options: +cmd
.            20394    IN    NS    e.root-servers.net.
.            20394    IN    NS    h.root-servers.net.
.            20394    IN    NS    l.root-servers.net.
.            20394    IN    NS    i.root-servers.net.
.            20394    IN    NS    a.root-servers.net.
.            20394    IN    NS    d.root-servers.net.
.            20394    IN    NS    c.root-servers.net.
.            20394    IN    NS    b.root-servers.net.
.            20394    IN    NS    j.root-servers.net.
.            20394    IN    NS    k.root-servers.net.
.            20394    IN    NS    g.root-servers.net.
.            20394    IN    NS    m.root-servers.net.
.            20394    IN    NS    f.root-servers.net.
.            20394    IN    RRSIG    NS 8 0 518400 20160716050000 20180918101100 46551 . m/M"7522g.G)XJ!c..cJWxWDZBaCd35K8Dc[Z,swTKax\t`*&rY!t)f>Nk\_z}e4X` FobKZP+cFlvdppa6jqaq2Rwz/oOb4m58zAxdjJnqkCxWSALT2hyEjS/E 7Kg=
;; Received 267 bytes from 100.168.100.10#53(100.168.100.10) in 16 ms

com.            172800    IN    NS    h.gtld-servers.net.
com.            172800    IN    NS    e.gtld-servers.net.
com.            172800    IN    NS    a.gtld-servers.net.
com.            172800    IN    NS    i.gtld-servers.net.
com.            172800    IN    NS    j.gtld-servers.net.
com.            172800    IN    NS    f.gtld-servers.net.
com.            172800    IN    NS    g.gtld-servers.net.
com.            172800    IN    NS    k.gtld-servers.net.
com.            172800    IN    NS    c.gtld-servers.net.
com.            172800    IN    NS    b.gtld-servers.net.
com.            172800    IN    NS    d.gtld-servers.net.
com.            172800    IN    NS    l.gtld-servers.net.
com.            172800    IN    NS    m.gtld-servers.net.
com.            86400    IN    DS    30909 8 2 JBwfBpyDsJVJqdZeAMCzIOwoLzSHxXCD7ZUJklad6Y C41A5766
com.            86400    IN    RRSIG    DS 8 1 86400 20160716050000 20180918101100  46551 . jwc5mkdGe7/@TSu;%=#Yn+b:{:Qca(dK[FzS*_VDeSJ*Ux(s/&FgN89}c]`Bqzy{ 59]8_Qav`=LGtre6%G/\/%@Hyv3TJ,^Kbr(QC*}L}g2CkD&V9m}eLc`sxk%BxLK> 
;; Received 800 bytes from 192.100.10.12#53(b.root-servers.net) in 155 ms

exampleURL.com.    172800    IN    A    192.168.100.10
exampleURL.com.    172800    IN    A    192.168.100.10
9QUAWW3xeCUjFUFaotsjt1FehkkO4KDD5vEBqPUq.com. 86400 IN NSEC3 1 1 0 - XK4aM5L4BGIcH9wDWYa3ClcpOTlk4r0AroxJwSu NS SOA RRSIG DNSKEY NSEC3PARAM
9QUAWW3xeCUjFUFaotsjt1FehkkO4KDD5vEBqPUq.com. 86400 IN RRSIG NSEC3 8 2 86400 20180918101100  20160706034648 34745 com. aVwxZ2KO7g9AQjppyFAGacNs5KbMbRuQ7bg2IeRGhXtS2kxiUW88NTlh5W0Sy5uM PCeQri8EWGSVkKppUPOVRDh79erhQcHeJbvraotJtQ6NQsAlOb1rLixOZZJiK6Ra xvsPpZolKi8vW42GJrkHjEtJHH26aJg3VGDTbfX0hOCsizON7u2569j Q20=
3EGF8BHQUNNRJ95NDCCG9J2NNLM0FN9J.com. 86400 IN NSEC3 1 1 0 - 3EGGQPEM5AUKOE7P8NTV39RR7FHAA7MS NS DS RRSIG
3EGF8BHQUNNRJ95NDCCG9J2NNLM0FN9J.com. 86400 IN RRSIG NSEC3 8 2 86400 20180918101100 20160703040946 34745 com. VwxZ2KO7g9AQjppyFAGacNs5KbMbRuQ7bg2IeRGhXtS2kxiUW88NTlh5W0Sy5uM VwxZ2KO7g9AQjppyFAGacNs5KbMbRuQ7bg2IeRGhXtS2kxiUW88NTlh5W0Sy5uM VwxZ2KO7g9AQjppyFAGacNs5KbMbRuQ7bg2IeRGhXtS2kxiUW88NTlh5W0Sy5uM YIT=
;; Received 671 bytes from 192.168.10.10#53(g.gtld-servers.net) in 26 ms

exampleURL.com.    300    IN    A    100.168.100.12
exampleURL.com.    300    IN    A    100.168.100.12
;; Received 200 bytes from 103.145.99.14#53(mary.ns.cloudflare.com) in 18 ms

The other alternative is to use the services of DNS traversal checker if you do not have access to the dig command. However, if your issues still persist at this juncture, you can make a quick search over the internet.

Troubleshooting to Identify Common Errors

Most Nginx errors you are likely to encounter have been well documented with corresponding solutions. So now we're going to look at some of the most common errors and their corresponding solutions:

Error 1: 98- Unavailable address

If you encounter the address already in use error if there is another process that is listening on the port. To kill the process responsible for the error, run either of the two commands:

sudo fuser -k 80/tcp
sudo pkill culprit_process

Note: You can use either ss or lsof to find the process above and then kill it as demonstrated.

Error 2: Maximum POST size exceeded

If you encounter this error (shown below) when you try uploading a file size that is beyond the maximum allowable POST:

[error] 2589#0: *6001 client intended to send too large body: 89676720 bytes, client: 198.100.10.1, request: "POST /upload/ HTTP/1.1", host: "www.example.com", referrer: "http://www.example.com/upload/"

Then, you can rectify this error by increasing the default file size in the client_max_body_size in the configuration file:

server {
¡­ file content
client_max_body_size 30m;
¡­ file content
}

When running a PHP backend, access the /etc/php5/fpm/php.ini and make the adjustment as you have done above like so:

upload_max_filesize = 30M
post_max_size = 30M

For a more permanent changes, access the directive client_body_buffer_size and make the adjustments:

server {
¡­ file content
client_body_buffer_size 1m;
¡­ file content
}

Last, restart both services after making the changes.

Error 3: Proxy_pass errors

For keepalive and WebSocket connections in proxy_pass adjust the configuration from proxy_http_version 1.0 to 1.1 like so:

server {
¡­ file content
proxy_http_version 1.1;
¡­ file content
}

Error 4: Syntax errors

If you encounter this error when a simple syntax error or unsupported directive is issued, the log will save the following:

[emerg] 2593#0: unknown directive "client_body_temp_path" in /etc/nginx/conf.d/virtualhost.conf:16

Next, invalid syntax causes the errors below:

[emerg] 2287#0: unexpected "}" in /etc/nginx/conf.d/virtualhost.conf:20

 [emerg] 2287#0: unexpected end of file, expecting "}" in /etc/nginx/conf.d/virtualhost.conf:42

For unsupported directives, you will also encounter error messages such as the one below:

[emerg] 3039#0: "get_file" directive is not allowed here in /etc/nginx/conf.d/virtualhost.conf:16

To solve this, go through the documentation to determine the alternative used if any exists.

Conclusion

In this blog, we've gone through some common troubleshooting procedures and analyzed some common errors you are most likely to encounter when using a NGINX server, which are usually very reliable servers. Regardless, with the wealth of knowledge on the web these days about NGINX servers, troubleshooting can be made easy, as we have shown you here, helping you get your feet wet in the troubleshooting world. There may still be other issues you could encounter, or you may be interested in learning more on the subject. In either case, I recommend that you check out Alex Kapranoff's Nginx Troubleshooting.

Don't have an Alibaba Cloud account? Sign up for an account and try over 40 products for free worth up to $1200. Get Started with Alibaba Cloud to learn more.

nginx http Tech Share Web Dev Tutorials Troubleshooting
0 0 0
Share on

Read previous post:

Use Kubeadm to Create a Kubernetes Cluster

Read next post:

Boosting Redis's Security in Four Easy Steps

Alex

53 posts | 8 followers

You may also like

Comments

Alex

53 posts | 8 followers

Related Products

  • Web Hosting Solution

    Explore Web Hosting solutions that can power your personal website or empower your online business.

    Learn More

  • Web Hosting

    Explore how our Web Hosting solutions help small and medium sized companies power their websites and online businesses.

    Learn More

  • HTTPDNS

    HTTPDNS is a domain name resolution service for mobile clients. It features anti-hijacking, high accuracy, and low latency.

    Learn More

  • EMAS HTTPDNS

    EMAS HTTPDNS is a domain name resolution service for mobile clients. It features anti-hijacking, high accuracy, and low latency.

    Learn More

More Posts by Alex

See All