用C#复现Invoke-WebRequest行为遇403错误，求差异原因

核心差异点 #

1. 默认请求头缺失 #

PowerShell的Invoke-WebRequest会自动添加浏览器风格的默认头，比如User-Agent（类似Chrome的标识），而你写的C#代码完全没设置这个头。SEC服务器的反爬规则会拦截无合理User-Agent的请求，这是403的主要原因。

除此之外，PowerShell还会自动补充其他浏览器常用头，比如Connection、Host的默认值，这些你C#代码里要么没设置，要么处理方式和PowerShell有细微差别。

2. 请求头完整性不足 #

你从Chrome复制的PowerShell代码只保留了三个头，但Chrome实际发送的远不止这些——比如sec-fetch-mode、sec-fetch-dest这类sec-fetch-*系列头，PowerShell可能底层自动带上了，而你的C#代码只加了sec-fetch-site，服务器会校验这些头的完整性，缺失就会拒绝请求。

另外Accept-Encoding字段，PowerShell可能自动补充了deflate、br等编码，你C#代码只写了gzip，虽然这不是403的主因，但也会影响服务器对请求的判断。

3. 底层请求处理逻辑不同 #

• PowerShell的Invoke-WebRequest会自动维护Cookie容器，即使首次请求，服务器返回的Cookie会被自动保存并复用；而你写的C#代码没有配置Cookie容器，部分网站会依赖Cookie标识会话，拒绝无Cookie的请求。
• HttpClient默认的请求管道和PowerShell底层的实现有细微差别，比如重定向处理、证书验证的默认行为，但这对403的影响相对较小。

修复后的C#代码 #

补充缺失的关键请求头即可解决问题，示例代码：

using var client = new HttpClient();
using var request = new HttpRequestMessage(HttpMethod.Get, "https://www.sec.gov/data-research/sec-markets-data/financial-statement-data-sets");

// 必加：模拟Chrome的User-Agent
request.Headers.UserAgent.ParseAdd("Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/120.0.0.0 Safari/537.36");
// 补充完整的Accept-Encoding
request.Headers.Add("Accept-Encoding", "gzip, deflate, br");
// 完整的sec-fetch系列头
request.Headers.Add("sec-fetch-site", "none");
request.Headers.Add("sec-fetch-mode", "navigate");
request.Headers.Add("sec-fetch-dest", "document");
// 原有的Accept头
request.Headers.Add("Accept", "application/signed-exchange");

var response = await client.SendAsync(request);
response.EnsureSuccessStatusCode(); // 验证请求是否成功

隐藏的实现细节 #

• PowerShell的Invoke-WebRequest底层封装了浏览器兼容的请求逻辑，会自动填充大量浏览器常用头，模拟真实用户的请求行为；而HttpClient是更底层的工具，默认不会添加这些“浏览器专属”头，需要开发者手动配置。
• SEC服务器的反爬机制会严格校验请求头的特征，只有符合真实浏览器请求模式的请求才会被允许，任何头信息缺失或不符合规则都会触发403拦截。

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