Socket closing immediately on creation

Runtime Framework
1

Versions: Nakama 3.35.1

Hi friends,

We are opening a socket to receive notifications to the client from the server. As soon as we open this connection it is being terminated immediately and I’m not sure why!

The connection is established successfully, but is closed instantly.

The client is built in Godot, see client code snippet below. _socket is not a local variable and is not going out of scope, it lives on this node for the duration of the app’s lifetime.

Asking our AI overlords they suggest it is related to the hosting environment which is Fly.io and the configuration of our Fly app there - this is where my understanding starts to break down :smiley:

// Fly app configuration
[[services]]
  internal_port = 7350
  protocol = "tcp"

  [[services.ports]]
    handlers = ["tls"]
    port = 443

[[services]]
  internal_port = 7351
  protocol = "tcp"

  [[services.ports]]
    handlers = ["tls"]
    port = 7351

// Client snippet
func _connectToSocket() -> bool:
	_socket = Nakama.create_socket_from(_client)
	var connected : NakamaAsyncResult = await _socket.connect_async(_nakamaClient.GetAuthManager().Session())
	if connected.is_exception():
		printerr(connected.exception)
		return false

	_socket.received_notification.connect(_on_notification)
	return true

// Nakama logs
11:54:42 {"level":"info","ts":"2026-01-30T11:54:42.443Z","caller":"server/session_ws.go:84","msg":"New WebSocket session connected","uid":"527957b5-c96e-40c0-9fec-a5cc20a66dda","sid":"76ac0df8-fdd2-11f0-aecd-006100a0eb06","format":0}
11:54:42 [PP02] could not proxy TCP data to/from instance: failed to copy (direction=client->server, op=read, error=peer closed connection without sending TLS close_notify: https://docs.rs/rustls/latest/rustls/manual/_03_howto/index.html#unexpected-eof)

Any help is greatly appreciated, thanks very much!

2

Definitely a configuration issue on the Fly.io side, the socket and notifications work flawlessly when I run the server locally. Am I exposing the incorrect ports or with the wrong protocol / handler?

3

Hi @DWoodhouse22,

I was going to suggest double checking that the socket behaves correctly locally to ensure everything is correct in the client usage, but since you’ve already done that, I suspect it’s something on the provider side as well. Also make sure you’re running the server with debug logging and inspect the server logs, they may provide some helpful context.

We don’t typically help with self-hosted solutions as it’s a very involved and time consuming process, due to the many things to consider for a production ready system as well as the heterogeneity between the different providers, but perhaps someone else from the community can provide some assistance.

Best.

4

Thanks, I appreciate the response.

After hours of trial and error I’ve managed to resolve the issue and it’s wonderfully simple as is almost always the case!

If anyone else gets stuck in this, the solution for me was to add both tls and http handlers on port 7350, final config looks like this:

[[services]]
  internal_port = 7350
  protocol = "tcp"

  [[services.ports]]
    handlers = ["tls", "http"]
    port = 443

[[services]]
  internal_port = 7351
  protocol = "tcp"

  [[services.ports]]
    handlers = ["tls"]
    port = 7351