Asignación de directorios de segundo nivel
En la actualidad, cuando hay muchos escenarios en los que se separan los proyectos front-end y back-end, generalmente hay un puerto para el front-end y un puerto para el back-end.
Por ejemplo, la interfaz es https://example.com/index.html y la interfaz de llamada es https://example.com:4433
Este tipo de implementación es un poco problemática para algunos proyectos pequeños.Por supuesto, también puede optar por utilizar nombres de subdominio u otros nombres de dominio para el acceso entre dominios en el entorno de red pública.
De lo que estamos hablando aquí es del mismo nombre de dominio y el mismo puerto, para que los extremos delantero y trasero puedan acceder al servicio al mismo tiempo.
Dirección de front-end: https://example1.com
Dirección de interfaz: https://example.com
Aquí registro primero el método de proxy inverso que he probado y aprobado, es decir, sin cambiar la configuración original del servidor. Redirigir example.com/api a example.com:4443/ directamente a través del proxy inverso
location ^~ /api/ {
proxy_pass https://example.com:4433/;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
}Vale la pena mencionar que ^~ en la sección de ubicación representa un cierto carácter como coincidencia inicial, y aquí está la regla de URL coincidente que comienza con /api/.
No se puede escribir aquí, porque significa coincidencia regular. Si usa reglas regulares, no puede configurar URI en la sección proxy_pass. El llamado URI es el / detrás del puerto 4433.
Aquí, el nombre de dominio detrás de proxy_pass debe escribirse como https://examle.com:443/;
Si / no está escrito, al acceder a example.com/api/index.php, se redirigirá a example.com:4433/api/index.php. No puede ubicar la ruta raíz del backend, por lo que termina con /.
Redirección de puerto HTTPS no estándar
Si desea que su puerto https no estándar, como 2083, admita el acceso HTTPS de redirección HTTP, consulte la siguiente configuración.
error_page 497 https://$host:2083$request_uri;Si no configura de esta manera, de forma predeterminada, cuando los usuarios no estén seguros del protocolo del sitio web, no podrán acceder a su sitio web HTTPS utilizando el protocolo HTTP.
错误如：La solicitud HTTP simple se envió al puerto HTTPS
HTTP Forced Jump to HTTPS
Daily Para garantizar la seguridad de los visitantes, a menudo necesitamos mantener el acceso HTTPS en todo el sitio, luego puede usar la siguiente configuración.
server {
listen 80 default_server;
server_name example.com;
rewrite ^(.*) https://$server_name$1 permanent;
#上面的rewrite也可以写作
return 301 https://$host$request_uri;
}
server {
listen 443 ssl;
server_name example.com;
}El método es redirigir todos los enlaces HTTP monitoreados por 80 al puerto HTTPS.
La política HSTS mantiene la conexión HTTPS
Al mismo tiempo, también puede obligar al navegador del visitante a seguir usando la conexión HTTPS habilitando la política HSTS, agregue el siguiente código:
- add_header Strict-Transport-Security "max-age=31536000; includeSubDomains;preload" siempre;
- max-age: establezca el uso obligatorio de la conexión HTTPS dentro de la unidad de tiempo (segundos), aquí es 1 año
- includeSubDomains: opcional, todos los subdominios del sitio tienen efecto al mismo tiempo
- precarga: valor opcional, no estándar, utilizado para definir el uso de la "lista de precarga HSTS"
- siempre: opcional, asegúrese de que todas las respuestas envíen este encabezado de respuesta, incluidas varias respuestas de error integradas
Proxy inverso Nginx
Hay muchos escenarios de proxy inverso, como puertos de nombres de dominio unificados front-end y back-end, como equilibrio de carga.
location / {
proxy_pass http://example.com;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
}Configuración completa de parámetros
location / {
proxy_pass http://example.com;
proxy_redirect off;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_next_upstream error timeout invalid_header http_500 http_502 http_503 http_504;
proxy_max_temp_file_size 0;
proxy_connect_timeout 90;
proxy_send_timeout 90;
proxy_read_timeout 90;
proxy_buffer_size 4k;
proxy_buffers 4 32k;
proxy_busy_buffers_size 64k;
proxy_temp_file_write_size 64k;
}Reenvío de puertos
El rendimiento del reenvío de puertos de Nginx también es muy poderoso y se puede usar en escenarios donde las bases de datos de la intranet y otros puertos de servicio están expuestos.
Por ejemplo, el puerto de la base de datos MySQL 192.168.1.2 de la intranet se expone a través del puerto 33062 del servidor donde se encuentra Nginx.
upstream TCP3306 {
hash $remote_addr consistent;
server 192.168.1.2:3306;
}
server {
listen 33062;
proxy_connect_timeout 5s;
proxy_timeout 300s;
proxy_pass TCP3306;
}