MySQL 内网穿透：内网数据库远程连接怎么选路
MySQL 内网穿透怎么选路？内网数据库要给外面连，端口映射、DDNS、SSH 端口转发、VPN 与公网映射五条路逐项对比，外加一张「连不上卡在哪一层」的排错表。
内网的 MySQL 要给外面的人连，这件事通常叫 MySQL 内网穿透。但这个叫法容易让人以为，只要把那条路打通，事情就成了。
打通的只是一条通路。数据库起没起、账号允不允许从外面连、防火墙放不放行、客户端的驱动认不认这套认证——一件都不在这条通路里，而任何一件没弄对，你看到的都是同一句「连不上」。
这一页把能走的几条通路摆在一起比，也把通路之外那几层说清楚。
内网 MySQL 直接开放外网，安全吗
不安全，而且数据库是这件事上最不该冒险的一类服务。
3306 不是什么秘密。它和 5432、6379、27017 一样，都在自动扫描程序的默认清单里——端口一开到公网，几个小时内就会有陌生 IP 来试。这不需要谁特意盯上你，是全网无差别的常态。
一次失手丢的是全部数据
别的服务被打穿，攻击者还要在里面找数据；数据库被连上，就是直接开始导。而且导走不留明显痕迹——很多时候是数据出现在别处了，才知道出过事。
很多部署默认就不设防
Redis 装完不设密码、MongoDB 启动时不加认证、MySQL 的 root 允许远程登录——这些都不是漏洞，是默认配置。在内网里它们没事，端口一出公网，就是全网可读可写。
数据库的认证面还比多数服务薄：没有账户锁定这类语义，弱口令加上不限次尝试，撞开只是时间问题。
所以结论不是「内网数据库不能远程连」，而是外面那个入口必须收窄到只有该连的人能碰。剩下的问题就是：用哪条通路把它接出来。
外网访问内网 MySQL 数据库，五条通路怎么选
同一个目标，五条路。差别集中在三处：要不要公网 IP、暴露面有多大、谁来维护。
| 通路 | 要公网 IP | 公网暴露面 | 维护成本 |
|---|---|---|---|
| 路由器端口映射 | 必须 | 固定 IP + 3306，全网可探测 | 低 |
| DDNS + 端口映射 | 必须 | 同上，域名固定后更好找 | 中：解析与拨号变更要盯 |
| SSH 端口转发 | 要一台可达的跳板机 | 只暴露 SSH | 中：账号与密钥要有人管 |
| 自建 frp | 要一台带公网 IP 的云服务器 | 服务端那个端口，得自己守 | 高：两端配置 + 服务端安全组 |
| 自建 VPN | 必须 | 只暴露 VPN 端口 | 高：装服务端、发证书、轮换 |
| 蜻蜓映射 | 不需要 | 一条随机入口，可按 IP 与时段收窄 | 低：节点与加密由服务侧维护 |
怎么对号入座：
- 没有公网 IP，前两行直接划掉。路由器上那个「端口映射」页面在运营商 NAT 环境里配了也不通——这不是配置问题，是那个 IP 本来就不是你的。
- 有跳板机、人又少，SSH 端口转发最划算：不引入任何额外服务。代价是每个使用者都得自己会建转发，账号和密钥要有人管，人一多就开始乱。
- 自建 frp 之前先算一笔账。它本身是开源免费的，但你得先有一台带公网 IP 的云服务器——那台机器的租金、系统维护、安全组配置，才是这条路的真实成本。网上大部分 frp 教程把这个前提写在「准备工作」里一句带过，等你照着做到第三步才发现绕不开。
- 需要整段内网可达，那是 VPN 的题。VPN 的授权单位是「网络」：给一个人开 VPN，等于把整段内网的可达性一并给了他，而你想给的可能只是一个 3306。它同样需要一个能被连上的公网入口。
- 只想把一个库开给固定几个人：公网映射的授权单位就是单条映射，也不要求你有公网 IP。
只关心安全这一面？同样这几条路按攻击面、能不能收窄、出事能不能查再比一遍，在 RDP 暴露公网安全吗 那页。
建一条 TCP 映射：MySQL 有预设，别的库手填
不管哪种数据库，形状是一样的——一个 TCP 端口送出去。
新建映射时协议选 TCP，本地端口填数据库监听的那个。客户端预设里直接有 MySQL 和 SQL Server 两项，点一下协议和端口就自动填好；其余的库预设里没有，手填端口即可。
本地地址填数据库所在机器的地址：客户端就装在那台机器上，填 127.0.0.1；装在局域网里另一台，填数据库那台的内网 IP。
| 数据库 | 默认端口 | 客户端预设 |
|---|---|---|
| MySQL / MariaDB | 3306 | 有 |
| SQL Server | 1433 | 有 |
| PostgreSQL | 5432 | 手填 |
| Redis | 6379 | 手填 |
| MongoDB | 27017 | 手填 |
判据不是哪个数据库，是它监听一个 TCP 端口还是一片端口。 上面这些都是单端口，走的是同一条路；真要遇上一个需要一整片端口、还夹着 UDP 的服务，那才是另一个问题。
创建之后拿到的入口是「域名:端口」形式——一个随机前缀的域名，加一个由服务器分配的端口。这个地址是固定的：客户端重启不变，映射停用再启用不变，只有把这条映射删掉重建，才会拿到新的一个。
这件事对数据库比对别的服务要紧得多。连接串是写死在应用配置里、写死在 BI 工具的数据源里、写死在流水线环境变量里的——地址变一次，所有引用它的地方一起断。
连不上，卡在哪一层
公网映射只负责通路那一层。剩下的几层都是数据库自己的，任何一层没弄对，报出来都是「连不上」。
先别逐层猜。 对着那条映射点「链路诊断」，四段链路逐段判——公网访问、蜻蜓服务器、蜻蜓客户端、本地服务——哪一段红了问题就在哪一段，报错原文和处理建议一起给出来。
诊断停在「本地服务」这一段时，看错误词分岔：connection refused 说明机器在、网络也通，只是那个端口上没人应答；timeout 是包被丢在半路，根本没到达服务。这一句就把范围砍掉一半。
| 症状 | 多半卡在 | 怎么确认 |
|---|---|---|
诊断报 connection refused |
数据库根本没起来 | 先看服务在不在跑：systemctl status mysql，Windows 在服务管理器里看 |
服务在跑，仍报 refused |
只监听在 127.0.0.1 |
Linux ss -tln | grep :3306；Windows netstat -an | findstr :3306。看到 0.0.0.0 或 * 才算 |
诊断报 timeout |
防火墙拦了 | Windows 入站规则放行该端口；Linux 看 firewalld 或 ufw |
两端都配好仍 timeout（自建 frp 路线特有） |
云厂商安全组 | 云控制台的安全组入方向规则 |
链路全绿，客户端报 Access denied for user |
账号不允许从外面连 | MySQL 的 root 默认只允许 localhost。新建一个专用用户，别去改 root 的 host |
| 链路全绿，报认证插件不被支持 | 客户端驱动太旧 | 较新版本的 MySQL 默认用 caching_sha2_password，旧版 Navicat 与部分 JDBC 驱动不认这套，报 Authentication plugin 'caching_sha2_password' is not supported 之类 |
注意最后两行和前面四行的分界：前四行是「连不上」，后两行是「连上了但被拒」。诊断四段全绿却还是失败，就直接跳到最后两行——不必再回头查网络。
顺带说一件几乎每篇教程都让你做、却没人说清前提的事：把 bind-address 改成 0.0.0.0。
先查再改。 MySQL 自己的默认值是 *，也就是监听所有接口——是不少 Linux 发行版的打包配置把它改成了 127.0.0.1。ss -tln 看一眼当前监听在哪，本来就是 0.0.0.0 或 * 的话，这一步根本不用做。
真需要改的时候，它做的事情是让数据库从「只有本机能连」变成「网络上能到达它的都能连」。改完之后，账号权限和 IP 白名单这两层就从「建议」变成了「必须」——你刚刚亲手拆掉了原本挡在最前面的那道墙。
谁能连到这个库
见得最多的一种误解：配了 IP 白名单，就觉得数据库的密码可以松一点。
这两层是叠加的，不是替代的。映射侧的限制决定谁能敲到门，数据库的账号密码决定敲开了能不能进——少掉任何一层，另一层都要独自扛下全部，而独自扛的那一层，往往正是你以为不用管的那层。
下面这些设置在客户端左侧的「安全 → 访问规则」里。
用白名单，不是黑名单
选「仅允许」模式，只放行办公网出口或云上跳板的固定 IP，其余一律拒绝。数据库这类只有自己人用的服务，建议直接上白名单。注意只支持 IPv4，且家庭宽带的公网 IP 常会变——用之前先确认你的出口 IP 是固定的。
按时段开放
按每周的星期与小时开放，比如只在工作日的上班时间开着。人不在的时候入口就是关的，这一层不花钱也不费事。
访问口令用不上
访问口令只对 HTTP / HTTPS 映射有效。数据库走的是 TCP 映射，用不了它——这一层要靠 IP 限制，和数据库自己的账号密码。
还有一件要说在前面的事：爆破防护不覆盖数据库端口。它只承诺 SSH 与远程桌面这两类最常被撞库的服务，你的 3306 上没有那层东西。
所以这一页不会告诉你「开了防护就安全了」。映射侧的限制是加固，不是替代：数据库自身仍然要强密码、要用最小权限账号（只读的就别给写权限），能配数据库自己的 IP 白名单就再配一层。
入口地址随机、传输全程加密这些通用能力，完整清单见安全指南。
额度与限制
真正值得在决定前算一遍的是带宽，不是并发。
| 免费版 | 专业版 | 企业版 | |
|---|---|---|---|
| 映射条数 | 1 条 | 2 条 | 3 条 |
| 单条带宽 | 1 Mbps | 3 Mbps | 6 Mbps |
| 月流量 | 1 GB | 不限 | 不限 |
| 并发连接数 | 20 | 100 | 500 |
价格与加购项见价格页。
带宽是硬限速，按条计
日常查询、跑几个报表、连着 IDE 调试，完全够用。全库导出、大批量数据迁移、跨库同步这类会持续打满链路的用法，请按上面的数字先算一遍要多久——多半应该换别的方式传，而不是升级带宽。
并发数是同时连接数，不是人数
一条映射不限单人使用，这个数说的是同一时刻挂着多少条连接。两者差得远——一个默认配置的应用连接池上来，闲着不动也占十几条。
要实名认证
映射上线前需在控制台完成实名，这是国内公网服务的合规要求。另外自有域名只能绑 HTTP / HTTPS 映射且须已完成 ICP 备案，数据库走 TCP 映射，用的一定是系统分配的域名。
什么时候别选它
下面几种情况该换别的答案。
- 生产主库——不管用哪种公网方案都不该直接对外，走专线或让应用层提供受控接口。
- 有等保 / 数据合规审计要求——审计口径通常不接受任何形式的公网入口，先问合规再选型。
- 大批量数据搬运——那是带宽题，不是连通性题，上一节已经算过账。
- 组织内已有成熟 VPN 与运维团队——库的访问权已经在那套账号体系里管着了，再引入一套映射侧的授权，两边都要维护，容易对不上。
优先把它用在预发库、测试库、只读从库上，这也是它最省心的位置：通路好搭，出事的代价也可控。
