nginx proxy_pass导致404 Not Found页面

时间：2017-08-13 11:53:38

标签： docker nginx proxy kubernetes

我有一个在安装了nginx的docker ubuntu映像中运行的角度应用程序。我想将此映像部署到Kubernetes并使用nginx代理将所有对/ api的调用重定向到Kubernetes中的后端服务。

我的静态网络资源位于/ var / www / html中，我将以下配置添加到/etc/nginx/conf.d: 

upstream backend-service {
  server backend-service:8080;
}

server {
  listen 80;

  location / {
    try_files $uri $uri/ /index.html;
  }

  location ^~ /api {
    proxy_pass http://backend-service;
  }
}

访问/或/＃/ dashboard上的前端服务会返回我的Angular页面的预期组件，但对/ api / v1 / data的调用仅显示默认的nginx 404 Not Found页面。

我需要修改哪些内容才能将后端调用重定向到后端？

我在ubuntu 16.04上使用nginx 1.10.3 ，我的前端Dockerfile看起来像这样：

FROM ubuntu:16.04

# Install curl, nodejs and nginx
RUN apt-get update && \
  apt-get install -y curl && \
  curl -sL https://deb.nodesource.com/setup_8.x | bash - && \
  apt-get install -y nodejs nginx && \
  rm -rf /var/lib/apt/lists/*

# Create directory
RUN mkdir -p /usr/src/app
WORKDIR /usr/src/app

# Copy and build rest of the app
COPY . /usr/src/app
RUN npm install
RUN node_modules/@angular/cli/bin/ng build --prod
RUN cp -a dist/. /var/www/html

# Configure and start nginx
COPY frontend.conf /etc/nginx/conf.d

EXPOSE 80

CMD ["nginx", "-g", "daemon off;"]

编辑：有关后端服务的信息

后端服务侦听在/ api / v1 / data 上获取和发布请求，并且可以通过名为backend-service的服务在Kubernetes中访问。

Edit2：Nginx access.log

https://gist.github.com/Steffen911/a56e3175bf12e511048d01359a475724 

172.17.0.1 - - [13/Aug/2017:13:11:40 +0000] "GET / HTTP/1.1" 200 380 "-" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_12_6) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/60.0.3112.90 Safari/537.36"
172.17.0.1 - - [13/Aug/2017:13:11:40 +0000] "GET /styles.d41d8cd98f00b204e980.bundle.css HTTP/1.1" 200 0 "http://192.168.99.100:30497/" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_12_6) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/60.0.3112.90 Safari/537.36"
172.17.0.1 - - [13/Aug/2017:13:11:40 +0000] "GET /inline.c9a1a6b995c65c13f605.bundle.js HTTP/1.1" 200 1447 "http://192.168.99.100:30497/" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_12_6) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/60.0.3112.90 Safari/537.36"
172.17.0.1 - - [13/Aug/2017:13:11:40 +0000] "GET /polyfills.117078cae3e3d00fc376.bundle.js HTTP/1.1" 200 97253 "http://192.168.99.100:30497/" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_12_6) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/60.0.3112.90 Safari/537.36"
172.17.0.1 - - [13/Aug/2017:13:11:40 +0000] "GET /main.3e9a37b4dd0f3bf2465f.bundle.js HTTP/1.1" 200 64481 "http://192.168.99.100:30497/" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_12_6) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/60.0.3112.90 Safari/537.36"
172.17.0.1 - - [13/Aug/2017:13:11:40 +0000] "GET /vendor.146173c1a99cc2172a5f.bundle.js HTTP/1.1" 200 661261 "http://192.168.99.100:30497/" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_12_6) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/60.0.3112.90 Safari/537.36"
172.17.0.1 - - [13/Aug/2017:13:11:40 +0000] "GET /api/v1/data/ HTTP/1.1" 404 209 "http://192.168.99.100:30497/" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_12_6) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/60.0.3112.90 Safari/537.36"
172.17.0.1 - - [13/Aug/2017:13:11:40 +0000] "GET /assets/home.jpg HTTP/1.1" 200 2608 "http://192.168.99.100:30497/" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_12_6) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/60.0.3112.90 Safari/537.36"
172.17.0.1 - - [13/Aug/2017:13:11:40 +0000] "GET /assets/busy.gif HTTP/1.1" 200 48552 "http://192.168.99.100:30497/" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_12_6) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/60.0.3112.90 Safari/537.36"
172.17.0.1 - - [13/Aug/2017:13:11:40 +0000] "GET /assets/background_light.png HTTP/1.1" 200 170599 "http://192.168.99.100:30497/" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_12_6) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/60.0.3112.90 Safari/537.36"
172.17.0.1 - - [13/Aug/2017:13:11:40 +0000] "GET /assets/google.svg HTTP/1.1" 200 2232 "http://192.168.99.100:30497/" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_12_6) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/60.0.3112.90 Safari/537.36"
172.17.0.1 - - [13/Aug/2017:13:11:40 +0000] "GET /assets/email.svg HTTP/1.1" 200 1596 "http://192.168.99.100:30497/" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_12_6) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/60.0.3112.90 Safari/537.36"
172.17.0.1 - - [13/Aug/2017:13:11:40 +0000] "GET /favicon.ico HTTP/1.1" 200 198 "http://192.168.99.100:30497/" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_12_6) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/60.0.3112.90 Safari/537.36"
172.17.0.1 - - [13/Aug/2017:13:11:44 +0000] "GET /api/v1/data/ HTTP/1.1" 404 209 "-" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_12_6) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/60.0.3112.90 Safari/537.36"

error.log文件为空。

编辑3：新的nginx版本和其他SO线程

我也试过nginx 1.12.1并且它显示了相同的行为。这个问题的答案也没有帮助：nginx proxy_pass 404 error, don't understand why

编辑4：我上传了一个在GitHub上重现我的问题的最小例子

https://github.com/Steffen911/nginx-sample

2 个答案:

答案 0 :(得分：4)

从nginx的故障排除中看来，你所拥有的nginx配置文件实际上没有任何效果 - 你报告404 Not Found除索引页以外的所有内容都有try_files错误，所有指令都来自{{1}在location /，proxy_pass和return 200 test更具体的location ^~ /api，无效。

因此，问题似乎出现在Dockerfile中 - 似乎大多数其他NGINX + Docker教程删除了默认配置（例如，使用RUN rm /etc/nginx/conf.d/default.conf），而您的文件缺少任何此类删除

事实上，Debian / Ubuntu似乎有一个名为/etc/nginx/sites-available和/etc/nginx/sites-enabled的可疑实用程序的非标准目录，默认情况下必须包含{ {3}}文件具有冒昧的listen 80 default_server，在没有更具体的server_name的情况下，有效地优先于同一端口的任何其他default。

因此，有多个独立的解决方案：

  • 不要使用Debian / Ubuntu提供的基本破解软件包。 我花了很多时间拉着头发试图找出原因我的配置不起作用，只是注意到甚至来自listen的备份文件（如test.conf~也通过Debian的默认include /etc/nginx/sites-enabled/*;包含在Debian中。 启用网站是邪恶的。

    请注意，emacs不会出现此问题，因为它不会尝试在default_server中定义/etc/nginx/conf.d/default.conf，而是执行listen 80;使用server_name localhost;，在大多数情况下自动离开。

    例如，将FROM ubuntu:16.04中的FROM nginx替换为Dockerfile，以使用NGINX官方图片。

  • 如果仍在使用Debian / Ubuntu中的nginx ，请务必在 {{1}中 RUN rm /etc/nginx/sites-enabled/default } 删除Dockerfile default_server。

答案 1 :(得分：2)

  

对/ api / v1 / data的调用仅显示默认的nginx 404 Not Found页面

proxy_pass指令极不可能生成默认的nginx 404 Not Found错误页面。

  • 404可能由上游生成，在这种情况下，如果没有进一步的指令，nginx将简单地从上游传播消息。如果你在404中获得了nginx签名，那么这意味着上游也在运行nginx，可能会让你大吃一惊，揭露出配置的罪魁祸首。

  • 如果404确实是由nginx实际生成的，那么可能是location不匹配的情况。尝试使用return 200 thisisatest;代替proxy_pass来解决问题。

    但是，在您的特定情况下，location ^~ /api {是一个几乎不可能的指令，与/api/v1/data/请求URI不匹配 - 我唯一能想到的是，如果您可能有{{3}在任何其他server指令之外的location配置中，这可能会使所有位置指令无效。您确定try_files完全包含在location /上下文中吗？

相关问题
最新问题