Nginx子文件夹中的Node.js应用程序，WSS连接到同一服务器

在Apache服务器上管理web项目多年后，我不得不使用Nginx将它们移动到新的服务器上。除了使用WebSocket的一个，我已经成功地迁移了它们

该项目是一个基于web的扫雷舰，使用WebSocket与游戏服务器进行通信。游戏可以通过网络访问。在其client.js文件中，连接是通过行

const ws=new WebSocket（'wss://www.my.domain.com:8081/）

服务器使用包，下面是server.js文件的摘录，位于web文件夹之外：

const fs = require('fs')
const https = require('https')
const server = new https.createServer({
  key: fs.readFileSync('/etc/letsencrypt/.../privkey.pem'),
  cert: fs.readFileSync('/etc/letsencrypt/.../fullchain.pem')
})
const wss = new WebSocket.Server({ server })

wss.on('connection', function (ws) {
  ws.on('message', function (data) {
    // ...
  })
  ws.on('close', function () {
    // ...
  })
})

server.listen(8081)

游戏在以前的服务器上使用这种配置，但我记不起是否必须编辑apacheconf文件才能正常工作

现在，在新服务器上，我有以下配置文件：

server {
    add_header Content-Security-Policy "default-src 'self' *.jquery.com wss: data: blob:;";

    listen 443 ssl;
    listen [::]:443 ssl;

    root /var/www/mydomain;

    index index.html index.htm index.nginx-debian.html index.php;

    server_name www.my.domain.com;

    charset utf-8;
    source_charset utf-8;

    location / {
        rewrite ^/(.*).html$ /index.php?page=$1;
        try_files $uri $uri/ /index.php$is_args$args;
    }

    location /minesweeper/ {}

    location ~ /\.ht {
        deny all;
    }
    ssl_certificate /etc/letsencrypt/.../fullchain.pem; # managed by Certbot
    ssl_certificate_key /etc/letsencrypt/.../privkey.pem; # managed by Certbot
}

如果没有任何额外的配置，当我试图通过其URL访问游戏时，websocket请求不会返回预期的101响应代码。Firefox还触发“无法建立到的连接”wss://www.my.domain.com:8081“错误

基于关于类似问题的SO和其他答案，我尝试使用多个proxy_*参数组合编辑我的Nginx配置，但没有成功

但是，基于websocket服务器和Nginx服务器位于同一IP上，并且websocket服务器正在侦听8081端口这一事实，Nginx服务器是否也应该侦听8081服务器（如果我编辑配置以执行此操作，Nginx会拒绝重新启动，因为websocket服务器已经在该端口上侦听了，并且反过来）？Nginx真的是问题所在还是我遗漏了另一件事

---

提前感谢！

我确认我不必编辑我的Nginx配置。这与代理无关：问题是防火墙不允许8081端口

以下是我在服务器上执行的命令，我在允许端口之前保存了防火墙设置（不确定该过程是否最佳，但它工作正常，连接已建立，我已获得101响应代码）：

• /etc/init.d/iptables save

• iptables-I输入-m状态-state新建-m tcp-p tcp-dport 8081-j接受

• /etc/init.d/iptables save

• /etc/init.d/iptables重新启动