我们的应用程序在Laravel Forge上的一台服务器上运行,但我们最近不得不添加另一台服务器,所以我们这样做并将它们放在一个新的AWS ELB上,出于可扩展性的目的,我们更喜欢Forge的ELB解决方案。一切正常,但是ELB的健康检查失败,将两个目标标记为不健康。尽管这不会导致任何问题,但我想解决这个问题,这样我就可以使用像Cloudwatch这样的监视器。我登录到一个服务器查看日志,这是我发现的:nginx正在向健康检查请求返回HTTP 444:
/var/log/nginx# tail -f access.log
[20/Jun/2023:23:24:23 +0000] "GET /health-check HTTP/1.1" 444 0 "-" "ELB-HealthChecker/2.0"
字符串
这是我现在的nginx文件:
# FORGE CONFIG (DO NOT REMOVE!)
include forge-conf/mywebsite.com/before/*;
server {
listen 80;
listen [::]:80;
server_name mywebsite.com;
server_tokens off;
root /home/forge/mywebsite.com/current/public;
# FORGE SSL (DO NOT REMOVE!)
# ssl_certificate;
# ssl_certificate_key;
ssl_protocols TLSv1.2 TLSv1.3;
ssl_ciphers ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384;
ssl_prefer_server_ciphers off;
ssl_dhparam /etc/nginx/dhparams.pem;
add_header X-Frame-Options "SAMEORIGIN";
add_header X-XSS-Protection "1; mode=block";
add_header X-Content-Type-Options "nosniff";
index index.html index.htm index.php;
charset utf-8;
# FORGE CONFIG (DO NOT REMOVE!)
include forge-conf/mywebsite.com/server/*;
location / {
try_files $uri $uri/ /index.php?$query_string;
}
location = /favicon.ico { access_log off; log_not_found off; }
location = /robots.txt { access_log off; log_not_found off; }
access_log off;
error_log /var/log/nginx/mywebsite.com-error.log error;
error_page 404 /index.php;
location ~ \.php$ {
fastcgi_split_path_info ^(.+\.php)(/.+)$;
fastcgi_pass unix:/var/run/php/php8.1-fpm.sock;
fastcgi_index index.php;
include fastcgi_params;
}
location ~ /\.(?!well-known).* {
deny all;
}
}
# FORGE CONFIG (DO NOT REMOVE!)
include forge-conf/mywebsite.com/after/*;
型
到目前为止,我已经尝试在nginx文件的开头添加这个,但没有运气:
location /health-check {
access_log off;
return 200;
}
型
还尝试在ELB健康检查中添加444
作为可接受的响应代码,但它不喜欢,我也不喜欢。
1条答案
按热度按时间5jdjgkvh1#
我有同样的问题,但使用DigitalOcean LB。虽然我还没有解决,但我找到了原因。当使用Forge配置服务器时,站点的Nginx配置会自动配置
server_name
以匹配域(或使用“默认”站点时服务器的公共IP)。另一方面,DigitalOceans LB在VPC网络上使用其私有IP连接到服务器。由于该私有IP与您网站的Nginx配置中的
server_name
不匹配,因此它福尔斯到全面的Nginx配置。如果你在你的服务器上查看/etc/nginx/sites-enabled/000-catch-all
的内容,你会看到如下内容:字符串
这就是444错误的来源。我猜这也可能是ELB的问题。
我们可以在catch-all配置中添加健康检查位置块,但感觉不对。主要是因为您必须在所有服务器上复制此操作。但是,这只会修复健康检查。LB上的传入流量仍将使用私有IP将请求委托给服务器,因此这些请求仍将失败。
因此,我们需要确保来自LB的流量与站点的Nginx配置匹配。我尝试将服务器的私有IP设置为
server_name
,但不起作用。你知道吗?