从专业角度讲，能比气象台 NB，那我五体投地。路过过一次天天耳闻中的北京南郊观象台，自己可以卫星图看一下规模就知道了。
从自娱自乐角度讲，这事完全没难度，正如 @locoz 13#所述，简单地很。

A 口 B 口冲突了吧
按道理，掩码只负责子网判定，跟 IP 无关，所以按照 LZ 描述，A 口 B 口可以同时设置 192.168.128.5，那显然这是不允许的。

/'dΛb,lju:'e'sel/
大不 留 艾 赛欧

@yitingbai 2# 英雄所见略同

再补充一条，程序是一个逻辑性极强的事情，程序弄多了，思维方式也会跟着强逻辑性，推而广之，世界观方法论都会受其影响。
曾经有人评论过我：编程改变世界。进一步讲，现在的技术发展，单纯的硬件是不可能运行的，各级别的软件均通过程序实现，进而控制住所有事情。

我在二进制上只处理过混淆的 java class bytecode 文件，祝楼主保持满头秀发

frps 本身监听一个端口用于 frpc 接入。然后 frpc 连接后，根据配置文件，在 frps 的服务器端创建一个新端口连接 frpc （相当于将 frpc 的端口映射到 frps 的新端口上）。然后第二个 frpc 连接同一个 frps，将 frpc 本地的端口映射到 frps 服务器上的另外一个端口（即映射第二个端口）即可。

微软市场搜索 QuickLook

话都说到这份上了，还要咋说？
不就是破解、桥接、软路由，路由从光猫上拆解出来。所以光电转换还会热？还怕热？降维打击了。

@rrfeng 7# 所以根本就是芯片性能不行，热不热的，PL1 和 PL2 ？

就是个光电转换器，需要散热片？
除非 LZ 的光猫就是个路由，那也不是散热的问题，真的是累死那颗小小的芯片了。
[臣妾做不到啊]

@liuzh336 6# 你想干啥你不知道么？
看样子像是根据服务器的服务器状态来一级一级反代，而不是根据用户请求条件分流。
你给的案例，是根据用户请求来判定反代去向。所以跟你的期望应该不一致。

又不是 10*10*10——O(n^3)，仅是 O(n)而已，无所谓的

实例编号，UUID 一劳永逸。
递增的编号，除了人阅读起来好看，机器处理起来，1 和 2 这两个实例，哪台设备能知道这两个是有所谓的先后顺序，就是两个字符而已。

如果仅是 2#所述的根据服务器状态来执行，那还是得用 upstream，这就是负载均衡的概念了，而不是仅仅为反代

如果 uri 或者参数场景都不能实现。那你靠什么实现 if-else 呢？

好像以前 youku 是国内 youtube 的定义，现在看来，抖音更有潜力了。youku 下去之后，好像国内一直缺乏一个 youbute 样式的视频站。

所以那天才知道现在搜索不去百度什么的，而是上抖音搜索。其实本人也是这么搞，哪些不懂的事情，去 youtube 上搜索一些视频，答疑解惑比纯文字更直接。

推介一波我之前写的文章： https://post.smzdm.com/p/636483/

删除不用的聊天。

如果还想继续清理空间，那就冒着被收集数据的风险，装流氓全家桶吧

16# 说的直接上缓存就行了
信息本来就是公开的，只不过你做了一个聚合罢了。没啥事。