网站首次加载连接被拒绝刷新后正常，Django/Nginx/Gunicorn/AWS环境该如何排查？

1. 服务启动时序问题（最高概率） #

• 确认systemd服务的启动顺序：检查Nginx和Gunicorn的service配置文件，是否配置了正确的启动依赖。默认如果两个服务没有设置依赖顺序，系统启动时Nginx可能先于Gunicorn完成启动，首次请求到达时Nginx找不到上游Gunicorn服务，直接返回连接拒绝，等Gunicorn完全启动后刷新即可正常访问。
  • 排查命令：查看Gunicorn的service配置/etc/systemd/system/gunicorn.service是否设置After=network.target，Nginx的service配置是否设置After=gunicorn.service
  • 验证方法：重启服务器后，立刻执行ss -tulnp | grep gunicorn和ss -tulnp | grep nginx，确认两个服务的端口监听先后顺序
• 检查Gunicorn的启动耗时：如果Django应用启动时存在大量初始化逻辑（比如静态资源预加载、数据库连接池初始化、第三方SDK调用），会导致Gunicorn worker长时间处于未就绪状态，启动阶段的请求直接被拒绝

2. Nginx 配置问题 #

• 检查上游服务配置：查看Nginx配置中upstream块是否配置了合理的重试机制、超时时间，未配置重试的情况下首次请求连接Gunicorn失败会直接返回错误给客户端
  • 参考合理配置：可以给upstream添加max_fails=1 fail_timeout=5s参数，proxy_pass相关配置添加proxy_connect_timeout 10s; proxy_next_upstream error timeout invalid_header;
• 检查Nginx的启动状态：查看Nginx错误日志/var/log/nginx/error.log，是否存在启动阶段连接上游失败的报错记录，报错关键字通常为connect() failed (111: Connection refused) while connecting to upstream

3. Gunicorn 配置问题 #

• 检查worker进程配置：如果worker数量设置过少，或者worker类配置不合理（比如同步worker处理慢请求时阻塞），首次请求过来时worker被占满会直接拒绝连接
• 检查绑定地址配置：确认Gunicorn绑定的是正确的地址（比如127.0.0.1还是0.0.0.0），和Nginx配置中proxy_pass指向的地址完全一致，避免启动时地址绑定延迟导致的临时连接失败

4. 系统及AWS环境问题 #

• 检查Ubuntu UFW防火墙规则加载状态：部分情况下UFW服务启动慢于Nginx，启动阶段80/443端口的放行规则还未生效，首次请求被防火墙拦截，规则加载完成后访问恢复正常
• 检查AWS安全组和网络ACL配置：确认安全组没有配置基于连接数的临时限制规则，EC2实例的网络接口初始化是否存在延迟
• 查看系统日志/var/log/syslog，检查启动阶段是否存在端口冲突、资源不足（内存/CPU不够）导致的服务启动失败/延迟问题

内容的提问来源于stack exchange，提问作者Gene9y