Skip to content

Why does server-side rendering fail when browser API calls work?

1 min read · main part only; folded sections are optional

After this you can answer: Why does server-side rendering fail when browser API calls work?

Service Connect supplies short service names through an ECS-managed proxy and a Cloud Map HTTP namespace. This is not a Route 53 private DNS zone. The configured client aliases let application code use api:4000 and web:3000.

Across the VPC, web-to-API proxy traffic enters port 14000, allowed from the web security group. API-to-web revalidation enters proxy port 13000, allowed from the API group. Public ALB requests still enter the application ports directly. That separation preserves the public path’s proxy-header assumptions.

Service discovery also has a startup ordering issue: existing client tasks may need replacement to learn a newly introduced service name. CD restarts the API once when the web service is first introduced. I would compare task creation times and Service Connect configuration before repeatedly restarting random services. In ALB-only mode the public route and the private route remain distinct even though the old CloudFront restriction is absent.

Would opening API port 4000 to the web group fix the proxy route?
The configured server proxy uses 14000. Change the exact proxy rule if missing; opening another port does not prove that route works.
Why not call the public ALB internally?
It adds a public dependency and mode-specific entry policy. The private path keeps internal calls inside the VPC.
What is the operational cost?
Another proxy and discovery configuration to observe and deploy. A simple URL is not evidence that the underlying path is simple.

Read the path chapter, select the relevant map piece →, then inspect infra/src/compute/service-connect.ts → createServiceConnect. Work through the related case for a diagnostic example.

Read this book online: https://book.theversehub.in/