Failed WebSocket handshake after deploying with phoenix 1.3 and edeliver

Phoenix Forum Questions / Help
, ,
1

Hello :slight_smile:

I’ve got a weird websocket error when I deploy my app using edeliver:

WebSocket connection to 'ws://staging.cur-vita.com/socket/websocket?token=undefined&vsn=2.0.0' failed: Error during WebSocket handshake: net::ERR_CONNECTION_RESET

I do not know what went wrong, everything is working fine locally (both dev and prod env).
Did anybody had a similar error?

My prod config:

config :curvita, CurvitaWeb.Endpoint,
  http: [port: 4000],
  url: [host: "localhost", port: 80],
  check_origin: true,
  cache_static_manifest: "priv/static/cache_manifest.json",
  server: true,
  root: ".",
  version: Mix.Project.config[:version]

# Do not print debug messages in production
config :logger, level: :info
config :curvita, :environment, :prod

my edeliver config is:

APP="curvita"

BUILD_HOST="staging.cur-vita.com"
BUILD_USER="deploy"
BUILD_AT="/tmp/edeliver/$APP/builds"

RELEASE_DIR="/tmp/edeliver/$APP/builds/_build/prod/rel/$APP"

# prevent re-installing node modules; this defaults to "."
GIT_CLEAN_PATHS="_build rel priv/static"

# STAGING_HOSTS="188.166.182.170"
# STAGING_USER="deploy"
# TEST_AT="/home/deploy/staging"

PRODUCTION_HOSTS="staging.cur-vita.com"
PRODUCTION_USER="deploy"
DELIVER_TO="/home/deploy"

# For *phx* projects, symlink prod.secret.exs to our tmp source
pre_erlang_get_and_update_deps() {
  local _prod_secret_path="/home/deploy/prod.secret.exs"
  if [ "$TARGET_MIX_ENV" = "prod" ]; then
    __sync_remote "
      ln -sfn '$_prod_secret_path' '$BUILD_AT/config/prod.secret.exs'
    "
  fi
}

pre_erlang_clean_compile() {
  status "Running phx.digest" # log output prepended with "----->"
  __sync_remote " # runs the commands on the build host
    # [ -f ~/.profile ] && source ~/.profile # load profile (optional)
    source ~/.profile
    
    # echo \$PATH # check if rbenv is in the path
    set -e # fail if any command fails (recommended)
    cd '$BUILD_AT' # enter the build directory on the build host (required)

    # prepare something
    mkdir -p priv/static # required by the phx.digest task
    cd ./assets

    npm install 

    ./node_modules/.bin/webpack -p

    cd ../

    # run your custom task
    APP='$APP' MIX_ENV='$TARGET_MIX_ENV' $MIX_CMD phx.digest $SILENCE
  "
}

Cheers

2

You should also have an error in your logs from Phoenix that looks like:

If you follow the instructions in there then it should resolve your issue.

Specifically changing:

url: [host: "localhost", port: 80],

to

url: [host: "staging.cur-vita.com", port: 80],
1 Like
3

@Gazler thx for your reply :slight_smile:
I had the host set already but changed later to localhost.
The log file indeed showed me this error you have mentioned, but not anymore.
Still I get the same error message again.
I have also added some origins there.

This is how my prod config looks now:

config :curvita, CurvitaWeb.Endpoint,
  http: [port: 4000],
  url: [host: "staging.cur-vita.com", port: 80],
  # check_origin: true,
  check_origin: ["http://staging.cur-vita.com", "http://staging.cur-vita.com:4000",
  	"//staging.cur-vita.com", "//staging.cur-vita.com:4000"],
  cache_static_manifest: "priv/static/cache_manifest.json",
  server: true,
  root: ".",
  version: Mix.Project.config[:version]

# Do not print debug messages in production
config :logger, level: :info
config :curvita, :environment, :prod
4

I have found out that I am getting this error when I call staging.cur-vita.com but not when I add the port staging.cur-vita.com:4000.

Still haven’t found a solution yet.

5

@dyyce If you are running on port 4000 and it works on port 4000, then I assume you have some sort of reverse proxy (nginx, haproxy, etc) running on port 80? In that case, it is certainly worth checking that the websockets aren’t being stopped at that level.

https://www.nginx.com/blog/websocket-nginx/ describes the process for nginx

2 Likes
6

Thx again!

this actually sounds like it might be the issue here!
Gonna give it a try

7

ok now I feel kinda stupid :see_no_evil:
it was nginx! After I have stopped nginx, it worked (since I actually do not need it)

thank you very much @Gazler for that hint!!!

Cheers