Artículo

Por qué una reescritura de middleware de Next.js devuelve 500 detrás de un proxy inverso

Comprenda cómo la información de protocolo reenviada puede enviar una reescritura Next.js al transporte equivocado detrás de un proxy.
— 14 de julio de 2026
Temas:Despliegue
Etiquetas:Next.jsCaddyNode.js

Una reescritura de idioma superó las comprobaciones locales, pero falló detrás del proxy inverso de producción. El error mostraba una negociación TLS dirigida a un puerto de aplicación que atendía HTTP. La diferencia importante era la solicitud que llegaba a través del proxy.

Inspeccione el destino resuelto

La reescritura copiaba la URL entrante y cambiaba su ruta por una ruta interna en inglés. En el despliegue afectado, el protocolo reenviado y el host de la aplicación formaban un destino HTTPS sobre un puerto HTTP. Inspeccionar esa URL explicó el fallo EPROTO.

Haga coincidir el transporte con el servicio real

Ajustamos el destino al transporte del servicio interno. Eso resolvió la incompatibilidad TLS en ese despliegue. No implica que toda reescritura Next.js deba forzarse a HTTP: el tratamiento del origen depende de la versión del framework, la configuración del proxy y el destino.

Cambiar el esquema también puede cambiar el origen. La solicitud reescrita puede volver a entrar en el enrutamiento e interactuar con redirecciones canónicas. Nuestra investigación posterior del bucle de redirección mostró por qué corregir el transporte era solo parte del contrato.

Verifique el recorrido completo

  • Ejecute la solicitud mediante un proxy representativo que termine TLS.
  • Inspeccione protocolo, host y destino efectivos sin registrar secretos.
  • Compruebe rutas sin prefijo, con prefijo de idioma y redirecciones canónicas.
  • Siga las redirecciones hasta la respuesta final y verifique la página.
  • Compruebe cómo se confía en los marcadores internos y si un solicitante externo puede suplantarlos.

Use comprobaciones de despliegue representativas

Una solicitud directa al puerto de la aplicación puede omitir el comportamiento de los encabezados reenviados. Una compilación correcta también. La comprobación debe recorrer la ruta del visitante y distinguir una versión nueva en servicio de una reversión correcta. Registre la versión del framework y la configuración del proxy para reevaluar la corrección cuando cambien.