@zhea55 frp 的 xtcp 也是 p2p 模式，去年国庆在老家成功过，挺好使的。但是我在本地走 4G 在 Android 上运行总是不成功，不知道是不是联通 4G 有限制。

@brader 24 的已经没有了，我之前买了 34 的，后来发现买 34 的完全浪费，想过段时间再买个 24 的，春节期间发现升 zhang 级 jia 了。

samba
frp
trojan-go
addon_a0d7b954_esphome
addon_a0d7b954_nodered
addon_a0d7b954_adguard
addon_55275d54_zigbee2mqtt
addon_core_mosquitto
hassio_multicast
hassio_observer
hassio_cli
hassio_audio
hassio_dns
nginx
homeassistant
hassio_supervisor

不影响漏保效果，但是你注意下功率是否在允许范围。
@ajaxfunction 漏保是检测零火线电流，有接地的话漏电后自动就跳了，避免触电；没接地的话在人触电的时候可以触发，防止持续伤害。

玩玩还是不错的，不过如果你的需求是接收 MQTT 推送，可以 MQTT 接收后再走企业微信发消息，用微信接收，就不存在你说的烦恼了，谁还没微信一直在线呢。

stopCh <- struct{}{}被你注释了，main 阻塞在 wg.Wait()，work 阻塞在 select ，没其他 goroutine 在活动能改变这俩阻塞状态。

用小鹤几年了，回不去了，用别人电脑拼音打字时总是输错，想给他改双拼

要求不高的话，用 frp 吧，简单很多，缺点是代理中转了一次，丢失了原始客户端 ip 。

returnValue_1 是 NRVO ，Named Return Value Optimization 具名返回值优化，简单说就是编译器会尽可能给你做返回值优化，减少拷贝。

@weyou frp 的 p2p 模式没有按这个实现吧，我用工具测试，一般是第一次不通过，后面再测就能通过，但是 frp 每次都换一个端口且不会重试，所以 p2p 模式经常不成功。

@fenghuang

@sagaxu 再生一个

static 作用是把符号限制在本编译单元，这样同名函数多处定义也不会报错； inline 作用是建议编译器内联展开，但是编译器也可能不内联，如果内联了，当然不存在符号问题，没内联的话，相当于会在.o 里生成一个弱符号函数，链接时同名的只会取一份。所以按需选择吧：
如果你定义在.c 文件里面，建议 static inline ，因为如果其他.c 有跟你同名但不同实现的 inline ，是有风险的；
如果你定义在.h 里，建议 inline ，在保证只有这个.h 里 inline 定义该函数的前提下，可以使没 inline 时共享同一份实现，减小文件体积，当然你怕出错用 static inline 也行；
还有个 extern inline ，会在.o 里生成一个强符号，也有用处，但也容易出错，几乎没人用。

static 作用是把符号限制在本编译单元，这样同名函数多处定义也不会报错； inline 作用是建议编译器内联展开，但是编译器也可能不内联，如果内联了，当然不存在符号问题，没内联的话，相当于会在.o 里生成一个弱符号函数，链接时同名的只会取一份。所以按需

static 作用是把符号限制在本编译单元，这样同名函数多个编译单元定义也不会报错； inline 作用是建议编译器内联展开，但是编译器也可能不内联，如果你想函数体

@zhoudaiyu 如果后端服务支持 proxy protocol ，可以，例如 nginx 。如果后端服务既不支持 xff 也不支持 pp ，只认 tcp 协议报文取到的 ip ，巧妇难为无米之炊。