Azure 美金充值 微软云 Azure 账号内网穿透方案

微软云 Azure 账号内网穿透方案：不买公网IP，也能让老家树莓派被全世界访问

你有没有过这种深夜崩溃时刻？——刚在 Azure 上部署好一个 Web API，兴冲冲用 curl 测试，返回 Connection refused；换浏览器访问，提示 This site can’t be reached。你翻遍门户控制台，发现虚拟机没配公网 IP，NAT 规则空空如也，网络安全组（NSG）像一堵沉默的砖墙……别急，不是 Azure 在针对你，而是它默认奉行「最小暴露原则」：你的 VM 默认只活在 VNet 内部，连自己都 ping 不通外网——除非你主动伸手要。

先划重点：Azure 里没有“内网穿透”这个按钮，但有五种靠谱解法

Azure 本身不提供 Ngrok 那种一键隧道服务（虽然能装），但它给足了积木：负载均衡器、应用网关、函数、SignalR、甚至一条 SSH 连接。我们不用魔法，靠组合拳破局。以下方案按「上手难度→运维成本→适用场景」递进排列，全部基于真实踩坑经验，附可复制粘贴的命令和配置。

方案一：SSH 反向隧道——最轻量，适合临时调试

前提：你有一台带公网 IP 的 Linux 服务器（哪怕只是 5 美元/月的 DigitalOcean 小鸡），或一台始终在线的家用宽带路由器（支持端口映射+DDNS）。核心思想：让 Azure VM 主动“倒挂”到这台中转机上。

在 Azure VM 上执行：

ssh -fN -R 8080:localhost:3000 [email protected]

解释：-R 8080:localhost:3000 表示「把中转机的 8080 端口流量，转发到本机（Azure VM）的 3000 端口」；-fN 让它后台静默运行。然后在中转机上，用 Nginx 做一层反代（避免裸露端口）：

location /api {
    proxy_pass http://127.0.0.1:8080;
    proxy_set_header Host $host;
}

⚠️ 注意：Azure NSG 必须放行出站 SSH（22 端口）；中转机防火墙需开放 8080；若中转机无固定 IP，务必配 DDNS（如 noip.com 免费版）。

方案二：自建 FRP ——稳定可控，适合长期项目

FRP（Fast Reverse Proxy）是国产开源神器，比 Ngrok 更省资源、更透明。你需要两台机器：一台当服务端（建议部署在阿里云轻量应用服务器，年付 60 元起），一台当客户端（即你的 Azure VM）。

服务端配置 frps.ini：

[common]
bind_port = 7000
vhost_http_port = 8080
dashboard_port = 7500
dashboard_user = admin
dashboard_pwd = yourpwd

客户端配置 frpc.ini（放在 Azure VM）：

[common]
server_addr = your-frps-domain.com
server_port = 7000

[web]
type = http
local_port = 3000
custom_domains = dev.yourdomain.com

启动后，访问 dev.yourdomain.com:8080 即可直达 Azure VM 的 3000 端口。FRP 支持 HTTPS、TCP/UDP 多协议、健康检查，且所有流量走你自己的服务器，隐私可控。

方案三：Azure Application Gateway + 自签名证书——零成本 HTTPS 穿透

Azure 美金充值 如果你已有域名（哪怕只是免费的 .xyz），且不想碰第三方服务器，Application Gateway 是 Azure 原生最优解。关键点：它自带 WAF 和 SSL 终止，且支持基于主机名的路由（Host-based routing）。

步骤精简版：
① 在 Azure 门户创建 Application Gateway（选 WAF v2 层）；
② 创建后端池，指向你的 Azure VM 私有 IP（无需公网 IP！）；
③ 上传自签名证书（openssl req -x509 -nodes -days 365 -newkey rsa:2048 -keyout key.pem -out cert.pem）；
④ 配置 HTTP 设置，启用「使用自定义探针」并指向 VM 的健康检查端口（如 /health）；
⑤ 创建侦听器，绑定证书；
⑥ 添加规则，将请求路由至后端池。

完成！你的 https://yourapp.azurewebsites.net（实际用自有域名）将直接加密访问 VM 内部服务。注意：Application Gateway 按小时计费（约 $0.18/h），但比租 ECS 更便宜，且免运维。

方案四：Azure Functions + SignalR Service——无服务器穿透，适合 WebSocket 场景

如果你的服务本质是实时通信（如聊天、IoT 设备上报），别硬扛 HTTP 隧道。SignalR Service 是 Azure 托管的实时消息总线，Functions 则负责接收外部请求并广播。

架构链路：
外部用户 → Azure Function HTTP Trigger → SignalR Service → Azure VM 上的 SignalR Client SDK（监听 Hub）

VM 端只需一段 C# 或 Node.js 代码连接 SignalR Hub 并注册方法：

const hubConnection = new signalR.HubConnectionBuilder()
    .withUrl("https://your-signalr.service.signalr.net/client/?hub=iot")
    .build();
hubConnection.on("InvokeLocalApi", (data) => {
    // 在本地执行 curl http://localhost:8080/api/trigger
});

Function 接收请求后，调用 signalRClient.invoke 向 VM 发送指令。整个过程不暴露 VM 网络，不依赖端口映射，毫秒级响应——这才是云原生该有的样子。

方案五：利用 Azure Bastion 的「端口转发」功能——最隐蔽，适合安全审计场景

Bastion 是 Azure 提供的安全 RDP/SSH 网关，2023 年悄悄上线了「端口转发」能力。它不走公网，全程在 Azure 骨干网内加密传输，连 NSG 都不用开。

操作路径：Azure Portal → 你的 VM → 「Connect」→ 「Bastion」→ 勾选「Enable port forwarding」→ 输入本地端口（如 8081）和目标端口（VM 上的 3000）。连接成功后，在你本地浏览器打开 http://localhost:8081，流量已加密透传至 VM 内部服务。

限制：仅支持单端口、需 Bastion Standard SKU（$0.19/h）、必须用 Chrome/Firefox。但它完美规避了「暴露公网 IP」的风险，合规性拉满，金融客户实测通过等保三级。

避坑指南：那些文档里不会写的真相

• NSG 是头号背锅侠：很多人只开了入站规则，忘了出站默认全拒——Azure VM 出站流量需显式放行（尤其 DNS 53 端口），否则 FRP/SSH 连不上中转机；
• Ubuntu VM 默认禁用 root SSH：用 sudo su 切换后，ssh -R 会因权限失败，改用普通用户或配置 PermitRootLogin yes（不推荐）；
• Application Gateway 健康探针超时是 30 秒：若你的本地服务启动慢（如 Java Spring Boot），探针会持续报红，务必加 startup-delay 或改用 TCP 探针；
• SignalR Service 的连接数上限：免费层仅 20 并发，生产环境务必升级到标准层（$1.49/百万消息）；
• Bastion 端口转发不支持 UDP：想穿 DNS 或 VoIP？换方案。

最后说句实在话

内网穿透的本质，从来不是技术炫技，而是「用最小攻击面，换取最大可用性」。Azure 不给你公网 IP，不是吝啬，是在逼你思考：这个服务真的需要被互联网直连吗？能不能用 API 网关做鉴权？能不能用 Event Grid 解耦？当你开始问这些问题，你就从「搬箱子的运维」，进化成了「筑城墙的架构师」。

所以，下次再看到 Connection refused，别急着开 NSG——先泡杯茶，问问自己：我到底想让谁访问？访问多久？要不要加密？要多少并发？答案清楚了，方案自然浮现。毕竟，云不是黑盒子，而是你思维的放大器。