netstat -tulpn mostra che è in ascolto su queste porte, ma quando si tenta di accedere, si verifica un timeout.
Ho trovato un articolo che esegue su sottocartella meta . discourse . org/t/serve-discourse-from-a-subfolder-path-prefix-instead-of-a-subdomain/30507 che non è applicabile.
Ho trovato anche meta . discourse . org/t/install-discourse-on-a-residential-internet-with-cloudflare-tunnel/211297
Che va nella giusta direzione, ma non è esattamente quello di cui ho bisogno.
PS Mi scuso per aver rimosso i link al forum, ma altrimenti non posso pubblicare.
Non supportiamo l’esecuzione su porte non standard. Se le porte 80/443 sono già occupate, dovrai utilizzare un server separato in cui non lo sono o eseguire un proxy inverso dai tuoi altri servizi e Discourse.
A volte “non supportiamo” significa “è al di là dell’aiuto che puoi aspettarti qui”, ma questa volta significa “stai perdendo il tuo tempo anche solo provandoci”.
Le porte non sono “occupate” nel modo consueto. Discourse può utilizzare le porte 80 e 443 su quel sistema, è già in esecuzione su un server separato per conto proprio.
Sono bloccato al passaggio per disabilitare il reindirizzamento/rimuovere la porta nell’URL e tutto funzionerebbe come previsto.
Se non è possibile pubblicare sulle porte standard, non funzionerà affatto. Le tue opzioni sono utilizzare un server in cui :80/443 sono disponibili, oppure scegliere una piattaforma di discussione alternativa.
Puoi aiutarmi con la configurazione del reverse proxy nginx?
Ho provato varie opzioni senza successo
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 / {
# Rimuove la porta dall'URL di proxy_pass utilizzando un'espressione regolare
# La parte catturata dell'espressione regolare ($1) verrà sostituita nell'URL di proxy_pass
# L'effettivo IP e la porta del server backend sono specificati separatamente nella direttiva 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;
# Preserva l'header Host inviato dal client al server backend
#proxy_set_header Host $host;
proxy_set_header Host $http_host;
}
}
Quel tutorial serve per l’esecuzione sullo stesso server tramite socket Unix. Esiste anche una configurazione per eseguire il proxy inverso su un sistema diverso con una porta diversa? Penso di sì, dato che questo caso potrebbe verificarsi più spesso. Sull’altro host ho già un certificato.
Solo per essere chiari: questa configurazione è solo per test. In produzione verrà eseguito sulla porta 443, ma per lo sviluppo e il test una VM a casa è completamente sufficiente e consente di risparmiare i costi di affitto di un server nel frattempo.