修改Nginx配置接入Let's Encrypt后站点访问报Cloudflare 504错误

三个核心问题叠加导致故障，按影响优先级排序：

• Nginx配置加载失败。错误日志中明确记录emerg级错误：/etc/nginx/sites-enabled/default文件不存在。你在重装、修改Nginx配置部署证书的过程中误删了默认站点配置文件，导致Nginx重载、重启时配置校验不通过，不会加载你编写的新站点规则，只会保留旧的异常进程占用端口。这也是你更换Apache作反向代理依旧失效的核心原因——异常Nginx残留进程一直占着80/443端口，Apache根本无法正常绑定端口提供服务。
• 后端Node服务未正常响应请求。Nginx日志中的upstream timed out错误，说明Nginx转发请求到127.0.0.1:3000时始终拿不到返回结果：要么是你部署证书操作过程中误操作导致Node服务退出，要么是Node服务启动路径变更触发了代码bug——你的代码里视图目录、静态资源目录全用的相对路径（../public/views、public），如果启动Node时的工作目录不是项目原目录，会直接出现文件找不到的错误，导致进程卡死、无法响应请求。
• 公网入站链路存在拦截。你提到直接通过服务器公网IP访问也无响应，说明要么是云服务器安全组、服务器本地ufw/firewalld防火墙在配置证书时被误改，80/443端口的入站规则被删除；要么是Cloudflare回源时连不上源站端口，直接抛出504错误。

按顺序操作，每步验证通过再进下一环：

• 清理异常进程，修复Nginx配置
  先执行systemctl stop nginx apache2停掉所有web服务，再执行lsof -i :80 -i :443 -i :3000查询残留占用端口的进程，用kill -9 进程号全部清理干净。
  处理Nginx配置缺失问题：两种方案二选一，要么把sites-available目录下的default配置软链接回sites-enabled目录；要么直接编辑nginx.conf，注释掉include /etc/nginx/sites-enabled/*;这行，只保留你自己写的站点配置引入路径。改完执行nginx -t校验配置，直到返回syntax is ok、test is successful的结果，再启动Nginx。
• 修复Node.js服务异常
  进入Node项目的根目录，手动执行入口文件启动命令（就是包含app.listen逻辑的那个js文件），看控制台是否报模块缺失、路径找不到的错误，如果能正常打印app is alive日志，再新开终端执行curl http://127.0.0.1:3000，本地测试能拿到正常响应才算服务正常。
  后续如果用pm2、systemd做进程守护，一定要把工作目录配置为项目根目录，避免相对路径解析错误。用Nginx反向代理的场景下，Node保持绑定127.0.0.1即可，不需要改成0.0.0.0对公网暴露，安全性更高。
• 排查公网链路，重新配置证书
  先登录云服务器控制台检查安全组规则，确认入方向放通80、443端口的TCP请求，再检查服务器本地防火墙规则，确认没有拦截公网访问。本地用公网IP访问80端口能正常拿到响应后，再重新执行Let's Encrypt证书签发流程，签完证书后在Nginx配置中新增443端口的SSL监听配置，同时把80端口的请求统一301跳转到HTTPS，所有配置改完都要先执行nginx -t校验通过，再重载Nginx。
• 校验Cloudflare回源配置
  确认Cloudflare控制台的回源端口和Nginx监听端口一致（默认用80/443即可，不要随意改非常规端口）。排查阶段可以先把Cloudflare的代理状态改成「仅DNS」，直接解析源站IP测试访问，等源站服务完全正常后再开启代理加速。

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