NGINX is a web server designed for high-traffic cases that is lightweight and highly efficient.
The ability to easily support static content such as HTML and media files is one of the most significant features of NGINX. NGINX uses a predictable loading output asynchronous event based model.
NGINX transmits CGI, FastCGI or any other web server, such as Apache, with dynamic content. The contents are then returned to NGINX to be delivered to the customer. You will get to know basic parameters and conventions in this NGINX text.
All files in the NGINX setup are /etc/nginx/ directory The primary setup file is /etc/nginx/nginx.conf.
NGINX Configuration solutions are referred to as directives. Guidelines are grouped into sections or structures identified to classes. Both are synonymous with two words.
Comments and not NGINX are followed by a # character. Containing guidelines will end with a; or the configuration should not be loaded by NGINX and error report.
The following is a simplified copy of the NGINX registry installation file /etc/nginx/nginx.conf included. This file starts with 4 instructions: user, worker process, error log and pid. They are outside a particular block or context, but in the main sense they are expected to exist. Further instructions are protected by the events and HTTP lines, and in the most relevant sense.
See NGINX documents in the main sense for descriptions of the directives and others.
error_log /var/log/nginx/error.log warn;
pid /var/run/nginx.pid;
events {
. . .
}
http {
. . .
}
The http block contains network traffic control instructions. These instructions are often referred to as universal, since they are forwarded to all NGINX website settings. For a list of usable http block guidelines, see the NGINX documents.
http {
include /etc/nginx/mime.types;
default_type application/octet-stream;
log_format main '$remote_addr - $remote_user [$time_local] "$request" '
'$status $body_bytes_sent "$http_referer" '
'"$http_user_agent" "$http_x_forwarded_for"';
access_log /var/log/nginx/access.log main;
sendfile on;
#tcp_nopush on;
keepalive_timeout 65;
#gzip on;
include /etc/nginx/conf.d/*.conf;}
The above http block contains a directive specifying that NGINX is to find website settings.
This will include /etc/nginx/conf.d/*.conf because it happens to be in the above http section when you install the NGINX official repository. That NGINX web site should be given its own /etc/nginx/conf.d/ configuration file with the name formatted like abc.com.conf. Disabled sites will be called abc.com.conf.disabled (not supported by NGINX).
This line says /etc/nginx/sites-enabled/* if you have installed NGINX from the Debian or Ubuntu repositories. The .. /sites-enabled/ folder provides symlinks to files stored in the /etc/nginx/sites-available/ directory. The pages that are accessible on these pages may be deactivated by removing the symlink to the websites.
In /etc/nginx/conf.d/default.conf, /etc/nginx/sites-enabled/ default, a sample configuration file can be found depending on the source you are downloading.
Regrettably, server configuration files must provide a domain block(s) for a website irrespective of the installation source. Types include:
The listen rule defines hostname / IP to NGINX and the TCP port on which HTTP connections should be listened. This virtual host, the default server assertion, responds to port 80 requests that explicitly do not suit any listen comment of a virtual host. The second statement is IPv6 listening and acting in the same way.
The server name rule allows several domains from a single IP address to be served. On the basis of the request header, the server determines the domain to represent.
Normally, one file should be generated on your server per domain or site. Some examples are as follows:
1. The abc.com and www.abc.com manage requests:
2. The server_name directive can also use wildcards. *.abc.com and .abc.com both instruct the server to process requests for all subdomains of abc.com
3. Process applications starting with example for all domain abc.:
You may assign server names that are not acceptable domain names from NGINX. NGINX uses the HTTP header name to respond to requests, whether or not the domain name is correct.
It is useful to use hostnames other than the domain if your server is on LAN or if you already know all the customers who make server requests. This includes the /etc/hosts registry of the front-end proxy for the IP address NGINX is using.
The setting of the location allows you to decide how NGINX responds to server resource requests. Much as the NGINX directive for server name tells NGINX how to handle domain queries, location directives cover file and folder specifications, like http:/abc.com/blog/. Some examples are given here
The above are string matches that match every portion of an HTTP request after the host segment:
Request: http://abc.com/
Returns: If there is a server name entry such as.com, the location / directive determines what happens with this order.
With the most specific match, NGINX always meets the requests:
Request: http://abc.com/customblog/ or http://abc.com/custom/blog/about/
The above are string matches that match every portion of an HTTP request after the host segment:
Request: http://abc.com/
Returns: If there is a server name entry such as.com, the location / directive determines what happens with this order.
With the most specific match, NGINX always meets the requests:
Request: http://abc.com/custom/blog/ or http://abc.com/custom/blog/about/
Returns: The /custom /blog/ guideline is fulfilled as it is more precise, even though /custom/ is still consistent with this criterion.
If a tilde (~) follows a position instruction, NGINX frequently matches expression. Such matches are often informal. Therefore, the first example above is indexpage.php, but indexpage.php does not suit. In the second example, the regular expression ^/BlogCustom(/|index.php)$ will match requests for /BlogCustom/ and /BlogCustom/index.php, but not /BlogCustom, /blogCustom/, or /BlogCustom/index.php. Perl Compatible Regular Expressions (PCRE) is used by NGINX.
If matches are insensitive to the case, use an asterisk tilde (~ *). In particular, the examples show how nginx should process applications which end in an extension of the specific file. In the first case, the request will be matched by any file ending in:.pl,.PL,.cgi,.CGI,.perl,.perl,.prl, and .. PrL (amongst others).
Adding a caret and tilde (^~) to your position instructions tells NGINX to stop looking for similar matches when matching a particular string. Besides, these guidelines work in the first category like the actual string matches. Even if a more precise fit is found later, the settings here will be used if a request meets any of these guidelines. For information on the position directive processing order and priority, see below.
if open, /srv /www/abc.com/blog/public html/ index.html. This must support /srv/www/abc.com/blog/public_html/ index.hen if this file doesn’t have that file. NGINX returns a 404 error if no one exists.
Directives are processed in the below order:
1. Exact matches of strings are first analyzed. NGINX stops looking if there is a match and meets the order.
2. Next are processed the remaining literal string directives. If the ^~ argument is found in the match, NGINX stops and fulfills the request. This is an alternative. NGINX will then continue to process location guidelines.
3. Standard expressions (~ and ~ *) are processed for each position directive. If the request matches a regular expression, nginx stops looking for and fulfills the query.
4. The most precise abstract string match is used when no regular expressions match.
Make sure that every domain file and folder matches at least one location directive.
Note:- No approved and/or supported location blocks.
The position is an additional variable with its own statement block.
If NGINX decides the location directive better fits that request, the contents in the corresponding location directive block shall decide the response to that request. Here’s a case in point:
The root document is in the html/ directory in this case. The entire route to this place is /etc / nginx / html/ under the default NGINX installation prefix.
Request: http://abc.com/blog/includes/style.css
Returns: NGINX must seek to represent the location of the file /etc/nginx/html/blog/includes/style.css
Note:- If you like, you can use absolute root paths.
NGINX is indicated by the index variable, which file is being served when none is given. Types include:
Request: http://abc.com
Returns : NGINX must seek to represent the location of the file /etc/nginx/html/index.html .
If a number of files for the index directive are specified, NGINX will process the list in order and complete the first existing request file. In the corresponding tab, index.html will be used if it does not exist. A 404 message will be received if none exists.
This is a more complex example of a server that responds to the domain with a set of localization directives abc abc.com:
location ~ .pl$ {
gzip off;
include /etc/nginx/fastcgi_params;
fastcgi_pass unix:/var/run/fcgiwrap.socket;
fastcgi_index index.pl;
fastcgi_param SCRIPT_FILENAME /srv/www/abc.com/public_html$fastcgi_script_name;
}
In this example the second place block, which specifies a fastcgi handler for these queries, is used to handle all requests for resources which end in a.pl extension. Otherwise, the first position instruction will be used by NGINX. The resources on the /srv/www/abc.com/public_html/ file system are located. If no file name is entered in the request, the index.html or index.htm file is searched by NGINX. The server returns an error 404 if no index files are found.
Analyze what happens in a variety of applications:
Request: http://abc.com/
Returns: If open, /srv /www/abc.com/public html/ index.html. This must support /srv/www/abc.com/ public html / index.hen if this file doesn’t have that file. NGINX returns a 404 error if no one exists.
Request: http://abc.com/blog/
Returns: If open, /srv /www/abc.com/blog/public html/ index.html. This must support /srv/www/abc.com/blog/public_html/ index.hen if this file doesn’t have that file. NGINX returns a 404 error if no one exists.
Request: http://abc.com/tasks.pl
Returns: To run the file on /srv/www/abc.com/ public html / tasks.pl, NGINX will use FastCGI handler and return the results.
Request: http://abc.com/username/roster.pl
Returns: NGINX will use the FastCGI handler to execute the file located at /srv/www/abc.com/public_html/username/roster.pl and return the result.
Thankyou..