# fly-proxy now gracefully terminates WebSocket connections before stopping/suspending a machine

**URL:** <https://community.fly.io/t/fly-proxy-now-gracefully-terminates-websocket-connections-before-stopping-suspending-a-machine/27544>\
**Category:** Fresh Produce\
**Created:** [April 9, 2026, 8:19am UTC](https://community.fly.io/t/fly-proxy-now-gracefully-terminates-websocket-connections-before-stopping-suspending-a-machine/27544 "2026-04-09T08:19:34Z")\
**Posts on this page:** 1\
**Page:** 1

<div class="post-metadata">

**Author:** ![pavel](https://avatars.discourse-cdn.com/v4/letter/p/a4c791/32.png) [@pavel](https://community.fly.io/u/pavel)\
**Post date:** [April 9, 2026, 8:19am UTC](https://community.fly.io/t/fly-proxy-now-gracefully-terminates-websocket-connections-before-stopping-suspending-a-machine/27544/1 "2026-04-09T08:19:34Z")

</div>

If you’re running WebSocket servers with autostop on [Fly.io](http://fly.io/), we’ve got a quality-of-life improvement for you.

`fly-proxy` will now send a WebSocket GoAway close frame to all open WebSocket connections before a Machine is stopped or suspended. This gives clients a signal to reconnect elsewhere rather than being left hanging.

Before this change, auto-suspending a Machine with active WebSocket connections wasn’t a nice experience: connections didn’t receive any close signal, so clients had no idea anything had happened. From their perspective the connection just hung, until the failing TCP keep-alives eventually caused the connection to be torn down.

For apps with `auto_stop_machines=stop` configuration the situation was already more manageable. Because the app received `SIGTERM` before being killed, it could catch that signal and close its connections gracefully itself. And even if the app didn’t handle `SIGTERM`, the kernel running in the Machine would’ve quickly terminated TCP connections anyway.

Normal HTTP requests were largely unaffected because of how the proxy handles the shutdown sequence: when a stop or suspend is triggered, `fly-proxy` soft-cordons the Machine first and then waits a brief period before actually issuing the stop/suspend command. By that point, any in-flight short-lived HTTP requests have likely already completed.

Now `auto_stop_machines=suspend` should work much better with WebSocket apps, allowing more apps to benefit from automatic scaling and fast Machine suspend/resume operations.