18 days ago
Os deploys buildam com sucesso e o container roda limpo (confirmado via logs — sem crashes, porta correta vinculada), mas a borda da plataforma (railway-hikari) retorna um 404 sintético (corpo vazio/minúsculo, nunca chega no app) para toda requisição HTTP, tanto em domínio customizado quanto em domínios *.up.railway.app. Isso é reproduzível em 3 serviços diferentes, 2 projetos diferentes, e 2 implementações de servidor HTTP diferentes. Um serviço irmão no mesmo projeto (backend/Express) funciona normalmente o tempo todo.
Recursos afetados:
Projeto: pedexpress-teste (ID: 5861a219-ed52-4778-aa84-1ba001bba544)
Ambiente: production (ID: a1eb438d-1eca-4692-9905-c5cfbed8868a)
Serviço frontend (ID: f9dbba47-c477-4990-8d86-a011389e0c7a), domínio teste.pedexpress.store
Serviço frontend-v2 (ID: 23a79978-349e-4580-8796-73df1edbf346), domínio frontend-v2-production-32e9.up.railway.app
Projeto de teste isolado pedexpress-routing-test (ID: 291389b1-47b9-458a-a49f-210d69ecd5b7), serviço frontend-test (ID: 5c98e24d-1d0f-4a6c-b799-78994e2aecd9), domínio frontend-test-production-a714.up.railway.app
Controle funcional para comparação: serviço backend em pedexpress-teste, domínio api.teste.pedexpress.store — funciona corretamente (200 OK, resposta JSON real) durante todo o teste.
Reprodução:
curl -v https://teste.pedexpress.store/
curl -v https://frontend-v2-production-32e9.up.railway.app/
curl -v https://frontend-test-production-a714.up.railway.app/
Os três retornam:
HTTP/1.1 404 Not Found
Server: cloudflare (domínio customizado) / railway-hikari (domínio nativo)
x-hikari-trace: gru1.xxxx
x-railway-edge: gru1
com corpo praticamente vazio (~5 bytes), enquanto os logs de runtime do deploy correspondente mostram o container iniciando limpo e escutando na porta correta (8080), com zero linhas de log de requisição recebida — indicando que a borda nunca encaminha a requisição ao container.
Ações já tomadas (nenhuma resolveu):
Corrigido o Root Directory do serviço frontend de frontend para . (raiz do monorepo) — confirmado aplicado via metadata do deployment (rootDirectory: "."), o build passou a instalar corretamente todos os workspaces do monorepo (484 pacotes) em vez de só a subpasta frontend.
Múltiplas tentativas de railway redeploy após a correção — builds bem-sucedidos, borda continua 404.
Reconectada a fonte GitHub do frontend (mesmo repo/branch) para descartar um snapshot de build travado — novo hash de snapshot confirmado, build passa, borda continua 404.
Reiniciado o serviço frontend — reinício limpo do container confirmado via logs, borda continua 404.
Domínio customizado teste.pedexpress.store apagado e recriado — novo alvo de CNAME emitido e DNS atualizado, borda continua 404.
Criado um serviço novo frontend-v2 no mesmo projeto, mesmo repo/branch, domínio novo gerado pelo Railway, targetPort definido explicitamente pra bater com a porta real da aplicação (8080) — borda continua 404.
Testadas duas implementações de servidor HTTP diferentes no frontend-v2 (vite preview e o pacote npm serve) — ambas confirmadas rodando limpo nos logs, ambas ainda pegam 404 na borda.
Criado um projeto inteiramente novo e isolado (pedexpress-routing-test) com um único serviço novo, pra descartar corrupção de estado no nível do projeto — o mesmo comportamento de 404 se reproduziu lá também.
Aguardado 15+ minutos após a criação de domínio novo pra descartar atraso de propagação DNS/CDN — sem mudança.
O que funciona: o serviço backend no mesmo projeto/ambiente (app Express simples) respondeu corretamente (200 OK) em todo teste ao longo de toda essa investigação, usando o mesmo Root Directory (null/raiz do repo), mesma região (ams), mesma convenção de porta ($PORT → 8080), e a mesma borda (gru1/hikari).
Pergunta para o suporte: Dado que o container está confirmadamente saudável e escutando corretamente, e isso se reproduz em múltiplos serviços e até um projeto novo isolado, isso parece ser um problema de roteamento/borda do lado da plataforma, não algo corrigível do nosso lado via CLI ou dashboard. Poderiam investigar por que a borda (hikari) não está encaminhando tráfego para esses deploys específicos? Posso compartilhar os IDs de deployment se precisarem:
deploy frontend: 5c557af3-caa1-441a-9100-09a4b6310f4e
deploy frontend-test: 8570a35d-90ea-4de7-aed9-f38d378f496b
1 Replies
18 days ago
Apologies, we only correspond in English. Please open a new thread in English.
Status changed to Closed Railway • 18 days ago