【问题标题】:nginx proxy_pass 404 error, don't understand whynginx proxy_pass 404错误,不明白为什么
【发布时间】:2013-04-15 23:47:42
【问题描述】:

我正在尝试将对 /api 的所有调用传递给我的 web 服务,但我不断收到以下配置的 404。按预期调用 / 返回 index.html。有谁知道为什么?

upstream backend{
    server localhost:8080;
}

 server {

    location /api {
        proxy_pass http://backend;
    }

    location / {
        root /html/dir;
    }
}

更多信息在这里

adept@HogWarts:/etc/nginx/sites-available$ curl -i localhost/api/authentication/check/user/email
HTTP/1.1 404 Not Found
Server: nginx/1.2.1
Date: Mon, 22 Apr 2013 22:49:03 GMT
Content-Length: 0
Connection: keep-alive

adept@HogWarts:/etc/nginx/sites-available$ curl -i localhost:8080/authentication/check/user/email
HTTP/1.1 200 OK
Content-Type: application/json
Date: Mon, 22 Apr 2013 22:49:20 GMT
Transfer-Encoding: chunked

{"user":["false"],"emailAddress":["false"]}

【问题讨论】:

  • 后端服务器的位置是否可用?
  • 是的,直接调用 8080 上的 Web 服务正在按预期工作
  • 是nginx还是响应404的webservice?
  • 我对问题进行了编辑以获取更多信息

标签: nginx


【解决方案1】:

尝试逐步排除故障,以确定可能导致问题的点。以下是一些可能的错误:

Nginx 配置改变了,但 Nginx 没有重新加载它

当您覆盖 nginx.conf 文件但未触发 nginx 重新加载配置时,可能会发生这种情况。可能经常发生在 docker 用户身上。
要重新加载 nginx 配置,在 Nginx 主机中,执行命令:nginx -s reload
使用码头工人:docker exec <container_name> nginx -s reload
参考:Controlling NGINX Processes at Runtime

Nginx 默认配置覆盖了你的配置

当nginx.conf 还包含默认 Nginx 配置并且它意外覆盖了您的配置时,可能会发生这种情况,请仔细检查您的 nginx.conf 是否包含任何默认配置路径。
例如:include /etc/nginx/conf.d/*.conf;,它还将在以下地址加载 nginx 默认配置

如果是这种情况,请从您的 nginx.conf 文件中注释掉(或删除)此 include 配置语句。

验证 Nginx 配置

使用命令nginx -T验证实际应用的配置,这将触发Nginx测试并打印配置,检查配置输出是否符合您的预期结果:
Reference: Nginx commandlines
您应该会看到类似以下的内容

root@22a2e5de75ba:/etc/nginx/conf.d# nginx -T
nginx: the configuration file /etc/nginx/nginx.conf syntax is ok
nginx: configuration file /etc/nginx/nginx.conf test is successful
# configuration file /etc/nginx/nginx.conf:
user  nginx;
worker_processes  auto;

error_log  /var/log/nginx/error.log notice;
pid        /var/run/nginx.pid;


events {
    worker_connections  1024;
}

http {
    server {
        server_name "localhost";
        listen 80;
        location /todo_server/ {
            proxy_pass http://jsonplaceholder.typicode.com;
        }
    }
    # 
    
    include       /etc/nginx/mime.types;
    # default_type  application/octet-stream;
    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;
    sendfile        on;
    #tcp_nopush     on;
    keepalive_timeout  65;
    #gzip  on;
    # include /etc/nginx/conf.d/*.conf;
}

Nginx proxy_pass 配置问题

与此线程中的上一个答案类似
如果您在 URI 末尾指定尾部斜杠 /,这将导致意外的代理映射。
一、查看完成:Nginx proxy_pass document
我将使用来自jsonplaceholder 的API http://jsonplaceholder.typicode.com/todos/ 进行演示(它实际上是为您提供响应以供您测试)

带有斜杠
末尾的斜杠表示此 proxy_pass 指令是使用 URI 指定的。在这种情况下,当请求传递到服务器时,与位置匹配的规范化请求 URI 的部分将被指令中指定的 URI 替换。

示例:使用以下配置(被理解为使用 URI 指定)将导致此映射

location /path1/ {
    proxy_pass http://jsonplaceholder.typicode.com/todos/;  
    # Requesting http://localhost:8080/path1/ will proxy to => http://jsonplaceholder.typicode.com/todos/
    # Requesting http://localhost:8080/path1/1/ will proxy to => http://jsonplaceholder.typicode.com/todos/1
}

location /path2/ {
    proxy_pass http://jsonplaceholder.typicode.com/;
    # Requesting http://localhost:8080/path2/todos/ will proxy to => http://jsonplaceholder.typicode.com/todos/
}

没有斜杠
没有尾部斜杠/,理解为没有URI方案,请求URI在处理原始请求时以客户端发送的相同形式传递给服务器,或者在处理请求时传递完整规范化的请求URI更改了 URI。

location /todos/ {
    proxy_pass http://jsonplaceholder.typicode.com; 
    # Requesting : http://localhost:8080/todos/ will proxy to ==> http://jsonplaceholder.typicode.com/todos/
    # Requesting : http://localhost:8080/todos/1 will proxy to ==> http://jsonplaceholder.typicode.com/todos/1
}

另请参阅来自@dayo 的the completed answer 还有answer by Richard Smith

【讨论】:

    【解决方案2】:

    只是想提醒其他人,你的proxy_pass url后面的斜杠(backend*/*)非常重要!

    如果配置是

    location /api/ {
        proxy_pass http://backend;
    }
    

    如果您访问http://abc.xyz/api/endpoint,您将被定向到http://backend/api/endpoint;

    如果配置是

    location /api/ {
        proxy_pass http://backend/;
    }
    

    如果您访问http://abc.xyz/api/endpoint,您将被引导至 http://backend/endpoint.

    这就是区别。

    更多请参考:Nginx reverse proxy return 404

    【讨论】:

      【解决方案3】:

      请检查您是否从site-enabled 文件夹中删除了default.conf 文件。 如果您在基于 debian 的 ubuntu 系统中,请运行该命令

      sudo rm /etc/nginx/sites-enabled/default
      

      它对我有用。

      【讨论】:

        【解决方案4】:

        由于某种原因,Nginx 中的 proxy_pass 在传递到上游之前会削减标头“Host”,并且默认服务器会捕获请求,甚至 proxy_header_pass 也无济于事,所以我必须明确设置它:

        location / {
            proxy_set_header Host $host;
            proxy_pass  http://backend;
        }
        

        【讨论】:

          【解决方案5】:

          我忘记在 PORT 80 上收听了,已修复。

          nginx 配置的“http”部分,位于:/etc/nginx/nginx.conf,如下:

          http {
              server {
                  listen 192.111.111.11:80;
                  location /path1/ {
                      proxy_pass http://127.0.0.1:3000/path1/
                  }
              }
          }
          

          现在,访问
          http://192.111.111.11/path1/
          会得到访问结果
          http://127.0.0.1:3000/path1/

          注意:
          将上面的 192.111.111.11 替换为您的 IP 地址。
          运行“ifconfig”命令,“inet addr”部分会给出你的IP地址

          【讨论】:

            【解决方案6】:

            这个

            location /api {
                proxy_pass http://backend;
            }
            

            需要这样

            location /api/ {
                proxy_pass http://backend/;
            }
            

            【讨论】:

            • 似乎解决了这个问题,但解释一下这会带来什么不同会很好。
            • 这并不能解决我的问题。事实上,它让事情变得更糟,并在 chrome 中给了我一个 ERR_TOO_MANY_REDIRECTS。
            • 0xAffe - 注意路径和 proxy_pass url 的和处的斜线。如果您错过了其中一个斜线,有时会发生过多的重定向
            • 哇哦。我让它在其他后端没有斜杠的情况下工作,但是这个出于某种原因需要它。
            • Nginx 配置真的很混乱。那么这个斜线到底有什么意义呢?
            猜你喜欢
            • 2023-04-03
            • 1970-01-01
            • 2013-03-19
            • 1970-01-01
            • 2018-04-01
            • 2020-06-15
            • 2023-04-10
            • 1970-01-01
            • 2020-09-04
            相关资源
            最近更新 更多