Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

WebSocket Connection Failure in Self-Hosted Supabase on EC2 #1244

Open
brookbdt opened this issue Dec 8, 2024 · 2 comments
Open

WebSocket Connection Failure in Self-Hosted Supabase on EC2 #1244

brookbdt opened this issue Dec 8, 2024 · 2 comments
Labels
bug Something isn't working

Comments

@brookbdt
Copy link

brookbdt commented Dec 8, 2024

Issue: WebSocket Connection Failure in Self-Hosted Supabase on EC2

Description

When attempting to connect to Supabase Realtime through a self-hosted instance on EC2, the WebSocket connection fails.

Environment

  • Deployment: Self-hosted on AWS EC2
  • Domain: {supabasePublicUrl}
  • Connection URL: wss://{supabasePublicUrl}/realtime/v1/websocket
  • Client Parameters:
    • apikey: [ANONKEY]
    • eventsPerSecond: 2
    • vsn: 1.0.0

Steps to Reproduce

  1. Set up self-hosted Supabase on EC2
  2. Attempt to establish WebSocket connection to the Realtime service
  3. Connection fails immediately

Expected Behavior

  • WebSocket connection should establish successfully
  • Client should maintain stable connection to Realtime service

Additional Context

  • The server logs show multiple GET requests to the WebSocket endpoint
  • GET /realtime/v1/websocket returning 404
  • Client receives a connection failure without specific error details

Questions

  1. Are there specific configuration requirements for self-hosted Realtime service on EC2?
  2. Are there known networking/firewall considerations for WebSocket connections in this setup?
  3. How can we enable more detailed error logging to diagnose the connection failure?
@brookbdt brookbdt added the bug Something isn't working label Dec 8, 2024
@jsmueller7
Copy link

jsmueller7 commented Dec 11, 2024

This is probably caused by a cookie that is too large. It doesn't occur if you're using a local account. But with SSO I've seen this. Even if you set MAX_HEADER_LENGTH to 8192, the cookie can cause a problem with the ws:// connection.

A temporary fix in this case is to let Kong remove the cookie with a request-transformer.

@filipecabaco
Copy link
Contributor

You can also configure it with MAX_HEADER_LENGTH

max_header_value_length: String.to_integer(System.get_env("MAX_HEADER_LENGTH") || "4096")

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

No branches or pull requests

3 participants