https://bugs.kde.org/show_bug.cgi?id=524483
--- Comment #3 from [email protected] --- I found the cause. **The payload socket is the only socket in the LAN backend that never gets `setProxy(QNetworkProxy::NoProxy)`**, so it inherits the application proxy. With a system proxy configured, the connection is rejected inside Qt's proxy layer before any packet is sent. In `LanDeviceLink::dataReceived()` (`core/backends/lan/landevicelink.cpp:138`): QSharedPointer<QSslSocket> socket(new QSslSocket); LanLinkProvider::configureSslSocket(socket.data(), deviceId(), true); ... socket->connectToHostEncrypted(address, port, QIODevice::ReadWrite); `configureSslSocket()` only sets up certificates and verification. The call that disables the proxy lives in the *other* helper, `configureSocket()` (`lanlinkprovider.cpp:646`), which is never applied to this socket. Every other socket in that file disables the proxy explicitly — lines 81, 84, 236 and 350 — this one is the exception. **Reproduced in isolation.** I wrote a small Qt program that mirrors `configureSslSocket()` exactly and connects to the phone's payload port while a transfer is pending. With `setProxy(NoProxy)` it fetches the payload in 116 ms: SSL backend: openssl (OpenSSL 3.6.3) [113 ms] ENCRYPTED - handshake complete, cipher: ECDHE-ECDSA-AES128-GCM-SHA256 [116 ms] PAYLOAD RECEIVED - 19 bytes Letting it inherit the system proxy instead — what kdeconnectd does — fails immediately: [41 ms] proxy: INHERITING system proxy [47 ms] SOCKET ERROR: UnsupportedSocketOperationError - The proxy type is invalid for this operation That error never reaches the user: `landevicelink.cpp` does not connect `errorOccurred`, and `FileTransferJob::doStart()` (`core/filetransferjob.cpp:77-81`) only waits on `readyRead`. So the job hangs silently until the sender times out, which is exactly the reported symptom. It also explains the absence of any `SYN_SENT` — the connection is refused above the network layer. **Confirmed end to end:** with the system proxy disabled, phone-to-desktop file transfer works immediately. Re-enabling it brings the failure back. **Suggested fix** — one line: QSharedPointer<QSslSocket> socket(new QSslSocket); socket->setProxy(QNetworkProxy::NoProxy); // add this LanLinkProvider::configureSslSocket(socket.data(), deviceId(), true); **Workaround for affected users:** disable the system proxy, or add the local subnets to its bypass list (e.g. `192.168.*;10.*;127.*;localhost`), then restart kdeconnectd. I originally suspected a Qt regression because this reporter and I both run Qt 6.11.1, but that was a coincidence — the bug is version-independent and would affect any user with a system proxy configured, on any platform. That also fits this report being filed from Linux while I hit it on Windows. My environment: Windows 10.0.26200, KDE Connect desktop built 2026-09-12, Qt 6.11.1 with the OpenSSL backend, KDE Connect Android 1.35.16 (protocol 8). --- -- You are receiving this mail because: You are watching all bug changes.
