内网网址映射外网

公司内网跑着一套ERP系统，内网访问地址是网址外网 http://192.168.1.50:8080。这串数字只在内网有效，映射出了公司大门就是内网死路一条。但出差在外的网址外网销售总监要审批订单，居家办公的映射财务要核对报表，怎么办？内网答案就是把这串内网地址映射到一个外网能访问的域名上，比如 https://erp.company.com。网址外网

这件事听起来简单，映射做起来坑不少。内网我去年帮一家三十来人的网址外网贸易公司折腾过一回，前后踩了三个坑，映射每个都卡了大半天。内网

第一个坑：以为改个DNS就完事

最开始我想当然地觉得，网址外网把 erp.company.com 的映射DNS解析指向公司出口的公网IP，然后在路由器上做端口映射不就得了？实际操作才发现，公司用的是动态公网IP，每隔几天就变一次。DNS解析刚生效，IP换了，域名又指向了错误地址。

解决办法是上DDNS（动态域名解析）。路由器里一般自带这个功能，绑定一个DDNS服务商，比如花生壳或者No-IP，IP变了自动更新解析记录。但这里有个隐患——DDNS更新有延迟，短则几十秒，长则几分钟。对于ERP这种需要稳定连接的场景，几分钟的中断足够让正在提交订单的同事骂娘。

后来我换了个思路：直接租一台最低配的云服务器，用frp做内网穿透。云服务器有固定公网IP，内网机器主动连上去，稳定性比DDNS好太多。成本一个月几十块，比折腾DDNS省心。

第二个坑：端口映射开得太随意

我见过一个更离谱的案例。某工厂的IT把内网监控系统的554端口直接映射到了公网，没有任何访问控制。结果被扫描到之后，摄像头画面在境外网站上直播了整整两天才被发现。

端口映射不是把内网端口原样搬到公网就完事了。几个基本原则：能不用默认端口就不用，3389、22、1433这些端口在公网上每分钟都有成千上万次扫描；映射之前先确认这个服务有没有做身份认证，没有的话加一层；如果只是自己人用，加个IP白名单比什么都管用。

我自己的做法是，外网只暴露一个443端口，后面挂Nginx做反向代理。所有内网服务走不同的子域名，Nginx根据域名转发到对应的内网地址。这样公网上只看到一个HTTPS入口，攻击面小了很多。

第三个坑：忽略了HTTPS和WebSocket

内网系统大多跑在HTTP上，映射到外网如果不加HTTPS，浏览器会直接标记“不安全”，有些功能比如剪贴板、地理位置直接不可用。更麻烦的是，很多内网系统用了WebSocket做实时通知，反向代理配置不对的话，页面能打开但消息永远不推送。

Nginx配置WebSocket需要显式设置Upgrade和Connection头。我当时的配置大概是这样的：

location /ws/ {  proxy_pass http://192.168.1.50:8080; proxy_http_version 1.1; proxy_set_header Upgrade $http_upgrade; proxy_set_header Connection "upgrade"; proxy_read_timeout 86400; }

少了proxy_read_timeout这一行，连接会在60秒后自动断开，前端表现就是每隔一分钟重连一次。

证书方面，Let's Encrypt免费够用，certbot自动续期。但要注意，如果内网系统本身用了自签名证书，Nginx转发时需要加proxy_ssl_verify off，否则会报502。

一个容易被忽略的细节

内网系统的页面里经常硬编码了内网IP或端口。比如某个按钮的链接写死了http://192.168.1.50:8080/report，外网用户点开直接超时。这种情况要么改代码用相对路径，要么在Nginx里做内容替换（sub_filter），但后者性能损耗不小，只适合临时救急。

说到底，内网映射外网这件事，技术方案本身不复杂，复杂的是每个内网系统都有自己的脾气。DDNS、frp、Nginx反代、端口安全、WebSocket、硬编码链接——这些环节里任何一个出问题，用户看到的就是“打不开”三个字。而你要做的，就是在这三个字出现之前，把坑都填上。