Project: TreeHouse

Project ID: 28e6e60c-f660-4e8d-bb6f-b7fcf9ae6b13

Environment: production (e6565e0b-5b61-474c-9cc3-c4274a6c4786)

Service: treehaous-web (bcbff691-5cbd-4012-a421-01ad54450f8d)

Affected domain: app.treehaous.com

Current domain ID: 1a80dfd4-1029-458d-bf7f-9b380f73a896

Current target: 9i0er2i4.up.railway.app (69.46.46.100)

Issue

app.treehaous.com is completely unreachable — every HTTPS connection attempt fails at the

TLS handshake stage (connection reset before any HTTP response), even though Railway's own

domain status API reports the domain as fully healthy:

Sync status: ACTIVE

Verified: yes

Certificate status: CERTIFICATE_STATUS_TYPE_VALID

Certificate detail: CERTIFICATE_STATUS_TYPE_DETAILED_COMPLETE

DNS is correctly configured and propagated — confirmed the CNAME (app -> 9i0er2i4.up.railway.app)

resolves correctly from multiple resolvers (1.1.1.1 confirmed correct target; 8.8.8.8 briefly

served a cached record from before our DNS change, expected TTL behavior, not the root cause).

Connecting directly to the resolved IP with the correct SNI (app.treehaous.com) still resets

mid-handshake:

$ curl -sv --resolve app.treehaous.com:443:69.46.46.100 https://app.treehaous.com/

• Trying 69.46.46.100:443...
• Recv failure: Connection was reset
• schannel: failed to receive handshake, SSL/TLS connection failed

What we've already tried

1. Deleted and fully recreated the custom domain in Railway (previous domain ID

   4d3fce56-3c46-4ee2-aeb2-3d7aefca9eca, target 4yxmeokk.up.railway.app -> deleted;

   new domain ID 1a80dfd4-1029-458d-bf7f-9b380f73a896, target 9i0er2i4.up.railway.app).

   Identical TLS-reset symptom on BOTH the old and the new binding.

2. Updated DNS at our registrar to the new CNAME target immediately after recreation;

   confirmed propagated via 1.1.1.1.

3. Triggered a fresh redeploy of treehaous-web (new deployment 18f8fb78-00f7-4c75-9f69-441d2e899690,

   confirmed Online) — no effect on the domain issue, as expected since redeploy doesn't touch

   edge/domain bindings.

4. Attempted railway domain certificate retry app.treehaous.com — rejected because Railway

   already considers the cert status VALID.

Why we believe this is edge-side, not client/DNS/app-side

Two sibling custom domains on the exact same service (demo.treehaous.com, admin.treehaous.com)

work perfectly right now — same account, same DNS provider, same service, same client. Only

app.treehaous.com fails, across two entirely different domain records/targets, despite the

control-plane API reporting both as healthy. This strongly suggests the TLS cert/route for this

specific hostname is not actually deployed/live on the edge fleet, out of sync with what the

domain status API reports.

We also confirmed the underlying app itself is healthy: hitting the known-good service domain

(treehaous-web-production.up.railway.app) with a Host: app.treehaous.com header returns a clean

HTTP 200.

Ask

This is a production outage for a customer-facing domain. Please check the edge/cert deployment

state for domain ID 1a80dfd4-1029-458d-bf7f-9b380f73a896 (app.treehaous.com) and force a

re-sync/re-issue on your end if the control-plane and edge fleet are out of sync. Happy to hop on

a call if that's faster.