The www.camp50.ca subdomain is not currently registered as a custom domain on your service. Only the apex camp50.ca is attached (and its certificate is valid). When you deleted and re-added the domain, it appears only the apex was re-added. You'll need to add www.camp50.ca as a separate custom domain entry on the camp50 service's settings page, and a certificate will be issued for it automatically. Your CNAME and TXT records for the www subdomain are already correct, so issuance should start immediately after you add it. Reply here once you've added it and we can verify the certificate issued correctly.

This issue has resurfaced....

The www.camp50.ca domain is currently verified with a valid certificate, DNS is propagated correctly, and edge routes are installed. Our logs show successful HTTPS traffic on that hostname as recently as 22:30 UTC today, so the TLS handshake and certificate are being served normally right now.

This site can’t be reached

The connection was reset.

Try:

Checking the connection

Checking the proxy and the firewall

ERR_CONNECTION_RESET

We've looked into this from our side and haven't found anything on the Railway platform that explains what you're seeing, so working it out means digging into your specific setup.

That's exactly what the Railway community is good at, so we'd like to open your thread as a community bounty. Railway pays a bounty to the community member who solves it, and threads like this usually get picked up quickly.

Opening it makes this entire thread public, including everything already posted. Nothing becomes public until you decide. Use the buttons below.

• Open to the community - Before you click, take a moment to edit or remove anything you'd rather not share. The thread becomes publicly visible right away.
• Keep it private and close the thread - Nothing becomes public and the thread closes.

Your domain is currently accessible with a valid certificate on my end. Have you tried accessing it from an incognito tab, different device/network, or by using a VPN?

Subject: Custom domain verified but edge serves no TLS cert — valid certificate exists and is not being served (recurrence of 2026-08-04)

Project: camp50 / soothing-kindness · production · edge yyz1

Domain: www.camp50.ca (port 8080) · Edge IPs tested: 69.46.46.45, 69.46.46.80

Problem

www.camp50.ca is attached and shows verified; the service is Online. The edge accepts TCP on 443 for SNI www.camp50.ca then closes with no ServerHello — no certificate offered at all. Every browser fails.

A valid certificate for this hostname already exists. CT shows Let's Encrypt issued www.camp50.ca on 2026-08-05 08:43:14Z, valid through 2026-11-03. It is current today and is not loaded on the edge.

This is the second occurrence in 11 days (first reported 2026-08-04, same service, identical signature).

Scope: camp50.ca (apex) is also attached but its DNS is mid-change on my side — excluded from this ticket. Everything below is www.camp50.ca only.

Evidence

1. FAILING — SNI www.camp50.ca, two separate edge IPs

$ openssl s_client -connect 69.46.46.45:443 -servername www.camp50.ca
no peer certificate available

$ openssl s_client -connect 69.46.46.80:443 -servername www.camp50.ca
no peer certificate available

$ curl --resolve www.camp50.ca:443:69.46.46.45 https://www.camp50.ca
curl: (35) Recv failure: Connection was reset

2. WORKING control — same IP, *.up.railway.app SNI

$ openssl s_client -connect 69.46.46.45:443 -servername f4jmhogl.up.railway.app
subject=CN=*.up.railway.app
issuer=C=US, O=Let's Encrypt, CN=YE1
Verify return code: 0 (ok)

Edge nodes are healthy. The problem is specific to cert material for my custom domain.

3. DNS correct — verified at the authoritative nameserver, not a cached resolver

$ nslookup -type=CNAME www.camp50.ca anderson.ns.cloudflare.com
www.camp50.ca   canonical name = f4jmhogl.up.railway.app

$ nslookup f4jmhogl.up.railway.app
f4jmhogl.up.railway.app   A   69.46.46.45

Record is DNS-only / grey-cloud — no A, no AAAA, no Cloudflare proxy. It resolves straight to a Railway edge IP.

4. No issuance attempt logged today

Latest CT entry for this hostname is 2026-08-05. No ACME activity today, despite DNS being correct since 22:20 UTC and the dashboard showing verified. Provisioning appears never to have been re-enqueued.

Timeline (UTC)

| When | Event |

|---|---|

| 2026-08-05 08:43 | Cert issued, valid → 2026-11-03; service recovered |

| ~2026-08-15 | DNS migrated to Cloudflare nameservers |

| 2026-08-15 22:20 | www CNAME corrected to f4jmhogl.up.railway.app, unproxied |

| 22:24–22:56 | Polled every 60s for 32 min — no cert at any point |

| 23:59 | 1h39m after DNS correct — still no cert, on two edge IPs |

Ruled out

Not DNS (authoritative-verified) · not Cloudflare proxying (grey-cloud, resolves to your IP) · not expiry (valid → 2026-11-03) · not one bad edge node (two tested) · not client/network (Schannel, OpenSSL, curl) · not the app (fails at TLS termination) · not propagation timing (32 min continuous polling + recheck at 1h39m).

Ask

1. Load the existing cert for www.camp50.ca onto the edge, or manually re-trigger provisioning. A valid cert (2026-08-05 → 2026-11-03) exists and isn't served.
2. Check internal logs for why provisioning hasn't re-fired — verified domain, correct DNS for 1h39m, no ACME attempt in CT today. Looks never-enqueued rather than attempted-and-failed.
3. Please look at the recurrence pattern. Both occurrences followed a DNS change. If cert material is dropped when a domain's DNS stops resolving to Railway and re-provisioning isn't enqueued when corrected, that explains both — and will recur on any future DNS change.

Urgency: this site is for an event starting 2026-08-22. Login is email-magic-link only, so while it's unreachable no attendee can use it at all. A manual cert push would unblock us immediately even if root cause takes longer.

Happy to make any change on my side that would unblock issuance — but from every external check available to me, DNS and domain config are correct.

Yes it works from some networks, but not others. Most users are reporting the outage but not all.

have you tried to regenerate a new cert

most people dont perfer trying with vpn so i dont think its a good idea

solution without vpn is better

True, but I'm afraid that's the only option, if my analysis is correct.

The issue appears isolated to one ISP and not a railway issue. This case can be closed.