ELB Headers Configuration

TODO: collapasable, copyable, download, etc

I have a sveltekit app running on localhost:8081 and I am exposing it on on an AWS elb. When I git it with the elb hostname, the NodeJS server side code parses the incoming request as localhost:8081 instead of the ELB's domain name on port 443. What am I missing?When you're exposing a SvelteKit app (or any web application) through an AWS Elastic Load Balancer (ELB) and noticing that the NodeJS server-side code parses incoming requests as localhost:8081 instead of the ELB's domain name on port 443, it typically involves a discrepancy in how the host and protocol headers are managed or forwarded by the ELB and interpreted by your application. Here are a few areas to check and configure to ensure your application recognizes the original host and protocol used by clients:

1. Forwarded Headers

Ensure your ELB is configured to pass the original Host header and the X-Forwarded-Proto header to your application. These headers are crucial for your application to understand the original request's domain and protocol (HTTP or HTTPS).

• X-Forwarded-For: The IP address of the client.
• X-Forwarded-Proto: The protocol (HTTP or HTTPS) used by the client.
• X-Forwarded-Port: The port used by the client.
• Host: The original host requested by the client.

For an Application Load Balancer (ALB), you can configure these settings in the listener rules.

2. Application Configuration

On the application side, you may need to configure your SvelteKit or underlying NodeJS server to trust these headers. This is because, by default, applications may not trust proxy headers for security reasons.

• If you're using an Express server beneath SvelteKit, you might need to tell the application to trust the proxy:

  app.set('trust proxy', true);
  

  This tells the Express app to trust the headers forwarded by the ELB, allowing the application to use X-Forwarded-Proto and Host headers to reconstruct the original URL.

• For SvelteKit specifically, you might need to adjust your configuration or server.js file to ensure it respects these headers. This might involve custom code to parse these headers and set the base URL or protocol accordingly.

3. AWS ELB Configuration

Ensure your ELB (especially if it's an ALB) is correctly configured to handle HTTPS traffic and that it's forwarding requests to the appropriate target group. If you're terminating SSL at the ELB, the connection from the ELB to your application might be over HTTP, even if the original request to the ELB is HTTPS. This is where X-Forwarded-Proto becomes essential.

4. Review Documentation

AWS documentation provides guidance on configuring listener rules for your ELB to forward these headers. Additionally, the SvelteKit and Express (if applicable) documentation may offer insights into handling proxied headers.

5. Debugging Headers

To diagnose the issue, you might temporarily modify your application to log all headers received on incoming requests. This can help you verify whether the necessary headers are being forwarded by the ELB and received by your application as expected.

app.use((req, res, next) => {
  console.log(req.headers);
  next();
});

By ensuring that your ELB is correctly configured to forward the necessary headers, and your application is configured to trust and use these headers, you should be able to maintain the original request's domain and protocol throughout your application.

ELB Headers Configuration created at Tue Jan 20 1970 18:22:40 GMT+0000 (Coordinated Universal Time)