Windows Can't Connect to WebDAV: A Diagnosis Checklist

Search for this problem and page one is mostly forum threads that trail off without an answer. Part of the reason: "Windows can't connect to WebDAV" is not one failure. It is at least nine, and Windows reports several of them with the same misleading box.

So work symptom-first. Find your exact error text in the table, then follow the check it points at. The first two checks resolve most cases, and everything below them is a genuinely different problem wearing a similar message.

Those error numbers and their wording, typo in 1244 included, are Microsoft's own, from the WebDAV redirector documentation.

Check 1: is the WebClient service even running?

Every mapped WebDAV drive on Windows goes through a service called WebClient. Microsoft deprecated it in November 2023, and the deprecation notice states that the Webclient service isn't started by default in Windows. On a clean Windows 11 machine, this is the answer more often than any other.

Get-Service WebClient | Format-List Name, Status, StartType
Set-Service -Name WebClient -StartupType Automatic
Start-Service -Name WebClient

If the Status column was empty in services.msc, the WebDAV redirector was never loaded and no mapping could have succeeded. What Explorer tells you in that state is that the folder you entered does not appear to be valid, which sends people off to inspect a URL that was never the problem.

Check 2: will Windows send Basic credentials over HTTP?

WebClient reads a registry value named BasicAuthLevel, documented with three values: 0 disables Basic authentication, 1 enables it for SSL sites only, and 2 enables it for both SSL and non-SSL sites. The default is 1, so an http:// endpoint with Basic auth fails before Windows even prompts for a password.

reg add "HKLM\SYSTEM\CurrentControlSet\Services\WebClient\Parameters" /v BasicAuthLevel /t REG_DWORD /d 2 /f
net stop WebClient
net start WebClient

The restart is not optional. Microsoft's documentation says that after changing any value in that key, WebClient has to be restarted or the machine rebooted. Skipping it is why so many people conclude the fix is folklore.

Know what level 2 costs: credentials travel in clear text. Fine for 127.0.0.1, defensible on a network you control, wrong across the open internet, where you want an HTTPS endpoint.

Check 3: is the URL in a shape the redirector accepts?

• Include the scheme. http://host:port/path. A bare host name is treated as SMB and never reaches your server.
• Include the port whenever it is not 80 or 443. The WebDAV extensions specification notes that pre-Vista clients supported port 80 only, which is why the port syntax feels bolted on.
• Match the subpath exactly. Servers publish under paths like /dav or /remote.php/dav/files/alice, and mapping one level too high produces the same "not valid" wording.
• From the command line, either form works: net use * http://www.example.com, or the UNC form documented as \\server[@SSL][@port][\path], where DavWWWRoot addresses the server root.

Check 4: is a stale credential being replayed?

Open Control Panel, Credential Manager, Windows Credentials, and delete every entry for the host. Then drop the half-built mapping with net use Z: /delete before retrying. 0x80070043 regularly survives a corrected password because the wrong one is still cached.

Related and worth knowing: Microsoft states that since Windows 7, Basic authentication credentials cannot be persisted by Credential Manager, so a Basic-auth mapping cannot be silently restored at sign-in. Its own recommendation is a logon script that re-runs net use.

Check 5: the timeouts and caches nobody mentions

All of these live in HKLM\SYSTEM\CurrentControlSet\Services\WebClient\Parameters, all are documented by Microsoft, and all need a service restart to take effect. They explain a whole class of "it works sometimes" reports.

• ServerNotFoundCacheLifeTimeInSec, default 60. WebClient remembers hosts it decided were not WebDAV servers and fails instantly against them for a minute. Fix the server, retry immediately, get the same error: this is why.
• InternetServerTimeoutInSec, default 30, and LocalServerTimeoutInSec, default 15. Connection timeouts for remote and local servers respectively.
• SendReceiveTimeoutInSec, default 60. Applies per request, so a slow PUT of a large file can die here rather than at the size limit.
• FileAttributesLimitInBytes, default 1,000,000. The cap on the total size of all properties on one collection, which a folder with thousands of entries can reach.
• SupportLocking, default 1. Turning it off changes how the redirector behaves against servers that do not implement LOCK.
• FileNotFoundCacheLifeTimeInSec. Microsoft recommends setting it to 0 when connecting to a case-sensitive Linux WebDAV server, where two names differing only in case cause "file not found" errors and overwritten data.

When it is not Windows at all

• On macOS the failure mode is different: the drive mounts, then writes fail silently, because Finder wants a class-2 server that advertises LOCK. See WebDAV slow on Mac.
• If you are trying to run the server rather than connect to one, WebDAV server on Windows covers that side.
• If the mapping works but large copies stop at 50 MB, nothing above is wrong. That is the 50 MB limit.

Mapping a local server, such as AnyStorage on port 3211

AnyStorage runs a WebDAV server on your own machine: Services in the sidebar, the WebDAV tab, Start, endpoint http://127.0.0.1:3211, port configurable. Every connection open in the app appears as a folder under that root, so one mapped drive reaches an S3 bucket, Cloudflare R2, Backblaze B2, MinIO, Google Drive, OneDrive, Dropbox and an SFTP host at once.

Checks 1 and 2 apply to it directly: the endpoint is HTTP, authentication is Basic and always on, so WebClient must be running and BasicAuthLevel must be 2. Credentials are in the WebDAV tab, default username anystorage and a 24-character generated password. On the free tier the mount is read-only, with read-write reserved for Pro, and a connection appears under the root only after you have opened it in the app this session, because connections connect lazily. There is no TLS in the current version, which is exactly why it binds to 127.0.0.1 by default and warns before you enable LAN access.