线上部署CodeIgniter-Ratchet-WebSocket报错：连接被拒绝求助

Let's break down the most likely causes and fixes for your "ERR_CONNECTION_REFUSED" error—since it works locally but fails online, the problem is almost always tied to how the WebSocket service is configured or running on your production server.

1. Verify the WebSocket Service is Actually Running on Your Server #

First things first: the error explicitly states no service is listening on port 2000, so let's confirm that.

• Log into your server via SSH and run these commands to check if the Ratchet process is active:

  # Check for PHP/Ratchet-related processes
  ps aux | grep php
  # Or narrow it down to Ratchet specifically
  pgrep -f ratchet
  

• If you don't see the process, start it manually first to test functionality:

  php /path/to/your/codeigniter-project/your-ratchet-start-script.php
  

  Important note: Running the service directly in your terminal will stop it as soon as you close your SSH connection. You'll need a way to keep it running in the background (more on this later).

• Next, confirm the port is being actively listened on:

  # For older Linux systems
  sudo netstat -tulpn | grep 2000
  # For newer Linux systems
  sudo ss -tulpn | grep 2000
  

  You should see an entry showing php bound to port 2000. If not, the service isn't attaching to the port correctly.

2. Fix the Service's Bound IP Address #

By default, some Ratchet setups bind only to 127.0.0.1 (localhost), which means it's only accessible from the server itself—not from external users.

• Open your Ratchet startup script (the file you run to launch the WebSocket server) and locate the IoServer::factory line.
• Modify it to bind to 0.0.0.0 (all network interfaces) instead of 127.0.0.1:

  // Replace this (local access only):
  // IoServer::factory(new HttpServer(new WsServer(new YourChat())), 2000);
  
  // Use this (allows external access):
  IoServer::factory(new HttpServer(new WsServer(new YourChat())), 2000, '0.0.0.0');
  

• Restart the service after making this change.

3. Correct the Frontend WebSocket Connection URL #

This is an extremely common mistake! If your frontend code still uses ws://127.0.0.1:2000, users' browsers will try to connect to their own local machine's port 2000—not your server.

• Update your frontend JavaScript to use your server's public IP address or domain name:

  // Replace with your server's public IP or domain
  const ws = new WebSocket('ws://your-server-ip-or-domain.com:2000');
  

• If your website uses HTTPS, you'll need to switch to wss:// (secure WebSocket) instead of ws://—this may require setting up a reverse proxy (like Nginx) to handle SSL termination for the WebSocket port.

4. Keep the WebSocket Service Running Persistently #

Running the service manually in SSH isn't reliable for production. Use a process manager like Supervisor to ensure it starts on server boot and restarts automatically if it crashes.

• Install Supervisor (if not already installed):

  sudo apt-get install supervisor # For Debian/Ubuntu
  sudo yum install supervisor     # For CentOS/RHEL
  

• Create a Supervisor config file (e.g., /etc/supervisor/conf.d/ratchet-websocket.conf):

  [program:ratchet-websocket]
  command=php /path/to/your/codeigniter-project/your-ratchet-start-script.php
  directory=/path/to/your/codeigniter-project/
  user=www-data # Use the same user as your web server (e.g., apache for CentOS)
  autostart=true
  autorestart=true
  stdout_logfile=/var/log/ratchet.log
  stderr_logfile=/var/log/ratchet-error.log
  

• Update Supervisor and start the service:

  sudo supervisorctl reread
  sudo supervisorctl update
  sudo supervisorctl start ratchet-websocket
  

• Check the service status anytime with sudo supervisorctl status ratchet-websocket.

5. Double-Check Firewall/Network Rules #

Even though your host confirmed the port is open, it's worth verifying the server's local firewall:

• For UFW (Debian/Ubuntu):

  sudo ufw status
  # If port 2000 isn't allowed, add it:
  sudo ufw allow 2000/tcp
  

• For iptables:

  sudo iptables -L -n | grep 2000
  # If no entry exists, add it:
  sudo iptables -A INPUT -p tcp --dport 2000 -j ACCEPT
  

6. Check for SELinux/AppArmor Restrictions #

If you're on a CentOS/RHEL-based server, SELinux might be blocking PHP from binding to non-standard ports:

• Check SELinux status:

  getenforce
  

• If it says Enforcing, temporarily disable it to test:

  sudo setenforce 0
  

• If the service starts working, you can either set SELinux to Permissive permanently or add a custom rule to allow PHP to bind to port 2000.

内容的提问来源于stack exchange，提问作者Taimur Tariq Sikandar