Hacktoberfest 2026: los issues que los mantenedores marcaron para octubre, abiertos y aptos para principiantes. Explorar issues de Hacktoberfest

stack: the gateway sets no X-Forwarded-For or X-Real-IP, so Edge Functions cannot see the client IP

Abierto Apto para principiantes
  • ¿Algo no está bien?
#7,275 0 comentarios 0 reacciones 0 asignados Ver en GitHub

Los mantenedores suelen responder en 1 día

Nadie ha tomado este issue todavía.

Evaluación

Dificultad
2/5
Tiempo estimado
1-3 horas
Aptitud para principiantes
72/100
Tipo de issue
Error
Claridad
Bien especificado
Estado de actividad
Activo
Stack tecnológico
typescript
Área
backend

Línea de trabajo

Lee packages/stack/src/HttpProxy.ts, especialmente upstreamHeadersFor y el uso de request.socket.remoteAddress en el registro de acceso. Reproduce el problema con el comando de stack nativo indicado y la función hello, y luego comprueba que la función recibe ambos encabezados de reenvío con la dirección del cliente, tal como ocurre con el comportamiento del stack heredado.

Escrito por el modelo de indexación a partir del texto del issue.

Descripción

🐛 Bug supabase/cli
Affected area

Local development

Supabase CLI version

2.121.0

Operating system

macOS 27.0.1 (Apple silicon)

Installation method

pnpm

Command
SUPABASE_EXPERIMENTAL_STACK=1 supabase start --runtime native
for i in 1 2 3 4 5; do curl -s -w '  %{time_total}s\n' http://127.0.0.1:54321/functions/v1/hello; done
Actual output
{"requests":1,"workerStartedAt":"2026-10-22T04:47:49.507Z","xForwardedFor":null,"xRealIp":null}  1.111719s
{"requests":1,"workerStartedAt":"2026-10-22T04:47:49.553Z","xForwardedFor":null,"xRealIp":null}  0.023354s
{"requests":1,"workerStartedAt":"2026-10-22T04:47:49.586Z","xForwardedFor":null,"xRealIp":null}  0.018719s

# same project on the legacy stack (SUPABASE_EXPERIMENTAL_STACK=0 supabase start)
{"requests":1,"workerStartedAt":"2026-10-22T04:48:40.137Z","xForwardedFor":"192.168.171.1","xRealIp":"192.168.171.1"}  0.056585s
{"requests":2,"workerStartedAt":"2026-10-22T04:48:40.137Z","xForwardedFor":"192.168.171.1","xRealIp":"192.168.171.1"}  0.004061s
{"requests":3,"workerStartedAt":"2026-10-22T04:48:40.137Z","xForwardedFor":"192.168.171.1","xRealIp":"192.168.171.1"}  0.003451s

On the experimental stack the function gets neither X-Forwarded-For nor X-Real-IP. On the legacy stack Kong sets both to the client address.

Expected behavior

The experimental stack's gateway adds the client address as X-Forwarded-For and X-Real-IP, like Kong does on the legacy stack, so functions see who is calling them.

Steps to reproduce
  1. mkdir repro && cd repro && supabase init
  2. Create supabase/functions/hello/index.ts: 
    let requests = 0;
const workerStartedAt = new Date().toISOString();

Deno.serve((req) =>
  Response.json({
    requests: ++requests,
    workerStartedAt,
    xForwardedFor: req.headers.get("x-forwarded-for"),
    xRealIp: req.headers.get("x-real-ip"),
  })
);
  3. Add to supabase/config.toml: 
    [functions.hello]
verify_jwt = false
  4. SUPABASE_EXPERIMENTAL_STACK=1 supabase start --runtime native, then call the function as above. Both header fields are null.
  5. Stop it, start the legacy stack with SUPABASE_EXPERIMENTAL_STACK=0 supabase start (I passed -x for everything except the database, Kong and the edge runtime) and make the same call. Both fields hold the client address.

(The requests counter is for #7274 and doesn't matter here.)

Crash report ID

No response

Docker and service versions
Docker: Client 29.8.2, Server 29.8.2 (linux/arm64)

supabase/postgres       17.11.0.004
supabase/gotrue         v2.197.0
postgrest/postgrest     v16.4
supabase/realtime       v2.143.4
supabase/storage-api    v1.82.1
supabase/edge-runtime   v1.77.4
supabase/studio         2026.10.12-sha-3699278
supabase/postgres-meta  v0.100.0
supabase/logflare       1.53.0
supabase/supavisor      2.9.13
Additional context

In the v2.121.0 tag (97531eb590ccd2c5cf215287ae03e877180810b4), packages/stack/src/HttpProxy.ts builds the upstream headers in upstreamHeadersFor (lines 132-148). It copies the client's headers, drops hop-by-hop ones and rewrites host and the API key, but adds no forwarding headers. The client address is already there: the access log reads request.socket.remoteAddress (line 156). develop and next have no forwarding headers in that file either.

Our functions rate-limit by client IP, taken from the first X-Forwarded-For hop, and answer 400 when there is none. So on the native runtime every one of those functions fails locally, while the same project works on the legacy stack. Sending X-Forwarded-For from the client gets past it, because the gateway passes client headers through, but that means changing every caller just for local development.

I investigated this with help from an AI coding assistant (Claude Code), which also drafted this text. The results above come from real runs.

Lenguaje dominante
TypeScript
Estrellas
2.4k
Forks
537
Merge medio
19 h 40 min
PR fusionados (30 d)
403

Preparar el entorno

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de supabase/cli

Todos los issues de supabase/cli

Issues similares

Más issues de TypeScript

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.