0

I have no doubt the comments here does not work. By the looks of things, it should. No matter what I've done, I'm getting 502. My setup is a bit different:

We have an ec2 with AWS. We have a private IP (10.0.0.1) and a public IP (52.0.0.1). After installing Laravel Websockets, I can start up a websocket server (ws) with php artisan websockets:serve as a Pusher Replacement.

Here's where I'm confused, should I start the ws with --host=10.0.0.1? Here's my nginx setup:


 # 52.0.0.1 is not needed here. I put it here to troubleshoot ws connection
 # <actual-domain-name> is the domain name ie: foobar.com
 server_name 52.0.0.1 <actual-domain-name>;

 # The usual Laravel configs
 [..]

 location /v2/api {
   # We use the public ip address here.
   # I see no mention of the private IP in this config
   # Hey, everything works
   proxy_pass http://52.0.0.1/api/;
 }

 # I need to implement web sockets
 location /v2/api/ws {
  # This is where I'm lost. Should I use 127.0.0.1, 10.0.0.1 or 52.0.0.1?
  proxy_pass    http://127.0.0.1:6001;

  # Allow the use of websockets
  proxy_http_version   1.1;
  proxy_set_header Upgrade $http_upgrade;
  proxy_set_header Connection "upgrade";
  proxy_set_header Host $host;
  proxy_cache_bypass $http_upgrade;
 }

With the command to start up ws server php artisan websockets:serve then using the websocket section of Postman, I make the request: ws://<actual-domain-name>/v2/api/ws I get 502 Bad Gateway.

No matter how I start ws:

# I start it manually for troublshooting
php artisan websockets:serve --host=10.0.0.1
php artisan websockets:serve --host=127.0.0.1
php artisan websockets:serve

# It wont let me start with
# php artisan websockets:serve --host=52.0.0.1

I cannot make a connection. I have not mentioned ssl just to keep things simple so I make the request with ws:// instead of wss://. I was advised that port 6001 was enabled in AWS and I have also enabled port 6001 for ufw.

Would the laravel-websockets config interfere with using php artisan websockets:serve?

Edit:

config/broadcasting.php

'pusher' => [
    'driver' => 'pusher',
    'key' => env('PUSHER_APP_KEY'),
    'secret' => env('PUSHER_APP_SECRET'),
    'app_id' => env('PUSHER_APP_ID'),
    'options' => [
        'cluster' => env('PUSHER_APP_CLUSTER'),
        'useTLS' => true,
        'encrypted' => true,
        'host' => 127.0.0.1,
        'port' => 6001,
        'scheme' => 'http', // I'll use https once I get this working
        'curl_options' => [
            CURLOPT_SSL_VERIFYHOST => 0,
            CURLOPT_SSL_VERIFYPEER => 0,
        ],
    ],
],

Sylar
  • 11,422
  • 25
  • 93
  • 166
  • `proxy_pass` should point to the IPV4 where the service is exposed. If you want to use Nginx as a load balancer, you should expose the service to `127.0.0.1` (using the `--host` argument) and `proxy_pass` to it as such. If you want to simply expose it to the domain like `foobar.com:6001` then expose it to the public IPV4 and `proxy_pass` as such. The bad gateway indicates a network issue, it looks like you want to load balance so expose the service to `127.0.0.1` and `proxy_pass` to `127.0.0.1:6001`. – Jaquarh Sep 22 '21 at 12:00

1 Answers1

1

It wont let me start with php artisan websockets:serve --host=52.0.0.1

52.0.0.1 is your Public Inet4 address, this is not in the scope of your address. You cannot expose the service on the router.

If you want to load balance: if the local machine is running both services, then you'll need to expose it locally on loopback. If another machine is responsible for running the service, on the same network, then you'll need to expose it to its private IPV4.

Here is an example for loopback (the node is running both services):

# expose the service on the loopback address
php artisan websockets:serve --host=127.0.0.1

location /v2/api/ws {
  # It also may be worth noting you'll need an X-Forwarded-For for the remote address if you plan on using the remote IPV4 inside your application
  proxy_pass    http://127.0.0.1:6001;

  # Allow the use of websockets
  proxy_http_version   1.1;
  proxy_set_header Upgrade $http_upgrade;
  proxy_set_header Connection "upgrade";
  proxy_set_header Host $host;
  proxy_cache_bypass $http_upgrade;
 }

Remember to reload the Nginx service for changes to take effect.

Jaquarh
  • 6,493
  • 7
  • 34
  • 86
  • Thanks. I've using the private IPv4 as `proxy_pass http://10.0.0.1:6001;` then start ws with `--host=10.0.01` Correct? I restart nginx but still getting 502 – Sylar Sep 22 '21 at 12:17
  • no, you need to use your loopback address on `127.0.0.1` if you're running the services from the same machine – Jaquarh Sep 22 '21 at 12:18
  • Right. One sec... – Sylar Sep 22 '21 at 12:18
  • 502 is indicating a network issue, try expose the websocket on `127.0.0.1` and then `proxy_pass` to `127.0.0.1:6001`. Is this service definitely running on this port? You can check using `netstat -ano|grep 6001`. – Jaquarh Sep 22 '21 at 12:19
  • How to confirm? I assume once I start the ws with the php command that should be it? – Sylar Sep 22 '21 at 12:21
  • If you're running Linux as your OS, use `netstat -ano | grep 6001`. You should see it `LISTENING` for connections on `127.0.0.1` after you run the `php` command, yes. For Windows, use `netstat -ano | find /I "6001"` or similar. – Jaquarh Sep 22 '21 at 12:22
  • Yes: `tcp 0 0 127.0.0.1:6001 0.0.0.0:* LISTEN off (0.00/0/0)` – Sylar Sep 22 '21 at 12:24
  • Gonna take a moment and explore `X-Forwarded-For`. – Sylar Sep 22 '21 at 12:26
  • Great, so now `proxy_pass 127.0.0.1:6001` and `service nginx reload` (or your preferred way to restart the Nginx service) and try access `foobar.com/v2/api/ws`. – Jaquarh Sep 22 '21 at 12:26
  • Ok.. still getting 502 despite I've accessed the server using the direct public ip: `ws://52.0.0.1/v2/api/ws` I think there's an issue with laravel-websockets as I see nothing else to try. – Sylar Sep 22 '21 at 13:23
  • You need to put the `/v2/api/ws` location above the `/v2/api` location. Right now, all requests to `/v2/api` take precedence. Move it up the precedence chain. Reload Nginx and try that, seems your 502 issue resides in your `/v2/api` location. – Jaquarh Sep 22 '21 at 13:29
  • Funny... by doing that, I now get "404 not found". Stopping ws I got back "502". Ive made an edit. Does this looks right: config/broadcasting.php – Sylar Sep 22 '21 at 13:39
  • This means your Nginx is now proxy passing correctly, yes. It may be a configuration issue from here on forwards. 502 indicates a network issue, so by stopping the service - you are indeed causing this 502. I'll take a look now for you. – Jaquarh Sep 22 '21 at 13:40
  • The `host` should be your public address I believe, not your bind address. Try changing it to `host => 52.0.0.1` and then re-execute your php command to serve the application. This is because Nginx is listening for connections on `52.0.0.1` and `foobar.com` <-- so only these will be accepted as a VHOST in Nginx. This should fix your issue otherwise revert and ensure your `ws://` connection also points to the public IPV4 because when you connect, you are connecting to the Nginx load balancer, not the loopback service. If that makes sense? Hard to explain by typing. – Jaquarh Sep 22 '21 at 13:44
  • Best way to remember it is expose/bind locally, connect publicly. So ensure all your configuration for binding is set to your loopback and then connect on the public IPV4/FQDN (`ws://52.0.0.1/v2/api/ws`) <-- This varies on how your Nginx `server_name` is set, in your case, your public IPV4 will work or you can use your FQDN (`foobar.com`). – Jaquarh Sep 22 '21 at 13:49
  • Thinking of giving up on this. Still getting "404 not found". In the broadcasting.php, host is set to a string value: '52.0.0.1' And this all works on localhost. Im using ubuntu for production – Sylar Sep 22 '21 at 14:02
  • Try reverting back to `127.0.0.1` in the `broadcasting.php` and accessing it using `ws://52.0.0.1/v2/api/ws`. Yeah, SO isn't really the place for server related issues unless its IAC (docker) which, in your case, would probably be much easier. [I open sourced a Larvel production server](https://github.com/Kyle-Jeynes/Laravel-Dockerized) for AWS etc using IAC to avoid these sorts of issues. Before giving up, get me on Discord: `jaquarh#4194` as sharing screens may be much easier to debug. – Jaquarh Sep 22 '21 at 14:13
  • Hey Jaquarh! I got to work at the root instead of the `/v2/api/ws`. Do you know why? I cannot figure it out. I've upvotes for you efforts which should work. – Sylar Sep 22 '21 at 17:04
  • 1
    It should work regardless of the location, unless you have miss-configuration on other related files with the same location. Good job however! Post your solution for future viewers I guess! :) Glad to help. – Jaquarh Sep 22 '21 at 17:51
  • Because I have `/v2/api/ws`, that requires a custom handler. I'll have a read in the morning: https://beyondco.de/docs/laravel-websockets/advanced-usage/custom-websocket-handlers – Sylar Sep 22 '21 at 19:01