HttpClient 默认自动处理301/302重定向（最多5次），返回最终响应；若下载内容异常，需检查RequestUri是否变更、StatusCode是否为200，并注意关闭自动重定向时需手动处理Location头及上下文传递。
HttpClient 默认会自动处理 301/302 重定向
只要没显式禁用，
在发起请求时默认跟随重定向（最多 5 次），你拿到的
是最终响应，不是跳转中间页。这是 .NET Core 2.1+ 和 .NET 5+ 的行为，和旧版
或手动发 HTTP 请求不同。
常见错误现象：你发现下载文件内容是 HTML（比如登录页、404 页面），而不是预期的 PDF/ZIP —— 很可能是因为重定向到了一个需要鉴权或已失效的地址，而你没检查
是否和原始 URL 一致。
用
查看实际到达的地址
用
确认是不是
（200），别只看没抛异常就以为成功
如果服务端返回 302 但 Location 是相对路径，
能正确拼接，无需手动处理
需要手动控制重定向时：设置
有些场景必须自己接管跳转逻辑：比如要记录每次跳转的 URL、要对特定跳转做鉴权头注入、或要防止跳到不可信域名。这时得关掉自动跳转，自己解析
头再发新请求。
注意：关闭后，遇到 301/302 你会直接收到该状态码响应，
通常为空，必须读
才能得到目标地址。
创建
实例，设
用这个 handler 构造
，否则默认 handler 仍会跳转
可能是绝对 URL，也可能是相对路径；用
安全解析
手动跳转时记得复用 cookie、认证头等上下文，
不会帮你带过去
下载大文件时重定向带来的流中断风险
自动重定向对小响应没问题，但如果你用
下载大文件，而中间某次跳转失败（如 302 后目标服务器拒绝连接），整个流就断了，且不会抛出明显异常 —— 你可能只拿到截断的文件。
C知道
CSDN推出的一款AI技术问答工具
下载
根本原因：重定向是
底层透明处理的，上层流不感知跳转过程。一旦某次跳转失败，它可能静默返回空流或部分流。
务必校验最终响应的
（如果服务端返回了）是否与文件大小预期一致
下载完成后用
检查实际字节数，不要只依赖“没异常”
对关键下载，建议加一层校验：比如服务端提供
或
，下载完比对哈希
避免在重定向链中跨协议跳转（如 http → https），某些 handler 配置下会静默失败
HttpClient 实例复用与重定向配置的耦合问题
是
的属性，不是
的。很多人改了
实例的配置却无效，是因为复用了全局 handler 或用了静态单例。
典型坑：你在某个方法里 new 了一个
关掉重定向，但项目其他地方用的是另一个共享的
，结果行为不一致，调试时一头雾水。
每个有特殊重定向需求的下载逻辑，应配专属的
+
不要对已创建的
尝试修改 handler 属性（它只读）
.NET 6+ 推荐用
注册不同命名的 client，比如
和
handler 设置
时，重定向间 cookie 会自动携带；但若设为
，每次跳转都丢失上下文
事情说清了就结束。重定向看着简单，真到下载文件这一步，URL 变了、流断了、长度不对、权限丢了——问题往往藏在自动行为和你假设的一致性之间。
HttpClientHttpResponseMessageWebClientResponseMessage.RequestMessage.RequestUriresponse.RequestMessage.RequestUriresponse.StatusCodeOKHttpClientAllowAutoRedirect = falseLocationContentHeaders.LocationHttpClientHandlerAllowAutoRedirect = falseHttpClientLocationnew Uri(response.RequestMessage.RequestUri, locationHeader)HttpClientresponse.Content.ReadAsStreamAsync()HttpClientContent-Lengthstream.LengthETagContent-MD5AllowAutoRedirectHttpClientHandlerHttpClientHttpClientHttpClientHandlerHttpClientHttpClientHttpClientHandlerHttpClientIHttpClientFactory"download-with-redirect""download-no-redirect"UseCookies = truefalse