我们正尝试通过SSL使用网络使用连接到WebDAV服务器。 在某些服务器上，我们看到一个问题，即只有在 URL 中指定端口 443 时，此连接才会成功。
做地图
net use * "https://example.com:443/folder" net use * "\example.com@SSL@443folder"
而且，奇怪的是，这也是这样做的： net use * "\example.com@SSLasdffolder"
不映射
net use * "https://example.com/folder" net use * "\example.com@SSLfolder"
在非工作情况下，我们始终收到以下错误：
System error 67 has occured. The network name cannot be found.
我们注意到一些可能是有用信息的内容：
- 我们有一个测试服务器，其配置方式与生产服务器相同，并且按预期工作。
- 在非工作情况下，生产服务器上不会看到来自故障主机的传入请求。
- 所有客户端都基于同一映像。
- 这个问题并没有在所有客户端上统一表现出来——有些有效，有些则不然。
- 客户端 DNS 缓存中存在一个现有的有效 example.com 条目。
- 刷新受影响服务器的客户端 DNS 缓存不能解决问题。
- 一旦问题出现，它似乎就会坚持下去。 也就是说，如果我执行其中一个工作映射，将其删除，然后立即执行其中一个非工作映射，则问题仍然存在。
我们完全被难住了。 有什么理论吗？
您看到不同的行为，因为您使用不同的名称进行连接。尝试名称失败后，Web客户端（这是启用 WebDAV 的服务）会将响应缓存一段时间。要清除缓存，请在服务控制台中找到 Web 客户端服务并重新启动它。或者从管理命令提示符执行以下命令：
net.exe stop webclient && net.exe start webclient
我们最终确定我们误解了net use回归System Error 67。我们发现了两件有趣的事情：
-
如果 WebDAV 在初始根文件夹
PROPFIND上返回 404 或 50x，net use将（正确）将其解释为根文件夹不可用。 它说找不到网络名称的事实让我们相信问题出在名称解析上，但它实际上只是在说，'嘿，我在这条路上找不到任何东西。 -
如果"网络使用"由于 404/50x 而失败，则似乎在短时间内它将自动使同一主机的任何其他映射失败，而无需发出请求。例如，如果
net use http://me.com/foo返回 404，则net use http://me.com/bar如果快速连续地进行第一次调用，则会立即失败，并且在 WebDAV 服务器日志中不会看到任何请求记录。
我最好的猜测是附加@443端口没有任何真正的区别。 它可能所做的是欺骗net use认为它正在与不同的主机交谈，至少出于其"自动失败"功能的目的。 但这只是一个猜测。