ps_accounts v8.0.15, Debian 13, server IP 162.55.2.182 (Hetzner).

[diskawrs]

Fresh install.
Getting accounts-api/connect-error on store verification. Not sure exactly what's causing it but here's what I've found so far, hoping someone can help make sense of it.
TLS connection to accounts.distribution.prestashop.net resets mid-handshake, before any cert exchange:
For the purpose fo this test, I turned iptables, WAF off. Cloudflare is on bypass. (Turned it back on again now obviously).

$ curl -v https://accounts.distribution.prestashop.net

• Trying 104.18.1.230:443...
• TLSv1.3 (OUT), TLS handshake, Client hello (1):
• Recv failure: Connection reset by peer
  Same result with openssl s_client. Same request from a different (non-Hetzner) network works fine, 200 OK.

I opened a support ticket and they came back saying to whitelist these IPs on my end:
104.199.32.134, 23.251.142.64, 34.78.238.154

But the domain actually resolves to 104.18.1.230 / 104.18.0.230 (Cloudflare) for me, not those addresses, so whitelisting them didn't change anything —
still get the same reset. Not sure if those IPs are for something else or just outdated info.
Given it fails identically from two separate TLS clients (curl and raw openssl), only from this IP, only against this host, my best guess is it's some kind of IP-reputation or bot-mitigation block on your Cloudflare/Google edge, and Hetzner ranges get hit by this kind of thing more than most. But I don't know your setup so could easily be wrong.
Would appreciate if someone could take a look, or at least clarify whether those IPs support gave me are right for anything. Happy to run more tests if useful.

---

This and the support desk generic answer, I am lost. Fresh install.

warning
Store verification failed
Store server returned an error while trying to reach the Accounts API.

How to debug
keyboard_arrow_up
Error code
accounts-api/connect-error
Debug information
We could not verify your store because it could not connect to the Accounts API. This usually happens when your network or hosting setup blocks your connection (firewall, proxy, security rules, etc.). You can contact your hosting provider to check your settings.

content_copy
Copy information

[diskawrs]

From home on windows, it connects fine.

PS C:\WINDOWS\system32> curl -v https://accounts.distribution.prestashop.net
VERBOSE: GET with 0-byte payload
VERBOSE: received -1-byte response of content type text/html

StatusCode : 200
StatusDescription : OK
Content :




<meta name="viewport" content="width=device-w...
RawContent : HTTP/1.1 200 OK
Transfer-Encoding: chunked
Connection: keep-alive
CF-RAY: a15e462d4e2ef355-MAN
cf-cache-status: DYNAMIC
Accept-Ranges: bytes
Content-Type: text/html
Date: Sat, 04 Jul 2026 12:53...
Forms : {}
Headers : {[Transfer-Encoding, chunked], [Connection, keep-alive], [CF-RAY, a15e462d4e2ef355-MAN], [cf-cache-status, DYNAMIC]...}
Images : {}
InputFields : {}
Links : {}
ParsedHtml : mshtml.HTMLDocumentClass
RawContentLength : 1467

[hschoenenberger]

Hi @diskawrs, thanks for the detailed report — your diagnosis is correct, and this is not an issue with the ps_accounts module itself.

The TLS connection is reset mid-handshake (right after the Client hello, before any certificate is exchanged), i.e. at the network edge before any HTTP request reaches us. Since it fails from two independent TLS clients (curl and openssl) only from your Hetzner IP (162.55.2.182) while working fine from other networks, this points to an IP-reputation / bot-mitigation block at the Cloudflare edge in front of accounts.distribution.prestashop.net (Hetzner ranges get caught by this more often). Nothing on your side — firewall, WAF, or module config — will change it.

The IPs support gave you (104.199.32.134, 23.251.142.64, 34.78.238.154) are Google Cloud egress addresses used for inbound callbacks to your shop, so allowlisting them can't help an outbound connection to our Cloudflare edge — which is why it made no difference.

This has to be handled on our infrastructure side, so please get back to support with this analysis and ask them to have your source IP reviewed against the Cloudflare edge filtering rules on accounts.distribution.prestashop.net. That's the fastest path to the right team.

Thanks again for the thorough testing — it made this much easier to pinpoint.