现象：
今天测试搭建一个简单的负载均衡，一台Nginx机器为两台web机器提供反向代理，但是很意外两台都报了404错误，很简单的配置，貌似看不出错误，排查测试了很久之后，发现是URL路径拼接的问题。
三台机器的配置
lb
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
| upstream static{
server web01 weight=1;
server web02 weight=1;
}
server{
listen 80;
server_name blog;
set_real_ip_from 192.168.110.0/24;
location /static/{
proxy_pass http://static;
proxy_set_header Host $http_host;
}
}
|
web01&&web02
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
| server {
listen 80;
server_name blog;
location / {
root /data/blog;
index index.html;
}
location /nginx_status {
stub_status;
}
location /php_status {
fastcgi_pass 127.0.0.1:9000;
fastcgi_index index.php;
fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
include fastcgi_params;
}
location ~ \.php$ {
fastcgi_pass 127.0.0.1:9000;
fastcgi_index index.php;
fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
include fastcgi_params;
}
}
|
原因：
问题出在lb机器的配置文件proxy_pass http://static;一句。
本质上，web机器接收到的请求URL是lb机器转发的proxy_pass拼接上请求的资源名(目录及文件名)。所以，未修改之前，请求的URL是http://static index.html，所以出错的这句应该改为proxy_pass http://static/;，就是多加了一个斜杠。改完之后果然访问恢复了正常。
拓展：
那么很容易联想到另一个问题，既然是缺了一个斜杠，让index.html前面加一个斜杠应该也可以拼接出正确的URL啊，所以，我将lb的配置改回了原来的样子，将web机器的关于首页的配置改为/index.html，重启，确实也能解决问题，这让我确信了就是URL路径拼接的问题。
但是在生产环境中只能改lb机器的配置，如果采用第二种方式，用户请求的URL中指定了资源名，仍然是没办法拼接的，因为第二种方法只对首页文件生效。
