webapi服务器部署

把 WebAPI 部署到服务器上，服务最常见的器部翻车点不是代码写错了，而是服务服务器根本“听不见”你的请求。本机调试一切正常，器部一上服务器就 404 或 502，服务十有八九是器部绑定地址、端口映射或者反向代理这三件事没对齐。服务

先看绑定地址。器部ASP.NET Core 默认只监听 localhost:5000，服务这意味着只有服务器自己能访问，器部外部请求全被挡在门外。服务你得改成 0.0.0.0，器部或者用 Nginx 做反向代理把流量转进来。服务我见过一个团队折腾了一下午，器部最后发现是服务 appsettings.json 里 Kestrel 的 Endpoints 配置写成了 http://127.0.0.1:5000，改成 http://*:5000 后立刻通了。这种问题没有报错日志，只有沉默的拒绝。

Nginx 反向代理是生产环境的标准做法。配置不复杂，但有几个细节容易漏。比如 proxy_set_header Host $host; 这行，不写的话后端拿到的 Host 是 127.0.0.1:5000，生成的回调链接、重定向地址全都会指向 localhost，前端拿到这种 URL 直接懵掉。还有 proxy_set_header X-Forwarded-For 和 X-Forwarded-Proto，不传的话你的 API 永远以为自己在跑 HTTP，哪怕外面套了 HTTPS。我就吃过这个亏——支付回调地址拼出来是 http，第三方平台直接拒了。

进程管理别用 dotnet run 挂后台。那玩意儿一断 SSH 就死，而且没有自动重启。systemd 是 Linux 上最省心的选择。写个 .service 文件，Restart=always，User=www-data，完事。journalctl -u yourapi -f 看日志比翻文本文件舒服多了。Windows Server 上可以用 IIS 配合 AspNetCoreModuleV2，或者干脆用 sc.exe 注册成服务。我偏向 systemd，配置透明，日志集中，重启策略也灵活。

环境变量和配置文件别硬编码在代码里。数据库连接串、JWT 密钥、第三方 API Key，这些走环境变量或者 appsettings.Production.json。有个坑：appsettings.Production.json 默认不会被复制到发布目录，你得在 .csproj 里加 <CopyToOutputDirectory>Always</CopyToOutputDirectory>。或者更干净的做法，全部用环境变量，Docker 部署时直接 -e 传进去。我现在的习惯是本地开发用 user secrets，服务器上全部走环境变量，配置文件里只留非敏感的默认值。

健康检查和日志。加一个 /health 端点，返回数据库连接状态和版本号。Nginx 或者负载均衡器可以定时探活，挂了自动摘掉。日志用 Serilog 写到文件加控制台，控制台输出被 systemd 捕获，文件留着事后排查。别用 Console.WriteLine 打日志，没有级别，没有时间戳，生产环境里就是灾难。

防火墙和 SELinux 是另一个隐形杀手。CentOS 上 SELinux 默认阻止 Nginx 反向代理到本地端口，报 502 但 Nginx 错误日志只写 Permission denied。setsebool -P httpd_can_network_connect 1 一行解决。Ubuntu 的 ufw 相对友好，但别忘了 ufw allow 80,443/tcp。云服务器还有安全组，那层是独立于系统防火墙的，经常有人改了 iptables 忘了改安全组，然后对着 curl localhost 正常、外网超时的现象发呆。

部署完跑一遍冒烟测试。curl -v http://yourdomain/api/values，看响应头、状态码、返回体。再用 ab 或者 wrk 压一下，确认连接数、超时设置合理。Kestrel 默认的 MaxConcurrentConnections 和 KeepAliveTimeout 在生产流量下可能需要调。我一般会把 KeepAliveTimeout 从默认的 130 秒降到 60 秒，配合 Nginx 的 keepalive_timeout，避免连接堆积。

整个链路就是：客户端 → 云安全组 → 系统防火墙 → Nginx → Kestrel → 你的代码。任何一层出问题，表现都是“访问不了”。挨个排查，别跳步。

很赞哦!（8782）