Android Beta APP Could not connect to WebDAV server
I have encountered the same issue as well. Please provide the following logs for assistance in troubleshooting:
Windows version 10.0-beta.7+982c00aaf is working properly.
The relevant server logs are captured as follows:
The server only shows the following log entry.
There are no errors on the server backend.
But it said `Could not connect to WebDAV server` in the APP.
Additionally, I found that both versions 240 and 246 were still functioning properly on May 27, 2026, at 01:14:18 +0800. No other operations were performed during that time.
Windows version 10.0-beta.7+982c00aaf is working properly.
The relevant server logs are captured as follows:
x.x.x.x | - | 01/Jul/2026:23:26:07 +0800 | "webdav.host" | "OPTIONS /dav/zotero/ HTTP/1.1" | 200 | 0 | "-" | "Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:140.0) Gecko/20100101 Firefox/140.0 Zotero/10.0-beta.7+982c00aaf" "x.x.x.x"
x.x.x.x | - | 01/Jul/2026:23:26:07 +0800 | "webdav.host" | "PROPFIND /dav/zotero/ HTTP/1.1" | 401 | 0 | "-" | "Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:140.0) Gecko/20100101 Firefox/140.0 Zotero/10.0-beta.7+982c00aaf" "x.x.x.x"
x.x.x.x | webdav_username | 01/Jul/2026:23:26:08 +0800 | "webdav.host" | "PROPFIND /dav/zotero/ HTTP/1.1" | 207 | 190 | "-" | "Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:140.0) Gecko/20100101 Firefox/140.0 Firefox/140.0 Zotero/10.0-beta.7+982c00aaf" "x.x.x.x"
x.x.x.x | webdav_username | 01/Jul/2026:23:26:09 +0800 | "webdav.host" | "GET /dav/zotero/nonexistent.prop HTTP/1.1" | 404 | 9 | "-" | "Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:140.0) Gecko/20100101 Firefox/140.0 Zotero/10.0-beta.7+982c00aaf" "x.x.x.x"
x.x.x.x | webdav_username | 01/Jul/2026:23:26:10 +0800 | "webdav.host" | "PUT /dav/zotero/zotero-test-file.prop HTTP/1.1" | 201 | 31 | "-" | "Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:140.0) Gecko/20100101 Firefox/140.0 Zotero/10.0-beta.7+982c00aaf" "x.x.x.x"
x.x.x.x | webdav_username | 01/Jul/2026:23:26:10 +0800 | "webdav.host" | "GET /dav/zotero/zotero-test-file.prop HTTP/1.1" | 200 | 25 | "-" | "Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:140.0) Gecko/20100101 Firefox/140.0 Zotero/10.0-beta.7+982c00aaf" "x.x.x.x"
x.x.x.x | webdav_username | 01/Jul/2026:23:26:11 +0800 | "webdav.host" | "DELETE /dav/zotero/zotero-test-file.prop HTTP/1.1" | 204 | 0 | "-" | "Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:140.0) Gecko/20100101 Firefox/140.0 Zotero/10.0-beta.7+982c00aaf" "x.x.x.x"
The Android version of Zotero-Beta, Version 1.0.0-247 and 1.0.0-255, is not available.The server only shows the following log entry.
There are no errors on the server backend.
But it said `Could not connect to WebDAV server` in the APP.
x.x.x.x | - | 01/Jul/2026:18:36:26 +0800 | "webdav.host" | "OPTIONS /dav/zotero/ HTTP/1.1" | 200 | 0 | "-" | "Zotero/1.0.0-247 (Android 36)" "x.x.x.x"
x.x.x.x | - | 01/Jul/2026:23:26:37 +0800 | "webdav.host" | "OPTIONS /dav/zotero/ HTTP/1.1" | 200 | 0 | "-" | "Zotero/1.0.0-255 (Android 36)" "x.x.x.x"
The log captured in Android debug mode is as follows:
(+0000001):[ERROR] WebDavController: checkServerfailed:null
(+0000001):[DEBUG] cf-ray: xxxxxxx-LAX
(+0000000):[DEBUG] server: cloudflare
(+0000000):[DEBUG] report-to:{"group":"cf-nel","max_age":604800,"endpoints":[{"ur!":"https://a.nel.cloudflare.com/report/v4?s=xxxxxxxx"}]}
(+0000000):[DEBUG] cf-cache-status: DYNAMIC
(+0000001):[DEBUG] strict-transport-security:max-age=15768000;
(+0000000):[DEBUG] set-cookie:sl-session=xxxxxxxx;SameSite=None; Secure; Path=/; Max-Age=86400;HttpOnly
(+0000000):[DEBUG] vary: Accept-Encoding
(+0000000):[DEBUG] ms-author-via: DAV
(+0000001):[DEBUG] dav:1, 2
(+0000000):[DEBUG] cache-control: private,no-cache
(+0000000):[DEBUG] allow: OPTIONS, LOCK,PUTMKCOL
(+0000000):[DEBUG] nel:{"report_to":"cf-nel","success_fraction':0.0,"max_age":604800}
(+0000001):[DEBUG] date: Wed, 01 Jul 2026 15:31:11GMT
(+0001792):[DEBUG]<-- 200 https://webdav.host/dav/zotero/(1791ms)
(+0000000):[DEBUG]--> END OPTIONS
(+0000000):[DEBUG] User-Agent: Zotero/1.0.0-255(Android36)
(+0000863):[DEBUG]-> OPTIONS https://webdav.host/dav/zotero/
(+1083566):[INFO] WebDavController: checkServer
Additionally, I found that both versions 240 and 246 were still functioning properly on May 27, 2026, at 01:14:18 +0800. No other operations were performed during that time.
Upgrade Storage
Both of my devices are using this version right now.
Debug ID: D722221758
You can see that the PC logs I provided show that PROPFIND returns a 401 status code, but the synchronization is working fine.
Other software also works just fine.
I am re-deploying the environment on localhost; please wait a moment.
This is also a PROPFIND request with the HTTP 207 that was just sent out by the PC.
Cloudflare is not being used for routing.
server: cloudflareand other Cloudflare headers. It's literally a Cloudflare server responding to the HTTP request.Perhaps it will take some time to synchronize the DNS broadcasts.?
Re: your edit: it would be a TTL (time-to-live) on the DNS record — there's no "broadcast" — but yes, essentially.
There should be the directed address no problems now.
You're right, it's the TTL. This is the new Debug log package.
This time, there should be no Cloudflare relay involved. >-<
Some clients (apparently the desktop app) could ignore that, and we can make the Android app do so, but if the server is under your control, you should try to fix that.
However, accessing the subpaths under webdav requires authentication.
Otherwise, it returns a null value.
You can try to directly access the root directory of that site using A segment of routine UA .
I have now unzipped the WAF.
content-encoding: gzip.The test results show that if I use the following command: It includes the username and password, returns the following response: section is omitted, the response is: I believe this is the cause of the authentication failure on the Android side.
And this seems to have nothing different with whether the gzip package is enabled or not.
I executed the following command and obtained the following output:
The content has been desensitized.
The file content of the server can be obtained correctly.
Or is it that the Android version does not support gzip?
At first, you said it was because the server was using Cloudflare, and then you said the server didn't support PROPFIND.
But I've already proven both of those points for you.
As for the return length being 0 even though gzip is claimed to be used, that doesn't make sense;
there's no data to compress in the first place, so it doesn't really matter. Or do you think the ideal content-length returned by OPTIONS shouldn't be 0?
The comparison of my OPTIONS tests above shows that the methods obtained after authentication are completely inconsistent.
Additionally, all the programs that use WEBDAV are working properly except for Zotero Android.
Here is the comparison of the results for the OPTIONS request.
It's clear that there's no issue with PROPFIND after authentication, and there are very few cases of unauthenticated OPTIONS or unauthenticated PROPFIND (this is only limited to Zotero). And the difference between Zotero PC and Android is also obvious.
Therefore, I don't think it's a problem with the gzip package. Yes, I have tried other WEBDAV providers, and they do work.
However, only the Android app does not support this server.
Isn't it a problem with the APP?
Only on Zotero Android says "Could not connect to WebDAV server," but is it really impossible to connect?
Although, according to the server configuration, the gzip package itself will not work for content of this size.
But in reality, I added a new layer of Nginx in front of the webdav server and removed the field in the header.
This has really resolved the issue, and now the links are working properly.
Thank you all for your help!