将Atlassian Confluence从NGINX迁移至Caddy后/synchrony路径异常求助

Hey there, sorry to hear you hit this frustrating snag after switching from NGINX to Caddy—those weird "half-working" issues are always the most head-scratching! Let’s break down what’s going on here: your raw WebSocket tests pass, but Confluence’s ability to fetch scripts via /synchrony is failing. That tells me the basic WebSocket routing is solid, but there’s probably a missing header, path rewrite, or config quirk specific to how Confluence interacts with its Synchrony service.

Key Fixes & Checks for Your Caddy Config #

Let’s start with the most common culprits:

• Proxy Headers That Preserve Request Context
  Confluence and Synchrony rely heavily on knowing the original request details (like host, protocol, and client IP) to generate valid scripts. Make sure your Caddyfile includes these headers for both the main Confluence proxy and the /synchrony route:

  your-confluence-domain.com {
      # Proxy for Synchrony
      reverse_proxy /synchrony/* http://your-synchrony-instance:8091 {
          header_up Host {host}
          header_up X-Forwarded-For {remote_host}
          header_up X-Forwarded-Proto {scheme}
          websocket  # Explicitly enable WebSocket support (though Caddy often auto-detects)
      }
  
      # Main Confluence proxy
      reverse_proxy http://your-confluence-instance:8090 {
          header_up Host {host}
          header_up X-Forwarded-For {remote_host}
          header_up X-Forwarded-Proto {scheme}
      }
  }
  

  The X-Forwarded-Proto is especially critical if you’re using Caddy’s automatic TLS—without it, Synchrony might generate HTTP URLs for scripts that fail to load over HTTPS.

• Verify Synchrony’s Context Path in Confluence
  Head to Confluence’s admin panel: General Configuration > Synchrony Settings. Double-check that the Synchrony Base URL matches exactly what’s being proxied through Caddy (e.g., https://your-confluence-domain.com/synchrony). A mismatch here will break script fetching every time.

• CORS Configuration (If Needed)
  Even if WebSocket works, script requests might hit CORS blocks. Add targeted CORS headers for /synchrony if you see CORS errors in your browser’s dev tools:

  @synchrony path /synchrony/*
  header @synchrony Access-Control-Allow-Origin "*"
  header @synchrony Access-Control-Allow-Methods "GET, POST, OPTIONS"
  header @synchrony Access-Control-Allow-Headers "Content-Type, Authorization"
  

Debugging Tips to Dig Deeper #

• Turn on Caddy’s debug logging to see exactly what’s happening with /synchrony requests:

  caddy run --config your-Caddyfile-path --debug
  

  Look for 4xx/5xx status codes, missing headers, or path mismatches in the logs—this will often point you straight to the issue.
• Use your browser’s Network tab (dev tools) to inspect the failed script request. Check the response code:
  • 404 = Caddy isn’t routing the path to Synchrony correctly
  • 502 = Caddy can’t reach your Synchrony service
  • CORS error = Adjust the header rules above

I’ve tackled similar proxy-switching issues with Confluence before, and 9 times out of 10, it’s either missing proxy headers or a misconfigured Synchrony base URL that’s causing the script fetch failure. Give these steps a try and let me know if you need more help!

内容的提问来源于stack exchange，提问作者Joel Bourbonnais