OP 14#
我觉得，应该这么解决：家里运行 frps ，同时这个 frps 对公网公开——公开的方法在防火墙上开口，V4 的 NAT 或者 V6 的放行。然后如果公司是 Windows ，那就比较简单了，frpc 把 3389 怼到 frps 上。最终在家里连接 frps 的 3389 （或者映射的其他端口）就完活了；如果是非 Windows ，类似，映射 22 或者其他什么端口。
当然了，这个需求是在家里能够操控公司的电脑。如果在家里需要接入公司的网络，那没有公司网管的配合，估计很困难。

frps 必须在一个 frpc 能找得到的地方（公网 IP ）上，然后把 client 的端口映射到 server 上。这个主要解决的是外网连接内网的某个具体端口。并不是构建外网到内网的全网络连接——这是 VPN 或者 SD-WAN 或者 Zerotier 的功能。

坐等楼下来喷楼上😂

@also24 14# 那要这么说，严格意义上的推送是不可能的，但广义上能做到“推送”的行为。
要么 client 变 server ，服务器端按照 client 的方式找 server ，随便推。
或者 client 跟 server 保持密切关系，维持连接，http 长连接，包括这个 IDLE 。
再不济，那就是轮询，ajax ，邮件每 15 分钟检查。

@also24 10# 按照 11#所属的 IDLE ，那也是客户端维持一个服务器端的连接，然后服务器端通知客户端。这个机制遇到应用被杀死、网络变化——即连接断开了，那也是无济于事的。何况文章还说了更多的情况，比如监控多个文件夹，需要创建多个连接，然后就更加复杂了。

其实根本问题还是 server-client 的模式，server 永远不可能主动找到 client 。

一提起萧峰 /乔峰，你们想起谁？
一提起白娘子，你们想起谁？

主要是剧荒（文艺不发达）的年代，一部好剧给我们的印象太深刻了。现在的电视剧，角色<>演员的固化，已经很淡很淡了。

1# 3# 把问题看明白，他的核心点是云主机的流量问题，而不是端口问题。
端口问题可以通过二级域名解决，二级域名走反代，但是走了反代意味着流量都要过云主机。家宽的端口是硬伤，绕不过去，要么端口化，要么云主机流量化。

找个开放 80 、443 的，nignx 上发 HTTP 301 ，但非 http 无效

修正 13# JSON.stringify(---).indexOf(---) > -1
遍什么历。。。

JSON.stringify(---).substring(---) > -1

难道这不是设置邮件 APP 的定时获取，然后开后台以及通知么？
IMAP 和 POP3 都是获取的协议，没有推送的丁点功能。

两张图片，过渡动画擦除
你这图还没有对齐，对齐了效果更好一些。