Utilisez Caddy au lieu de NGNIX comme proxy inverse

[Discourse]

Voici quelques notes sur la façon dont j’ai mis mon instance de test Discourse en marche avec Caddy Server.

Choses cool à propos de Caddy :

• Ils utilisent Discourse

• SSL gratuit avec Let’s Encrypt

• HTTP2 et QUIC prêts à l’emploi

• Plus facile à configurer que nginx

Inconvénients :

• Moins éprouvé au combat qu’apache, nginx et cia.

Comment faire

Préparation de Discourse

Tout d’abord, vous devez appliquer ces modifications à votre 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" # <<<----- CECI EST NOUVEAU

## Laissez ces deux commentés
#  - "templates/web.ssl.template.yml"
#  - "templates/web.letsencrypt.ssl.template.yml"

## Laissez ces deux commentés 
expose:
#  - "8080:80"   # http
#  - "443:443" # https

env:
  ## Ceci doit être commenté
  #LETSENCRYPT_ACCOUNT_EMAIL: mymail@gmail.com
  ## Ceci est requis pour éviter les avertissements de contenu mixte derrière un proxy inverse
  DISCOURSE_FORCE_HTTPS: true

Préparation de Caddy

Dans l’esprit de Discourse, mettons Caddy dans une image Docker aussi

Préparez d’abord avec :

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

Ajoutez ce qui suit au Caddyfile (en utilisant la syntaxe Caddy v2) :

{
  email MYEMAILHERE@gmail.com
}

forum.example.com { # votre domaine ici
  reverse_proxy unix//sock/nginx.http.sock
}

Enregistrez et quittez.

Testons

Maintenant, vous devez reconstruire Discourse :

cd /var/discourse
./launcher rebuild app

Et ensuite exécutez 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

Après tout, votre forum devrait être disponible sur votre domaine, utilisant SSL + HTTP2 + QUIC. On ne peut pas être plus hipster que ça.

[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

Cela ne fonctionne pas sur mon serveur. Pour moi, j’ai utilisé :

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

Et ceci est pour caddy v1. Pour caddy v2, veuillez utiliser :

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

Remplacez simplement “:” par “/”.

[Falco]

Ce chemin fonctionne si vous suivez le guide dans le OP et exécutez Caddy dans docker et montez les volumes comme spécifié. Si vous ne suivez pas le guide, il y aura différents chemins, oui.

[RPaladin]

@Falco

Ils utilisent Discourse

Leur nom de domaine et sous-domaine de forum sont maintenant nommés sous ceci.

[ARHAEEM (A.R.)]

Désolé d’exhumer de vieux fils, j’essaie de faire fonctionner Caddy avec Discourse. Dans votre configuration Caddy, vous utilisez « proxy », mais quand je l’utilise, il indique qu’il y a une erreur de syntaxe et que ce n’est pas valide. N’est-ce pas que « proxy » a maintenant été remplacé par « reverse_proxy » ?

voici ma configuration :

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

[pfaffman (Jay Pfaffman)]

@ARHAEEM

N’est-ce pas que « proxy » a maintenant été remplacé par « reverse_proxy » ?

Je pense que oui. L’avez-vous essayé ?

[bananaman]

Merci Matt !
Je peux confirmer que la configuration sans conteneur fonctionne toujours en 2025 :smiley :

forum.website.com {
        reverse_proxy localhost:8080
}

Utiliser simplement « proxy » n’a pas fonctionné.

[manuel (Manuel Kostka)]

@bananaman

Je peux confirmer que la configuration sans conteneur fonctionne toujours en 2025

Ça fonctionne très bien pour moi aussi !

Cependant, j’ai reçu des avertissements de « Contenu mixte » en suivant cette configuration très simple :

Pour résoudre ces problèmes, j’ai dû ajouter une directive supplémentaire à la section env du fichier de configuration (app.yml ou web_only.yml) :

# FORCER SSL 
DISCOURSE_FORCE_HTTPS: true

[manuel (Manuel Kostka)]

Pour référence, voici les étapes actuelles pour une configuration non dockerisée utilisant Caddy comme proxy inverse :

1) Ajuster le fichier de configuration de Discourse

• Commenter les certificats

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

• Changer le mappage de port et désactiver le mappage 443

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

• Forcer HTTPS pour servir les fichiers statiques

  env: 
  DISCOURSE_FORCE_HTTPS: true
  

2) Reconstruire Discourse

./launcher rebuild app

3) Configurer Caddy

• Installer Caddy, en utilisant simplement les paramètres par défaut officiels : Install — Caddy Documentation

• Ajuster /etc/caddy/Caddyfile

  forum.example.com {
        reverse_proxy localhost:8080
  }
  

  Si vous avez un multisite, vous pouvez simplement lister vos domaines :

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

  Vous pouvez également exécuter systemctl status caddy pour vérifier l’emplacement du fichier de configuration par défaut.

4) Exécuter Caddy

systemctl start caddy

Recharger la configuration après les modifications :

cd /etc/caddy
caddy reload

[David_Ghost]

Salut, merci pour le tutoriel.

Y a-t-il un avantage à utiliser Caddy pour une configuration non-multisite ? Performance ou autre chose ?

[manuel (Manuel Kostka)]

Je ne sais pas à ce sujet… J’utilise simplement cette configuration sur mes serveurs de staging maintenant parce qu’il est vraiment facile d’ajouter ou de modifier des instances sans rencontrer de problèmes de certificat.

[DeanMarkTaylor (Dean Taylor)]

J’ai fait quelque chose de similaire sur une configuration multisite pour rationaliser la configuration SSL…
… mais mis à jour vers Caddy v2, et en utilisant docker-compose avec une configuration multisite.

Dans le web.yml :

• en utilisant uniquement templates/web.socketed.template.yml et aucun fichier yml SSL.
• en commentant les ports \"443:443\", \"80:80\" etc.
• en ajoutant DISCOURSE_HOSTNAME_ALIASES et DISCOURSE_FORCE_HTTPS: true

Cela utilise la dernière version de Caddy 2, c’est pourquoi cela peut sembler différent de certaines configurations Caddy v1 mentionnées ci-dessus dans ce sujet.

Voici le fichier bash qui crée initialement les fichiers pertinents et démarre caddy :

#!/usr/bin/env bash

# Créer les répertoires nécessaires
mkdir -p /var/caddy
mkdir -p /var/caddy/data
mkdir -p /var/caddy/config



# Créer le Caddyfile simplifié
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

# Créer 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

# Naviguer vers le répertoire caddy et démarrer
cd /var/caddy

# Démarrer Caddy
docker compose up -d

[lxbnks (Alex)]

Merci ! Je veux passer de Nginx à Caddy. Vous avez toujours /unix/sock/nginx.http.sock — utilisez-vous Nginx et Caddy ensemble ?