Local HTTP server (127.0.0.1:23119) intermittently resets connections — Connector can't save

Sherlock75
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.
  • dstillman Zotero Team
    Can you provide a Debug ID from Zotero in Troubleshooting Mode that shows this happening?

    Very unlikely that this is a 10.0.2 regression.
  • Sherlock75
    Debug ID: D1723634966

    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.
  • adomasven Zotero Team
    This seems like a local networking issue. You should check security software, firewalls, proxy setups, etc. Even restarting the machine may help. Since the requests don't seem to be reaching Zotero, it's likely the issue is somewhere in the networking stack.
  • Sherlock75
    Thanks — we've now been through exactly that checklist:

    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?
  • dstillman Zotero Team
    Sorry, but as Adomas says, we have no reason to think this is an issue within Zotero itself. Your log shows 40 answered ping requests, with no delays or errors.
  • Sherlock75
    Update: found the culprit on our side — it was the IDM (Internet Download Manager) Integration Module extension in Chrome. With that extension enabled, connector requests to the local server were being intermittently dropped: the button showed "Is Zotero running?" and the progress window's delaySync heartbeats alternated between HTTP 204 and "Failed to fetch". After disabling the IDM extension in chrome://extensions, saving works again — items land in Zotero normally, including from CNKI pages.

    Same machine, same Zotero, same network — only difference is the IDM extension. Sorry for the noise, and thanks for the debug guidance. The "40 answered pings" observation makes sense in hindsight: Zotero answered everything it received; the responses were being lost on the browser side.
Sign In or Register to comment.