首先咱们先拆解两个请求的核心差异，这是问题的关键：

• 你用curl发起请求时，一开始就主动携带了Authorization: Basic ...身份验证头，直接完成了认证，所以服务器返回200正常响应。
• 而Windows资源管理器背后的WebDAV组件（Microsoft-WebDAV-MiniRedir）遵循HTTP基本认证的标准流程：先发送不带任何授权信息的OPTIONS请求，预期服务器返回401并附带WWW-Authenticate: Basic realm="..."头，之后它才会重新发送带Authorization头的请求完成认证。

结合你提到的两个怪异现象——Explorer请求返回401后没有重试、应用日志里完全看不到Explorer的请求——我给你梳理几个排查方向：

1. 先确认服务器/中间件是否允许匿名OPTIONS请求 #

你的WebDAV服务器（milton.io）或者应用容器（比如Tomcat）的安全配置，很可能拦截了不带授权的OPTIONS请求，甚至没把请求转发到你的应用里：

• 如果用了Spring Security这类安全框架，要单独配置放行OPTIONS方法，允许匿名访问；
• 检查容器的全局安全配置，比如Tomcat的web.xml里是否有针对OPTIONS的拦截规则；
• 如果有反向代理（比如Nginx），确认代理配置没有过滤掉不带Authorization头的OPTIONS请求。

可以先手动模拟MiniRedir的流程验证：

# 第一步：不带授权发OPTIONS，预期返回带WWW-Authenticate的401
curl -i -X OPTIONS http://localhost:8080/storage-explorer/rest/dav
# 第二步：再发带授权的请求，应该返回200
curl -i -X OPTIONS http://localhost:8080/storage-explorer/rest/dav -u joe:JoeSchmo1!

如果第一步的返回没有WWW-Authenticate头，那服务器端的配置肯定有问题，得先解决这个。

2. 检查WebClient的注册表配置（并重启服务） #

你已经修改了BasicAuthLevel，但要确认几个细节：

• 确保HKLM\SYSTEM\CurrentControlSet\Services\WebClient\Parameters\BasicAuthLevel的值设为2（允许HTTP和HTTPS的基本认证）；
• 同时检查UseBasicAuth项是否设为1，启用基本认证；
• 修改注册表后，必须重启WebClient服务：打开命令行执行net stop webclient，再执行net start webclient。

3. 排查请求链路的日志 #

既然WireShark能抓到Explorer的请求，但应用日志看不到，说明请求被中间环节拦截了：

• 直接查看应用容器的访问日志（比如Tomcat的localhost_access_log.*.txt），确认Explorer的请求是否真的到达了容器层面；
• 如果容器日志也没有，那问题出在反向代理或者防火墙，要检查这些组件的规则。

4. 检查milton.io的Windows客户端适配配置 #

milton.io作为WebDAV服务器，可能有针对Windows客户端的特殊配置项：

• 查看官方文档，确认是否需要开启对匿名OPTIONS请求的支持；
• 检查服务器返回的WWW-Authenticate头里的realm值，是否和客户端弹出窗口里的领域匹配（虽然你的截图里显示的是应用的realm，但也要确保没有配置冲突）。

备注：内容来源于stack exchange，提问作者kc2001