在s390x架构的linux系统（ubuntu22.04）部署后，日志显示运行，但功能无法生效

[B1gCarr0t]

Describe the bug 在s390x架构的linux系统（ubuntu22.04）部署后，日志显示运行，但功能无法生效 To Reproduce 一、bash <(curl -fsSL https://get.hy2.sh/) 二、生成自签证书 三、配置 四、重新运行 五、返回server up and running 客户端无法获得服务

[tobyxdd]

先排查这些常见原因： https://v2.hysteria.network/zh/docs/advanced/Troubleshooting/#failed-to-initialize-client-connect-error-timeout-no-recent-network-activity

[egg1234]

由于s390x新装ubuntu 22会缺省设置iptables关闭所有端口，22端口除外，并且系统已经安装iptables-persistent程序，所以需要使用root用户执行下面命令清除所有iptables制定的规则并保存

iptables -F iptables -X netfilter-persistent save

使用下面命令检查系统缺省的iptables规则是否清除干净，然后重启机器再检查 iptables-save

[B1gCarr0t]

由于s390x新装ubuntu 22会丙酮设置iptables关闭所有端口，22端口如此，并且系统已经安装iptables-persistent程序，所以需要使用root用户执行下面命令清除所有iptables制定的规则并保存

iptables -F iptables -X netfilter-持久保存

使用下面命令检查系统的iptables规则是否清除干净，然后重启机器再检查 iptables-save

我已经为iptables添加了如下规则 sudo iptables -A INPUT -p udp --dport 22 -j ACCEPT
sudo iptables -A INPUT -p udp --dport 80 -j ACCEPT
sudo iptables -A INPUT -p udp --dport 443 -j ACCEPT
sudo iptables -A OUTPUT -p udp --sport 22 -j ACCEPT
sudo iptables -A OUTPUT -p udp --sport 80 -j ACCEPT
sudo iptables -A OUTPUT -p udp --sport 443 -j ACCEPT
sudo iptables -A FORWARD -p udp --dport 22 -j ACCEPT
sudo iptables -A FORWARD -p udp --dport 80 -j ACCEPT
sudo iptables -A FORWARD -p udp --dport 443 -j ACCEPT
sudo iptables -A INPUT -p tcp --dport 22 -j ACCEPT
sudo iptables -A INPUT -p tcp --dport 80 -j ACCEPT
sudo iptables -A INPUT -p tcp --dport 443 -j ACCEPT
sudo iptables -A OUTPUT -p tcp --sport 22 -j ACCEPT
sudo iptables -A OUTPUT -p tcp --sport 80 -j ACCEPT
sudo iptables -A OUTPUT -p tcp --sport 443 -j ACCEPT
sudo iptables -A FORWARD -p tcp --dport 22 -j ACCEPT
sudo iptables -A FORWARD -p tcp --dport 80 -j ACCEPT
sudo iptables -A FORWARD -p tcp --dport 443 -j ACCEPT 并用netfilter永久固定，reboot后监听443端口，发现hysteria正在监听，可客户端依旧无法与服务端通信

[B1gCarr0t]

netfilter-persistent save 服务器已正常运行： ● hysteria-server.service - Hysteria Server Service (config.yaml) Loaded: loaded (/etc/systemd/system/hysteria-server.service; enabled; vendor preset: enabled) Active: active (running) since Fri 2023-10-13 08:22:31 UTC; 1min 25s ago Main PID: 2004 (hysteria) Tasks: 5 (limit: 4749) Memory: 5.6M CPU: 26ms CGroup: /system.slice/hysteria-server.service └─2004 /usr/local/bin/hysteria server --config /etc/hysteria/config.yaml

Started Hysteria Server Service (config.yaml). server up and running 443端口监听： COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME hysteria 2004 hysteria 3u IPv6 26929 0t0 UDP *:https hysteria 2004 hysteria 7u IPv4 26936 0t0 TCP cloud:46520->104.21.69.135:https (ESTABLISHED) 防火墙放行： To Action From

---

80 ALLOW Anywhere
22 ALLOW Anywhere
443 ALLOW Anywhere
10443 ALLOW Anywhere
80 (v6) ALLOW Anywhere (v6)
22 (v6) ALLOW Anywhere (v6)
443 (v6) ALLOW Anywhere (v6)
10443 (v6) ALLOW Anywhere (v6)
IP地址相同且端口一致 IP可正常ping通 并未设置DNS解析，未使用域名而直接使用IP链接。 服务端客户端混淆方式一致，且密码正确。

[egg1234]

你可以先把s390x的hysteria服务停下来，然后使用nc测试一下udp端口的通讯是否正常

服务器端打入下面命令监听原来hysteria监听的udp端口（假设hysteria服务器端监听的udp端口是443） nc -ulp 443

linux客户端打入下面命令 nc -u 服务器的ip地址 443

然后linux客户端打入hello并回车 这时服务器端应该显示hello的字符，这样才能证明udp通讯是正常的，然后才去排查hysteria不能通讯的原因，否则应该排查udp通讯不正常的原因

另外检查监听端口的命令建议是下面这个，内容详细很多 netstat -tunap

[B1gCarr0t]

你可以先把s390x的hysteria服务停下来，然后使用nc测试一下udp端口的通讯是否正常

服务器端打入下面命令监听原来hysteria监听的udp端口（假设hysteria服务器端监听的udp端口是443） nc -ulp 443

linux客户端打入下面命令 nc -u 服务器的ip地址 443

然后linux客户端打入hello并回车 这时服务器端应该显示hello的字符，这样才能证明udp通讯是正常的，然后才去排查hysteria不能通讯的原因，否则应该排查udp通讯不正常的原因

另外检查监听端口的命令建议是下面这个，内容详细很多 netstat -tunap

感谢回复，nc已经测试过了，443端口的udp通信没有问题

[B1gCarr0t]

我发现问题了，但是无法解决，我发现hysteria无法监听443端口，lsof -i:443 返回了 COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME hysteria 18747 hysteria 3u IPv6 112712 0t0 UDP *:https hysteria 18747 hysteria 7u IPv6 112719 0t0 TCP [2606:4700:110:8bfb:63ad:5f00:b143:4357]:44886->[2606:4700:3037::ac43:d0f6]:https (ESTABLISHED) 但是缺失了listen 确实是以root权限运行的，更换其他低权端口同样无法监听

[mmmjie]

我发现问题了，但是无法解决，我发现hysteria无法监听443端口，lsof -i:443 返回了 COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME hysteria 18747 hysteria 3u IPv6 112712 0t0 UDP *:https hysteria 18747 hysteria 7u IPv6 112719 0t0 TCP [2606:4700:110:8bfb:63ad:5f00:b143:4357]:44886->[2606:4700:3037::ac43:d0f6]:https (ESTABLISHED) 但是缺失了listen 确实是以root权限运行的，更换其他低权端口同样无法监听

同样。。我是用git上的linux脚本部署的，部署后缺少listen 访问不了，但我端口全开了啊，也是sudo运行的

[frank-pian]

docker同样问题，做了nc测试udp通讯测试，但是主机没有ipv6只有ipv4，查看端口显示监听的是443 udp6

udp        0      0 0.0.0.0:111             0.0.0.0:*                           -                   
udp        0      0 10.0.4.2:123            0.0.0.0:*                           -                   
udp        0      0 127.0.0.1:123           0.0.0.0:*                           -                   
udp        0      0 0.0.0.0:123             0.0.0.0:*                           -                   
udp        0      0 127.0.0.53:53           0.0.0.0:*                           -                   
udp        0      0 10.0.4.2:68             0.0.0.0:*                           -                   
udp6       0      0 :::111                  :::*                                -                   
udp6       0      0 fe80::5054:ff:fe6c::123 :::*                                -                   
udp6       0      0 ::1:123                 :::*                                -                   
udp6       0      0 :::123                  :::*                                -                   
udp6       0      0 :::443                  :::*                                -                   

[egg1234]

@frank-pian netstat -tunap命令输出结果显示hysteria只监听udp6端口是非常正常的，我这边同样是IPv4 only的机器也是监听udp6的端口，因为即使IPv4 only的机器，只要是双栈的机器，go语言写的程序一般都会表现为只监听v6的地址，但实际上会同时监听v4及v6端口流量，这个现象即使是xray-core你配置好了之后，用netstat -tunap命令检查监听，同样会发现xray-core也是只监听v6地址，因为xray-core也是go语言写的，但不影响hysteria及xray-core等这些go程序的正常v4通讯，这个现象无论监听tcp或udp只要是go语言写的程序都一样

[frank-pian]

@frank-pian netstat -tunap命令输出结果显示hysteria只监听udp6端口是非常正常的，我这边同样是IPv4 only的机器也是监听udp6的端口，因为即使IPv4 only的机器，只要是双栈的机器，go语言写的程序一般都会表现为只监听v6的地址，但实际上会同时监听v4及v6端口流量，这个现象即使是xray-core你配置好了之后，用netstat -tunap命令检查监听，同样会发现xray-core也是只监听v6地址，因为xray-core也是go语言写的，但不影响hysteria及xray-core等这些go程序的正常v4通讯，这个现象无论监听tcp或udp只要是go语言写的程序都一样

感谢回答，已经找到原因了，配置文件密码后面多了个空格。。。

[B1gCarr0t]

问题是不监听，而不是监听 v6 或者 v4 的问题

[imoonkin]

问题是不监听，而不是监听 v6 或者 v4 的问题

UDP有listen这个状态吗？netstat的状态只是TCP的吧

[egg1234]

@imoonkin netstat -tunap这个命令当然是有udp监听状态显示的，下面是使用root用户运行这个命令并截取其中输出udp监听的部分

udp 0 0 10.0.0.8:53 0.0.0.0: 820/hysteria
udp 0 0 127.0.0.53:53 0.0.0.0: 795/systemd-resolve udp 0 0 10.0.0.8:68 0.0.0.0: 793/systemd-network udp6 0 0 :::443 ::: 822/hysteria

[imoonkin]

@egg1234 我猜他的意思是“State没有显示listen”（最后一个是hysteria）。我的回复也没说清楚，应该说“netstat只是显示UDP，但是在State列不会显示listen”

netstat -tunap
Proto Recv-Q Send-Q Local Address           Foreign Address         State       PID/Program name
tcp        0      0 0.0.0.0:80              0.0.0.0:*               LISTEN      844/nginx: master p
tcp        0      0 10.0.00.2:33226         170.67.208.246:443      TIME_WAIT   -
tcp        0    340 10.00.9.2:22            100.226.22.109:6996     ESTABLISHED 4010/sshd: root@pts
tcp6       0      0 :::22                   :::*                    LISTEN      872/sshd
udp        0      0 127.0.0.53:53           0.0.0.0:*                           706/systemd-resolve
udp6       0      0 :::443                  :::*                                4115/./hysteria-lin

[imoonkin]

你可以先把s390x的hysteria服务停下来，然后使用nc测试一下udp端口的通讯是否正常 服务器端打入下面命令监听原来hysteria监听的udp端口（假设hysteria服务器端监听的udp端口是443） nc -ulp 443 linux客户端打入下面命令 nc -u 服务器的ip地址 443 然后linux客户端打入hello并回车 这时服务器端应该显示hello的字符，这样才能证明udp通讯是正常的，然后才去排查hysteria不能通讯的原因，否则应该排查udp通讯不正常的原因 另外检查监听端口的命令建议是下面这个，内容详细很多 netstat -tunap

感谢回复，nc已经测试过了，443端口的udp通信没有问题

我用nc测试发现单方向畅通，从server发消息到client，client收不到。更换端口就正常了。

[ipdor]

你可以先把s390x的hysteria服务停下来，然后使用nc测试一下udp端口的通讯是否正常

服务器端打入下面命令监听原来hysteria监听的udp端口（假设hysteria服务器端监听的udp端口是443） nc -ulp 443

linux客户端打入下面命令 nc -u 服务器的ip地址 443

然后linux客户端打入hello并回车 这时服务器端应该显示hello的字符，这样才能证明udp通讯是正常的，然后才去排查hysteria不能通讯的原因，否则应该排查udp通讯不正常的原因

另外检查监听端口的命令建议是下面这个，内容详细很多 netstat -tunap

感谢，我一开始懒得关闭hysteria，客户端用了nc -uvz ip地址 端口 的命令检测，下面输出告诉我正常的，但还是不行。用了你的方法后发现服务端没有回显，最后在vps运营商的控制台界面放行了该udp端口，然后正常了(服务器iptables之前设置过了)。