企业官网建设流程全解析

1. 为什么在VSCode里跑ASP.NET Core不是“装个插件点一下就完事”

很多人第一次想用VSCode写C# Web项目，搜到的教程开头都是：“安装C#扩展、.NET SDK，然后Ctrl+Shift+P输入‘.NET: Create Project’——搞定！”
结果一执行，弹出一堆选项：Console、ClassLib、Web、WebAPI、MVC……选哪个？选完生成一堆文件夹，Program.cs里只有几行代码，Startup.cs不见了，Program.cs里又突然冒出builder.Services.AddControllersWithViews()和app.MapControllerRoute()——这跟以前Visual Studio里拖控件、双击打开cshtml改页面的体验完全对不上号。更别说运行起来后浏览器打不开localhost:5000，控制台报错“Unable to start Kestrel”，或者访问/api/values返回404，连最基础的Hello World都卡在路由配置上。

这不是你手残，是VSCode+C#+ASP.NET Core这套组合，本质上是一套命令行驱动、约定优于配置、高度模块化的开发流。它不隐藏底层，也不替你做决策；它把选择权交给你，但前提是——你得知道每个选项背后意味着什么。比如：

• dotnet new mvc和dotnet new webapi生成的项目结构差异，不只是文件名不同，而是默认注册的服务、中间件、路由策略、甚至默认启用的跨域（CORS）行为都完全不同；
• VSCode里按F5调试，背后其实是启动了一个dotnet watch run进程，而这个进程依赖于.csproj里<TargetFramework>和<OutputType>的精确配置，哪怕多一个空格，都会导致“无法找到可执行入口点”；
• launch.json里的"program"路径写成"bin/Debug/net8.0/MyApp.dll"还是"bin/Debug/net8.0/MyApp.dll"，看着一样，但在WSL或macOS下大小写敏感，直接导致调试器找不到程序集；
• appsettings.Development.json里加了一行"Logging": { "LogLevel": { "Default": "Debug" } }，你以为只是多打几行日志，结果Kestrel监听端口从5000变成5001，因为开发环境默认启用了HTTPS重定向，而你没配证书——浏览器直接报ERR_CONNECTION_REFUSED。

我去年带三个实习生从零搭内部管理后台，前两周全卡在“VSCode里怎么让MVC页面显示出来”。不是他们不会写HTML，是根本不知道ViewEngine是怎么根据控制器方法名去匹配Views/Home/Index.cshtml的，也不知道_Layout.cshtml里的@RenderBody()到底被谁调用、什么时候调用。最后发现，问题不在代码，而在他们以为“运行项目=启动服务器”，其实真正的起点是理解ASP.NET Core的请求生命周期：从Kestrel接收HTTP请求，到中间件管道（Middleware Pipeline）逐层处理，再到路由匹配控制器动作，最后由视图引擎渲染HTML——每一步都在Program.cs里明确定义，而VSCode只是帮你把这段定义编译、启动、调试。

所以这篇不是“手把手教你点哪里”，而是带你拆开这个黑盒：为什么VSCode能跑C# Web项目？它依赖什么？哪些环节最容易出错？出错了怎么一层层往下挖？接下来的内容，全部基于真实踩坑记录——包括我在CI/CD流水线里因dotnet publish --configuration Release漏掉--self-contained false导致Linux容器启动失败，也包括客户现场因app.UseStaticFiles()没放在app.UseRouting()之后导致CSS全404的凌晨三点电话。

2. 环境基石：不是“装SDK就行”，而是三件套必须严丝合缝

VSCode本身只是个编辑器，它跑C# Web项目的底气，全靠背后三件套：.NET SDK、C#扩展、终端命令行工具链。这三者不是简单安装就能联动，而是存在严格的版本兼容矩阵和初始化顺序。我见过太多人反复重装，问题却始终存在，根源就在没理清这三者的依赖关系。

2.1 .NET SDK：版本不是越新越好，而是要与项目目标框架对齐

.NET SDK不是单个软件，而是一个包含编译器（Roslyn）、运行时（Runtime）、CLI工具（dotnet CLI）的集合体。关键点在于：你用dotnet new创建的项目目标框架（如net8.0），必须有对应版本的SDK来编译和运行。但现实是，很多人电脑上同时装了6.0、7.0、8.0三个SDK，结果VSCode默认调用的是最早装的那个——因为dotnet --list-sdks输出的第一行，就是CLI默认使用的版本。

验证方式很简单，在VSCode集成终端里执行：

dotnet --list-sdks # 输出示例： # 6.0.400 [/usr/share/dotnet/sdk] # 7.0.400 [/usr/share/dotnet/sdk] # 8.0.100 [/usr/share/dotnet/sdk]

此时dotnet new mvc --framework net8.0会成功，但如果你用dotnet run运行一个目标框架为net6.0的旧项目，它会自动降级使用6.0 SDK；可一旦你删掉了6.0 SDK，哪怕8.0 SDK再新，也会报错：“The project was restored using Microsoft.NETCore.App version 6.0.0, but with current version 8.0.0”。

我的实操建议是：永远用global.json锁定项目所需SDK版本。在项目根目录新建global.json：

{ "sdk": { "version": "8.0.100", "rollForward": "disable" } }

rollForward: "disable"是关键——它禁止SDK自动升级到更高补丁版本（如8.0.101），避免因小版本差异导致的微妙行为变化。这个文件就像项目的“SDK身份证”，VSCode的C#扩展和dotnet CLI都会优先读取它，而不是系统全局默认版本。

提示：global.json必须放在解决方案根目录（即包含.sln或首个.csproj的目录），且不能嵌套。如果项目结构是src/MyApp/MyApp.csproj，global.json就得放在src/目录下，否则无效。

2.2 C#扩展：不是装了就完事，而是要确认Language Server已就绪

VSCode的C#扩展（由OmniSharp或官方.NET Dev Kit提供）本质是个语言服务器（Language Server Protocol, LSP）。它负责代码补全、跳转定义、错误检查——但这些功能的前提是：LSP进程必须成功加载项目，并解析所有.csproj引用。

常见失效场景：

• 项目刚创建完，VSCode右下角显示“Loading C# dependencies…”持续两分钟以上；
• 按F12跳转到ControllerBase类，提示“Definition not found”；
• Program.cs里builder.Services.AddControllersWithViews()下划红线，但dotnet build却成功。

根本原因通常是：项目未正确还原（restore）或LSP缓存损坏。解决步骤必须严格按顺序：

1. 在VSCode集成终端中，cd到项目根目录（含.csproj的目录）；
2. 执行dotnet restore——这是强制触发NuGet包下载和项目依赖解析，比VSCode自动触发更可靠；
3. 关闭VSCode，删除项目根目录下的.vscode/文件夹（清除VSCode专属配置缓存）；
4. 重新打开VSCode，等待右下角状态栏出现“C# (powered by OmniSharp)”且无加载提示。

注意：不要依赖VSCode右键菜单里的“Restore NuGet Packages”，它有时会静默失败。dotnet restore命令的输出是唯一可信依据——成功时最后一行是“Restore completed in X.XX sec for /path/to/MyApp.csproj”。

2.3 终端与Shell：Windows PowerShell vs WSL Bash，路径分隔符是隐形炸弹

VSCode的集成终端（Terminal）默认使用系统Shell。在Windows上，如果你用PowerShell，路径写法是.\MyApp.csproj；但如果你启用了WSL并设为默认终端，路径就是./MyApp.csproj。问题在于：.csproj文件里的<PackageReference>和<ProjectReference>路径，以及launch.json里的"program"字段，对路径分隔符极其敏感。

典型错误：

• 在WSL终端里执行dotnet run成功，但VSCode按F5调试失败，报错“Could not find file '/home/user/MyApp/bin/Debug/net8.0/MyApp.dll'”；
• 原因是launch.json里写的"program": "${workspaceFolder}/bin/Debug/net8.0/MyApp.dll"，在WSL里/bin是系统目录，而实际DLL在/home/user/MyApp/bin/...——VSCode变量${workspaceFolder}在WSL下解析为/home/user/MyApp，但开发者误以为它等同于Windows的C:\Users\Name\MyApp。

我的经验是：永远用/作为路径分隔符，且在launch.json中用${workspaceFolder}而非硬编码路径。VSCode会自动将/转换为当前Shell的正确分隔符（Windows用\，Linux/macOS用/）。同时，在tasks.json里定义构建任务时，明确指定Shell：

{ "version": "2.0.0", "tasks": [ { "label": "build", "command": "dotnet", "args": ["build", "${file}"], "type": "shell", "group": "build", "presentation": { "echo": true, "reveal": "silent", "focus": false, "panel": "shared", "showReuseMessage": true, "clear": false }, "problemMatcher": "$msCompile", "windows": { "options": { "shell": { "executable": "powershell.exe", "args": ["-NoProfile", "-ExecutionPolicy", "Bypass", "-Command"] } } }, "linux": { "options": { "shell": { "executable": "/bin/bash", "args": ["-c"] } } } } ] }

这样，无论你在哪个平台，构建任务都调用正确的Shell，避免路径解析歧义。

3. 项目创建实战：从命令行到VSCode，每一步都藏着关键开关

VSCode里创建ASP.NET Core项目，表面看是Ctrl+Shift+P → “.NET: Create Project”，但背后调用的全是dotnet new命令。而dotnet new的每一个参数，都决定了项目骨架的基因。忽略它们，等于给自己埋雷。

3.1dotnet new模板选择：MVC与WebAPI的本质差异

先看核心命令：

# 创建MVC项目（带视图、布局、静态文件支持） dotnet new mvc -n MyApp -f net8.0 # 创建WebAPI项目（纯RESTful接口，无视图引擎） dotnet new webapi -n MyApp -f net8.0 # 创建空项目（仅基础HTTP管道，需手动添加所有服务） dotnet new web -n MyApp -f net8.0

关键区别不在文件数量，而在Program.cs的默认配置：

我曾接手一个客户项目，需求是“做个后台管理页面”，开发用webapi模板创建，结果发现ViewData、@model全报错——因为webapi模板压根没注册Razor视图引擎。强行加AddControllersWithViews()后，又因UseStaticFiles()没启用，CSS和JS全404。最终重构时，第一件事就是删掉整个项目，用dotnet new mvc重建。

实操技巧：创建项目时，务必用-n指定名称（避免空格和特殊字符），用-f明确框架版本。不要省略-f，否则默认用最新SDK的最新LTS版本（如8.0），而你的团队可能还在用6.0。

3.2Program.cs深度解析：从“一行代码”看透整个请求管道

ASP.NET Core 6.0+ 的Program.cs是单文件模型，但它浓缩了整个应用的启动逻辑。以MVC项目为例：

var builder = WebApplication.CreateBuilder(args); // 1. 服务注册：向DI容器注入服务 builder.Services.AddControllersWithViews(); // ← 关键！注册MVC所需所有服务 var app = builder.Build(); // 2. 中间件配置：定义HTTP请求处理管道 if (!app.Environment.IsDevelopment()) { app.UseExceptionHandler("/Error"); // 开发环境外，启用异常处理器 app.UseHsts(); // 启用HSTS安全头 } app.UseHttpsRedirection(); // 强制HTTPS app.UseStaticFiles(); // ← 关键！提供CSS/JS/图片等静态资源 app.UseRouting(); // ← 关键！启用路由系统 app.UseAuthorization(); // 启用授权（若需要） app.MapControllerRoute( // ← 关键！定义MVC路由规则 name: "default", pattern: "{controller=Home}/{action=Index}/{id?}"); app.Run();

这里每一行都是开关：

• AddControllersWithViews()：不仅注册控制器，还注册IViewEngine、IRazorViewEngine、IHtmlHelper等视图相关服务。如果换成AddControllers()，视图功能就没了；
• UseStaticFiles()：必须放在UseRouting()之前，否则路由中间件会拦截所有/css/site.css请求，当成控制器路由去匹配，结果404；
• MapControllerRoute()：{controller=Home}表示默认控制器是HomeController，{action=Index}表示默认动作是Index方法。这意味着访问/会自动调用HomeController.Index()。

WebAPI项目则简化为：

builder.Services.AddControllers(); // 不带Views // ... 其他配置 app.UseRouting(); app.UseAuthorization(); app.MapControllers(); // ← 直接映射所有[ApiController]标记的控制器

MapControllers()会扫描所有标记[ApiController]的类，按[Route("api/[controller]")]属性生成路由，无需手动定义模式。

踩坑实录：某次部署到Linux服务器，首页CSS全白屏。排查发现UseStaticFiles()被误放在UseRouting()之后。修复后，/css/site.css能正常返回200，但/api/values却404了——因为MapControllers()必须在UseRouting()之后，而UseStaticFiles()必须在UseRouting()之前。最终调整顺序：UseStaticFiles()→UseRouting()→UseAuthorization()→MapControllerRoute()/MapControllers()。

3.3launch.json与tasks.json：VSCode调试的命脉所在

VSCode的调试能力，完全依赖.vscode/launch.json和.vscode/tasks.json两个文件。它们不是可有可无的配置，而是调试流程的精确指令集。

标准MVC项目的launch.json：

{ "version": "0.2.0", "configurations": [ { "name": ".NET Core Launch (web)", "type": "coreclr", "request": "launch", "preLaunchTask": "build", // ← 关键！启动前先执行build任务 "program": "${workspaceFolder}/bin/Debug/net8.0/MyApp.dll", // ← 关键！指向编译后的程序集 "args": [], "cwd": "${workspaceFolder}", "stopAtEntry": false, "serverReadyAction": { "action": "openExternally", // ← 关键！检测到Kestrel启动后自动打开浏览器 "pattern": "\\bNow listening on:\\s+(https?://\\S+)" }, "env": { "ASPNETCORE_ENVIRONMENT": "Development" }, "sourceFileMap": { "/Views": "${workspaceFolder}/Views" } } ] }

其中三个致命细节：

• "preLaunchTask": "build"：必须与tasks.json中定义的"label": "build"完全一致，否则调试前不编译，运行的是旧代码；
• "program"路径：必须指向bin/Debug/.../MyApp.dll，不是obj/目录，也不是.csproj文件；
• "serverReadyAction"的pattern：正则表达式"Now listening on:\\s+(https?://\\S+)"用于捕获Kestrel启动日志中的URL。如果项目日志格式被修改（如加了自定义前缀），这个正则就会失效，浏览器不会自动打开。

tasks.json的构建任务：

{ "version": "2.0.0", "tasks": [ { "label": "build", "command": "dotnet", "args": [ "build", "${file}", "/property:GenerateFullPaths=true", "/consoleloggerparameters:NoSummary" ], "type": "process", "problemMatcher": "$msCompile" } ] }

/property:GenerateFullPaths=true确保错误信息里显示完整文件路径，方便VSCode定位；/consoleloggerparameters:NoSummary去掉冗余的“生成成功”总结行，让错误日志更清晰。

经验技巧：当F5调试无反应时，先检查终端是否报错“Failed to launch debug adapter”。90%的情况是launch.json里"program"路径错误，或preLaunchTask名称不匹配。此时打开VSCode命令面板（Ctrl+Shift+P），输入“Tasks: Run Task”，手动运行build任务，看是否有编译错误——这才是最真实的诊断入口。

4. 运行与调试：从“localhost:5000打不开”到精准定位每一毫秒

在VSCode里按F5启动ASP.NET Core项目，表面上只是等待几秒后浏览器自动打开，但背后涉及Kestrel服务器启动、端口绑定、HTTPS证书生成、静态文件缓存等多个环节。任何一个环节卡住，表现都是“页面打不开”，但原因千差万别。

4.1 Kestrel启动失败：端口占用与HTTPS重定向的双重陷阱

最常见的现象：VSCode控制台输出：

info: Microsoft.Hosting.Lifetime[14] Now listening on: https://localhost:5001 info: Microsoft.Hosting.Lifetime[14] Now listening on: http://localhost:5000 info: Microsoft.Hosting.Lifetime[0] Application started. Press Ctrl+C to shut down.

但浏览器访问http://localhost:5000却显示“无法访问此网站”。
根本原因不是端口被占，而是开发环境默认启用了HTTPS重定向。Program.cs里app.UseHttpsRedirection()这行代码，会让所有HTTP请求（5000端口）307重定向到HTTPS（5001端口）。而5001端口需要本地开发证书，如果证书未正确安装或信任，浏览器就会拒绝连接。

验证方法：在浏览器地址栏直接输入https://localhost:5001。如果显示“您的连接不是私密连接”，说明证书问题；如果显示正常页面，说明是HTTP重定向导致。

解决方案分三步：

1. 信任开发证书：在VSCode终端执行dotnet dev-certs https --trust（Windows/macOS）或dotnet dev-certs https --trust --user（Linux）；
2. 禁用HTTPS重定向（仅开发环境）：在Program.cs中，将app.UseHttpsRedirection()包裹在环境判断里：

   if (app.Environment.IsDevelopment()) { // 开发环境不强制HTTPS，方便调试 // app.UseHttpsRedirection(); // ← 注释掉这一行 } else { app.UseHttpsRedirection(); }

3. 指定监听端口：在Properties/launchSettings.json中，修改applicationUrl：

   "profiles": { "MyApp": { "commandName": "Project", "dotnetRunMessages": true, "launchBrowser": true, "applicationUrl": "http://localhost:5000", // ← 只留HTTP "environmentVariables": { "ASPNETCORE_ENVIRONMENT": "Development" } } }

提示：launchSettings.json只在dotnet run或VSCode调试时生效，不影响dotnet publish后的生产部署。生产环境必须启用HTTPS，这是安全底线。

4.2 MVC视图404：不是文件丢了，而是视图查找路径错了

创建HomeController，写好Index()方法，Views/Home/Index.cshtml也写了，但访问/Home/Index却报404。控制台日志显示：

warn: Microsoft.AspNetCore.Mvc.Razor.RazorViewEngine[0] Could not find view 'Index' for controller 'Home' in area ''.

这说明Razor视图引擎根本没找到Index.cshtml文件。原因通常有两个：

路径约定错误：ASP.NET Core的视图查找路径是严格约定的：

• Views/{ControllerName}/{ActionName}.cshtml（如Views/Home/Index.cshtml）
• Views/Shared/{ActionName}.cshtml（如Views/Shared/Error.cshtml）
• Views/Shared/_Layout.cshtml（布局文件）

如果Index.cshtml放在Views/Home/Index/Index.cshtml，或Views/Home/Index.html，都会失败。

Razor编译未启用：在MyApp.csproj中，必须有以下配置：

<Project Sdk="Microsoft.NET.Sdk.Web"> <PropertyGroup> <TargetFramework>net8.0</TargetFramework> <Nullable>enable</Nullable> <ImplicitUsings>enable</ImplicitUsings> </PropertyGroup> <ItemGroup> <PackageReference Include="Microsoft.AspNetCore.Mvc.Razor.RuntimeCompilation" Version="8.0.0" /> </ItemGroup> <ItemGroup> <Content Update="Views/**/*"> <CopyToOutputDirectory>PreserveNewest</CopyToOutputDirectory> </Content> </ItemGroup> </Project>

关键是<Content Update="Views/**/*">——它告诉MSBuild，所有Views目录下的文件都要复制到输出目录（bin/Debug/net8.0/），否则运行时Razor引擎在bin目录下找不到.cshtml文件。

实操验证：运行dotnet publish -c Debug，检查bin/Debug/net8.0/publish/Views/目录是否存在Home/Index.cshtml。如果不存在，就是csproj配置问题。

4.3 API接口404：路由匹配失败的七种可能

WebAPI项目里，[HttpGet] public IActionResult Get()方法写好了，但GET /api/values返回404。排查链路如下：

1. 控制器命名与路由属性：ValuesController类必须有[ApiController]和[Route("api/[controller]")]：

   [ApiController] [Route("api/[controller]")] public class ValuesController : ControllerBase { [HttpGet] public ActionResult<IEnumerable<string>> Get() => new[] { "value1", "value2" }; }

   如果漏了[Route]，默认路由是/Values（无api/前缀），而MapControllers()不会自动加api/。

2. MapControllers()位置：必须在UseRouting()之后，且不能被其他中间件拦截。常见错误是在UseAuthentication()后忘了UseAuthorization()，导致未授权请求被拒绝，返回401而非404。

3. HTTP方法不匹配：[HttpGet]只能响应GET请求。用Postman发POST请求，必然405 Method Not Allowed。

4. 参数绑定失败：[HttpGet("{id}")] public IActionResult Get(int id)，如果URL是/api/values/abc，id无法转换为int，会返回400 Bad Request，而非404。

5. 控制器未继承ControllerBase：必须是ControllerBase或Controller，不能是普通类。

6. Startup.cs残留：如果项目是从旧版迁移，Startup.cs里还有app.UseMvc()，会与Program.cs的MapControllers()冲突，导致路由混乱。

7. Swagger未启用：app.UseEndpoints(endpoints => { endpoints.MapControllers(); });在旧版中有效，但在新WebApplication模型中，必须用app.MapControllers()。

快速诊断法：在Program.cs里临时加一行日志中间件：

app.Use(async (context, next) => { Console.WriteLine($"Request: {context.Request.Method} {context.Request.Path}"); await next(); });

运行后看控制台输出的请求路径，对比MapControllers()注册的路由，立刻定位是否匹配。

5. 生产部署避坑：从VSCode调试到Linux服务器，那些没人告诉你的细节

在VSCode里调试成功的项目，放到Linux服务器上dotnet MyApp.dll一运行就报错：“Failed to bind to address http://[::]:5000: address already in use”。这背后是开发环境与生产环境的根本差异：VSCode调试用的是dotnet watch run，而生产部署必须用dotnet publish+systemd托管。

5.1dotnet publish不是“复制文件”，而是构建独立部署包

dotnet run只在开发机上运行源码，而生产环境需要发布（publish）后的独立文件包。关键命令：

# 发布为框架依赖型（需服务器装.NET Runtime） dotnet publish -c Release -o ./publish # 发布为自包含型（含运行时，体积大但免依赖） dotnet publish -c Release -r linux-x64 --self-contained true -o ./publish

区别在于：

• 框架依赖型（Framework-Dependent Deployment, FDD）：发布包里只有你的DLL和依赖NuGet包，运行时需服务器已安装对应版本的.NET Runtime。体积小（~10MB），但部署前必须确认服务器环境；
• 自包含型（Self-Contained Deployment, SCD）：发布包里包含整个.NET Runtime（~80MB），可直接运行，无需服务器预装。适合环境不可控的场景。

我的选择逻辑：

• 内部服务器统一管理.NET Runtime版本 → 用FDD，节省磁盘空间；
• 客户现场服务器环境未知 → 用SCD，避免因Runtime版本不匹配导致启动失败。

注意：-r linux-x64必须与目标服务器架构一致。x64服务器不能用-r win-x64发布的包，反之亦然。ARM64（如树莓派）需用-r linux-arm64。

5.2systemd服务配置：让ASP.NET Core在后台稳定运行

Linux上不能靠nohup dotnet MyApp.dll &这种野路子。必须用systemd作为进程管理器，实现开机自启、崩溃重启、日志收集。

创建服务文件/etc/systemd/system/myapp.service：

[Unit] Description=My ASP.NET Core App After=network.target [Service] Type=notify User=myuser WorkingDirectory=/home/myuser/myapp ExecStart=/usr/bin/dotnet /home/myuser/myapp/MyApp.dll Restart=always RestartSec=10 KillSignal=SIGINT Environment=ASPNETCORE_ENVIRONMENT=Production Environment=DOTNET_PRINT_TELEMETRY_MESSAGE=false [Install] WantedBy=multi-user.target

关键参数解析：

• Type=notify：要求应用在启动完成时发送READY=1信号给systemd，避免systemd误判启动失败；
• Restart=always：进程退出后总是重启，配合RestartSec=10（间隔10秒）防雪崩；
• Environment=ASPNETCORE_ENVIRONMENT=Production：覆盖开发环境配置，启用生产级日志和错误页；
• KillSignal=SIGINT：优雅关闭信号，让Kestrel有机会完成正在处理的请求。

启用服务：

sudo systemctl daemon-reload sudo systemctl enable myapp.service sudo systemctl start myapp.service sudo systemctl status myapp.service # 查看状态

日志查看：sudo journalctl -u myapp.service -f实时跟踪日志，比tail -f更可靠，因为systemd会自动轮转日志。

5.3 Nginx反向代理：为什么不能直接暴露5000端口

Kestrel是优秀的开发服务器，但不推荐直接暴露在公网。生产环境必须用Nginx（或Apache）作为反向代理，理由有三：

• 安全加固：Nginx处理SSL/TLS终止、DDoS防护、请求限流，Kestrel专注业务逻辑；
• 静态文件卸载：CSS/JS/图片由Nginx直接返回，不经过Kestrel，降低.NET进程负载；
• 端口映射：将https://myapp.com映射到http://localhost:5000，用户无需记住端口号。

Nginx配置示例（/etc/nginx/sites-available/myapp）：

server { listen 443 ssl; server_name myapp.com; ssl_certificate /etc/letsencrypt/live/myapp.com/fullchain.pem; ssl_certificate_key /etc/letsencrypt/live/myapp.com/privkey.pem; location / { proxy_pass http://localhost:5000; proxy_http_version 1.1; proxy_set_header Upgrade $http_upgrade; proxy_set_header Connection keep-alive; 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; } location /static/ { alias /home/myuser/myapp/wwwroot/; expires 1y; add_header Cache-Control "public, immutable"; } }

其中proxy_set_header系列是关键：它把原始请求信息（如真实IP、协议类型）传递给Kestrel，否则HttpContext.Connection.RemoteIpAddress会显示为127.0.0.1，无法做IP限流或地理围栏。

最后检查：sudo nginx -t测试配置语法，sudo systemctl reload nginx重载配置。此时访问https://myapp.com，Nginx会把请求转发给http://localhost:5000的Kestrel，用户无感知。

我在给一家制造企业部署MES系统时，客户坚持用Kestrel直连，结果遭遇一次DDoS攻击，Kestrel进程CPU 100%，整个系统瘫痪。切换Nginx后，通过limit_req指令限制每秒请求数，攻击流量被Nginx拦截，Kestrel毫发无伤。这件事让我彻底明白：VSCode里调试的便利性，绝不能牺牲生产环境的健壮性。