> For the complete documentation index, see [llms.txt](https://esmp-fun.gitbook.io/plugins/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://esmp-fun.gitbook.io/plugins/community-chat/getting-started/hub-domain-address.md).

# Give the hub a domain address (wss)

This page is the **last step of every hub setup** — the address you hand out to the network should be a domain address:

```
wss://cchat.your-domain.com
```

Why not just the IP-and-port address from the hosting guide? Because that address only works if every community's *host* allows outbound connections to that exact, unusual port number — and many Minecraft hosts quietly don't. With more than a couple of communities, the odds that all of their hosts let a random high port through are close to zero, and the ones that block it just see a silent timeout nobody can fix from their side. Port **443** is the port every website uses; no host blocks it, because their own servers need it for ordinary web requests. As a bonus the connection becomes encrypted (`wss` = WebSocket Secure, same idea as `https`), so the tokens no longer cross the internet in plain text.

The raw `ws://address:port` form still has its place — testing on your own machine, and checking the hub works before the domain is set up — but it's the fallback, not the address to build a network on.

**What you need:** a domain name you control (the one your Minecraft server already uses is fine — you'll add a subdomain like `cchat.`, which doesn't disturb anything already using the domain). The hub itself needs no changes at all: something in front of it answers on 443 and forwards to the hub's normal port.

Pick your route:

* [Hub on a VPS](#hub-on-a-vps--caddy) — one small extra program, \~10 minutes.
* [Hub on Minecraft hosting](#hub-on-minecraft-hosting--panel-proxy--cloudflare) — click-only, using the panel's reverse-proxy feature and Cloudflare.

## Hub on a VPS — Caddy

Caddy is a tiny web server that gets and renews the SSL certificate for you, automatically, forever. Three steps on the VPS from the [VPS guide](/plugins/community-chat/getting-started/hub-on-a-vps.md):

1. **Point a subdomain at the VPS.** In your domain's DNS settings, add a record: **Type** `A`, **Name** `cchat`, **Value** your VPS's IP.
2. **Install Caddy** ([full instructions](https://caddyserver.com/docs/install) if your system differs):

   ```
   sudo apt install -y caddy
   ```
3. **Tell Caddy about the hub.** Replace the contents of `/etc/caddy/Caddyfile` (`sudo nano /etc/caddy/Caddyfile`) with — using your real subdomain:

   ```
   cchat.your-domain.com {
       reverse_proxy 127.0.0.1:8377
   }
   ```

   Then `sudo systemctl reload caddy`. Caddy fetches the certificate on its own (allow ports 80 and 443 in your provider's cloud firewall the same way you allowed 8377 — Caddy needs 80 for the certificate dance).

That's it. Your hub address is now `wss://cchat.your-domain.com`. Once every community has switched over, you can close port 8377 in the cloud firewall — with Caddy in front, the hub's own port no longer needs to be open to the internet.

## Hub on Minecraft hosting — panel proxy + Cloudflare

Panel hosts (Kinetic and other Pterodactyl-style panels) usually have a **reverse proxy** feature — often on a page called *Create A Proxy*, meant for things like Dynmap. Combined with a free Cloudflare account it gives you the 443 address without touching a terminal. Cloudflare handles the SSL part, so when the panel's proxy form asks for a certificate, you get to skip it entirely.

### Part 1 — Put your domain on Cloudflare (one-time, free)

Skip to Part 2 if your domain is already on Cloudflare (its dashboard shows the domain as **Active**).

1. Create a free account at [cloudflare.com](https://cloudflare.com), click **Add a domain**, enter your domain, pick the **Free** plan.
2. Cloudflare shows two *nameserver* addresses. At your domain registrar (where you bought the domain), find the **Nameservers** setting and replace what's there with those two. If asked to import existing DNS records, keep them — your Minecraft server's address keeps working.
3. Wait for Cloudflare's "your domain is active" email (minutes to hours).

### Part 2 — Create the address (in Cloudflare)

1. In the Cloudflare dashboard, open your domain → **DNS** → **Add record**:
   * **Type:** `A`
   * **Name:** `cchat`
   * **IPv4 address:** the hub instance's IP (shown next to its port in your panel)
   * **Proxy status:** the cloud icon must be **orange** ("Proxied") — this is what provides the SSL.
2. Left menu → **SSL/TLS** → **Overview** → set the mode to **Flexible**.
3. Left menu → **Network** → check the **WebSockets** toggle is **On** (it usually is).

### Part 3 — The panel proxy (in your hosting panel)

On the **hub instance's** panel page (not your Minecraft server's), find the reverse-proxy page and create one:

* **Proxy domain:** `cchat.your-domain.com` — exactly the address from Part 2, no `http://`, no slashes.
* **Allocation / target:** the hub's port — the one the hub's console says it is listening on. Double-check this; the dropdown often defaults to the instance's primary port, which is the wrong one.
* **Enable SSL:** **off**. Cloudflare is doing the SSL; the panel's own certificate boxes stay empty.

### Part 4 — Switch the connectors

Every community sets, in `plugins/CommunityChat/config.yml`:

```yaml
hub:
  url: "wss://cchat.your-domain.com"
```

`wss` with two s's, **no port number** — then `/cchat reload`. The old `ws://ip:port` address keeps working during the switch, so communities can migrate one at a time.

### If it doesn't connect: the header check

Panel proxies are built for ordinary web pages, and some of them drop the special *upgrade* headers a WebSocket connection needs. The tell-tale symptom: the connector logs `answered, but not as a CommunityChat hub` (older versions: a `WebSocketHandshakeException`), and opening `https://cchat.your-domain.com` in a browser shows a page titled **404 WebSocket Upgrade Failure**.

That page actually being the *hub's own* error page is good news — the whole chain works except the final handshake. It needs a one-time fix by the host; send their support this, filling in your subdomain:

> Your reverse-proxy feature strips the WebSocket `Upgrade` and `Connection` headers, so WebSocket apps behind it get a 404 from the backend. Could you enable WebSocket support (`proxy_http_version 1.1` plus `Upgrade`/`Connection` header passthrough) on my proxy for `cchat.your-domain.com`?

### Rather not use Cloudflare?

The panel-proxy route also works without it: point the DNS record straight at the hub's IP (no Cloudflare, or grey cloud), turn **Enable SSL on** in the panel's proxy form, and paste in a free certificate from [zerossl.com](https://zerossl.com) (their website walks you through verifying the domain and gives you the certificate and key to paste). The catch: free certificates expire every 90 days, so you'll repeat the ZeroSSL part four times a year — Cloudflare's is automatic forever, which is why it's the main recipe above.

## No domain at all?

Then this page can't help directly — but the problem it solves still can be. Options, roughly in order of sense: buy a domain (a `.com` is \~$10/year and your Minecraft server probably wants one anyway); or have the affected communities ask their host to allow *outbound* connections to your hub's port (note: outbound — nothing needs to be opened or forwarded on their server, it's the direction of an ordinary web request).