Usa Caddy invece di NGINX come tuo reverse proxy

[Discourse]

Ecco alcune note su come ho avviato la mia istanza di prova di Discourse con Caddy Server.

Cose fantastiche su Caddy:

• Usano Discourse

• SSL gratuito con Let’s Encrypt

• HTTP2 e QUIC pronti all’uso

• Più facile da configurare di nginx

Contro:

• Non testato sul campo come apache, nginx e compagnia bella.

Come Fare

Preparazione di Discourse

Per prima cosa, devi applicare queste modifiche al tuo app.yml:

templates:
  - "templates/postgres.template.yml"
  - "templates/redis.template.yml"
  - "templates/web.template.yml"
  - "templates/web.ratelimited.template.yml"
  - "templates/web.socketed.template.yml" # <<<<<----- QUESTO È NUOVO

## Lascia questi due commentati
#  - "templates/web.ssl.template.yml"
#  - "templates/web.letsencrypt.ssl.template.yml"

## Lascia questi due commentati 
expose:
#  - "8080:80"   # http
#  - "443:443" # https

env:
  ## Questo dovrebbe essere commentato
  #LETSENCRYPT_ACCOUNT_EMAIL: mymail@gmail.com
  ## Questo è richiesto per evitare avvisi di contenuti misti quando si è dietro a un reverse proxy
  DISCOURSE_FORCE_HTTPS: true

Preparazione di Caddy

Nello spirito di Discourse, mettiamo Caddy anche in un’immagine Docker

Prima prepara con:

mkdir -p /var/caddy/data /var/caddy/config
nano /var/caddy/Caddyfile

Aggiungi quanto segue al Caddyfile (usando la sintassi Caddy v2):

{
  email MYEMAILHERE@gmail.com
}

forum.example.com { # il tuo dominio qui
  reverse_proxy unix//sock/nginx.http.sock
}

Salva ed esci.

Testiamo

Ora devi ricostruire Discourse:

cd /var/discourse
./launcher rebuild app

E poi esegui Caddy:

docker run -d \
    -v /var/caddy/Caddyfile:/etc/caddy/Caddyfile \
    -v /var/caddy/data:/data \
    -v /var/caddy/config:/config \
    -v /var/discourse/shared/standalone:/sock \
    -p 80:80 -p 443:443 \
    -p 443:443/udp \
    --restart=always \
    --name caddy \
    caddy:latest

Alla fine, il tuo forum dovrebbe essere disponibile al tuo dominio, utilizzando SSL + HTTP2 + QUIC. Non puoi essere più hipster di così.

[mholt (Matt)]

I run Caddy’s Discourse forums with this Caddyfile and no container:

forum.caddyserver.com

timeouts off
proxy / localhost:8080 {
	transparent
}

I just set up Discourse (with one easy tweak) and ran Caddy on the host machine.

^ This setup has been tested, and I can confirm it has been running with no glitches for months.

[Whitestrake (Matthew Fay)]

I like how you’ve proxied to the socket and left the ports unexposed.

Neat little guide that one can use as a guideline to easily incorporate their Discourse installation to an existing Caddy proxy, too. Cheers!

[RoldanLT]

@Falco

They use Discourse

But using nginx, as I can see now.

[Falco]

@RoldanLT

@Falco

They use Discourse

But using nginx, as I can see now.

Well, I have more than 1 Discourse install with Caddy in the front, but I didn’t bother to replace the server header and it still shows nginx. Can be the same. Or they are just using the simple Discourse install and have no need to run a reverse proxy at all in the front.

[pfaffman (Jay Pfaffman)]

My Discourse sites behind Caddy show nginx as the server too. I guess that transparent setting might make Caddy, uh, transparent.

[mholt (Matt)]

That might be a bug from a recent change, it didn’t used to do that.

[honggian]

Dear @Falco

Thank you so much for your posting.

I would like to install discourse using caddy condition, but I was confused with your docker command.

I never heard about the caddy, so I follow the digital ocean document

How To Host a Website with Caddy on Ubuntu 16.04 | DigitalOcean

My question is, in the current server situation, Should I change the path
from etc/Caddyfile to /etc/caddy/Caddyfile?

docker run -d \
    -v /var/caddy/Caddyfile:/etc/Caddyfile \
    -v /var/caddy:/root/.caddy \
    -v /var/discourse/shared/standalone:/sock \
    -p 80:80 -p 443:443 \
    -p 80:80/udp -p 443:443/udp \
    --restart=always \
    --name caddy \
    --entrypoint "/usr/local/bin/caddy" \
    abiosoft/caddy -quic -email MYEMAILHERE@gmail.com -agree --conf /etc/Caddyfile --log stdout

Sincerely

[tachibanalolo]

@Falco

unix:/sock/nginx.http.sock

Questo non funziona sul mio server. Per me, ho usato:

unix:/var/discourse/shared/standalone/nginx.http.sock

E questo è per caddy v1. Per caddy v2, usa:

unix//var/discourse/shared/standalone/nginx.http.sock

Basta sostituire “:” con “/”.

[Falco]

Quel percorso funziona se stai seguendo la guida nell’OP e stai eseguendo Caddy in docker e montando i volumi come specificato. Se non stai seguendo la guida, ci saranno percorsi diversi, sì.

[RPaladin]

@Falco

Usano Discourse

Il dominio e il sottodominio del loro forum sono ora denominati sotto questo.

[ARHAEEM (A.R.)]

Mi scuso per aver riaperto vecchie discussioni, sto cercando di far funzionare Caddy con Discourse. Nella tua configurazione di Caddy, usi “proxy”, ma quando lo uso, dice che c’è un errore di sintassi e che non è valido. “proxy” non è ora stato cambiato in “reverse_proxy”?

ecco la mia configurazione:

forum.example.com {
    reverse_proxy / unix//var/discourse/shared/standalone/nginx.http.sock {
        transparent
    }
}

[pfaffman (Jay Pfaffman)]

@ARHAEEM

Non è stato forse cambiato “proxy” in “reverse_proxy”?

Penso di sì. Ci hai provato?

[bananaman]

Grazie Matt!
Posso confermare che la configurazione senza container funziona ancora nel 2025

forum.website.com {
        reverse_proxy localhost:8080
}

Usare solo “proxy” non ha funzionato.

[manuel (Manuel Kostka)]

@bananaman

Confermo che la configurazione senza container funziona ancora nel 2025

Funziona benissimo anche per me!

Tuttavia, ho ricevuto avvisi di “Contenuto misto” seguendo quella configurazione molto semplice:

Per risolverli, ho dovuto aggiungere una direttiva aggiuntiva alla sezione env del file di configurazione (app.yml o web_only.yml):

# FORCE SSL
DISCOURSE_FORCE_HTTPS: true

[manuel (Manuel Kostka)]

Per riferimento, questi sono i passaggi attuali per una configurazione non dockerizzata che utilizza Caddy come proxy inverso:

1) Regola il file di configurazione di Discourse

• Commenta i certificati

  templates:
  #  - "templates/web.ssl.template.yml"
  #  - "templates/web.letsencrypt.ssl.template.yml"
  

• Cambia il mapping delle porte e disabilita il mapping 443

  expose:
  - "8080:80"   # http
  # - "443:443" # https
  

• Forza HTTPS per servire file statici

  env:
  DISCOURSE_FORCE_HTTPS: true
  

2) Ricostruisci Discourse

./launcher rebuild app

3) Configura Caddy

• Installa Caddy, utilizzando solo le impostazioni predefinite ufficiali: Install — Caddy Documentation

• Regola /etc/caddy/Caddyfile

  forum.example.com {
        reverse_proxy localhost:8080
  }
  

  Se hai multisito, puoi semplicemente elencare i tuoi domini:

  forum.example.com, forum2.example.com, forum3.example.com {
        reverse_proxy localhost:8080
  }
  

  Puoi anche eseguire systemctl status caddy per verificare la posizione predefinita del file di configurazione.

4) Esegui Caddy

systemctl start caddy

Ricarica la configurazione dopo le modifiche:

cd /etc/caddy
caddy reload

[David_Ghost]

Ciao, grazie per il tutorial.

Ci sono vantaggi nell’usare Caddy per una configurazione non multi-sito? Performance o altro?

[manuel (Manuel Kostka)]

Non so a riguardo… Io uso questa configurazione sui miei server di staging ora perché è davvero facile aggiungere o modificare istanze senza incorrere in problemi di certificati.

[DeanMarkTaylor (Dean Taylor)]

Ho fatto qualcosa di simile in una configurazione multisito per semplificare l’impostazione SSL…
… ma ho aggiornato a Caddy v2 e sto usando docker-compose con una configurazione multisito.

In web.yml:

• utilizzando solo templates/web.socketed.template.yml e nessun file yml SSL.
• commentando le porte \"443:443\", \"80:80\" ecc.
• aggiungendo DISCOURSE_HOSTNAME_ALIASES e DISCOURSE_FORCE_HTTPS: true

Questo utilizza l’ultima versione di Caddy 2, motivo per cui potrebbe apparire diverso da alcune delle configurazioni di Caddy v1 menzionate in precedenza in questo argomento.

Questo è il file bash che crea inizialmente i file pertinenti e avvia caddy:

#!/usr/bin/env bash

# Crea le directory necessarie
mkdir -p /var/caddy
mkdir -p /var/caddy/data
mkdir -p /var/caddy/config



# Crea il Caddyfile semplificato
cat > /var/caddy/Caddyfile << 'EOF'
{
    email your-email-address-here@example.com
}

community1.example.com, community2.example.com, community3.example.com {
    reverse_proxy unix//sock/nginx.http.sock
}
EOF

# Crea docker-compose.yml
cat > /var/caddy/docker-compose.yml << 'EOF'
services:
  caddy:
    image: caddy:latest
    container_name: caddy-proxy
    restart: unless-stopped
    ports:
      - "80:80"
      - "443:443"
      - "443:443/udp"
    volumes:
      - /var/caddy/Caddyfile:/etc/caddy/Caddyfile
      - /var/caddy/data:/data
      - /var/caddy/config:/config
      - /var/discourse/shared/standalone:/sock
EOF

# Naviga nella directory di caddy e avvia
cd /var/caddy

# Avvia Caddy
docker compose up -d

[lxbnks (Alex)]

Grazie! Voglio passare da Nginx a Caddy. Hai ancora unix//sock/nginx.http.sock: stai usando Nginx e Caddy insieme?