运营商封80端口这件事，端口我最早是被禁办法在2018年碰上的。当时帮一个朋友部署公司官网，解决服务器上Nginx跑得好好的端口，本地curl测试返回200，被禁办法外网访问就是解决超时。折腾了一下午防火墙、端口安全组、被禁办法DNS解析，解决最后打电话问机房，端口对方轻描淡写一句“80端口默认封了，被禁办法要备案才能开”。解决那一刻我才意识到，端口问题根本不在我这边。被禁办法

国内大多数云服务商和IDC对80端口的解决限制逻辑其实很简单：防止未备案的网站直接对外提供HTTP服务。工信部要求境内服务器绑定域名必须完成ICP备案，而80端口是HTTP的默认端口，封掉它等于从入口卡住了未备案网站的访问。443端口情况类似，很多机房也是一并封禁的。所以你买完服务器兴冲冲装好环境，浏览器里敲IP地址发现打不开，大概率就是这个原因。

先确认是不是真的被封了

别急着改配置。用telnet 你的IP 80试一下，如果连接被拒绝或者超时，而telnet 你的IP 22正常，那基本可以确认是端口层面的封锁。另一个办法是用在线端口检测工具，从外部扫描你的80端口状态。本地netstat -tlnp看到Nginx在监听0.0.0.0:80，但外部连不上，这个对比就很说明问题了。

最直接的路：换端口

把HTTP服务从80改成8080、8000或者别的端口，是最省事的做法。Nginx配置里listen 8080;改一行，重启，外网用http://你的IP:8080就能访问了。缺点是用户得带端口号，体验差一点，但对于内部系统、测试环境、API接口这类场景完全够用。我自己的几台开发机就是这么干的，8080跑应用，8888跑管理后台，互不干扰。

如果你的域名已经备案了，那直接找机房解封80端口就行。提交备案号，一般一两个工作日就给你开了。没备案的域名，这条路走不通。

用Nginx做端口转发

有人会想：那我用80端口跑一个Nginx，再转发到后端其他端口行不行？问题是80端口本身就被封了，Nginx监听80也没用，外部流量根本到不了。所以这个方案的前提是80端口可用，只是你想把请求分发到不同后端——那是另一回事了。

真正可行的是反向代理配合非标准端口。比如Nginx监听8080，根据域名把请求转发到本机3000、5000等不同服务。外部访问统一走8080，后端服务不用暴露。这台Nginx就充当了网关的角色。

CDN回源绕开限制

这是个比较实用的思路。把域名接入CDN，CDN节点回源的时候可以指定非标准端口。比如源站Nginx监听8080，CDN配置回源端口为8080，用户访问http://yourdomain.com走的是CDN的80端口，回源走8080。这样用户侧看起来是标准的80访问，实际源站端口被封也不影响。

不过CDN接入通常也要求域名备案。国内CDN服务商无一例外。所以这条路本质上还是绕不开备案，只是把端口问题转化成了CDN配置问题。

IPv6的可能性

部分地区运营商的IPv6策略和IPv4不一样，80端口在IPv6下可能是通的。如果你的服务器有IPv6地址，可以试试curl -6 http://[你的IPv6]。我去年在华东某机房测试过，IPv4的80封得死死的，IPv6居然能通。但这个因地区、因运营商而异，不能当作通用方案。而且用户侧也得支持IPv6才能访问，局限性明显。

我的建议

如果面向公众提供服务，老老实实备案，然后找机房解封80和443。这是最稳妥的路径，没有之一。如果只是内部使用或者测试，换高位端口加Nginx反向代理，五分钟搞定，别在80端口上死磕。CDN方案适合已有备案域名、想隐藏源站IP的场景，但配置成本比直接解封高。IPv6可以当作一个备选探测手段，别把它当主力方案。

说到底，80端口被封不是一个技术问题，是一个合规问题。技术手段能绕，但绕过去的方案都有各自的代价。想清楚你的使用场景，选一条匹配的路就行了。