Mastodon Relay Behind Cloudflare: HTTP Signature Compatibility

When a Mastodon relay is placed behind Cloudflare, the relay often stops receiving posts from remote instances. The core cause is that Cloudflare’s reverse proxy strips or modifies the HTTP signature headers that Mastodon uses to verify incoming federated requests. Without these headers intact, the relay sees every incoming activity as unauthenticated and silently drops it. This article explains why Cloudflare breaks HTTP signature verification and provides a concrete configuration fix to restore relay functionality.

Why Cloudflare Breaks HTTP Signature Verification for Mastodon Relays

Mastodon uses HTTP Signatures (draft-cavage-http-signatures-12) as its primary authentication mechanism for ActivityPub federation. When an instance sends an activity to a relay, it signs a set of headers — typically (request-target), host, date, and digest. The receiving relay reconstructs the signing string from the incoming request headers and verifies the signature against the sender’s public key.

Cloudflare acts as a reverse proxy that terminates the TLS connection from the sender. By default, Cloudflare re-encrypts the request to the origin server, but in doing so it may alter several critical headers:

• Host header: Cloudflare may change the Host header to the origin server IP or a different domain if not configured correctly.
• Date header: If Cloudflare caches the request or performs any buffering, the Date header can become stale or be removed entirely.
• Digest header: Cloudflare’s HTTP/2 to HTTP/1.1 translation can strip or recalculate the Digest header.
• Signature header: The Signature header itself is often passed through, but if any of the headers it signs are changed, verification fails.

The result is that the relay’s Mastodon software receives a request that fails signature verification. The relay logs show “HTTP Signature verification failed” and the activity is rejected. The relay appears to be running but never propagates any content.

Steps to Configure Cloudflare for Mastodon Relay HTTP Signature Compatibility

The following steps assume you already have a Mastodon relay instance running behind Cloudflare. You will need access to the Cloudflare dashboard and the ability to edit DNS records and firewall rules.

1. Set SSL/TLS encryption mode to Full (Strict)
   In the Cloudflare dashboard, go to SSL/TLS > Overview. Select Full (Strict). This ensures the origin server receives the original HTTPS connection with a valid certificate, and Cloudflare does not downgrade to HTTP. Do not use Flexible mode, as it strips the original client IP and can modify headers.
2. Disable Under Attack mode for the relay subdomain
   Go to Security > Settings. Set Security Level to Essentially Off for the relay subdomain. Under Attack mode adds JavaScript challenges that break the non-browser HTTP requests Mastodon instances send. If you must keep some security, create a Firewall Rule that sets Security Level to High only for specific countries, but never use Under Attack mode.
3. Create a Firewall Rule to preserve original headers
   Navigate to Security > WAF > Firewall Rules. Create a rule with the following settings:
   Field: Hostname, Operator: equals, Value: your-relay.example.com
   Then set the action: Bypass and select the following features: Security Level, Rate Limiting, Browser Integrity Check, and Super Bot Fight Mode. Name the rule “Mastodon Relay Bypass” and save it.
4. Configure SSL/TLS for origin pull
   Go to SSL/TLS > Origin Server. Create an Origin Certificate for your relay subdomain. Install this certificate on your origin server (Nginx or Apache). This allows Cloudflare to connect to the origin using Full (Strict) encryption. Without this, Cloudflare may fall back to Full mode and modify headers.
5. Disable HTTP/2 to origin for the relay subdomain
   In Speed > Optimization, turn off HTTP/2 to Origin. HTTP/2 to Origin can cause Cloudflare to convert request headers, stripping the Digest header. Keep HTTP/2 to visitors enabled — that does not affect the relay.
6. Add the relay subdomain to a Page Rule with SSL off
   Go to Rules > Page Rules. Create a new rule for your-relay.example.com/. Set the setting SSL to Full (not Flexible). Also set Cache Level to Bypass. This prevents Cloudflare from caching any ActivityPub payloads, which could alter the Date header.
7. Restart the Mastodon relay service
   On your origin server, restart the Mastodon relay service to clear any stale connections: sudo systemctl restart mastodon-relay. Then check the relay logs for successful signature verifications: journalctl -u mastodon-relay -f | grep "HTTP Signature".

If Mastodon Relay Still Rejects Activities After Cloudflare Configuration

“HTTP Signature verification failed” in relay logs despite correct Cloudflare settings

This usually means the origin server’s Nginx or Apache is stripping headers before they reach Mastodon. Check your web server configuration for any proxy_set_header directives that overwrite the Host, Date, or Digest headers. In Nginx, ensure you have:
proxy_set_header Host $host;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Proto $scheme;
Do not add any custom logic that modifies the Date or Digest headers.

Relay receives only activities from instances on the same Cloudflare network

If activities from instances that also use Cloudflare work but others do not, the issue is likely TLS version mismatch. Cloudflare may be presenting a 1.3 connection to the origin while the sender expects 1.2. In your Firewall Rule, explicitly set the TLS version to 1.3 for the relay subdomain. This forces all incoming connections to use the same protocol version, preventing header modification.

Relay stops working after Cloudflare IP range changes

If you have firewall rules on your origin server that whitelist Cloudflare IPs, update them using the current Cloudflare IP ranges from https://www.cloudflare.com/ips/. Outdated IP lists cause Cloudflare requests to be blocked, and Mastodon retries with different headers. Set up a cron job to refresh the IP list weekly.

Cloudflare Configuration Options for Mastodon Relay Compatibility

Item	Correct Setting	Incorrect Setting
SSL/TLS encryption mode	Full (Strict)	Flexible or Off
Security Level	Essentially Off for relay subdomain	Under Attack or High
HTTP/2 to Origin	Disabled	Enabled
Cache Level for relay subdomain	Bypass	Standard or Cache Everything
Origin Certificate	Installed and trusted	Not installed or self-signed

After applying these settings, test the relay by sending a test activity from a remote Mastodon instance. Use the Mastodon relay admin panel to confirm the relay is receiving and forwarding activities. If signatures still fail, examine the raw headers using curl -v from a remote server to see what Cloudflare sends to the origin. The Host and Date headers must exactly match what the sender signed.

This configuration is specific to Mastodon relays. A standard Mastodon instance behind Cloudflare may tolerate minor header changes because the instance verifies signatures against the inbox URL, not the relay’s URL. Relays are more sensitive because they verify against the relay’s dedicated endpoint. Always test with a staging relay before applying to a production relay.