Help configuring to allow websocket `Upgrade` request

1. Caddy version (caddy version):


2. How I run Caddy:

With Docker

a. System environment:


b. Command:

docker-compose up -d

c. Service/unit/compose file:

version: "3.6"

    image: caddy
    container_name: caddy_web_server
    hostname: caddy
    restart: unless-stopped
      - "80:80"
      - "443:443"
      - MY_DOMAIN
      - ./Caddyfile:/etc/caddy/Caddyfile:ro
      - ./config:/config
      - ./www:/usr/share/caddy
      - ./certs:/data

      name: $DOCKER_MY_NETWORK

d. My complete Caddyfile or JSON config:

http://hedgedoc.{$MY_DOMAIN}:80 {

        @websockets {
          header Connection *Upgrade*
          header Upgrade websocket
          path /

        reverse_proxy @websockets hedgedoc_app_1:3000

3. The problem I’m having:

I am trying to follow the instructions here to use Caddy as a reverse proxy for Hedgedoc. Hedgedoc is running just fine on the host machine (I can access it at localhost:3000 but I am having a hard time translating their reverse proxy requirements into Caddy. They have examples on that page for Nginx and Apache.

The specific instruction I need to accommodate is:

The reverse proxy must allow websocket Upgrade requests at path / .

My Caddyfile above represents my attempt so far, based on instructions I found in this forum here and here but I don’t think I have it quite right.

4. Error messages and/or full log output:

5. What I already tried:

I’ve tried incorporating the instructions from the two posts I’ve found on the forum and reading the documentation on request matchers and handle_path

6. Links to relevant resources:

The instructions from Hedgedoc.

You don’t need to do anything at all. Caddy proxies headers transparently. You can remove the matcher altogether, if that’s the only thing you’re serving on that site (is that really your entire Caddyfile? Please don’t omit any part of it).

What you might be hitting though, if you do need to separately handle websocket requests, is that path matchers in Caddy are exact. So matching on / will only match requests with the exact path / and not / To match those, add a * at the end of the matcher.

This topic was automatically closed after 30 days. New replies are no longer allowed.