Solución de problemas de cargas S3: el sitio se cuelga después de la reconstrucción, los activos JS no se cargan con net::ERR_... en R2 y GCS

Hola equipo y comunidad de Discourse,

He estado intentando configurar mi instancia de Discourse autoalojada para usar un almacenamiento de objetos externo compatible con S3, pero me he encontrado con un problema muy persistente e inusual. Estaría muy agradecido por cualquier ayuda.

Mi Entorno:

  • Versión de Discourse: Instalación Docker estándar, la última tests-passed.

  • Host: [TU PROVEEDOR DE VPS y OS] (请在这里填入您的服务商和系统)

  • Proxy Inverso: Caddy

Objetivo: Mi objetivo es mover todas las cargas (cargas de usuario y activos del sitio) del almacenamiento local a un proveedor externo.

Resumen del Problema: Después de configurar app.yml para S3 (ya sea Cloudflare R2 o Google Cloud Storage) y ejecutar ./launcher rebuild app, el sitio se queda colgado en la pantalla de carga inicial (el spinner azul). Las herramientas de desarrollador del navegador muestran que la mayoría de los activos principales de JavaScript no se cargan desde la URL CDN externa con un error de red genérico (net::ERR_...).

Pasos de Depuración Realizados:

  1. Intento con Cloudflare R2:

    • Configuré un bucket de Cloudflare R2, creé un Token de API (Lectura y Escritura de Objetos) y conecté un dominio personalizado (s3.ryzelan.sbs) a través de DNS de Cloudflare.
    • Configuré app.yml con las credenciales de R2, el dominio personalizado como el endpoint/URL CDN, y establecí DISCOURSE_FORCE_HTTPS: true y DISCOURSE_S3_FORCE_PATH_STYLE: true.
  2. Prueba Crucial - Cambio a Google Cloud Storage:

    • Para descartar un problema específico de Cloudflare, revertí todos los cambios e hice una configuración nueva con Google Cloud Storage utilizando claves de interoperabilidad S3.
    • Después de reconstruir con la configuración de GCS, encontré el mismo patrón de fallo de carga de JavaScript que con R2.

Estado Actual:

  • El proceso ./launcher rebuild app se completa sin mostrar ningún error en la terminal.
  • El contenedor app se está ejecutando correctamente después de la reconstrucción (verificado con docker ps).
  • El comando ./launcher logs app no muestra errores; todos los servicios internos (unicorn, redis, postgres) parecen estar funcionando normalmente.
  • El problema parece ser un fallo a nivel de red cuando el navegador intenta obtener los activos JS de la URL CDN externa configurada, y esto ocurre independientemente del proveedor (R2 o GCS) utilizado.

Aquí está el bloque de configuración final de app.yml que utilizamos para R2 (el de GCS fue similar):

— Cloudflare R2 S3 Configuration START (Final Version) —

DISCOURSE_FORCE_HTTPS: true
DISCOURSE_USE_S3: true
DISCOURSE_S3_REGION: “us-east-1”
DISCOURSE_S3_ENDPOINT: “https://s3.ryzelan.sbs
DISCOURSE_S3_CDN_URL: “https://s3.ryzelan.sbs
DISCOURSE_S3_ACCESS_KEY_ID: “REDACTED”
DISCOURSE_S3_SECRET_ACCESS_KEY: “REDACTED”
DISCOURSE_S3_BUCKET: “ryzelan-discourse”
DISCOURSE_S3_FORCE_PATH_STYLE: true

— Cloudflare R2 S3 Configuration END —

Mi Pregunta: ¿Qué podría causar que una reconstrucción nueva de Discourse falle consistentemente al cargar sus propios activos de dos proveedores de nube importantes y diferentes con un error de red? ¿Existe algún problema conocido con ciertos entornos de red de VPS, redes de Docker o Caddy que pudiera estar causando esto?

Gracias por su tiempo y cualquier información que puedan proporcionar.

¿Incluiste el código para subir esos activos a S3?

Si no haces eso, ninguno de los activos estará en S3 y el sitio no cargará.

@Ryze_Chen ¿pudiste resolver tu problema?

Este tema se cerró automáticamente 7 días después de la última respuesta. Ya no se permiten nuevas respuestas.