Eventually managed to deploy a mix release built Phx application in a docker container (wasn’t my plan to use docker but I thought I’d have fewer moving parts at least in the beginning if I go docker route). Starts, connects to database and generally seem to work when looked at from the browser. But when looking at the logs I see a stream of
20:53:56.156 [info] CONNECTED TO Phoenix.LiveView.Socket in 40µs
Transport: :websocket
Serializer: Phoenix.Socket.V2.JSONSerializer
Parameters: %{"_csrf_token" => "[...]", "_live_referer" => "undefined", "_mounts" => "0", "_track_static" => %{"0" => "https://<myapp.com>/assets/default-8e785bcdd3de7c28e9cee4a2ae6ac6a2.css?vsn=d", "1" => "https://<myapp.com>/assets/app-49579f0ef540eab1a38ba9a9e42f7a9e.js?vsn=d"}, "vsn" => "2.0.0"}
Obviously never noticed anything like that in dev environment. Whenever I entered a page with LiveView stuff on it, it rendered, connected and that was it. Now the question what am I doing wrong here?
Can you check the console in the browser to see if there’s any errors?
Repeated connections in prod usually means that the check_origin setting in the Endpoint isn’t set correctly, in dev mode the server accept connections from any origin.
https://hexdocs.pm/phoenix/Phoenix.Endpoint.html#module-runtime-configuration
Yes, there they are. I mean errors in the console. Now, the default for check_origin is true for :prod, and that means:
" If true , the header is checked against :host in YourAppWeb.Endpoint.config(:url)[:host]"
Now what do I configure for a setup like:
Internet => Rev-Proxy => container => phx_app
phx_app runs on port 4000, rev-proxy proxies between SSL/443 and internal 4000 exposed by the container
How is the host configured?
Are you using https://example.com as the host? Because this create problems when the websocket connects to wss://example.com, so if the host has the https:// you should remove it and use only example.com.
Sorry for the low hanging fruit suggestions, but since they are so common let’s take them out of the way first 
No problem but no. At least I think “no” as I explicitly supply the PHX_HOST environment variable with only FQDN, no schema etc.
Although I found something suspiciously looking:
20:30:16.711 [info] Running PhxAppWeb.Endpoint with cowboy 2.9.0 at :::4000 (http)
20:30:16.712 [info] Access PhxAppWeb.Endpoint at http://myapp.com:443
This is logged upon startup. And the errors are (all the same):
WebSocket connection to 'wss://myapp.com/live/websocket?_csrf_token=[...]&_track_static%5B0%5D=https%3A%2F%2Fmyapp.com%2Fassets%2Fdefault-8e785bcdd3de7c28e9cee4a2ae6ac6a2.css%3Fvsn%3Dd&_track_static%5B1%5D=https%3A%2F%2Fmyapp.com%2Fassets%2Fapp-49579f0ef540eab1a38ba9a9e42f7a9e.js%3Fvsn%3Dd&_mounts=0&_live_referer=undefined&vsn=2.0.0' failed:
connect @ app-49579f0ef540eab1a38ba9a9e42f7a9e.js?vsn=d:1
(anonymous) @ app-49579f0ef540eab1a38ba9a9e42f7a9e.js?vsn=d:1
(anonymous) @ app-49579f0ef540eab1a38ba9a9e42f7a9e.js?vsn=d:1
waitForSocketClosed @ app-49579f0ef540eab1a38ba9a9e42f7a9e.js?vsn=d:1
(anonymous) @ app-49579f0ef540eab1a38ba9a9e42f7a9e.js?vsn=d:1
waitForBufferDone @ app-49579f0ef540eab1a38ba9a9e42f7a9e.js?vsn=d:1
teardown @ app-49579f0ef540eab1a38ba9a9e42f7a9e.js?vsn=d:1
(anonymous) @ app-49579f0ef540eab1a38ba9a9e42f7a9e.js?vsn=d:1
(anonymous) @ app-49579f0ef540eab1a38ba9a9e42f7a9e.js?vsn=d:1
Of course myapp.com reflects the proper host name
For posterity - the rev-proxy - was configured according to these two fine articles. After configuring it according to “more sophisticated example” here:
https://nginx.org/en/docs/http/websocket.html
the problem seems to be eventually gone.
1 Like
