letsencrypt - Nginx, try_files proxy y ubicación con nombre con 404 de respaldo

nginx reverse proxy ssl

Question

Tengo un problema extraño que solo afecta a una aplicación local en la que estoy trabajando: otras aplicaciones con este enfoque parecen funcionar bien (Ghost). Esto es de mi configuración de servidor Nginx:

location @node_proxy {
  proxy_set_header        X-Real-IP            $remote_addr;
  proxy_set_header        X-Forwarded-For      $remote_addr;
  proxy_set_header        X-Forwarded-Proto    $scheme;
  proxy_set_header        X-NginX-Proxy        true;
  proxy_set_header        Host                 $host;
  proxy_redirect          off;
  proxy_pass              http://127.0.0.1:5000;
}

location / {
  try_files @node_proxy =404;
}

Como dije, tengo Ghost corriendo de forma idéntica a esto y funciona bien. Sin embargo, para esta configuración, cada solicitud es 404, parece que nunca llega al proxy. Revisé los registros y esto confirma mis sospechas, no hay entradas en los registros de acceso o error.

La aplicación a la que me estoy dirigiendo en esta instancia es simplemente una aplicación de nodo basada en Express simple, por lo que no es nada complejo. Visitando http://127.0.0.1:5000 veo los resultados esperados.

Si cambio mi configuración a:

location / {
  proxy_set_header        X-Real-IP            $remote_addr;
  proxy_set_header        X-Forwarded-For      $remote_addr;
  proxy_set_header        X-Forwarded-Proto    $scheme;
  proxy_set_header        X-NginX-Proxy        true;
  proxy_set_header        Host                 $host;
  proxy_redirect          off;
  proxy_pass              http://127.0.0.1:5000;
}

Funciona como se esperaba, sin embargo, me gustaría utilizar la ubicación indicada para evitar tener que repetir las declaraciones de proxy.

¿Me he perdido algo obvio?

Answer 1

Prueba este tipo de pirateo:

location @root {
    ...
}

location / {
    error_page 418 = @root; return 418; # redirect to @root
}

Parece que es imposible saltar a una ubicación con nombre de una ubicación regular. También puede probar try_files @root @root , sin embargo, Igor Sysoev (autor de nginx) dice que la página de error_page es mejor, ya que utiliza menos recursos.