Configuración completa de Nginx

Descripción general de Nginx

Nginx es un servidor proxy inverso web y de código abierto, de alto rendimiento y altamente confiable, y es compatible con la implementación en caliente. Puede ejecutarse casi 7 * 24 horas al día sin reiniciar, incluso si se ejecuta durante varios meses. En el caso del servicio , actualice en caliente la versión del software. El rendimiento es la consideración más importante para Nginx. Ocupa menos memoria, tiene sólidas capacidades simultáneas y puede admitir hasta 50 000 conexiones simultáneas. Lo más importante es que Nginx es gratuito y comercializado, y su configuración es relativamente simple.

El sitio web oficial explica la configuración de parámetros de cada URL del módulo:Documentación china de Nginx

Características de Nginx

• Alta concurrencia y alto rendimiento;
• La arquitectura modular lo hace muy escalable;
• El modelo asíncrono sin bloqueo basado en eventos es similar a Node.js;
• Comparado con otros servidores, puede durar varios meses o incluso más sin reiniciar el servidor, lo que lo hace altamente confiable;
• Implementación en caliente, actualización sin problemas;
• Completamente de código abierto, prosperidad ecológica;

Rol de Nginx

Los escenarios de uso más importantes de Nginx:

1. Servicio de recursos estáticos, que proporciona servicios a través del sistema de archivos local;
2. Servicio de proxy inverso, incluido almacenamiento en caché, balanceo de carga, etc.;
3. servicio API, OpenResty;

Node.js no es ajeno al front-end. Muchos conceptos de Nginx y Node.js son similares, como servidor HTTP, controlado por eventos, asíncrono y sin bloqueo, etc., y la mayoría de las funciones de Nginx también pueden ser realizado usando Node.js, pero Nginx y Node.js .js no entran en conflicto, cada uno tiene su propia área de especialización. Nginx es bueno en el procesamiento de recursos subyacentes del lado del servidor (reenvío de procesamiento de recursos estáticos, proxy inverso, equilibrio de carga, etc.), mientras que Node.js es mejor en el procesamiento de la lógica comercial específica en la capa superior, y los dos pueden ser perfectamente conjunto.

Usa una gráfica para representar:

Comandos comunes de Nginx

nginx -s reload  # 向主进程发送信号，重新加载配置文件，热重启
nginx -s reopen	 # 重启 Nginx
nginx -s stop    # 快速关闭
nginx -s quit    # 等待工作进程处理完成后关闭
nginx -T         # 查看当前 Nginx 最终的配置
nginx -t         # 检查配置是否有问题

Configuración del núcleo Nginx

estructura del archivo de configuración nginx.conf

Un ejemplo típico de configuración para Nginx:

# main段配置信息
user  nginx;                        # 运行用户，默认即是nginx，可以不进行设置
worker_processes  auto;             # Nginx 进程数，一般设置为和 CPU 核数一样
error_log  /var/log/nginx/error.log warn;   # Nginx 的错误日志存放目录
pid        /var/run/nginx.pid;      # Nginx 服务启动时的 pid 存放位置

# events段配置信息
events {
    use epoll;     # 使用epoll的I/O模型(如果你不知道Nginx该使用哪种轮询方法，会自动选择一个最适合你操作系统的)
    worker_connections 1024;   # 每个进程允许最大并发数
}

# http段配置信息
# 配置使用最频繁的部分，代理、缓存、日志定义等绝大多数功能和第三方模块的配置都在这里设置
http { 
    # 设置日志模式
    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;   # Nginx访问日志存放位置

    sendfile            on;   # 开启高效传输模式
    tcp_nopush          on;   # 减少网络报文段的数量
    tcp_nodelay         on;
    keepalive_timeout   65;   # 保持连接的时间，也叫超时时间，单位秒
    types_hash_max_size 2048;

    include             /etc/nginx/mime.types;      # 文件扩展名与类型映射表
    default_type        application/octet-stream;   # 默认文件类型

    include /etc/nginx/conf.d/*.conf;   # 加载子配置项
    
    # server段配置信息
    server {
    	listen       80;       # 配置监听的端口
    	server_name  localhost;    # 配置的域名
      
    	# location段配置信息
    	location / {
    		root   /usr/share/nginx/html;  # 网站根目录
    		index  index.html index.htm;   # 默认首页文件
    		deny 172.168.22.11;   # 禁止访问的ip地址，可以为all
    		allow 172.168.33.44；# 允许访问的ip地址，可以为all
    	}
    	
    	error_page 500 502 503 504 /50x.html;  # 默认50x对应的访问页面
    	error_page 400 404 error.html;   # 同上
    }
}

• configuración global principal, efectiva globalmente;
• La configuración de eventos afecta la conexión de red entre el servidor Nginx y el usuario;
• HTTP configura la mayoría de las funciones, como proxy, caché y definición de registro, así como la configuración de módulos de terceros;
• el servidor configura los parámetros relevantes del host virtual y puede haber múltiples bloques de servidor en un bloque http;
• la ubicación se utiliza para configurar el uri coincidente;
• upstream configura la dirección específica del servidor backend, que es una parte indispensable de la configuración del equilibrio de carga;

Utilice una imagen para mostrar claramente su estructura jerárquica:

Reglas gramaticales del archivo de configuración nginx.conf:

1. Los archivos de configuración consisten en directivas y bloques de directivas.
2. Cada instrucción termina con un ";" punto y coma, y ​​las instrucciones y los parámetros están separados por un símbolo de espacio
3. Los bloques de instrucciones usan {} llaves para organizar varias instrucciones juntas
4. La declaración de inclusión permite combinar varios archivos de configuración para mejorar la capacidad de mantenimiento
5. Agregue comentarios a través del símbolo # para mejorar la legibilidad
6. Usar variables con el signo $
7. Los parámetros de algunas instrucciones admiten expresiones regulares, como la instrucción de ubicación de uso común

Parámetros básicos de la sección principal del archivo de configuración

usuario

Especifique el propietario y el grupo del subproceso de trabajo que ejecuta Nginx, y el grupo no se puede especificar.

#语法：user USERNAME [GROUP]

user nginx lion; # 用户是nginx;组是lion

pid

Especifica la ruta de almacenamiento del archivo pid para ejecutar el proceso principal maestro de Nginx.

pid /opt/nginx/logs/nginx.pid # master主进程的的pid存放在nginx.pid的文件

trabajador_rlimit_nofile_number

Especifica el número máximo de identificadores de archivo que puede abrir un proceso secundario de trabajo.

worker_rlimit_nofile 20480; # 可以理解成每个worker子进程的最大连接数量。

trabajador_rlimit_core

Especifica el archivo principal después de la terminación anormal del subproceso de trabajo, que se usa para registrar y analizar problemas.

worker_rlimit_core 50M; # 存放大小限制
working_directory /opt/nginx/tmp; # 存放目录

número_de_procesos_de_trabajador

Especifica la cantidad de subprocesos de trabajo iniciados por Nginx.

worker_processes 4; # 指定具体子进程数量
worker_processes auto; # 与当前cpu物理核心数一致

trabajador_cpu_affinity

Vincule cada subproceso de trabajo a un núcleo físico de nuestra CPU.

worker_cpu_affinity 0001 0010 0100 1000; # 4个物理核心，4个worker子进程

La vinculación de cada subproceso de trabajo a un núcleo físico de CPU específico tiene la ventaja de evitar el cambio del mismo subproceso de trabajo en diferentes núcleos de CPU, lo que invalida la memoria caché y reduce el rendimiento. Pero realmente no puede evitar el cambio de proceso.

trabajador_prioridad

Especifique el valor agradable del subproceso de trabajo para ajustar la prioridad de ejecutar Nginx, generalmente establecido en un valor negativo para llamar a Nginx primero.

worker_priority -10; # 120-10=110，110就是最终的优先级

El valor de prioridad del proceso predeterminado de Linux es 120, y cuanto menor sea el valor, mayor será la prioridad; el valor agradable oscila entre -20 y +19.

Nota: El valor de prioridad predeterminado de la aplicación es 120 más el valor agradable es igual a su valor final, cuanto menor sea el valor, mayor será la prioridad.

trabajador_apagado_tiempo de espera

Especifica el tiempo de espera cuando el proceso secundario del trabajador finaliza correctamente.

worker_shutdown_timeout 5s;

resolución_temporizador

La precisión del temporizador utilizada dentro del subproceso del trabajador, cuanto mayor sea el intervalo de tiempo de ajuste, menos llamadas al sistema, lo que conduce a una mejora del rendimiento; por el contrario, cuantas más llamadas al sistema, menor será el rendimiento.

timer_resolution 100ms;

En el sistema Linux, cuando el usuario necesita obtener el temporizador, debe enviar una solicitud al kernel del sistema operativo.Si hay una solicitud, habrá una sobrecarga, por lo que cuanto mayor sea el intervalo, menor será la sobrecarga.

demonio

Especifique el modo de ejecución de Nginx, el primer plano o el segundo plano, el primer plano se usa para la depuración y el segundo plano se usa para la producción.

daemon off; # 默认是on，后台运行模式

Parámetros principales de la sección de eventos del archivo de configuración

usar

Qué modelo basado en eventos usa Nginx.

use method; # 不推荐配置它，让nginx自己选择

Los valores opcionales de método son: select, poll, kqueue, epoll, /dev/poll, eventport

conexiones_trabajadores

El número máximo de conexiones simultáneas que puede manejar un proceso hijo trabajador.

worker_connections 1024 # 每个子进程的最大连接数为1024

aceptar_mutex

Ya sea para abrir el mutex de balanceo de carga.

accept_mutex on # 默认是off关闭的，这里推荐打开

directiva nombre_servidor

Especifica el nombre de dominio del host virtual.

#语法：server_name name1 name2 name3

# 示例：
server_name www.nginx.com;

Cuatro formas de escribir coincidencias de nombres de dominio:

• Coincidencia exacta: nombre_servidor www.nginx.com ;
• Comodín izquierdo: server_name *.nginx.com ;
• Configuración en el lado derecho: server_name www.nginx.* ;
• Coincidencia normal: nombre_servidor ~^www\.nginx\.*$ ;

Prioridad de coincidencia: coincidencia exacta > coincidencia de comodín izquierdo > coincidencia de comodín derecho > coincidencia de expresión regular

ejemplo de configuración de server_name:

1. Configure el DNS local para resolver hosts

# 添加如下内容，其中 121.42.11.34 是阿里云服务器IP地址
121.42.11.34 www.nginx-test.com
121.42.11.34 mail.nginx-test.com
121.42.11.34 www.nginx-test.org
121.42.11.34 doc.nginx-test.com
121.42.11.34 www.nginx-test.cn
121.42.11.34 fe.nginx-test.club

Nota: aquí se utiliza un nombre de dominio virtual para las pruebas, por lo que se debe configurar la resolución de DNS local. Si se utiliza un nombre de dominio comprado en Alibaba Cloud, la resolución de nombre de dominio debe configurarse en Alibaba Cloud.

2. Configure Alibaba Cloud Nginx, vim /etc/nginx/nginx.conf 

# 这里只列举了http端中的sever端配置

# 左匹配
server {
	listen	80;
	server_name	*.nginx-test.com;
	root	/usr/share/nginx/html/nginx-test/left-match/;
	location / {
		index index.html;
	}
}

# 正则匹配
server {
	listen	80;
	server_name	~^.*\.nginx-test\..*$;
	root	/usr/share/nginx/html/nginx-test/reg-match/;
	location / {
		index index.html;
	}
}

# 右匹配
server {
	listen	80;
	server_name	www.nginx-test.*;
	root	/usr/share/nginx/html/nginx-test/right-match/;
	location / {
		index index.html;
	}
}

# 完全匹配
server {
	listen	80;
	server_name	www.nginx-test.com;
	root	/usr/share/nginx/html/nginx-test/all-match/;
	location / {
		index index.html;
	}
}

3. Análisis de acceso

• Al visitar www.nginx-test.com, se puede hacer coincidir, así que elija la "coincidencia exacta" de mayor prioridad;
• Al acceder a mail.nginx-test.com, se realizará una "coincidencia izquierda";
• Al visitar www.nginx-test.org, se realiza una "coincidencia correcta";
• Al acceder a doc.nginx-test.com, se realizará una "coincidencia izquierda";
• Al visitar www.nginx-test.cn, se realizará la "coincidencia correcta";
• Al acceder a fe.nginx-test.club, se realizará una "coincidencia regular";

raíz

Especifique la ubicación del directorio de recursos estáticos, que se puede escribir en http, servidor, ubicación y otras configuraciones.

#root path

#例如：
location /image {
	root /opt/nginx/static;
}

#当用户访问 www.test.com/image/1.png 时，实际在服务器找的路径是 /opt/nginx/static/image/1.png

Nota: root superpondrá la ruta de definición y el URI, y el alias solo tomará la ruta de definición.

alias

También especifica la ubicación del directorio de recursos estáticos, que solo se puede escribir en la ubicación.

location /image {
	alias /opt/nginx/static/image/;
}

#当用户访问 www.test.com/image/1.png 时，实际在服务器找的路径是 /opt/nginx/static/image/1.png

Nota: asegúrese de agregar / al final del alias, ya que solo se puede ubicar en la ubicación. 

ubicación

Configurar ruta.

location [ = | ~ | ~* | ^~ ] uri {
	...
}

Reglas de coincidencia:

• = coincidencia exacta;
• ~ Coincidencia regular, distingue entre mayúsculas y minúsculas;
• ~* Coincidencia normal, no distingue entre mayúsculas y minúsculas;
• ^~ Deja de buscar cuando coincida;

Precedencia coincidente:  =  >  ^~  >  ~  >  ~*  > sin ningún carácter.

Ejemplo:

server {
  listen	80;
  server_name	www.nginx-test.com;
  
  # 只有当访问 www.nginx-test.com/match_all/ 时才会匹配到/usr/share/nginx/html/match_all/index.html
  location = /match_all/ {
      root	/usr/share/nginx/html
      index index.html
  }
  
  # 当访问 www.nginx-test.com/1.jpg 等路径时会去 /usr/share/nginx/images/1.jpg 找对应的资源
  location ~ \.(jpeg|jpg|png|svg)$ {
  	root /usr/share/nginx/images;
  }
  
  # 当访问 www.nginx-test.com/bbs/ 时会匹配上 /usr/share/nginx/html/bbs/index.html
  location ^~ /bbs/ {
  	root /usr/share/nginx/html;
    index index.html index.htm;
  }
}

Barra invertida en la ubicación

location /test {
	...
}

location /test/ {
	...
}

• Sin / Al acceder a www.nginx-test.com/test, Nginx primero verificará si hay un directorio de prueba y, de ser así, encontrará index.html debajo del directorio de prueba; si no hay un directorio de prueba, nginx lo hará. encontrar si hay un archivo de prueba.
• Con / Al acceder a www.nginx-test.com/test, Nginx primero buscará el directorio de prueba, si lo hay, buscará el index.html en el directorio de prueba, si no, no buscará la existencia del archivo de prueba.

devolver

Deje de procesar la solicitud, devuelva directamente el código de respuesta o redirija a otra URL; después de ejecutar el comando de devolución, los comandos posteriores en la ubicación no se ejecutarán.

#return code [text];
#return code URL;
#return URL;

#例如：
location / {
	return 404; # 直接返回状态码
}

location / {
	return 404 "pages not found"; # 返回状态码 + 一段文本
}

location / {
	return 302 /bbs ; # 返回状态码 + 重定向地址
}

location / {
	return https://www.baidu.com ; # 返回重定向地址
}

volver a escribir

Vuelva a escribir la URL de acuerdo con las reglas de coincidencia de expresiones regulares especificadas.

#语法：rewrite 正则表达式 要替换的内容 [flag];

#上下文(标签)：server、location、if

#示例：rewirte /images/(.*\.jpg)$ /pic/$1; # $1是前面括号(.*\.jpg)的反向引用

El significado del valor opcional de la bandera:

• La última URL reescrita inicia una nueva solicitud, ingresa nuevamente al segmento del servidor y vuelve a intentar la coincidencia en la ubicación;
• break usa directamente la URL reescrita y ya no coincide con las declaraciones en otras ubicaciones;
• redirigir devuelve 302 redirección temporal;
• Devoluciones permanentes Redirección permanente 301;

server{
  listen 80;
  server_name fe.lion.club; # 要在本地hosts文件进行配置
  root html;
  location /search {
  	rewrite ^/(.*) https://www.baidu.com redirect;
  }
  
  location /images {
  	rewrite /images/(.*) /pics/$1;
  }
  
  location /pics {
  	rewrite /pics/(.*) /photos/$1;
  }
  
  location /photos {
  
  }
}

Analicemos según esta configuración:

• Al visitar fe.lion.club/search, automáticamente nos redirigirá a https://www.baidu.com.
• Al visitar fe.lion.club/images/1.jpg, el primer paso es reescribir la URL a fe.lion.club/pics/1.jpg, encontrar la ubicación de las fotos y continuar reescribiendo la URL a fe. lion.club/ photos/1.jpg , después de encontrar la ubicación de /photos, vaya al directorio html/photos para encontrar el recurso estático 1.jpg.

si la instrucción

#语法：if (condition) {...}

#上下文：server、location

#示例：
if($http_user_agent ~ Chrome){
  rewrite /(.*)/browser/$1 break;
}

condición Condición del juicio:

• Cuando $variable es solo una variable, el valor está vacío o una cadena que comienza con 0 se tratará como falsa;
• = o != igual o no igual;
• ~ partido regular;
• ! ~ coincidencia no regular;
• ~* Coincidencia normal, no distingue entre mayúsculas y minúsculas;
• -f o !-f detecta la presencia o ausencia de un archivo;
• -d o !-d detecta la existencia o inexistencia de un directorio;
• -e o !-e detecta la presencia o ausencia de archivos, directorios, enlaces simbólicos, etc.;
• -x o !-x detecta si el archivo se puede ejecutar o no;

Ejemplo:

server {
  listen 8080;
  server_name localhost;
  root html;
  
  location / {
  	if ( $uri = "/images/" ){
    	rewrite (.*) /pics/ break;
    }
  }
}

Al acceder a localhost:8080/images/, ingresará el juicio if para ejecutar el comando de reescritura.

índice automático

Cuando la solicitud del usuario finaliza con /, se muestra la estructura del directorio, que se puede utilizar para crear rápidamente un sitio web de descarga de recursos estáticos.

Información de configuración de autoindex.conf:

server {
  listen 80;
  server_name fe.lion-test.club;
  
  location /download/ {
    root /opt/source;
    
    autoindex on; # 打开 autoindex，，可选参数有 on | off
    autoindex_exact_size on; # 修改为off，以KB、MB、GB显示文件大小，默认为on，以bytes显示出⽂件的确切⼤⼩
    autoindex_format html; # 以html的方式进行格式化，可选参数有 html | json | xml
    autoindex_localtime off; # 显示的⽂件时间为⽂件的服务器时间。默认为off，显示的⽂件时间为GMT时间
  }
}

Al acceder a fe.lion.com/download/, se mostrarán los archivos bajo la ruta del servidor /opt/source/download/, como se muestra en la siguiente figura:

Variables integradas de Nginx

Las variables globales integradas comúnmente utilizadas por nginx, puede usarlas libremente en la configuración:

demostración de ejemplo:

server{
	listen 8081;
	server_name var.lion-test.club;
	root /usr/share/nginx/html;
	location / {
		return 200 "
remote_addr: $remote_addr
remote_port: $remote_port
server_addr: $server_addr
server_port: $server_port
server_protocol: $server_protocol
binary_remote_addr: $binary_remote_addr
connection: $connection
uri: $uri
request_uri: $request_uri
scheme: $scheme
request_method: $request_method
request_length: $request_length
args: $args
arg_pid: $arg_pid
is_args: $is_args
query_string: $query_string
host: $host
http_user_agent: $http_user_agent
http_referer: $http_referer
http_via: $http_via
request_time: $request_time
https: $https
request_filename: $request_filename
document_root: $document_root
";
	}
}

Cuando visitamos http://var.lion-test.club:8081/test?pid=121414&cid=sadasd, dado que el método de devolución está escrito en Nginx, el navegador Chrome descargará un archivo para nosotros de forma predeterminada, como se muestra a continuación Descargado contenido del archivo:

remote_addr: 27.16.220.84
remote_port: 56838
server_addr: 172.17.0.2
server_port: 8081
server_protocol: HTTP/1.1
binary_remote_addr: 茉
connection: 126
uri: /test/
request_uri: /test/?pid=121414&cid=sadasd
scheme: http
request_method: GET
request_length: 518
args: pid=121414&cid=sadasd
arg_pid: 121414
is_args: ?
query_string: pid=121414&cid=sadasd
host: var.lion-test.club
http_user_agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_14_0) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/88.0.4324.182 Safari/537.36
http_referer: 
http_via: 
request_time: 0.000
https: 
request_filename: /usr/share/nginx/html/test/
document_root: /usr/share/nginx/html

Configuración común de Nginx

Conceptos básicos de la aplicación Nginx 

Un proxy es una capa hipotética de servidores entre el servidor y el cliente. El proxy recibirá la solicitud del cliente y la reenviará al servidor, y luego reenviará la respuesta del servidor al cliente.

Independientemente de si se trata de un proxy directo o inverso, se implementan las funciones anteriores.

reenviar proxy

Proxy de reenvío significa un servidor ubicado entre el cliente y el servidor original (servidor de origen).Para obtener contenido del servidor original, el cliente envía una solicitud al proxy y especifica el destino (servidor de origen), y luego el proxy reenvía el contenido al servidor original Solicitar y devolver el contenido obtenido al cliente.

El proxy de reenvío es para nosotros, es decir, para el cliente. El cliente puede acceder a los recursos del servidor a los que no puede acceder por sí mismo según el proxy de reenvío.

El proxy de reenvío es transparente para nosotros y no transparente para el servidor, es decir, el servidor no sabe si recibe un acceso de un proxy o de un cliente real.

proxy inverso

Proxy inverso (Reverse Proxy) significa aceptar la solicitud de conexión en Internet por el servidor proxy, luego reenviar la solicitud al servidor en la red interna y devolver el resultado obtenido del servidor al cliente que solicita la conexión en Internet. En este tiempo, el servidor proxy actúa como un servidor proxy inverso externamente.

El proxy inverso sirve al servidor. El proxy inverso puede ayudar al servidor a recibir solicitudes de los clientes, ayudar al servidor a reenviar solicitudes, equilibrar la carga, etc.

El proxy inverso es transparente para el servidor y no transparente para nosotros, es decir, no sabemos que estamos accediendo a un servidor proxy, pero el servidor sabe que el proxy inverso lo está sirviendo.

Ventajas del proxy inverso:

• Ocultar el servidor real;
• El equilibrio de carga facilita la expansión horizontal de los servicios dinámicos de back-end;
• Separación de estática y dinámica para mejorar la robustez del sistema;

Entonces, ¿qué es la "separación de estática y dinámica"? ¿Qué es el equilibrio de carga?

separación estática y dinámica

La separación dinámica y estática se refiere al método de diseño de arquitectura para separar las páginas estáticas de las páginas dinámicas o las interfaces de contenido estático de las interfaces de contenido dinámico en la arquitectura del servidor web para separar el acceso a diferentes sistemas, lo que impulsa la accesibilidad y la capacidad de mantenimiento de todo el servicio.

En términos generales, es necesario separar los recursos dinámicos de los recursos estáticos.Debido a la alta concurrencia y el almacenamiento en caché de recursos estáticos de Nginx, los recursos estáticos a menudo se implementan en Nginx. Si la solicitud es para un recurso estático, vaya directamente al directorio de recursos estáticos para obtener el recurso. Si es una solicitud para un recurso dinámico, use el principio de proxy inverso para reenviar la solicitud a la aplicación en segundo plano correspondiente para su procesamiento, de ese modo dándose cuenta de la separación de lo dinámico y lo estático.

Después de separar los extremos delantero y trasero, la velocidad de acceso a los recursos estáticos se puede mejorar considerablemente. Incluso si el servicio dinámico no está disponible, el acceso a los recursos estáticos no se verá afectado.

[Beneficios del artículo]: C/C++Linux Server Development/Background Architect [Open Class Learning] (C/C++, Linux, tecnología golang, kernel, Nginx, ZeroMQ, MySQL, Redis, fastdfs, MongoDB, ZK, medios de transmisión, CDN, P2P, K8S, Docker, TCP/IP, Coroutine, DPDK, ffmpeg, preguntas de la entrevista de Dachang, etc.) Si lo necesita, puede hacer clic en 793599096 para unirse al grupo y recibirlo ~

balanceo de carga

En circunstancias normales, el cliente envía múltiples solicitudes al servidor y el servidor procesa las solicitudes, algunas de las cuales pueden necesitar operar algunos recursos como bases de datos, recursos estáticos, etc. Una vez que el servidor termina de procesar, los resultados se devuelven al cliente.

Para el sistema inicial, este modo tiene requisitos funcionales sencillos y aún puede ser competente cuando hay relativamente pocas solicitudes simultáneas y el costo también es bajo. A medida que la cantidad de información continúa creciendo, la cantidad de acceso y datos aumenta rápidamente y la complejidad del negocio del sistema continúa aumentando, este enfoque ya no puede cumplir con los requisitos.Cuando la cantidad de concurrencia es particularmente grande, el servidor es propenso Colapsar.

Obviamente, esto se debe al cuello de botella del rendimiento del servidor Además de apilar máquinas, lo más importante que se debe hacer es equilibrar la carga.

En el caso de un crecimiento explosivo de solicitudes, no importa cuán fuerte sea el rendimiento de una sola máquina, no puede cumplir con los requisitos. En este momento, surgió el concepto de clústeres. Para problemas que no pueden ser resueltos por un solo servidor, Se pueden usar múltiples servidores, y luego las solicitudes se distribuyen a cada servidor. La carga se distribuye a diferentes servidores, que es el equilibrio de carga, y el núcleo es "compartir la presión". Nginx implementa el equilibrio de carga, que generalmente se refiere al reenvío de solicitudes a los clústeres de servidores.

Para dar un ejemplo específico, al tomar el metro en la hora pico de la tarde, a menudo habrá un personal del metro en la entrada con una bocina fuerte que diga "Por favor, vaya a la salida B, hay pocas personas en la salida B y los trenes están vacíos". ...". El papel de este personal es el equilibrio de carga.

Nginx implementa una estrategia de equilibrio de carga:

• Estrategia de sondeo: La estrategia adoptada por defecto, todas las solicitudes de los clientes son sondeadas y asignadas al servidor. Esta estrategia puede funcionar normalmente, pero si uno de los servidores está bajo demasiada presión y hay un retraso, afectará a todos los usuarios asignados a este servidor.
• Estrategia de número mínimo de conexiones: prioriza las solicitudes a servidores con menos presión, lo que puede equilibrar la longitud de cada cola y evitar agregar más solicitudes a servidores con alta presión.
• Política de tiempo de respuesta más rápido: dé prioridad al servidor con el tiempo de respuesta más corto.
• Estrategia de vinculación de ip de cliente: las solicitudes de la misma ip siempre se asignan a un solo servidor, lo que resuelve de manera efectiva el problema de compartir sesiones en páginas web dinámicas.

Configuración de combate de Nginx

río arriba

Se utiliza para definir la información relevante del servidor ascendente (refiriéndose al servidor de aplicaciones proporcionado por el fondo).

语法：upstream name {
	...
}

上下文：http

示例：
upstream back_end_server{
  server 192.168.100.33:8081
}

Instrucciones disponibles en upstream:

• servidor define la dirección del servidor ascendente;
• la zona define la memoria compartida para los procesos secundarios entre trabajadores;
• keepalive permite conexiones largas a servicios upstream;
• keepalive_requests El número máximo de solicitudes HTTP para una conexión larga;
• keepalive_timeout En la situación inactiva, el período de tiempo de espera de una conexión larga;
• algoritmo de equilibrio de carga hash hash;
• ip_hash es un algoritmo de equilibrio de carga para el cálculo de hash basado en IP;
• algoritmo de balanceo de carga less_conn con el menor número de conexiones;
• algoritmo de equilibrio de carga de tiempo mínimo con el tiempo de respuesta más corto;
• algoritmo de equilibrio de carga aleatorio aleatorio;

servidor

Define la dirección del servidor ascendente.

语法：server address [parameters]

上下文：upstream

parámetros Valores opcionales:

• peso = valor de peso numérico, el valor predeterminado es 1;
• max_conns=número El número máximo de conexiones simultáneas al servidor ascendente;
• fail_timeout=time El tiempo de evaluación cuando el servidor no está disponible;
• max_fails=número de comprobaciones de indisponibilidad del servidor;
• servidor de respaldo de respaldo, solo habilitado cuando otros servidores no están disponibles;
• down indica que el servidor no está disponible durante mucho tiempo y se mantiene fuera de línea;

mantener viva

Limite la cantidad máxima de conexiones largas inactivas entre cada proceso secundario trabajador y el servidor ascendente.

keepalive connections;

上下文：upstream

示例：keepalive 16;

Keepalive_requests

El número máximo de solicitudes HTTP que puede manejar una sola conexión persistente.

语法：keepalive_requests number;

默认值：keepalive_requests 100;

上下文：upstream

mantener con vida el tiempo de espera

El tiempo de espera máximo para conexiones persistentes inactivas.

语法：keepalive_timeout time;

默认值：keepalive_timeout 60s;

上下文：upstream

Ejemplo de configuración

upstream back_end{
	server 127.0.0.1:8081 weight=3 max_conns=1000 fail_timeout=10s max_fails=2;
  keepalive 32;
  keepalive_requests 50;
  keepalive_timeout 30s;
}

proxy_pass

Se utiliza para configurar el servidor proxy.

语法：proxy_pass URL;

上下文：location、if、limit_except

示例：
proxy_pass http://127.0.0.1:8081
proxy_pass http://127.0.0.1:8081/proxy

Directrices para los parámetros de URL:

1. La URL debe comenzar con http o https;
2. Las variables se pueden transportar en la URL;
3. Si hay un URI en la URL afectará directamente la URL enviada a la solicitud ascendente;

Veamos dos usos comunes de URL:

1. proxy_pass http://192.168.100.33:8081 
2. proxy_pass http://192.168.100.33:8081/

La diferencia entre estos dos usos es con / y sin /, y la diferencia entre ellos es bastante grande al configurar el proxy:

• Sin / significa que Nginx no modificará la URL del usuario, sino que la transmitirá directamente al servidor de aplicaciones ascendente;
• Con / significa que Nginx modificará la URL del usuario, y el método de modificación es eliminar la URL después de la ubicación de la URL del usuario;

Uso sin /:

location /bbs/{
  proxy_pass http://127.0.0.1:8080;
}

analizar:

1. URL de solicitud de usuario: /bbs/abc/test.html 
2. La solicitud llega a la URL de Nginx: /bbs/abc/test.html 
3. La solicitud llega a la URL del servidor de aplicaciones ascendente: /bbs/abc/test.html 

Uso con /:

location /bbs/{
  proxy_pass http://127.0.0.1:8080/;
}

analizar:

1. URL de solicitud de usuario: /bbs/abc/test.html 
2. La solicitud llega a la URL de Nginx: /bbs/abc/test.html 
3. La solicitud llega a la URL del servidor de aplicaciones anterior: /abc/test.html 

/bbs no está empalmado, lo que es consistente con la diferencia entre raíz y alias.

Configurar proxy inverso

Aquí, para demostrar más cerca de la realidad, el autor ha preparado dos servidores en la nube, y sus IP públicas son: 121.42.11.34 y 121.5.180.193.

Tomamos el servidor 121.42.11.34 como servidor upstream y lo configuramos de la siguiente manera:

# /etc/nginx/conf.d/proxy.conf
server{
  listen 8080;
  server_name localhost;
  
  location /proxy/ {
    root /usr/share/nginx/html/proxy;
    index index.html;
  }
}

# /usr/share/nginx/html/proxy/index.html
<h1> 121.42.11.34 proxy html </h1>

Vuelva a cargar el archivo de configuración nginx -s reload después de completar la configuración.

Utilice el servidor 121.5.180.193 como servidor proxy y configúrelo de la siguiente manera:

# /etc/nginx/conf.d/proxy.conf
upstream back_end {
  server 121.42.11.34:8080 weight=2 max_conns=1000 fail_timeout=10s max_fails=3;
  keepalive 32;
  keepalive_requests 80;
  keepalive_timeout 20s;
}

server {
  listen 80;
  server_name proxy.lion.club;
  location /proxy {
  	proxy_pass http://back_end/proxy;
  }
}

La máquina local necesita acceder al nombre de dominio proxy.lion.club, por lo que debe configurar los hosts locales, ingresar el archivo de configuración a través del comando: vim /etc/hosts y agregar el siguiente contenido:

121.5.180.193 proxy.lion.club

analizar:

1. Al acceder a proxy.lion.club/proxy, busque 121.42.11.34:8080 a través de la configuración ascendente;
2. Por tanto, la dirección de acceso pasa a ser http://121.42.11.34:8080/proxy;
3. Conéctese al servidor 121.42.11.34 y busque el servidor proporcionado por el puerto 8080;
4. Encuentre el recurso /usr/share/nginx/html/proxy/index.html a través del servidor y finalmente muéstrelo.

Configurar el equilibrio de carga

Lo principal para configurar el balanceo de carga es usar el comando upstream.

Tomamos el servidor 121.42.11.34 como servidor upstream y lo configuramos de la siguiente manera:

server{
  listen 8020;
  location / {
  	return 200 'return 8020 \n';
  }
}

server{
  listen 8030;
  location / {
  	return 200 'return 8030 \n';
  }
}

server{
  listen 8040;
  location / {
  	return 200 'return 8040 \n';
  }
}

Utilice el servidor 121.5.180.193 como servidor proxy y configúrelo de la siguiente manera:

upstream demo_server {
  server 121.42.11.34:8020;
  server 121.42.11.34:8030;
  server 121.42.11.34:8040;
}

server {
  listen 80;
  server_name balance.lion.club;
  
  location /balance/ {
  	proxy_pass http://demo_server;
  }
}

Una vez completada la configuración, reinicie el servidor Nginx. Y configure la relación de mapeo entre ip y nombre de dominio en el cliente que necesita acceder.

# /etc/hosts

121.5.180.193 balance.lion.club

Ejecute el comando curl http://balance.lion.club/balance/ en la máquina cliente:

No es difícil ver que la configuración del balanceo de carga ha tenido efecto, y los servidores ascendentes que se nos distribuyen son diferentes cada vez. Es a través de una estrategia de sondeo simple para la distribución del servidor ascendente.

A continuación, aprendamos sobre otras estrategias de distribución de Nginx.

algoritmo hash

Al especificar una palabra clave como clave hash, se asigna a un servidor ascendente específico según el algoritmo hash. Las palabras clave pueden contener variables y cadenas.

upstream demo_server {
  hash $request_uri;
  server 121.42.11.34:8020;
  server 121.42.11.34:8030;
  server 121.42.11.34:8040;
}

server {
  listen 80;
  server_name balance.lion.club;
  
  location /balance/ {
  	proxy_pass http://demo_server;
  }
}

hash $request_uri significa usar la variable request_uri como el valor clave del hash, siempre que el URI accedido permanezca sin cambios, siempre se distribuirá al mismo servidor.

ip_hash

A juzgar de acuerdo con la solicitud de IP del cliente, mientras la dirección IP permanezca sin cambios, siempre se asignará al mismo host. Puede resolver eficazmente el problema del mantenimiento de la sesión en el servidor de fondo.

upstream demo_server {
  ip_hash;
  server 121.42.11.34:8020;
  server 121.42.11.34:8030;
  server 121.42.11.34:8040;
}

server {
  listen 80;
  server_name balance.lion.club;
  
  location /balance/ {
  	proxy_pass http://demo_server;
  }
}

algoritmo del menor número de conexiones

Cada subproceso de trabajo obtiene la información del servidor back-end leyendo los datos de la memoria compartida. Para seleccionar un servidor con el menor número de conexiones actualmente establecidas para las solicitudes de asignación.

语法：least_conn;

上下文：upstream;

Ejemplo:

upstream demo_server {
  zone test 10M; # zone可以设置共享内存空间的名字和大小
  least_conn;
  server 121.42.11.34:8020;
  server 121.42.11.34:8030;
  server 121.42.11.34:8040;
}

server {
  listen 80;
  server_name balance.lion.club;
  
  location /balance/ {
  	proxy_pass http://demo_server;
  }
}

caché de configuración

El almacenamiento en caché puede mejorar el rendimiento de manera muy efectiva, por lo que, ya sea el cliente (navegador), el servidor proxy (Nginx) o incluso el servidor ascendente, implicará el almacenamiento en caché hasta cierto punto. Se puede ver que el almacenamiento en caché es muy importante en cada enlace. Aprendamos cómo configurar la política de caché en Nginx.

proxy_cache

Almacene algunos recursos a los que se haya accedido antes y se pueda acceder de nuevo, para que los usuarios puedan obtenerlos directamente del servidor proxy, reduciendo así la presión sobre el servidor ascendente y acelerando toda la velocidad de acceso.

语法：proxy_cache zone | off ; # zone 是共享内存的名称

默认值：proxy_cache off;

上下文：http、server、location

proxy_cache_path

Establezca la ruta de almacenamiento del archivo de caché.

语法：proxy_cache_path path [level=levels] ...可选参数省略，下面会详细列举

默认值：proxy_cache_path off

上下文：http

Significado del parámetro:

• ruta La ruta de almacenamiento del archivo de caché;
• El nivel de directorio de la ruta de nivel;
• keys_zone establecer memoria compartida;
• inactivo Si no hay acceso dentro del tiempo especificado, el caché se borrará, el valor predeterminado es 10 minutos;

proxy_cache_key

Establece la clave del archivo de caché.

语法：proxy_cache_key

默认值：proxy_cache_key $scheme$proxy_host$request_uri;

上下文：http、server、location

proxy_cache_valid

Configure qué códigos de estado se pueden almacenar en caché y la duración del caché.

语法：proxy_cache_valid [code...] time;

上下文：http、server、location

配置示例：proxy_cache_valid 200 304 2m;; # 说明对于状态为200和304的缓存文件的缓存时间是2分钟

proxy_no_cache

Define las condiciones para guardar en la memoria caché en consecuencia, si al menos un valor del parámetro de cadena no está vacío y no es igual a "0", la respuesta no se guardará en la memoria caché.

语法：proxy_no_cache string;

上下文：http、server、location

示例：proxy_no_cache $http_pragma    $http_authorization;

proxy_cache_bypass

Define la condición bajo la cual la respuesta no se recuperará de la memoria caché.

语法：proxy_cache_bypass string;

上下文：http、server、location

示例：proxy_cache_bypass $http_pragma    $http_authorization;

variable upstream_cache_status

Almacena información sobre si el caché acierta y se establecerá en la información del encabezado de respuesta, lo cual es muy útil en la depuración.

MISS: 未命中缓存
HIT： 命中缓存
EXPIRED: 缓存过期
STALE: 命中了陈旧缓存
REVALIDDATED: Nginx验证陈旧缓存依然有效
UPDATING: 内容陈旧，但正在更新
BYPASS: X响应从原始服务器获取

Ejemplo de configuración

Tomamos el servidor 121.42.11.34 como servidor upstream y lo configuramos de la siguiente manera:

server {
  listen 1010;
  root /usr/share/nginx/html/1010;
  location / {
  	index index.html;
  }
}

server {
  listen 1020;
  root /usr/share/nginx/html/1020;
  location / {
  	index index.html;
  }
}

Utilice el servidor 121.5.180.193 como servidor proxy y configúrelo de la siguiente manera:

proxy_cache_path /etc/nginx/cache_temp levels=2:2 keys_zone=cache_zone:30m max_size=2g inactive=60m use_temp_path=off;

upstream cache_server{
  server 121.42.11.34:1010;
  server 121.42.11.34:1020;
}

server {
  listen 80;
  server_name cache.lion.club;
  location / {
    proxy_cache cache_zone; # 设置缓存内存，上面配置中已经定义好的
    proxy_cache_valid 200 5m; # 缓存状态为200的请求，缓存时长为5分钟
    proxy_cache_key $request_uri; # 缓存文件的key为请求的URI
    add_header Nginx-Cache-Status $upstream_cache_status # 把缓存状态设置为头部信息，响应给客户端
    proxy_pass http://cache_server; # 代理转发
  }
}

El caché está configurado de esta manera, y podemos encontrar el archivo de caché correspondiente en la ruta /etc/nginx/cache_temp.

Para algunas páginas o datos con requisitos de tiempo real muy altos, no se debe configurar el almacenamiento en caché. Veamos cómo configurar contenido que no se almacena en caché.

...

server {
  listen 80;
  server_name cache.lion.club;
  # URI 中后缀为 .txt 或 .text 的设置变量值为 "no cache"
  if ($request_uri ~ \.(txt|text)$) {
  	set $cache_name "no cache"
  }
  
  location / {
    proxy_no_cache $cache_name; # 判断该变量是否有值，如果有值则不进行缓存，如果没有值则进行缓存
    proxy_cache cache_zone; # 设置缓存内存
    proxy_cache_valid 200 5m; # 缓存状态为200的请求，缓存时长为5分钟
    proxy_cache_key $request_uri; # 缓存文件的key为请求的URI
    add_header Nginx-Cache-Status $upstream_cache_status # 把缓存状态设置为头部信息，响应给客户端
    proxy_pass http://cache_server; # 代理转发
  }
}

HTTPS

Antes de aprender a configurar HTTPS, repasemos brevemente el flujo de trabajo de HTTPS. ¿Cómo se cifra para garantizar la seguridad?

Flujo de trabajo HTTPS

1. El cliente (navegador) visita el sitio web de Baidu en https://www.baidu.com;
2. El servidor de Baidu devuelve el certificado de CA utilizado por HTTPS;
3. El navegador verifica si el certificado de CA es un certificado legítimo;
4. Se pasa la verificación, el certificado es legal, se genera una cadena de números aleatorios y se cifra con la clave pública (proporcionada en el certificado);
5. Envía el número aleatorio encriptado por la clave pública al servidor de Baidu;
6. El servidor de Baidu obtiene el texto cifrado, lo descifra con la clave privada y obtiene el número aleatorio (cifrado de clave pública, descifrado de clave privada y viceversa);
7. El servidor de Baidu cifra el contenido que se enviará al navegador con un número aleatorio y luego lo transmite al navegador;
8. En este momento, el navegador puede usar el número aleatorio para descifrar y obtener el contenido de transmisión real del servidor;

Este es el principio operativo básico de HTTPS, que utiliza cifrado simétrico y cifrado asimétrico para garantizar la seguridad del contenido transmitido.

Para obtener más información sobre HTTPS, puede consultar otro artículo "Aprender el protocolo HTTP" .

configurar certificado

Descargue el archivo comprimido del certificado, hay una carpeta Nginx dentro, copie los archivos xxx.crt y xxx.key en el directorio del servidor y luego configure de la siguiente manera:

server {
  listen 443 ssl http2 default_server;   # SSL 访问端口号为 443
  server_name lion.club;         # 填写绑定证书的域名(我这里是随便写的)
  ssl_certificate /etc/nginx/https/lion.club_bundle.crt;   # 证书地址
  ssl_certificate_key /etc/nginx/https/lion.club.key;      # 私钥地址
  ssl_session_timeout 10m;
  ssl_protocols TLSv1 TLSv1.1 TLSv1.2; # 支持ssl协议版本，默认为后三个，主流版本是[TLSv1.2]
 
  location / {
    root         /usr/share/nginx/html;
    index        index.html index.htm;
  }
}

Configurar CORS entre dominios

Definición de dominio cruzado

La política del mismo origen restringe cómo los documentos o scripts cargados desde el mismo origen pueden interactuar con recursos de otro origen. Este es un importante mecanismo de seguridad para poner en cuarentena archivos potencialmente maliciosos. Las operaciones de lectura entre diferentes fuentes generalmente no están permitidas.

Definición homóloga

Dos páginas tienen el mismo origen si su protocolo, puerto (si se especifica) y nombre de dominio son los mismos.

A continuación se muestra un ejemplo de comparación con la fuente de la URL http://store.company.com/dir/page.html:

http://store.company.com/dir2/other.html 同源
https://store.company.com/secure.html 不同源，协议不同
http://store.company.com:81/dir/etc.html 不同源，端口不同
http://news.company.com/dir/other.html 不同源，主机不同

Las diferentes fuentes tienen las siguientes restricciones:

• En el nivel de datos web, la política del mismo origen impide que los sitios de diferentes fuentes lean datos como cookies, IndexDB y LocalStorage del sitio actual.
• A nivel de DOM, la política del mismo origen restringe las operaciones de lectura y escritura de scripts de JavaScript de diferentes fuentes en el objeto DOM actual.
• A nivel de red, la política del mismo origen restringe el envío de datos del sitio a sitios de diferentes orígenes a través de métodos como XMLHttpRequest.

Nginx resuelve el principio de cross-domain

Por ejemplo:

• El nombre de dominio del servidor front-end es: fe.server.com 
• El nombre de dominio del servicio backend es: dev.server.com 

Ahora, cuando inicie una solicitud a dev.server.com desde fe.server.com, definitivamente habrá un dominio cruzado.

Ahora solo necesitamos iniciar un servidor Nginx, establecer el nombre_del_servidor en fe.server.com y luego establecer la ubicación correspondiente para interceptar solicitudes entre dominios desde el front-end y, finalmente, enviar las solicitudes a dev.server.com. Como la siguiente configuración:

server {
	listen   		 80;
	server_name  fe.server.com;
	location / {
		proxy_pass dev.server.com;
	}
}

Esto puede eludir perfectamente la política del mismo origen del navegador: fe.server.com acceder a fe.server.com de Nginx es un acceso del mismo origen, y la solicitud enviada por Nginx al servidor no activará la política del mismo origen del navegador.

Configurar para habilitar la compresión gzip

GZIP es uno de los tres formatos de compresión HTTP estándar especificados. En la actualidad, la gran mayoría de los sitios web utilizan GZIP para transmitir archivos de recursos como HTML, CSS y JavaScript.

Para los archivos de texto, el efecto de GZiP es muy obvio y el tráfico requerido para la transmisión se reducirá a aproximadamente 1/4~1/3 después de encenderlo.

No todos los navegadores admiten gzip. ¿Cómo saber si el cliente admite gzip? La codificación de aceptación en el encabezado de la solicitud identifica la compatibilidad con la compresión.

Habilitar gzip requiere la compatibilidad tanto del cliente como del servidor. Si el cliente admite el análisis de gzip, siempre que el servidor pueda devolver archivos gzip, se puede habilitar gzip. Podemos habilitar el servidor para admitir gzip a través de la configuración de Nginx. content-encoding:gzip en la siguiente respuesta significa que el servidor ha habilitado la compresión gzip.

# # 默认off，是否开启gzip
gzip on; 
# 要采用 gzip 压缩的 MIME 文件类型，其中 text/html 被系统强制启用；
gzip_types text/plain text/css application/json application/x-javascript text/xml application/xml application/xml+rss text/javascript;

# ---- 以上两个参数开启就可以支持Gzip压缩了 ---- #

# 默认 off，该模块启用后，Nginx 首先检查是否存在请求静态文件的 gz 结尾的文件，如果有则直接返回该 .gz 文件内容；
gzip_static on;

# 默认 off，nginx做为反向代理时启用，用于设置启用或禁用从代理服务器上收到相应内容 gzip 压缩；
gzip_proxied any;

# 用于在响应消息头中添加 Vary：Accept-Encoding，使代理服务器根据请求头中的 Accept-Encoding 识别是否启用 gzip 压缩；
gzip_vary on;

# gzip 压缩比，压缩级别是 1-9，1 压缩级别最低，9 最高，级别越高压缩率越大，压缩时间越长，建议 4-6；
gzip_comp_level 6;

# 获取多少内存用于缓存压缩结果，16 8k 表示以 8k*16 为单位获得；
gzip_buffers 16 8k;

# 允许压缩的页面最小字节数，页面字节数从header头中的 Content-Length 中进行获取。默认值是 0，不管页面多大都压缩。建议设置成大于 1k 的字节数，小于 1k 可能会越压越大；
# gzip_min_length 1k;

# 默认 1.1，启用 gzip 所需的 HTTP 最低版本；
gzip_http_version 1.1;

Configurar proxy de reenvío

Si Internet fuera de la LAN se imagina como un gran grupo de recursos, entonces el cliente en la LAN necesita acceder a Internet a través de un servidor proxy, y este servicio de proxy se denomina proxy de reenvío.

El proxy de reenvío de Nginx implica menos instrucciones, así que pegue el contenido de su archivo de configuración directamente debajo:

...  
server {  
    resolver 192.168.1.1; #指定DNS服务器IP地址  
    listen 8080;  
    location / {  
        proxy_pass http://$http_host$request_uri; #设定代理服务器的协议和地址  
    }  
}  
...  

en:

Se requiere resolución, lo que indica que la 
ubicación del servidor DNS indica que el recurso al que accedió el usuario coincide y se reenvía y procesa. La expresión regular se puede usar para hacer coincidir 
proxy_pass, que indica la dirección que debe 
ser proxy. $http_host indica la parte host del acceso del usuario al recurso. 
$request_uri indica el URI del acceso del usuario al recurso. part. 

Por ejemplo, http://nginx.org/download/nginx-1.6.3.tar.gz, luego $http_host=nginx.org, $request_uri=/download/nginx-1.6.3.tar.gz.

No puede establecer el número de puerto de escucha, nginx escucha el puerto 80 de forma predeterminada, a menos que desee modificar el puerto de escucha, puede usar el campo de escucha para especificar.

Puede verse que para el proxy de reenvío, solo se realiza un reenvío del acceso del usuario y no se realiza ningún otro procesamiento.

Configurar la lista blanca y negra de Nginx

Nginx usa los comandos deny y allow para implementar la configuración de listas blancas y negras, y usa listas blancas y negras para la configuración de seguridad.

#语法
allow address | CIDR | all;
deny address | CIDR | all;

#模块：http/server/location
#参数说明：
#allow：允许访问。
#deny：禁止访问。
#address：具体的ip地址。
#CIDR：ip加掩码形式地址。
#all：所有ip地址。

1. Lista negra

Con esta configuración, las direcciones IP 234, 235 y 236 no pueden acceder al servidor y se mostrará 403 Prohibido, mientras que se puede acceder a otras direcciones IP.

2. Lista blanca

Estrategia de configuración: la lógica de configuración de la lista blanca es configurar el acceso de IP permitido y prohibir el acceso de todas las demás direcciones.

Detalles de configuración: bajo esta configuración, las direcciones IP 234, 235 y 236 pueden acceder al servidor, mientras que las demás direcciones IP no pueden acceder y se muestra 403 Prohibido.

Configurar el acceso no permitido a archivos o carpetas

location ^~ /project/deny.txt {
    alias   /webroot/proj/;
    deny  all;
}

• ^~ /proyecto/ significa aceptar direcciones URL a las que se accede desde el exterior (como navegadores), como www.dominio.com/proyecto;
• ^~ /project/deny.txt significa que esta ubicación lo afecta claramente;
• alias /webroot/proj/ significa resolver el acceso a /project al directorio /webroot/proj;
• denegar todos los medios bloquear cualquier fuente

También puede cambiar deny all para devolver 404, que devolverá 404 en lugar de 403 Forbidden, que es más "engañoso".

Alta disponibilidad de Nginx

Generalmente, Nginx + Keepalived se usa para lograr una alta disponibilidad de Nginx.

Que es Keepalive

Keepalived es un software gratuito y de código abierto escrito en C similar al software de mecanismo de conmutación de capa 3, 4 y 7, que tiene las funciones de los conmutadores de capa 3, capa 4 y capa 7 que solemos decir. Proporciona principalmente funciones de equilibrio de carga (equilibrio de carga) y alta disponibilidad (alta disponibilidad). La implementación del equilibrio de carga debe basarse en el módulo de kernel de servicio virtual (ipvs) de Linux, y la alta disponibilidad es realizar el servicio de conmutación por error entre múltiples máquinas a través del protocolo VRRP. 

Todas las funciones de Keepalived se implementan configurando el archivo keepalived.conf.

apéndice

Optimización de la configuración: NGINX.CONF

• El autor de este artículo:  Baili Qianmu
• Enlace a este artículo:  https://www.cnblogs.com/xfeiyun/p/15877678.html