How do you test the connection? I tested it by running a command inside a Railway Sandbox and Service Console and both return the expected timestamp data

Thanks for testing this. We’ve now captured the response details from our failing service:

Endpoint: https://www.okx.com/api/v5/public/time

Method: GET

Client: Python 3.12 using standard urllib.request

Hosting region: Amsterdam (ams)

No API credentials, custom headers or request body; redirects disabled

HTTP status: 403

Server: cloudflare

Response body: error code: 1010

CF-RAY: a3a46cda59716624-AMS

Timestamp: 2026-09-13 04:31:56 UTC

Cloudflare documents 1010 as a client/browser-signature block. Your successful test used curl, so the client difference may be relevant alongside the region.

@mayori, could you confirm the regions of your working tests and try this Python request in the same environment?

import urllib.request

import urllib.error

url = "https://www.okx.com/api/v5/public/time"

try:

with urllib.request.urlopen(url, timeout=15) as response:

    print(response.status)

    print(response.read().decode())

except urllib.error.HTTPError as error:

print(error.code)

print(error.headers)

print(error.read().decode())

Regarding eea.okx.com: my account is Australian. The FAQ cited describes EEA users and error 50119, whereas ours is Cloudflare 1010 on an unauthenticated endpoint. Can OKX confirm whether that regional hostname applies to an Australian account hosted in Amsterdam before we change the integration?

Thanks again for investigating. We have an update from our Railway service:

OKX support instructed us to use us.okx.com for our Australian account. We tested that hostname from the same Amsterdam service, keeping Python’s default User-Agent and sending no credentials.

Endpoint: https://us.okx.com/api/v5/public/time

User-Agent: Python-urllib/3.12

Result: HTTP 403

Response body: error code: 1010

Server: Cloudflare

CF-RAY: a3a4d6ead8470e2e-AMS

Time: 2026-09-13 05:44:20 UTC

Changing the hostname alone did not resolve it. This remains consistent with your User-Agent finding.

OKX’s technical team is investigating the UA under ticket 7002843. We’ve asked them to confirm that the descriptive identifier okx-public-connectivity-check/1.0 is supported. We haven’t applied or tested that change on our service yet.

We’ll keep this thread open and report back with the verified result.

Could you test the same endpoint from the Railway deployment with:

1. curl -i https://www.okx.com/api/v5/public/time

2. curl -4 -i https://www.okx.com/api/v5/public/time

3. curl -6 -i https://www.okx.com/api/v5/public/time

4. curl -i -A "Mozilla/5.0" https://www.okx.com/api/v5/public/time

Please share the HTTP status and response headers/body for each test.

Our Railway service currently has IPv6 egress disabled. We’ve also confirmed the Python request returns Cloudflare 1010, with the response details posted above.

Could you clarify what the curl tests would establish beyond the client-signature difference already reproduced? We’re awaiting OKX’s confirmation of a supported, descriptive User-Agent rather than using a browser identifier.