¿Cómo servir contenido estático con múltiples sitios web/patos en Nginx?

Question

He estado siguiendo este artículo tratando de albergar múltiples sitios web en la misma máquina utilizando IIS y Nginx. Sobre la base de lo dispuesto en el artículo I, produjeron lo siguiente nginx.conf: http { server { listen 80; server_name localhost; keepalive_timeout 1; gzip_types text/css text/plain text/xml application/xml application/javascript application/x-javascript text/javascript application/json text/x-json; gzip_proxied no-store no-cache private expired auth; gzip_disable  MSIE [1-6] . ; # new website location /bacon/ { proxy_pass http://127.0.0.1:1500/; proxy_http_version 1.1; gzip_static on; } # old website location / { proxy_pass http://127.0.0.1:8881; proxy_http_version 1.1; gzip_static on; } } } Mi old website está funcionando bien. Pero cuando intento acceder a mi new website Tengo los siguientes errores: Note que mi new website funciona bien si se le pide a trough http://127.0.0.1:1500/. ¿Qué estoy perdiendo aquí?

cyberjedi · Accepted Answer

Reescribir Url proxy_pass directiva funciona sólo con la solicitud http y http redirect en respuesta. Eso significa que si http://127.0.0.1:1500/; responderá con HTTP 30x Ubicación: http://127.0.0.1:1500/aaaa/, nginx lo reescribirá a http://localhost/bacon/aaaaa/. Pero esta dosis de reescritura no toca el cuerpo de respuesta. Cualquier enlace en el HTML de respuesta será el mismo - , so no /bacon/ part here. Para arreglarlo hay dos maneras. Primero - edita tu aplicación. Reemplazar todos los enlaces con /beacon/ prefijo o uso URL relativa y añadir en cabeza en cada archivo. Si la edición de archivo no es posible, puede reescribir el cuerpo con ngx_http_sub_module. Hay doc del módulo http://nginx.org/en/docs/http/ngx_http_sub_module.html De esta manera necesitas añadir sub_filter para todas las construcciones html donde se utiliza enlace. Por ejemplo sub_filter_once off; sub_filter ' href= /' ' href= /bacon/'; sub_filter ' src= /' ' src= /bacon/'; Solo necesito tener cuidado. Deberías poner todo sub_filter a /bacon/ ubicación. Configurar aplicación backend es muy preferido pero a veces sólo sub_filter puede ayudar. También hay tercer método, pero se puede utilizar en algunos casos raros. Si /flutter_servivce_worker.js no existe en 127.0.0.1:8881 backend, puede agregar la ubicación personalizada para este archivo y proxy_pass a bacon backend: location = /flutter_servivce_worker.js { proxy_pass http://127.0.0.1:1500; } Seguro que este método puede ayudar en casos muy limitados cuando usted está perdiendo sólo unos pocos archivos y no utilizar ningún enlace.

debugdragon · Answer

Creo que tu primera aplicación está cargando main.dart.js del segundo (en el camino raíz) porque se olvidó de cambiar a dentro index.html archivo.

bughunterx · Answer

No hay nada que ver con NGINX.

Para el nuevo sitio, la solicitud está bien enrutada y HTML se carga en el navegador. Pero las referencias de archivo estático dependientes de la aplicación siguen apuntando a la ruta de ubicación base '/'.

Basado en el idioma de frontend elegido, la ruta base debe cambiarse a /bacon

(o)

crear una carpeta con el tocino de nombre y colocar los archivos construidos en esa carpeta y servir el contenido estático simplemente utilizando Nginx con configuración de servidor web

Respondida el Dec 17, 2020 a las 17:59 - por bughunterx

codesculptor · Answer

¿Lo has intentado? # new website location /new/ { proxy_pass http://127.0.0.1:1500; proxy_http_version 1.1; gzip_static on; } # old website location /old/ { proxy_pass http://127.0.0.1:8881; proxy_http_version 1.1; gzip_static on; }

Gpt · Answer

El problema que estás experimentando con tu configuración de Nginx podría deberse a un detalle en la forma en que estás configurando la ubicación del nuevo sitio web en tu archivo nginx.conf.

En la configuración que proporcionaste, estás utilizando la ubicación /bacon/ para el nuevo sitio web, sin embargo, estás redirigiendo el proxy_pass a http://127.0.0.1:1500/. Esto significa que cuando accedes a http://localhost/bacon/ en tu navegador, Nginx está tratando de acceder a http://127.0.0.1:1500/bacon/ en lugar de simplemente http://127.0.0.1:1500/ como esperas.

Para corregir esto, debes cambiar la configuración de la ubicación /bacon/ de la siguiente manera:

nginx
new website         location /bacon/ {
    proxy_pass          http://127.0.0.1:1500/;
    proxy_http_version  1.1;
    gzip_static         on;
}

Con esta modificación, cuando accedas a http://localhost/bacon/ en tu navegador, Nginx ahora pas

Respondida el Dec 18, 2020 a las 17:45 - por Gpt

Gemini · Answer

El problema es que Nginx está configurado para comprimir contenido estático, pero el proxy inverso a http://127.0.0.1:1500/ no admite la compresión GZIP.

Para resolver este problema, puedes deshabilitar la compresión GZIP para el proxy inverso a tu nuevo sitio web agregando la siguiente configuración a tu bloque de ubicación:

nginx
location /bacon/ {
    proxy_pass          http://127.0.0.1:1500/;
    proxy_http_version  1.1;
    gzip_static         off;
}

Esto deshabilitará la compresión GZIP para el proxy inverso a tu nuevo sitio web, asegurándose de que el contenido estático se sirva sin compresión y resolviendo el error que estás viendo.

Respondida el Dec 18, 2020 a las 17:52 - por Gemini

¿Cómo servir contenido estático con múltiples sitios web/patos en Nginx?

6 Respuestas:

new website