Project: adequate-learning (id: 34547050-1108-4760-9ed1-64f2de6a3950)

▎ Environment: production (id: a96b032f-59d0-4fa8-b3d7-acd5339ea58b)

▎ Service: saveri (id: 21af9afc-43b7-4f7d-b047-046d8dc7c042)

▎ Domain: saveri-production.up.railway.app (current domain id: c50315e6-a9f5-4c0b-8b58-150d3d7bf7c9, target port 3000, sync status ACTIVE)

▎

▎ Every HTTP request to this domain — any path (/, /health, /webhook) — returns 403 with zero content-length, served directly by railway-hikari (your edge), never reaching my container. Confirmed via curl from two different locations and from a laptop browser.

▎

▎ Reproduced from at least two different Railway edge PoPs:

▎ - x-railway-edge: bcn1, x-hikari-trace: bcn1.jwax, request-id odfGbElES6eILBUC6WHkDg, 2026-09-17 10:27:37 GMT

▎ - x-railway-edge: cdg1, x-hikari-trace: cdg1.8vsn, request-id nAQsC5n4SH6Hk6Sqjq4OvQ, 2026-09-17 14:02:26 GMT

▎

▎ What I've already ruled out:

▎ - App health: container logs show a clean start with no errors (latest deploy b18887aa, commit 901529e, SUCCESS status). The app itself successfully calls Telegram's setWebhook against this same domain on startup.

▎ - Domain config: deleted the original domain (id dafba5d6-dea6-4f8b-af5d-07f6deac7bb5) and generated a brand new one with the same hostname — the new domain still returns 403 identically.

▎ - Billing/account: Hobby plan, $2.40 of $5.00 included usage, no suspension notice anywhere in the dashboard.

▎ - Deployment history: clean, no stuck/duplicate deployments — old ones properly REMOVED as new ones succeed.

▎

▎ Since this is edge-level (never reaches the container, per the railway-hikari server header and zero-byte body) and reproduces across regions, I suspect a block or misconfiguration on Railway's side tied to this service/domain/account rather than anything in my app. Could you check for any WAF/abuse rule or account-level restriction applied to this service? Happy to provide more request IDs if useful.