如题，前提当然是：网络通、端口通。
使用python熟练的人，可能见过这样一个框架‘plotly-dash ’；我使用python不多，也只是知道这个框架的名字和大概的作用。
它可以帮你省掉写前端页面的功夫，并且可以用一行python代码启动一个web服务器。
事情就是从这里开始的。
朋友在windows系统上用python编写了一个程序，并用‘plotly-dash ’这个框架启动运行，然后测试：
使用127.0.0.1和localhost访问一切正常，当局域网内的其他电脑却无法访问（在此之前，朋友还将这台电脑的ip和mac地址进行了绑定——以防ip地址有变动）。
我不懂这个框架，朋友也认为既然本地都正常了，那问题应该出在网络上，所以我围绕这个‘可能的原因’花了一下午时间，进行了下面一系列尝试(我们把部署服务的这台电脑叫PC_A)：
1、在其他电脑ping PC_A，发现是通的；
2、然后telnet对应的端口，嗯，确实不通；
3、关闭PC_A的防火墙，再试，还是不通；
4、在PC_A上开启防火墙，并新建对应端口的入站规则，重试，失败；
5、网络查资料，再新建一个出站规则，重试，失败；
6、关闭防火墙，保留以上规则，重试，失败；
7、拔掉PC_A的网线，插到一台装有tomcat的电脑上，运行，发现一切正常；
8、启用SNMP服务——呃，突然发现这个家庭版的windows没这个服务，只好从安装SNMP开始，结果依旧失败；
9、解绑ip和mac——失败。
到此，只是排除了电脑以外的问题（比如路由、ip设置等），还是不知道真正的原因。
这时想到了应该去查看服务的运行状态，利用netstat命令查看端口信息——一开始发现结果很长，而且本机telnet端口是通的，就没多看，但此时只能研究它了。
然后对比了开启tomcat服务和dash服务时netstat结果的，发现了一个关键的地方：
tomcat开启后，有0.0.0.0:8080这条记录；
dash开启后，只有127.0.0.1:8080记录。
至此终于确认问题就出在dash这个框架上，将这个结果告诉朋友后，他也去查了这个框架的源码，发现这个框架把127.0.0.1这个地址硬编码了进去。
后来又查询了一些资料，发现java开发中，也可能会遇到这个问题，比如：
在nginx配置中有一个listen配置项，是用来配置监听端口的，只写端口的时候，意味着是监听所有ip对应的端口请求；但如果写成[ip]:[port]的形式，就变成了让nginx只监听这一个ip发来的请求。
网友评论