装好frp或者nps，设置时内配置文件里写好了本地IP和端口，内网服务端也跑起来了，穿透但浏览器一访问，网端502。口查折腾半天才发现，设置时内内网端口填错了。内网这种亏我吃过不止一次。穿透

内网穿透的网端本质是把内网某台机器上的某个服务暴露到公网。你得告诉穿透工具：流量转发到内网的口查哪个IP、哪个端口。设置时内IP一般好确认，内网端口才是穿透容易翻车的地方。很多人凭印象填了个8080，网端结果服务实际监听的口查是3000。

先确认服务到底在监听哪个端口

这是最核心的一步。不要猜，直接查。

Linux下用 ss 命令：

ss -tlnp

输出大概长这样：

State Recv-Q Send-Q Local Address:Port Peer Address:Port Process LISTEN 0 128 0.0.0.0:3000 0.0.0.0:* users:(("node",pid=12345,fd=20)) LISTEN 0 128 0.0.0.0:22 0.0.0.0:* users:(("sshd",pid=800,fd=3)) LISTEN 0 128 127.0.0.1:5432 0.0.0.0:* users:(("postgres",pid=1100,fd=5))

看到没有，node服务跑在3000，PostgreSQL跑在5432，但注意它绑的是127.0.0.1。这个细节后面会坑人。

如果机器上没有ss，用netstat也行：

netstat -tlnp

Windows下：

netstat -ano | findstr LISTENING

最后一列是PID，配合任务管理器可以定位到具体程序。

macOS：

lsof -iTCP -sTCP:LISTEN -P -n

这几个命令输出的信息结构差不多，关键是找到你那个服务的进程名对应的端口号。

127.0.0.1 和 0.0.0.0 的区别能让你白折腾一晚上

上面ss的输出里，PostgreSQL绑的是 127.0.0.1:5432，node绑的是 0.0.0.0:3000。这两个有本质区别。

0.0.0.0 表示监听所有网络接口，来自任何网卡的请求都接受。127.0.0.1 只监听本地回环，只有本机上的进程能访问。

如果你的服务绑的是127.0.0.1，而frp客户端配置里写的是内网机器的局域网IP（比如192.168.1.100），那frp转发过去的请求根本到不了服务。因为服务压根不接受来自192.168.1.100的请求。

解决办法有两个：要么改服务配置让它绑0.0.0.0，要么在frp客户端配置里把本地IP写成127.0.0.1。我一般选后者，改穿透配置比改服务配置省事。

Docker环境下的端口查看是另一回事

服务跑在Docker里，情况多一层。容器内部的端口和映射到宿主机的端口可能不一样。

docker ps

输出里的PORTS列会显示映射关系：

0.0.0.0:8080->80/tcp

意思是宿主机的8080映射到容器内的80。你穿透配置里应该填宿主机的8080，不是容器的80。但前提是frp客户端跑在宿主机上。如果frp客户端本身也跑在Docker里，那又是另一套网络逻辑了，得看它们是否在同一个Docker网络里。

我见过有人在frp配置里填容器IP 172.17.0.2，结果frp客户端在另一个网络命名空间里，根本路由不过去。这种问题查起来很烦，因为端口号本身没错，错的是网络可达性。

一个实际案例

上个月帮朋友调一个Ghost博客的内网穿透。他信誓旦旦说Ghost跑在2368端口，frp配置也写的2368。外网访问就是502。

登上去一看：

ss -tlnp | grep node

输出显示node进程确实在2368监听，但绑的是127.0.0.1。他frp客户端里local_ip写的192.168.1.50。请求到了192.168.1.50的2368端口，系统直接拒绝。

把frp配置里的local_ip改成127.0.0.1，重启客户端，秒通。

所以查端口这件事，不只是查端口号，还得看绑定地址。ss命令的Local Address列同时给了你这两个信息，养成习惯，一眼扫过去。

穿透工具自身的日志也能帮你确认

frpc启动时会打印类似这样的日志：

start proxy success: [web] 127.0.0.1:3000

这行日志告诉你它实际转发到了哪个地址。如果这里显示的和你预期的不一样，说明配置文件写错了。nps的日志在web管理面板里能直接看到，更直观一些。

端口查清楚了，穿透配置填对了，剩下的就是防火墙和云服务器安全组的事了。那是另一个坑，改天再说。