在CentOS上部署.NET应用程序已成为现代企业级开发的主流选择，这得益于.NET Core及后续版本（.NET 6/7/8）的跨平台能力与CentOS在企业环境中的广泛普及，将.NET运行于CentOS不仅能充分利用Linux服务器的稳定性和资源管理优势，还能显著降低基础设施成本，实现这一目标的核心在于构建一个由Nginx作为反向代理、Kestrel作为内部Web服务器、Systemd负责进程管理的生产级架构，并配合SELinux安全策略与性能调优,从而确保应用在高并发场景下的高性能与高可用性。
CentOS与.NET结合的技术优势
在深入部署细节之前，必须明确为何CentOS搭配.NET是构建后端服务的黄金组合，从成本效益分析，CentOS作为RHEL（Red Hat Enterprise Linux）的社区版，免除了商业授权费用，而.NET的跨平台特性使得开发团队无需维护Windows Server环境，大幅降低了运营支出，从性能维度考量，Linux内核在处理网络I/O和文件系统调用时，相比Windows具有更轻量的开销，配合Kestrel服务器的高性能异步I/O模型，.NET应用在Linux上的吞吐量往往优于同等配置的Windows环境，CentOS强大的YUM包管理器和Systemd初始化系统，为.NET应用的自动化部署、依赖管理和守护进程监控提供了原生支持,极大地提升了运维效率。
生产级环境部署架构设计
为了确保应用在CentOS上稳定运行，不能简单地将可执行文件丢到服务器上执行,而需要遵循标准的分层部署架构。
运行环境的安装，在CentOS 7或8及以上版本中，首先需要配置微软的官方软件包仓库，通过rpm Uvh安装微软提供的RPM包配置，随后使用yum install命令安装ASP.NET Core Runtime以及对应的SDK（如果需要在服务器上执行构建），值得注意的是，生产环境通常仅安装Runtime即可,以减少攻击面和磁盘占用。
Web服务器的配置，Kestrel虽然是.NET内置的高性能Web服务器，但它并不是一个功能完备的边缘服务器，缺乏对恶意请求的防御和复杂的路由管理，标准做法是在Kestrel前置部署Nginx作为反向代理，Nginx负责处理静态文件请求、SSL终止（HTTPS加密）、请求缓冲以及Gzip压缩，而将动态请求通过proxy_pass指令转发给后端的Kestrel端口（通常为5000），这种架构不仅发挥了Nginx处理高并发连接的强项,也利用了Kestrel处理动态逻辑的高效性。
进程守护与自启动，在Linux中，直接使用命令行启动应用存在终端关闭后进程终止的风险，专业的解决方案是创建一个Systemd服务单元文件（.service file），在该文件中，配置应用的启动路径、工作目录、重启策略（如Restart=always）以及运行用户，通过systemctl enable和systemctl start命令，即可将.NET应用注册为系统服务，实现开机自启和崩溃自动重启,这是保障服务高可用的关键步骤。
安全加固与SELinux策略
在CentOS上部署应用，安全是不可忽视的一环，CentOS默认启用的SELinux（SecurityEnhanced Linux）提供了强制访问控制（MAC）机制，这往往是导致部署失败（如Nginx无法连接Kestrel端口）的常见原因，专业的运维人员不应直接关闭SELinux,而应正确配置其策略。
当Nginx作为反向代理连接到非标准HTTP端口（如5000）时，SELinux会拦截该连接，解决方案是使用semanage工具开放网络端口类型，或者使用setsebool开启httpd_can_network_connect布尔值，允许HTTP服务发起网络连接，还需严格配置文件权限，确保.NET应用运行账户仅拥有最小必要的读写权限，避免因权限过大导致的安全漏洞，防火墙层面，应使用firewallcmd仅对外开放80（HTTP）和443（HTTPS）端口，内部通信端口（如5000）应严格限制在本地回环接口或内网访问。
性能优化与深度调优
在基础架构之上，针对.NET在Linux上的特性进行深度调优,能进一步挖掘系统潜能。
垃圾回收（GC）的配置。.NET在Linux上默认使用Server GC，适用于多核处理器，对于高并发、大内存的应用，可以通过环境变量COMPlus_GCServer=1显式启用服务器GC，并配置GCHeapCount来限制GC使用的堆数量，以减少CPU争用，合理设置System.GC.Server配置节中的LatencyMode,可以在低延迟场景下优化GC行为。
利用.NET 8引入的Native AOT（预编译）技术，对于启动速度敏感的场景（如Serverless或高频重启的微服务），可以将项目发布为Native AOT版本，这将完全消除JIT编译开销，并将.NET运行时静态链接到可执行文件中，大幅减少内存占用和启动时间，虽然牺牲了部分动态特性,但在特定场景下是极致性能的优选方案。
日志与监控，不应仅依赖控制台输出，应集成Serilog等结构化日志库，将日志输出到文件或Linux的Syslog中，便于后续通过ELK（Elasticsearch, Logstash, Kibana）栈进行分析，启用.NET内置的Health Check中间件，配合Prometheus采集指标，实时监控应用的内存、CPU和请求延迟,实现从被动运维向主动运维的转变。
相关问答
Q1：在CentOS上部署.NET应用时，Nginx报错502 Bad Gateway，最常见的原因是什么？A： 最常见的原因是SELinux策略阻止了Nginx（httpd服务）向后端Kestrel端口发起网络连接，在检查防火墙端口已开放且Kestrel服务正常运行的情况下，可以执行命令setsebool P httpd_can_network_connect 1来允许Nginx进行网络连接，Nginx配置文件中的proxy_pass地址填写错误或Kestrel仅监听了IPv4/IPv6中的某一种协议,也可能导致此错误。
Q2：生产环境中，应该直接上传源码在CentOS上编译，还是上传编译好的发布包？A： 强烈建议上传编译好的发布包，在生产服务器上安装SDK并执行编译不仅增加了服务器的安全风险（暴露了源码和构建工具），还消耗服务器CPU资源，专业的CI/CD流程应是在构建服务器上生成自包含发布或依赖框架的发布文件，然后通过SCP或镜像拉取的方式部署到CentOS,服务器端仅需安装Runtime即可。
如果您在CentOS部署.NET的过程中遇到关于端口权限或性能调优的特定问题，欢迎在评论区留言,我们可以共同探讨具体的配置方案。
