单个页面WebSocket连接失败（net::ERR_CONNECTION_REFUSED）技术求助

结合你给出的配置信息，咱们一步步来定位问题：

1. 确认服务器WebSocket端口的监听状态 #

首先排查最基础的网络连通性问题：

• 登录服务器，用命令检查8181端口是否被你的Java服务监听：
  • Windows：netstat -ano | findstr ":8181"
  • Linux/macOS：ss -tulpn | grep :8181
    如果看不到对应进程，说明你的WebSocket服务没启动，或者配置的监听端口不对。
• 同时确认服务器的防火墙/安全组是否开放了8181端口的TCP入站流量，云服务器还要检查控制台的安全组规则。

2. 验证WebSocket路径匹配是否正确 #

你的客户端连接地址是wss://serverName:8181/projectName/actions，服务器端点是/actions：

• 确认你的Java服务的上下文根确实是/projectName（和项目名称一致），那@ServerEndpoint("/actions")对应的实际路径就是/projectName/actions，这部分你客户端的写法是对的，但要检查服务器端有没有额外配置WebSocket的路径前缀（比如某些框架可能会添加自定义前缀）。
• 可以尝试直接用WebSocket测试工具（比如wscat）连接wss://serverName:8181/projectName/actions，看是否能建立连接。

3. 检查SSL与安全约束配置 #

因为你用的是wss（加密WebSocket），这部分很容易出问题：

• 确认服务器的WebSocket容器（比如Tomcat、Jetty）已经配置了有效的SSL证书，并且监听8181端口的Connector是SSL类型。如果是自签名证书，浏览器会默认阻止连接，你可以先尝试用ws（非加密）连接测试，看是否能成功，排除SSL的影响。
• 查看web.xml里的安全约束，确认<url-pattern>是否包含了/actions，或者有没有排除WebSocket路径。如果安全约束限制了未授权的访问，而WebSocket连接没有携带正确的认证信息，也可能导致连接被拒绝（不过通常这种情况是403错误，而非连接拒绝，但也需要排查）。

4. 排查反向代理（如果存在）的配置 #

如果你的前端页面是通过反向代理（比如Nginx）访问的，而WebSocket直接连接到后端端口：

• 确认反向代理是否支持WebSocket转发，比如Nginx需要配置：

  location /projectName/actions {
      proxy_pass https://localhost:8181;
      proxy_http_version 1.1;
      proxy_set_header Upgrade $http_upgrade;
      proxy_set_header Connection "upgrade";
  }
  

  没有正确配置的话，代理会阻断WebSocket的握手请求，导致连接失败。

5. 客户端侧的小细节 #

• 确认浏览器没有禁用WebSocket功能，或者有没有安装拦截WebSocket请求的插件（比如广告拦截器）。
• 检查页面的域名和WebSocket服务器的域名是否一致（你的情况是一致的，只是端口不同，WebSocket允许跨端口，但还是要确认没有浏览器的特殊限制）。

建议先从端口监听和网络连通性开始排查，这是最常见的原因。如果这些都没问题，再逐步深入路径、SSL和安全配置的问题。

内容的提问来源于stack exchange，提问作者tonder