netstat -tulpn muestra que está escuchando en estos puertos, pero al intentar acceder, hay un tiempo de espera agotado.
Encontré que se ejecuta en la subcarpeta meta . discourse . org/t/serve-discourse-from-a-subfolder-path-prefix-instead-of-a-subdomain/30507, lo cual no es aplicable.
También encontré meta . discourse . org/t/install-discourse-on-a-residential-internet-with-cloudflare-tunnel/211297
Eso va en la dirección correcta, pero no es exactamente lo que necesito.
PD. Disculpen por eliminar los enlaces al foro, pero no puedo publicar de otra manera.
No admitimos la ejecución en puertos no estándar. Si los puertos 80/443 ya están ocupados, necesitarás usar un servidor separado donde no lo estén o ejecutar un proxy inverso desde tus otros servicios y Discourse.
A veces, «no damos soporte» significa «eso está más allá de la ayuda que puedes esperar aquí», pero esta vez significa «estás perdiendo el tiempo incluso intentándolo».
Los puertos no están “ocupados” de la manera habitual. Discourse puede tomar los puertos 80 y 443 en ese sistema, ya se está ejecutando en un servidor separado por sí mismo.
Estoy atascado en el paso para deshabilitar la redirección/eliminar el puerto en la URL y todo funcionaría como se esperaba.
Si no puedes publicar en los puertos estándar, entonces no funcionará en absoluto. Tus opciones aquí son usar un servidor donde :80/443 estén disponibles, o elegir una plataforma de discusión alternativa.
¿Puedes ayudarme con la configuración del proxy inverso de nginx?
He probado varias opciones sin éxito
server {
listen 20633 ssl;
server_name mydomain.com;
ssl_certificate /etc/letsencrypt/live/mensa.myftp.org/fullchain.pem;
ssl_certificate_key /etc/letsencrypt/live/mensa.myftp.org/privkey.pem;
location / {
# Elimina el puerto de la URL de proxy_pass usando una expresión regular
# La parte capturada de la expresión regular ($1) se reemplazará en la URL de proxy_pass
# La IP y el puerto reales del servidor backend se especifican por separado en la directiva proxy_pass
proxy_pass http://192.168.178.31:80/;
#$request_uri;
proxy_redirect http://192.168.178.31:80/ $scheme://$host:20633/;
#return 301 $scheme://$host:$server_port/home;
#proxy_redirect http://192.168.178.31:20633 $scheme://$host:80;
# Conserva la cabecera Host enviada por el cliente al servidor backend
#proxy_set_header Host $host;
proxy_set_header Host $http_host;
}
}
Ese tutorial es para ejecutar en el mismo servidor a través de un socket Unix. ¿Existe también una configuración para ejecutar el proxy inverso en un sistema diferente con un puerto diferente? Creo que debería ser así, ya que este caso podría ocurrir con más frecuencia. En el otro host ya tengo un certificado.
Para que quede claro: esta configuración es solo para pruebas. En producción se ejecutará en el puerto 443, pero para el desarrollo y las pruebas, una VM en casa es completamente suficiente y ahorra los costos de alquilar un servidor mientras tanto.