The rewrites() approach resolves the backend URL once at server startup,
which always falls back to http://backend:8000 on Railway (where that
Docker Compose hostname doesn't exist). This caused ECONNREFUSED for
/api/analyze and all other proxied routes.
Fix: Add app/api/[...path]/route.ts that resolves the backend URL
per-request via getBackendUrl(), matching the pattern already used by
/api/chat and /api/auth/google/token routes.
Changes:
- New: frontend/app/api/[...path]/route.ts — catch-all proxy (GET/POST/PUT/PATCH/DELETE)
- Removed: frontend/app/api/chat/route.ts — now handled by catch-all
- Updated: frontend/next.config.ts — removed rewrites() block
- Updated: frontend/Dockerfile — cleared NEXT_PUBLIC_API_URL build default
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
Problem: Next.js frontend in production mode falls back to http://backend:8000
(Docker Compose internal hostname) when BACKEND_URL env var is not set.
In Railway's distributed environment, this hostname doesn't exist, causing
ECONNREFUSED errors.
Solution: Create unified getBackendUrl() function with consistent fallback
priority across all server-side proxying files:
1. Explicit BACKEND_URL (for Railway / custom deployment)
2. Development mode -> http://localhost:8000
3. NEXT_PUBLIC_API_URL (may be set in Railway)
4. Docker Compose default -> http://backend:8000
Changes:
- New: frontend/lib/backend-url.ts - centralized URL resolution
- Updated: frontend/next.config.ts - use getBackendUrl()
- Updated: frontend/app/api/chat/route.ts - use getBackendUrl()
- Updated: frontend/app/api/auth/google/token/route.ts - use getBackendUrl()
Railway users must set BACKEND_URL=https://<backend-service>.up.railway.app
Co-Authored-By: Claude Haiku 4.5 <noreply@anthropic.com>
MarkLo127
MarkLo