Nginx Vhost en conflicto entre sí

Quería usar nginx como proxy inverso para los siguientes subdominios api.example.com y monitor.example.com pero los ajustes de configuration de api.example.com siempre están sobrepasando monitor.example.com . El api vhost tiene limitador de velocidad y no quiero aplicar esa configuration en monitor access_log .. access_log y access_log path tampoco se siguen en la segunda configuration de vhost.

Puedo acceder al contenido de los serveres backend correctamente, pero no entiendo por qué los parameters de configuration de api.example.com también se aplican a monitor.example.com .

api.example.com

 limit_req_zone $binary_remote_addr zone=api:10m rate=90r/m; log_format custom '$remote_addr - $remote_user [$time_local] ' '"$request" $status $body_bytes_sent ' '"$http_referer" "$http_user_agent" "$request_body"'; upstream backend { server web-06:80 max_fails=5 fail_timeout=20s; server web-01:80 max_fails=5 fail_timeout=20s; } server { listen 80; #logging #access_log off; #error_log off; access_log /var/log/nginx/access.log custom; location / { #rate limiting limit_req zone=api burst=1; proxy_pass http://backend; proxy_networkingirect 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_max_temp_file_size 0; client_max_body_size 10m; client_body_buffer_size 128k; 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; } } 

monitor.example.com

 upstream backend2 { server web-06:80 max_fails=5 fail_timeout=20s; server web-01:80 max_fails=5 fail_timeout=20s; } server { listen 80; #logging #access_log off; #error_log off; error_log /var/log/nginx/monitor-error.log; access_log /var/log/nginx/monitor.log; location / { proxy_pass http://backend2; } } 

2 Solutions collect form web for “Nginx Vhost en conflicto entre sí”

Sus dos bloques de server siempre estarán en conflicto de tal manera que el primer bloque de server observado en el file de configuration tomará precedente como bloque de server pnetworkingeterminado para todas las requestes , a less que especifique un server_name adecuado para cada configuration para aplicar a las requestes entrantes para ese nombre de host / . (Esto también se aplica a todas las requestes de las cuales un $HOST solicitado no coincide con ninguna de las configuraciones proporcionadas, y no hay un default_server especificado en las configuraciones). Así es como NGINX maneja las requestes de forma pnetworkingeterminada cuando falta configuration en los bloques de server o con requestes $HOST sin igual.

NGINX comprobará qué nombre de host se solicita. Si $HOST coincide con un bloque de server con un nombre de server que coincide, utilizará esa configuration para determinar qué servir para la request. Sin esta configuration para definir qué bloque de server maneja, el primer bloque de configuration cargado en la configuration se usará de forma pnetworkingeterminada cuando no hay ningún nombre de server coincidente (y no se especificó un server pnetworkingeterminado). ( server_name api.example.com; especificará que el bloque del server coincidirá con api.example.com , mientras que server_name monitor.example.com; especifica el bloque del server que coincide con monitor.example.com )

El proxying inverso apropiado de múltiples backends por varios nombres de host a través de una instancia de NGINX solo puede ser logrado de esta manera, donde cada bloque de proxy para manejar diferentes requestes de host a diferentes backends ha definido individualmente directivas server_name para cada bloque de server .

Sus backends también tendrán diferentes configuraciones – si cada backend sólo sirve para ese host, entonces no es necesario especificar el nombre_server allí; sin embargo, debe especificar el nombre_server en el proxy inverso para asegurarse de que encamina las requestes a través de la dirección correcta config y luego el backend adecuado. (Sin embargo, una configuration similar puede ser necesaria en los backends si pueden servir ambos sitios)

He configurado muchos sistemas en los cuales una instancia de NGINX invierte los proxies a varios backends y sistemas diferentes en una networking, y siempre han necesitado server_name ser definido para funcionar correctamente. Esta es también la misma razón para get una instancia NGINX para servir a muchos sitios web diferentes desde la misma instancia y files de configuration. También mantengo el package nginx en Ubuntu, y este es un problema común que veo traído por la gente allí cuando configuran su NGINX para hacer lo que usted está tratando de hacer.

 http{ ... server { listen 80; server_name api.example.com; #charset koi8-r; access_log logs/api.example.com.access.log combined; location / { proxy_set_header X-Real-IP $remote_addr; proxy_pass http://servername1; root path1; } } server { listen 80; server_name monitor.example.com; access_log logs/monitor.example.com.access.log combined; location / { proxy_set_header X-Real-IP $remote_addr; proxy_pass http://servername2; root path2; } } 

}

  • Nginx inversa proxy a HTTPS upstream recibiendo 502 Bad Gateway?
  • El proxy inverso de Nginx y CouchDB no funciona
  • Apache proxy remoto para un proxy inverso SNI desajuste
  • manipulación de 404s en nginx en lugar de server ascendente
  • Configurar el proxy de revers en IIS 8.5 y Windows 2012 R2 no funciona correctamente en algunos casos
  • ¿Cómo puedo get Nginx para pasar authentication a IIS como un proxy inverso?
  • ¿Cómo puedo acceder a Webmin sin un puerto?
  • Problemas al establecer una cookie de una máquina proxied por nginx
  • ARR Reverse Proxy y varios sitios como subdirectorys con IIS 7.5
  • Apache proxy inverso de un host virtual a dos Tomcats
  • varios serveres físicos detrás de NAT con un IP
  • El linux y los temas del servidor de Windows, como ubuntu, centos, apache, nginx, debian y consejos de red.