12 days ago
Project heartfelt-optimism (0707e41f-b036-4772-9192-7b9a5bb381cd), production, Hobby plan. Six custom domains across three services.
SYMPTOM: every custom domain shows Verified: yes, CERTIFICATE_STATUS_TYPE_VALID / DETAILED_COMPLETE in the CLI, yet most are not served by the edge. TCP to :443 connects, but a TLS ClientHello with the custom SNI (e.g. api.ssacards.ru) gets NO ServerHello at all - the handshake hangs until timeout. The SAME edge IP with SNI target.up.railway.app completes TLS instantly, and the services work fine on their railway.app domains. Plain HTTP :80 on the custom domains also times out. Reproduced from multiple networks (EU and US).
DNS IS CORRECT: Cloudflare, grey-cloud (DNS only), CNAME flattening at the apex. Each name resolves exactly to the IP of its per-domain CNAME target. The railway-verify TXT records are in place for all six names (that is how the certs got issued).
ALREADY TRIED: (1) redeploying the services - no change; (2) railway domain certificate retry - refused, only available after issuance fails and ours are VALID; (3) delete + immediate re-add of ssacards.ru - fresh cert VALID in ~2 minutes, edge still hangs; (4) delete + 15-minute pause + re-add of ALL SIX domains - partial: ssacards.ru and www.ssacards.ru came alive within ~2 minutes, the other four have been Verified/VALID/COMPLETE for hours and the edge still hangs their handshake.
TIMELINE (UTC): domains first added 2026-08-09 ~13:30; certs VALID since ~16:45; partial recovery ~19:45; four still dead as of 2026-08-09 ~20:30 and counting.
DOMAIN IDS - WORKING: ssacards.ru 8152bd81-2573-4805-a86f-84f2cb5045ed, www.ssacards.ru 165a4f2d-c6a5-478e-9d72-a550f83de89e. STUCK (cert VALID, edge hangs): api.ssacards.ru ef35bec8-c565-4121-b0f9-ea66586979dd, ssa-navigator.ru cdc99981-729b-4c75-a73b-0218b8c0b57d, www.ssa-navigator.ru 8bf55250-8c55-47ac-9377-5408d3b3a4c7, api.ssa-navigator.ru 338f5b38-974b-4367-8215-567224075873.
Could you re-push the edge bindings / check the certificate distribution pipeline for these four domains? Happy to provide more diagnostics.
3 Replies
12 days ago
This thread has been opened as a bounty so the community can help solve it.
Status changed to Open Railway • 12 days ago
12 days ago
I’m able to access the sites you claimed to be broken just fine. Have you tried using a VPN?
11 days ago
The key point is that certificate issuance and edge binding appear to be separate in this case. Since the certificates are already VALID/COMPLETE and the same Railway edge IP completes TLS correctly with the railway.app SNI, this looks like the custom-domain binding is not being propagated to the edge rather than a DNS or certificate issuance problem.
Could you please manually re-push/reconcile the edge bindings for the four affected domains and check whether their certificate/hostname mappings have been fully distributed across the edge? In particular, could you verify the edge configuration for api.ssacards.ru (ef35bec8-c565-4121-b0f9-ea66586979dd), ssa-navigator.ru (cdc99981-729b-4c75-a73b-0218b8c0b57d), www.ssa-navigator.ru (8bf55250-8c55-47ac-9377-5408d3b3a4c7), and api.ssa-navigator.ru (338f5b38-974b-4367-8215-567224075873)?
The fact that ssacards.ru and www.ssacards.ru recovered after being removed and re-added, while the other four remain stuck despite having VALID/COMPLETE certificates, makes me suspect stale or missing edge bindings rather than an issue with DNS, validation, or the services themselves.
If possible, please also check whether these four domains are present in the active edge hostname/SNI routing configuration and whether their certificate deployments have reached all edge nodes. A manual edge reconciliation or re-provisioning of the custom-domain bindings would be greatly appreciated.
I can provide additional curl, openssl s_client, DNS, traceroute, or packet-level diagnostics if needed.
10 days ago
Update + re: moderator: the working domains (ssacards.ru, www.ssacards.ru) do open - the issue is the STUCK ones. Just re-verified from an independent non-RU network minutes ago: TLS to the stuck domains fails (no ServerHello / socket closed), while ssacards.ru opens fine from the same vantage. Reproduced from RU, EU and US networks - not a VPN/geo issue. New cycle attempted (Aug 10 ~18:00 UTC): deleted all four stuck domains, waited 15+ min, re-added, updated CNAMEs. The lottery reproduced exactly: 1 of 4 (api.ssa-navigator.ru) came alive within minutes, 3 are stuck again with fresh certs VALID/COMPLETE. NEW domain IDs (IDs in the opening post are obsolete): api.ssacards.ru 89ecd1a1-ec2d-4896-8f3d-87ec1dd0d6f0 (service back ssa navigator), ssa-navigator.ru 8952756e-ebf6-482f-b36e-a1be921575e1, www.ssa-navigator.ru 616fef5a-cf49-4605-aad8-0eab52e74c74 (both front ssa navigator). Possibly related data point: on Aug 10 (~17:21 UTC) two consecutive deployments of 'back ssa navigator' (the service carrying api.ssacards.ru) failed at 'Deploy -> Configure network' with 'Error: configuring network' after ~7 min each, while the container itself was up and serving internal traffic; a manual redeploy of the same commit then succeeded. Smells like the same edge-binding pipeline hiccuping. mendesdevel0per - thanks, agreed, that is exactly our read: issuance is fine, binding distribution is not. Railway team: could you manually reconcile / re-push the edge bindings for the three NEW stuck IDs above? Happy to provide curl/openssl traces if useful.