在香港AMD EPYC 4585PX服务器部署Web业务：反向代理与进程守护如何配置

先确定部署边界

在香港AMD EPYC 4585PX服务器上部署Web业务，较稳妥的生产结构是：Nginx只开放80/443端口，应用进程仅监听本机地址，由systemd负责启动、重启和资源限制。这样可以避免应用端口直接暴露，也能减少“SSH退出后进程消失”“应用异常退出后无人拉起”等问题。

以下示例适用于Ubuntu 24.04 LTS、Nginx和systemd，应用以Node.js为例，监听127.0.0.1:3000。如果使用Python、Java或其他系统版本，需要替换启动命令、运行用户及日志路径，不要直接照搬。

开始前应确认：

域名已解析到香港服务器公网IP；
应用可通过本机端口正常访问；
80和443端口未被其他服务占用；
已安装应用对应的运行环境；
配置修改前保留备份，并准备至少一个可用的旧版本。

cat /etc/os-release
nginx -v
systemctl --version
command -v node
sudo ss -lntp

先让应用脱离SSH会话运行

假设应用位于/srv/webapp/current，入口文件为server.js。生产环境不建议直接使用nohup或终端中的npm start长期运行，因为这类方式缺少明确的启动顺序、失败重启和资源边界。

先创建低权限服务账号；如果账号已经存在，不要重复执行：

id webapp || sudo useradd --system \
  --home /srv/webapp \
  --shell /usr/sbin/nologin \
  webapp

确认该账号能够读取应用目录，但不要为了省事将目录设置为777。随后创建/etc/systemd/system/webapp.service：

[Unit]
Description=Web Application
After=network-online.target
Wants=network-online.target

[Service]
Type=simple
User=webapp
Group=webapp
WorkingDirectory=/srv/webapp/current
Environment=NODE_ENV=production
Environment=HOST=127.0.0.1
Environment=PORT=3000
ExecStart=/usr/bin/node /srv/webapp/current/server.js
Restart=on-failure
RestartSec=5
TimeoutStopSec=30
KillSignal=SIGTERM
NoNewPrivileges=true
PrivateTmp=true
LimitNOFILE=65535

[Install]
WantedBy=multi-user.target

ExecStart必须使用command -v node查到的实际路径。应用密码、数据库连接串等敏感信息应放入权限受控的环境文件，不要直接写入服务文件或代码仓库。

加载并启动服务：

sudo systemctl daemon-reload
sudo systemctl enable --now webapp
sudo systemctl status webapp --no-pager
curl -i http://127.0.0.1:3000/

如果本机请求失败，先不要配置Nginx。应依次检查服务状态、应用日志和监听地址：

sudo journalctl -u webapp -n 100 --no-pager
sudo ss -lntp | grep ':3000'
sudo -u webapp test -r /srv/webapp/current/server.js

应用必须监听127.0.0.1:3000或本机Unix Socket。若监听0.0.0.0:3000，还需要通过安全组或防火墙阻止公网直接访问该端口。

配置Nginx反向代理

安装Nginx前先确认系统没有其他Web服务占用端口：

sudo ss -lntp | grep -E ':(80|443)\b' || true
sudo apt update
sudo apt install nginx

创建/etc/nginx/sites-available/webapp.conf，将example.com替换为实际域名：

server {
    listen 80;
    listen [::]:80;
    server_name example.com www.example.com;

    access_log /var/log/nginx/webapp_access.log;
    error_log /var/log/nginx/webapp_error.log warn;

    client_max_body_size 20m;

    location / {
        proxy_pass http://127.0.0.1:3000;
        proxy_http_version 1.1;

        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;

        proxy_connect_timeout 5s;
        proxy_send_timeout 60s;
        proxy_read_timeout 60s;
    }
}

上传业务如果可能超过20MB，需要同时调整Nginx和应用自身的请求体限制。长轮询、流式响应或WebSocket业务还应单独设置超时和Upgrade头，不能盲目增大所有站点的超时时间。

启用配置前先备份现有文件：

sudo cp -a /etc/nginx /etc/nginx.backup-before-webapp
sudo ln -s /etc/nginx/sites-available/webapp.conf \
  /etc/nginx/sites-enabled/webapp.conf
sudo nginx -t
sudo systemctl reload nginx

只有nginx -t返回成功后才能重载。此时可验证代理链路：

curl -I -H 'Host: example.com' http://127.0.0.1/
curl -I http://example.com/

如果出现502 Bad Gateway，通常表示Nginx已经收到请求，但无法连接应用。重点检查应用是否存活、端口是否一致，以及Nginx错误日志：

sudo tail -n 100 /var/log/nginx/webapp_error.log
sudo systemctl status webapp nginx --no-pager

证书、日志与资源边界

域名解析生效且80端口可从公网访问后，可以使用Certbot申请证书：

sudo apt install certbot python3-certbot-nginx
sudo certbot --nginx -d example.com -d www.example.com
sudo nginx -t
sudo certbot renew --dry-run

证书申请失败时，不要反复提交请求。先检查DNS解析、服务器时间、80端口访问和Nginx的server_name。证书私钥及/etc/letsencrypt目录应纳入加密备份，但不能提交到代码仓库。

Nginx请求日志位于/var/log/nginx/，应用日志则通过journal查看：

sudo journalctl -u webapp --since "30 minutes ago"
sudo journalctl -u webapp -f
sudo tail -f /var/log/nginx/webapp_access.log

AMD官方规格显示，EPYC 4585PX采用Zen 5架构，提供16核心、32线程。该规格有利于安排多进程或多容器并发，但不代表单个应用会自动利用全部核心，也不能直接等同于整机业务性能。进程数量仍应根据应用模型、内存容量和数据库压力确定。

可通过systemd限制单个服务的资源。例如下面的数值只是配置示例，应用前必须结合整机内存和压测结果调整：

[Service]
CPUQuota=400%
MemoryHigh=4G
MemoryMax=5G
TasksMax=512

将其写入服务的override配置后，先确认不会导致正常流量下频繁触发内存限制：

sudo systemctl edit webapp
sudo systemctl daemon-reload
sudo systemctl restart webapp
sudo systemctl show webapp \
  -p CPUQuotaPerSecUSec -p MemoryHigh -p MemoryMax -p TasksMax

重启会造成短暂中断，单实例业务应安排维护窗口；尚未掌握应用峰值内存时，先监控，再设置硬性MemoryMax。

上线验证与失败回滚

正式切换流量前，至少完成以下检查：

systemctl is-active webapp nginx均返回active；
ss -lntp确认公网只开放预期端口，应用端口仅绑定本机；
HTTP能够正确跳转到HTTPS，证书域名和有效期正常；
静态页面、登录、上传、API等核心功能均能完成；
Nginx错误日志和应用日志没有持续新增错误；
重启应用后，systemd能够自动恢复服务；
已备份Nginx配置、证书目录、应用配置和待上线版本；
数据库迁移另有备份和回滚方案，不能只回滚应用代码。

若新版本异常，可将/srv/webapp/current切回已保留的旧版本，再重启应用。执行前先记录当前软链接目标，避免无法恢复：

readlink -f /srv/webapp/current
sudo ln -sfn /srv/webapp/releases/previous /srv/webapp/current
sudo systemctl restart webapp
sudo journalctl -u webapp -n 50 --no-pager

Nginx配置异常时，可从备份目录恢复对应文件，但恢复后仍须先执行sudo nginx -t，确认通过再重载。回滚完成不等于故障结束，还应重新访问核心接口、观察新增日志，并确认代理状态码、应用响应和证书链均已恢复正常。

生产部署反向代理进程守护证书配置故障回滚

上一篇 香港GOLD 6230服务器购买误区：只看CPU型号如何核实内存、磁盘与带宽配置