Detailed explanation of root directory settings in nginx.conf

location ~ .php${
 root html
 }

root /usr/share;

location /{
 root /usr/html/www
 }

location /app {

}

## events, http, server, location, upstream, etc. in the code block are all block configuration items##
##Block configuration items can be nested. The inner block directly inherits the outer block, for example, any configuration in the server block is based on the existing configuration in the http block##

##Users and user groups running the Nginx worker process#Syntax: user username[groupname] Default: user nobody nobody
#user is used to set the user and user group under which the forked worker process runs after the master process is started. When set as "user username;", the user group name is the same as the user name.
#If the user uses the parameters --user=usergroup and --group=groupname when executing the configure command, nginx.conf will use the user and user group specified in the parameters.
#user nobody;

##Number of Nginx worker processes: The number directly affects performance.
#Each worker process is a single-threaded process, and they will call various modules to implement a variety of functions. If these modules do not have blocking calls, then the number of processes should be configured according to the number of CPU cores. Conversely, if blocking calls may occur, then more worker processes need to be configured.
worker_processes 1;

##SSL hardware acceleration.
#Users can use the command provided by OpenSSL to check whether there is an SSL hardware acceleration device: openssl engine -t
#ssl_engine device;

##Daemon. It is a process that is allowed to run in the background without leaving the terminal. It is separated from the terminal to prevent the information during the process execution from being displayed on any terminal. In this way, the process will not be interrupted by any information generated by the terminal. ##
##Turn off the daemon mode. This mode is provided to facilitate tracking and debugging of nginx. After all, the most tedious thing when debugging a process with gdb is how to continue to follow the forked child process. ##
##If the master_proccess mode is turned off, the worker process will not be forked to handle requests, but the master process itself will be used to handle requests #daemon off; #Check whether Nginx is running as a daemon process. The default is on 
#master_process off; #Whether to work in master/worker mode. The default is on

##Error log settings#
#Syntax: error_log /path/file level;
#Default: error_log / log/error.log error;
#When the value of path/file is /dev/null, no log will be output. This is also the only way to close the error log;
#The value range of level is debug, info, notice, warn, error, crit, alert, emerge, and the levels increase from left to right.
#When the level is error, logs of error, crit, alert, and emerge levels will be output. Those greater than or equal to this level will be output, and those less than this level will not be output.
#If the set log level is debug, all logs will be output. The amount of data will be very large. You need to ensure that the disk where /path/file is located has enough disk space in advance. To set the level to debug, you must add the --with-debug configuration option during configure.
#error_log logs/error.log;
#error_log logs/error.log notice;
#error_log logs/error.log info;

##Path of pid file (pid file storage path of master process ID) #pid logs/nginx.pid;


events {
 #Only output debug-level logs for the specified client: Syntax: debug_connection[IP|CIDR]
 #This setting item actually belongs to event configuration, so it must be placed in events{……} to take effect. Its value can be an IP address or a CIRD address.
 #debug_connection 10.224.66.14; #or debug_connection 10.224.57.0/24
 #In this way, only requests from the above IP addresses will output debug-level logs, and other requests will still use the log level configured in error_log.
 #Note: Before using debug_connection, make sure that the --with-debug parameter has been added when executing configure, otherwise it will not take effect.
 worker_connections 1024;
}

##Core dump (coredump): In Linux system, when a process is terminated due to an error or a signal, the system will write the memory content (core image) of the process execution to a file (core file) for debugging purposes only. This is called core dump (coredump).

http {
##Embed other configuration files syntax: include /path/file
#The parameter can be either an absolute path or a relative path (relative to the Nginx configuration directory, that is, the directory where nginx.conf is located)
  include 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 logs/access.log main;

  sendfile on;
  #tcp_nopush on;

  #keepalive_timeout 0;
  keepalive_timeout 65;

  #gzip on;

  server {
##listen listening port#Syntax: listen address:port [ default(deprecated in 0.8.21) | default_server | [ backlog=num | rcvbuf=size | sndbuf=size | accept_filter=filter | deferred | bind | ssl ] ]
#default_server: If this parameter is not set, the first server block found in nginx.conf will be used as the default server block listen 8080;

#Host name: It can be followed by multiple host names. When processing an HTTP request, nginx will take out the Host in the header and match it with the server_name in each server to decide which server will handle the request. It is possible that a Host matches the server_name in multiple server blocks. In this case, the server block to be processed will be selected based on the matching priority. The matching priority of server_name and Host is shown at the end of this article.
 server_name localhost;

    #charset koi8-r;

    #access_log logs/host.access.log main;

    #location / {
    #root html;
    # index index.html index.htm;
    #}

##location Syntax: location [=|~|~*|^~] /uri/ { ... }
# See the end of the article for examples of using location.
#Note: Locations are ordered. When a request may match multiple locations, the request will actually be processed by the first location.
 location / {
 proxy_pass http://192.168.1.60;
    }

    #error_page 404 /404.html;

    # redirect server error pages to the static page /50x.html
    #
    error_page 500 502 503 504 /50x.html;
    location = /50x.html {
      root html;
    }

    # proxy the PHP scripts to Apache listening on 127.0.0.1:80
    #
    #location ~ \.php$ {
    # proxy_pass http://127.0.0.1;
    #}

    # pass the PHP scripts to FastCGI server listening on 127.0.0.1:9000
    #
    #location ~ \.php$ {
    #root html;
    # fastcgi_pass 127.0.0.1:9000;
    # fastcgi_index index.php;
    # fastcgi_param SCRIPT_FILENAME /scripts$fastcgi_script_name;
    #include fastcgi_params;
    #}

    # deny access to .htaccess files, if Apache's document root
    # concurs with nginx's one
    #
    #location ~ /\.ht {
    # deny all;
    #}
  }



  # another virtual host using mix of IP-, name-, and port-based configuration
  #
  #server {
  # listen 8000;
  # listen somename:8080;
  # server_name somename alias another.alias;

  # location / {
  #root html;
  # index index.html index.htm;
  # }
  #}


  # HTTPS server
  #
  #server {
  # listen 443 ssl;
  # server_name localhost;

  # ssl_certificate cert.pem;
  # ssl_certificate_key cert.key;

  # ssl_session_cache shared:SSL:1m;
  #ssl_session_timeout 5m;

  # ssl_ciphers HIGH:!aNULL:!MD5;
  # ssl_prefer_server_ciphers on;

  # location / {
  #root html;
  # index index.html index.htm;
  # }
  #}

}