外网访问内网IP总是打不开？用贝锐花生壳把内外网链路接起来
1. 外网访问内网IP失败的根源，往往不在应用本身
很多人排查了半天应用配置，最后发现问题出在地址层面。路由器拨号后拿到的地址，如果属于 10.x.x.x、172.x.x.x、100.x.x.x、192.x.x.x 这几类，基本可以判定为运营商 NAT 后的私有地址，这类地址在全球不唯一，外网设备无法直接寻址。换句话说，内网服务在局域网里跑得好好的，一旦跨出出口就“查无此人”，外网访问内网IP自然无从谈起。这也解释了为什么同一套 OA、ERP 或 NAS 服务，在办公室内部访问毫无问题，回到家或出差途中却始终连接超时。
2. 先分清两条技术路径：动态域名解析与内网穿透
解决思路其实只有两条，但适用条件完全不同。第一条是动态域名解析，前提是宽带确实分配到了真实公网 IP，只是这个 IP 会变，通过域名把变化的 IP 绑定起来即可。第二条是内网穿透，适用于没有公网 IP、拿不到光猫或路由器管理权限、或者运营商直接屏蔽了 80 端口的环境。判断标准很简单：能查到真实公网 IP 且拥有端口映射权限，走第一条；否则走第二条。花生壳同时提供这两类能力，用户不必在两种工具之间来回切换。
3. 内网穿透的工作方式：把内网地址翻译成外网地址
内网穿透的核心逻辑并不复杂：内网设备主动向公网侧的服务节点发起连接，由该节点作为中转桥梁，把外部请求转发回内网服务。落到具体实现上，就是把服务器的内网 IP 和服务端口，通过转发服务器转换成域名加外网端口的形式，外网一侧只需要记住这个域名地址，不需要知道内网拓扑长什么样。这也是贝锐花生壳处理外网访问内网IP需求的基本模型，数据全程经由中转节点，内网主机不直接暴露在公网之上。整个方案不改变原有网络架构，也不必在路由器上开放入站端口。
4. 映射类型只有两种选择，选错就等于白配
花生壳的映射类型收敛到 TCP 与 HTTPS 两类，这是配置环节最容易出问题的地方。网站、Web 管理后台、需要浏览器直接访问的页面，选 HTTPS，花生壳会在服务端自动完成证书部署，本地服务器不需要额外安装证书，浏览器地址栏能看到安全标识。远程桌面、SSH、数据库、FTP 以及各类客户端软件，选 TCP，这类映射生成的是带五位端口号的外网地址，不支持在浏览器里直接打开。把网站错配成 TCP，结果就是页面打不开；把远程桌面错配成 HTTPS，同样连不上。类型与服务的对应关系，比带宽和参数更值得先确认一遍。
5. 参数填写与连通性验证的实操要点
新增映射时需要确认的核心信息包括内网主机和内网端口两项。内网主机填服务器在局域网中的固定 IP，不要填 127.0.0.1；内网端口填服务实际监听的端口，这个端口可以在应用自身的配置里查到，也可以在命令行用 ipconfig 确认主机地址。外网端口默认分配动态端口，删除映射后会变更，需要长期稳定入口的可以选用固定端口。填完之后先做内网验证：在局域网内用 IP 加端口访问一次服务，非 80 端口要带上 http:// 前缀和端口号，能正常打开才说明服务本身没问题。若映射显示已建立但外网打不开，优先回查内网主机 IP 与端口是否写错，再在服务器本地用 telnet 测试端口连通性。
6. 影响长期可用性的几个细节
映射建立之后，稳定性问题通常来自两个方向。一是账号侧，花生壳同一账号不支持多地同时登录，异地登录会互踢，已配置的本地内网服务映射会随之失效，多点位发布建议用不同账号分别映射。二是链路侧，服务节点采用高防 BGP 机房线路并支持冗余备份，不同运营商宽带下的连通质量相对可控。安全层面，HTTPS 映射可叠加访问控制策略，通过时间周期限制、IP 与区域限制、浏览器与系统限制、网页访问验证等方式收窄可访问范围，这项能力需单独开通后使用。对于承载内部业务系统的映射，这一步值得认真配置。
