安装 V2Ray Websocket + TLS 模式 排错指引

点击标签看相关主题:

如果你是第一次搭 WSS 梯子不成功，请看本篇排错教程。


操作有没有失误?

我的教程如果附有正常安装日志. 请自行与日志对比有哪里不一样. 

欢迎到Telegram群里求助, 记得描述你参考的是哪篇教程, 走到哪一步报错, 并附上你的终端日志或及问题截图.

也许是其它原因?

如果对比正常安装日志无错, 但是就是某一步安装失败, 或者脚本跑完了但节点就是不能用, 请不要盲目的重复执行脚本. 同样的环境和操作只会得到同样的结果.

请执行以下检查项:
(如果某项正常, 一般不用检查子项)

1. 如果跳过最后打开CDN的步骤, 节点能否使用?

(注意, 如果是在IPv6的小鸡上搭建的节点, 在打开CDN之前, 只能通过手机数据流量来进行IPv6访问)

2. 如果换个新域名, 能否成功?

(注意www.mydomain.com和mydomain.com和abc.mydomian.com是三个不同的域名. 所以你在Cloudflare那里, 只要设置一个新前缀就是一个新域名了)

3. 检查 v2ray 状态及最近的日志, 关注状态是否 active (running), 日志里有没有error或warning

service v2ray status

用service v2ray status检查v2ray运行状态和最近日志

3.1 检查v2ray配置文件config.json格式是否正确

/usr/local/bin/v2ray -config /usr/local/etc/v2ray/config.json -test

不同的脚本, 装出来的文件位置可能不一样, 以你的service v2ray status查询的结果为准. 就是这一行最后加上 ' -test' (注意有个空格)

用 -test 参数检查config.json格式
显示 Configuration OK. 说明配置文件正确。
Configuration OK 表示 config.json 格式正式

3.2 检查是否用户权限问题, 在当前用户下运行v2ray是否功能正常.

/usr/local/bin/v2ray -config /usr/local/etc/v2ray/config.json

4. 检查 caddy 状态及最近的日志, 关注状态是否 active (running), 日志里有没有error或warning

service caddy status

4.1 检查是否成功得到域名的证书. 有没有.crt .key 文件?

(以下为示例, 蓝色部分请换成你自己的域名)

find / -name "*chacuoganzao.ipv6a.my.id*"

检查域名的 .crt .key 证书文件

4.2 检查80 443端口占用情况

lsof -i:80
lsof -i:443

如果是用我的脚本, 正常情况下, 应该被 caddy 占用

如果是用其它脚本, 有可能会被 nginx 或者 v2ray / xray / sing-box 本身占用. 取决于脚本作者的思路. 这些都是正常的.

如果被其它程序(比如 apache)占用，需要关闭其它程序。 

4.3 检查caddy的日志

journalctl -f -u caddy.service

日志里有没有error或warning 

5. 用浏览器访问你的域名, 是否显示伪装站? 如果不是, 显示什么? 

https://chacuoganzao.ipv6a.my.id/

检查伪装站

5.1 检查是否DNS问题. 在VPS里访问域名, 是否得到<html>...</html>的结果?

curl https://chacuoganzao.ipv6a.my.id/

用curl检查https://域名

5.2 '第三方' ping检查DNS是否正确

https://ping.pe/chacuoganzao.ipv6a.my.id

用ping.pe测试IP address或域名

5.3 '第三方' tcp ping检查VPS的80端口 443端口

https://tcp.ping.pe/207.148.79.159:80
https://tcp.ping.pe/207.148.79.159:443
https://tcp6.ping.pe/[2a01:4f8:151:334b:face:452:8586:1]:80
https://tcp6.ping.pe/[2a01:4f8:151:334b:face:452:8586:1]:443

用tcp.ping.pe测试IP地址:端口

如果80端口 443端口不通, 再次确认caddy运行了没有. 如果caddy运行了, 但端口不通, 有可能被防火墙挡了. 确认一下有没有防火墙

which iptables

如果有防火墙, 需要关闭. 

iptables -P INPUT ACCEPT
iptables -P FORWARD ACCEPT
iptables -P OUTPUT ACCEPT
iptables -F

* Vultr一般装了ufw防火墙, 使用

ufw allow 80
ufw allow 443

重启caddy

service caddy restart

还不行的话, 尝试在关闭防火墙后重新执行安装脚本.  

5.4 在你的本地网络环境检测域名解析是否正确

ping 你的域名

在不打开CDN时，你本地网络环境解析域名应该为你的VPS的真实IP地址。

如果不是，可以修改你自己的hosts文件。

在打开CDN时，你本地网络环境解析域名应该为CDN商的服务器地址。

如果不是，可以修改你自己的hosts文件。如，hosts可以设置解析为Cloudflare优选IP。

6. 用浏览器访问 你的域名/path, 是否显示 400 Bad Request? 如果不是, 显示什么?  

https://chacuoganzao.ipv6a.my.id/a4d265a2ec82

用浏览器测试 https://domain/path 应得到400 Bad Request结果

6.1 如果浏览器访问 域名 能显示伪装站, 但是访问 域名/path 没有 400 Bad Request. 

说明caddy转发的数据没有被v2ray接到. 可能是以下原因:

  • caddy配置文件里的分流path和你输入浏览器的不一致.
  • v2ray没跑起来.
  • caddy配置文件里准备转给v2ray的数据走的端口与v2ray配置文件里监听的端口不一致.
caddy配置文件里准备转给v2ray的数据走的端口与v2ray配置文件里监听的端口应一致

欢迎到Telegram群里求助, 并描述你的自测结果.

日志是最好的问题描述

请参考<Xshell自动记录日志>进行设置.
如果你没有文本形式的日志, 请将你的SSH终端(命令行)的显示截图. 可以使用截图工具的滚动截图功能.

用Heroku等环境搭的，没有命令行进行检测怎么办

1. 用'第三方'HTTP检测工具检查 域名/path 应该得到 400 Bad Request

https://www.uptrends.com/tools/uptime

https://www.uptrends.com/tools/uptime 检查 你的域名/你的path

得到 400 Bad Request 就对了！ 

https://www.uptrends.com/tools/uptime 显示 400 Bad Request



评论

发表评论

The Hot3 in Last 30 Days

用浏览器 检测Reality伪装效果 是否搭建成功 排错Troubleshoot

图片
Reality的原理: 当 Reality 节点收到数据包的时候, 如果 Reality 协议的验证通过, 就走节点的翻墙逻辑; 如果 Reality 协议的验证不通过, 就把数据包转发到伪装站. 后续的整个交互过程就像是在和伪装站交互一样. 我们可以简单地用浏览器验证 Reality 伪装效果. 也相当于检测 从你自己到 Reality 节点之间的数据通路是否畅通. 以这样的一个 Reality 节点为例. IP  142.171.237.9 端口  18255 伪装站 learn.microsoft.com 在电脑的hosts文件中, 设置 learn.microsoft.com 解析的IP 为  142.171.237.9   然后在浏览器中, 访问 https://learn.microsoft.com: 18255 可以看到, TLS的锁是正常的. 验证证书, 也是正常的. 从你自己到Reality节点的数据路径是畅通的之后, 如果你的节点还不能用, 那么, 就应该检查你的Reality节点验证信息了 (UUID, 公钥) ======== update 如果是用了中转后的 Reality 节点 原 Reality 节点 IP  142.171.237.9 端口  18255 伪装站 learn.microsoft.com 中转 VPS  IP 142.171.223.56 端口 28828 那么, 在电脑的hosts文件中, 设置 learn.microsoft.com 解析的IP 为  142.171.223.56 然后在浏览器中, 访问 https://learn.microsoft.com: 28828 可以看到, TLS的锁是正常的. 验证证书, 也是正常的.
Read more »

用darkstat统计VPS上的流量

图片
感谢 https://0x3f.org/posts/darkstat-as-a-network-discharge-meter/ https://ilovn.com/2023/03/25/darkstat/ 安装 apt install -y darkstat 启用 darkstat -i 监听网卡 -p 网页端的端口号 如 darkstat -i eth0 -p 8964 页面端查看 http:// 你的vps的IP : 网页端的端口号 如 http:// 12.34.56.78 : 8964 效果类似下面这样 点 host 可以看到数字表格的统计信息. 点其中一条 可以看到更详细的信息. 能看到在本VPS上, 还有指定IP上, 分别用到了什么端口(包括TCP UDP), 以及分别跑了多少流量. 如果你有有更好的工具, 欢迎留言分享!
Read more »

233 sing-box 脚本 TCP 端口转发 Reality 协议 排错 Troubleshoot

图片
233 boy 的 TCP 端口转发的教程 https://233boy.com/sing-box/sing-box-direct/ 下图中示意, 左边的 142.171.237.9 是被墙的VPS, 右边的 142.171.223.56 是用来做端口中转的VPS. 如果你照着教程操作一遍, 发现不能正常使用. 那么本文指导你如何排查问题所在. ======== 首先, 你要理解整个原理是什么. 左边的, 本来的reality协议节点, 底层是TCP直连, 那么是从你的 翻墙客户端(手机/电脑/...) 去连接  142.171.237.9  的 18255 端口. 现在被墙了, 那么无法直接TCP连接了. 右边的, 用于中转的VPS, 设置的 TCP端口中转 的本质是,  142.171.223.56  从端口 28828 收到的TCP数据, 会转发给  142.171.237.9  的 18255 端口.  所以, 你现在可以把本来准备发送给  142.171.237.9  的  18255  端口 的realiy数据包, 发送给  142.171.223.56  的  28828  端口; 142.171.223.56  从端口  28828  收到的TCP数据, 转发给  142.171.237.9  的  18255  端口. ======== 我们延着数据路径一段一段的排查. 1. 从我们的翻墙客户端(手机/电脑/...)连接中转VPS  142.171.223.56  的  28828  端口; a) 可以用 tcp.ping.pe 检测 142.171.223.56  的  28828  端口是否正常; b) 在你自己的电脑  tcping 检测 142.171.223.56  的  28828  端口是否可连接. 2. 在中转VPS上查 sing-box 的 access.log cat /var/log/sing...
Read more »