Upgrade StorageLocal HTTP server (127.0.0.1:23119) intermittently resets connections — Connector can't save
Zotero 10.0.2, Windows 11 (Build 26300), Zotero Connector 5.0.212 / Chrome 150.
Since today, saving from the Chrome Connector fails almost every time. Clicking the Connector button shows "Is Zotero running? — The Zotero Connector was unable to communicate with the Zotero desktop application", even though Zotero is running and translator detection works fine (the button correctly offers "Save to Zotero (CNKI)", and the connector syncs translators from the local Zotero — a hash mismatch triggered a full re-sync of 841 translators, which succeeded).
Measuring the local HTTP server directly with curl from the same machine (no proxy, GET http://127.0.0.1:23119/connector/ping):
- ~20–50% of requests fail, in multi-second waves. Failures are either connection reset (curl exit 56) or timeout (exit 28); successes return 200 instantly.
- Persists across: restarting Zotero, Restart in Troubleshooting Mode (all plugins disabled), and a full Windows reboot.
- Affects other local clients at the same rate — my own curl scripts fail just like the Connector.
- netstat during failure windows shows a single LISTENING socket on 23119 (zotero.exe), zero lingering ESTABLISHED/CLOSE_WAIT connections, and no second process ever binding the port (polled every 150 ms for a full minute).
- When the initial ping does succeed, the save still usually dies later. In the Connector's service-worker console, the progress window's heartbeat POST /connector/delaySync alternates between HTTP 204 and "HTTP 0 … Failed to fetch" every few seconds; POST /connector/saveItems is never sent; the popup eventually closes with no item saved and no error.
- Right after Zotero starts, the first few connections fail before the server starts answering, then the success/failure waves continue.
So the local server appears to be dropping/resetting a large fraction of accepted connections in bursts, independent of the client. Anything else I should check on my end, or does this look like a 10.0.2 regression? Happy to run any diagnostics.
Since today, saving from the Chrome Connector fails almost every time. Clicking the Connector button shows "Is Zotero running? — The Zotero Connector was unable to communicate with the Zotero desktop application", even though Zotero is running and translator detection works fine (the button correctly offers "Save to Zotero (CNKI)", and the connector syncs translators from the local Zotero — a hash mismatch triggered a full re-sync of 841 translators, which succeeded).
Measuring the local HTTP server directly with curl from the same machine (no proxy, GET http://127.0.0.1:23119/connector/ping):
- ~20–50% of requests fail, in multi-second waves. Failures are either connection reset (curl exit 56) or timeout (exit 28); successes return 200 instantly.
- Persists across: restarting Zotero, Restart in Troubleshooting Mode (all plugins disabled), and a full Windows reboot.
- Affects other local clients at the same rate — my own curl scripts fail just like the Connector.
- netstat during failure windows shows a single LISTENING socket on 23119 (zotero.exe), zero lingering ESTABLISHED/CLOSE_WAIT connections, and no second process ever binding the port (polled every 150 ms for a full minute).
- When the initial ping does succeed, the save still usually dies later. In the Connector's service-worker console, the progress window's heartbeat POST /connector/delaySync alternates between HTTP 204 and "HTTP 0 … Failed to fetch" every few seconds; POST /connector/saveItems is never sent; the popup eventually closes with no item saved and no error.
- Right after Zotero starts, the first few connections fail before the server starts answering, then the success/failure waves continue.
So the local server appears to be dropping/resetting a large fraction of accepted connections in bursts, independent of the client. Anything else I should check on my end, or does this look like a 10.0.2 regression? Happy to run any diagnostics.
Very unlikely that this is a 10.0.2 regression.
Captured in Troubleshooting Mode (all plugins disabled) with Debug Output Logging enabled.
While the log was recording, I made 40 plain GET http://127.0.0.1:23119/connector/ping requests with curl from the same machine (no proxy) — 16 of them failed, in multi-second waves, with either a connection reset (curl exit 56) or a timeout (exit 28). I also triggered a save from the Zotero Connector on a CNKI article page during the capture, so the ping/GET-translators/delaySync traffic from that failing save is in there too.
One thing worth noting: many of the failing connections never seem to reach a request handler at all — curl gets RST or times out with no response — so those failures may not show up as handled requests in the log. Happy to capture anything else if that would help.
1. Security software: QQ PC Manager (Tencent suite; loads kernel filter drivers TAOKernelDri / TAOAccelerator / QQSysMonX64 / TFsFlt) — real-time protection exited and the kernel filter drivers unloaded; failures continued at the same rate (~30–40%).
2. Proxy: Clash Verge — all its processes killed during testing; failures continued.
3. Winsock catalog: only stock Microsoft mswsock.dll providers, no layered service providers.
4. A full Windows reboot and Restart in Troubleshooting Mode (all plugins disabled) were both done before the original post.
5. netstat polled every 150 ms for a minute: a single LISTENING socket on 23119 (zotero.exe), no second process ever binding the port, zero lingering connections during failure windows.
curl -v on a failing request shows: TCP connection established → request fully sent → connection closed/reset with no response at all. With the security suite's filter drivers unloaded and the proxy processes dead, I'm not sure what else on the machine would accept a request and then silently drop it.
FWIW the timeline: 10.0.2 was installed on Sept 12; connector saves still worked fine on the morning of Sept 14; the problem appeared Sept 15 and comes and goes in waves.
Anything else you'd like us to capture?