Skip to main content

​
Symptom

On the same machine, curl against api.apiyi.com works fine, but a Python program (especially in a Conda environment) fails with:
Sometimes it shows up as a connection timeout on port 443 or a drop during the handshake. No VPN is involved, and switching networks (for example to a phone hotspot) makes it work again.

​
Short Answer

This is not an APIYI server-side issue and not a certificate issue. Your OpenSSL version is incompatible with a middlebox on your network. Compare the OpenSSL versions on both sides:
If the failing side is on OpenSSL 3.5 or newer and the working side is older than 3.5, this is almost certainly the cause.

​
Why It Happens

Starting with OpenSSL 3.5, the TLS handshake includes a post-quantum key exchange (X25519MLKEM768) by default. That grows the first handshake message (ClientHello) from about 300 bytes to about 1500 bytes, larger than a single TCP segment, so it has to be split into two segments. Some corporate firewalls, TLS inspection appliances, and ISP-side deep packet inspection devices cannot handle a split ClientHello, or do not recognize the new key exchange algorithm, and simply close the connection. The client sees “EOF occurred in violation of protocol”. Every APIYI edge node supports this post-quantum handshake. On 2026-09-11 (UTC+8) we verified each node with OpenSSL 3.6.4 and all of them passed. The handshake packet is being dropped inside your network before it reaches us, so nothing on the server side can fix it for you.

​
Three Commands to Confirm

Run these with the openssl binary from the failing environment (activate the Conda environment first):

​
Fixes (pick one)

1

Option 1: Disable post-quantum key exchange via a config file (recommended)

Create a file, for example ~/no-pq.cnf:
Set the environment variable before running your program:
Every OpenSSL-based program in that environment (Python, curl, pip and so on) stops sending the post-quantum key share, and the ClientHello shrinks back to about 300 bytes. Encryption strength is unchanged. This simply restores the pre-3.5 default behavior.
2

Option 2: Downgrade OpenSSL in Conda

Versions before 3.5 do not enable post-quantum key exchange by default. This may also adjust packages that depend on OpenSSL, so test it in a staging environment first.
3

Option 3: Ask your network team to update the middlebox

Mainstream firewalls and TLS inspection appliances support hybrid post-quantum handshakes in firmware released after 2025. This is the permanent fix and prevents the same failure against other sites.

​
Follow-up Questions

The browser and your program may not share the same network path (the browser may use a system proxy), and browsers automatically retry the handshake without the post-quantum share when it fails. Programs do not.
Any client whose TLS library is OpenSSL 3.5 or newer can, including curl 8.x built against a recent OpenSSL. Go and Java use their own TLS stacks, and whether post-quantum exchange is on by default depends on their versions. The diagnosis is the same: use the three commands above to see whether only the default handshake fails.
No. The connection is closed during the handshake, before certificate verification even starts. Disabling verification does not fix it and adds security risk.
The first handshake message is sent by the client. When it is dropped inside your network, the server never receives it, so no server configuration can help. If the three commands show that the default handshake succeeds against other sites but fails only against api.apiyi.com, send us the results and we will investigate further.

Do I Need a Proxy to Use the API?

APIYI supports direct connections without a proxy or VPN

Timeout Configuration

How to set connect and read timeouts