WSL环境下SSH、Telnet、ShellInABox及Apache服务外部访问失败排查求助

看起来你遇到的问题确实挺闹心的——本地访问一切正常，但外部流量明明过了Norton防火墙却没触发WSL服务的日志，说明流量根本没进到WSL的网络栈里。结合你的情况，我给你列几个实用的排查方向，你可以一步步试：

• 确认WSL端口转发规则是否配置正确
  新电脑的WSL默认大概率用的是NAT模式，这种模式下WSL有自己的内部虚拟IP，Windows主机和WSL之间的端口转发不会自动配置。你可以先在WSL终端里用ip addr查到当前实例的IP（一般是eth0下的inet地址），然后打开Windows的命令提示符（管理员权限），用netsh interface portproxy show all查看是否有对应端口的转发规则。如果没有，手动添加，比如针对SSH的规则：

  netsh interface portproxy add v4tov4 listenport=2233 listenaddress=0.0.0.0 connectport=2233 connectaddress=<你的WSL实例IP>
  

  注意：WSL重启后IP可能会变化，你可以考虑给WSL设置静态IP，或者写个脚本在开机时自动更新portproxy规则。

• 检查Windows Defender防火墙是否拦截了流量
  哪怕你用了Norton 360，Windows自带的防火墙可能还在后台生效，尤其是新系统默认没关闭。你可以临时关闭Windows Defender防火墙测试一下能不能访问，或者手动给这几个端口添加入站允许规则，确保外部流量能先到达Windows主机，再转发到WSL。

• 验证路由器端口转发是否真的生效
  光看路由器的设置界面还不够，你可以用不在同一局域网的设备（比如手机开移动数据）尝试访问http://你的公网IP:80，或者用ssh -p 2233 你的公网IP测试。同时在Windows侧用netstat -ano | findstr "<端口号>"（比如netstat -ano | findstr 2233）查看是否有外部连接请求进来。如果Windows侧都没看到连接记录，那可能是路由器的端口转发没生效——比如你的ISP屏蔽了这些端口，或者路由器的公网IP其实是内网IP（双重NAT），这种情况得联系ISP解决。

• 检查WSL内服务的监听地址
  确保WSL里的sshd、apache、telnetd、shellinaboxd都是监听在0.0.0.0（允许所有地址访问），而不是127.0.0.1（只允许本地访问）。你可以在WSL里用ss -tulpn | grep "<端口号>"检查，比如查看SSH服务的监听情况：ss -tulpn | grep 2233。如果显示的是127.0.0.1:2233，就得修改对应服务的配置文件，把监听地址改成0.0.0.0。

• 抓包定位流量丢失环节
  如果上面的步骤都没找到问题，那就用抓包工具来排查：先用Wireshark在Windows侧抓包，过滤目标端口（比如80、2233），看看外部请求有没有到达Windows主机；如果到了，再在WSL里用tcpdump抓包，看看流量有没有转发进来。这样就能精准定位到是哪一步把流量丢了。

备注：内容来源于stack exchange，提问作者Mark Peterson