Apache2 / Phoenix: How To Set Up Reverse Proxy?

Phoenix Forum Questions / Help
,
1

Starting with a fresh install of Phoenix on a Ubuntu 20.04 server with Apache2, what are the specific steps for setting up a reverse proxy (what should the block of code in apache be exactly? what do I edit in the phoenix app files?)

By default, Phoenix runs fine on: https://www.mysite.com:4000/

I want it to run on: https://www.mysite.com/ex/ (without the port 4000 in the URL)

The “Welcome To Phoenix” page and all css/js/image files should load, the live view frame should load and the sockets should work with no errors.

Right now, I have something like the following in my Apache config:

<VirtualHost *:443>
ServerName www.mysite.com
ServerAlias mysite.com
 <Location /ex/>
    ProxyPass http://127.0.0.1:4000/
    ProxyPassReverse http://127.0.0.1:4000/
  </Location>
</VirtualHost>

In Phoenix, I edited config/config.exs to something like this:

config :exchat, ExchatWeb.Endpoint,
  url: [host: "localhost", path: "/ex"],

At the moment, the phoenix page on the website (css/js/images) loads up fine, but the sockets aren’t working. In the console, I’m seeing repeating errors like:

WebSocket connection to 'wss://www.mysite.com/socket/websocket?token=undefined&vsn=2.0.0' failed
WebSocket connection to 'wss://www.mysite.com/ex/phoenix/live_reload/socket/websocket?vsn=2.0.0' failed

…

Thanks

2

Running an application involve phoenix sockets not at the root path is tricky. Do you really want to do that? In the old time, people do this to save a separate https cert. now that letsencrypt is free, most people will just make another sub domain and build a virtual host.

If you really want to do this, check your app.js for the socket connection statement. You may want to fix that to your path prefix.

2 Likes
3

Thanks for the suggestion, it didn’t cross my mind to use a sub-domain. Based on my reading, I just assumed using Phoenix on a domain directory path was standard practice.

4

Using separate subdomains has some extra benefits:

  • Cookies are managed separately by default. There’s no need to specify the path option in cookies.
  • CORS strategies can be configured separately so that your applications are more secure than sharing the same domain.
  • Your URLs are shorter and easier to remember.
5

Depends on how do you define standard. If you do not use socket, then it is just as simple as adding a path to endpoint config. If you use socket, the js part need to be modified accordingly. I pass the application root through a data attributes of the the body tag, and connect the lv socket using that. This way the socket path is “float” wrt to the location: