如果是 Linux 路由器的话，应该可以用某种方式 hook dhcp server 的请求，然后用脚本触发一个 PPPoE 连接，并依据连接的信息分配 IP 地址。但是如果要让 IP 地址和 PPPoE 一样的话，那么通常路由器也需要有一个同网段的 IP 地址作为告知用户的网关地址。
听起来技巧主要是找一个合适的 DHCP 服务器软件，可以 hook 出地址池分配的逻辑就行。或许也可以借用一些 RADIUS 认证的机制。
另外就是要注意一下生命周期，比如可以在租约有效期限内维持 PPPoE ，租约到期以后断开，这样的话或许也要 hook 到 DHCP 租约到期的逻辑。

@OmoineMie 基于 TCP 的测速会受到 TCP 速率控制算法的影响，无线的延迟抖动和丢包会让速率控制算法收敛到不同的速率，通常更为保守。通常而言 TCP 的来回时间越长（距离越远），中间经过的不稳定链路越多（例如无线）都会导致这样的问题。
作为控制变量，你也可以在本地内网运行一个代理服务器，这样通过代理服务器上网就可以把一个 TCP 连接分成两段，一段有更大的延迟，一段有无线的抖动，把这两个影响分开可能速率就可以更快了。

早些年 TCP 为了让 Wi-Fi 连接 WAN 以后跑得起速率，在算法上做过很多改良的，但多少都会有性能损失。

看到评论区运营商都可以明明白白的做流量标记，开什么白名单，就觉得运营商自己越来越做不了自己的生意了。

企业内网用应该还是需要企业内网的 STUN 服务器吧。

在什么频段并不直接影响速率，也可能和设备有关。

1. 6GHz 频率比 5GHz 高，所以穿墙性能会减弱。
2. 可能你用的 6GHz 频率与其他用户有冲突，存在干扰避让。
3. 可能你用的 6GHz 信道频宽小一点？
4. 可能 6GHz 下的调制模式 MCS 碰巧差了一点？

如果这些参数一样的话，6GHz 和 5GHz 相比也不会更快，只是不同频率罢了。（厂商只是想卖货，但是实际上如果没有更大的频宽可用，其实没差。）

如果是在 Cloudflare 上的话，可以使用访问规则使得只有 Google Bots (known bots)可以访问特定 URL 。

苹果地图！好处是

1. 语音可以调成台妹
2. 不像高德那样话多
3. 没有广告
4. 界面简洁清晰
5. 注重隐私，数据更加合规（高德通常都是不遵守个人信息保护法的）

@wheat0r 腾讯云轻量的好像特殊一点，是服务器启用后才能在 web 端增加 v6 配置的。似乎也不是 slaac 之类的标准方法。

腾讯云轻量应用服务器的 ipv6 好像是初次配置时需要腾讯云的后台服务来进行 ip 地址的分配。但是后续使用（包括自己换其他系统后）都可以继续使用之前静态配置的 ipv6 地址。

国际网间路由是非常动态的，通常可以由服务商通过 BGP 协议控制，中间经过的运营商也会因为负载均衡，分流，海缆可用情况等等原因动态调节，观察下来一年中会变很多次。
你注意到的很可能不是针对性的“优化”，可能只是碰巧运营商网络割接、调整等等原因导致的。

希望可以加群了解一下。👀

Wireguard 在系统路由表建立路由其实有两个阶段。

第一个阶段是在系统加载虚拟网卡并设置网卡地址时。这时会读取 [Interface] 下的 Address ，设立相应的 IP 地址，如果是/24 的话，系统会自动对/24 增加一个路由，使得相关流量从该虚拟网卡走。

第二个阶段是使用类似 wg-quick 等工具时，这些工具会在基本操作之外读取你 [Peer] 下各个 peer 的 AllowedIPs 字段，并且将对应的段加到路由表，使得相关流量从该虚拟网卡走。


所以如果你是用 wg-quick （通常也包括 iPhone 客户端这类功能完整的 wireguard 前端），只要相应的 peer 下面的 AllowedIPs 包含需要的段的话，[Interface] 下面的地址设置成 /32 应该也是没有关系的。

与此相对的，在一些路由器上配置的 wireguard 并不会自动加载 AllowedIPs 路由（例如 RouterOS 就是这样），这种时候就需要通过设置虚拟网卡的 IP 地址和正确的前缀，或者手动增加路由条目来确保相应地址会走虚拟网卡。

这种不是去向丢包，是 icmp 反馈没有很积极，或者 icmp 包回程被丢了一部分。你的第七跳丢包率低就意味着你发过去的包在之前的几跳都是正常没有丢，只是前面几跳的路由器懒得搭理你给你反馈。
这是使用 mtr 或 traceroute 检查路由时的常见现象。

@journalist 要使设备 A 使用 B 的地址作为源地址向服务器建立连接，那么目标 C 返回的包的目的地址就是 B 的地址。

如果设备 A 使用 socks5 ，tproxy 等代理技术，那么设备 A 必须能够拦截到目标 C 返回的发给 B 的包，并重新以代理响应的方式返回给 B ，这就要求目标 C 发给 B 的包在网络中一定得经过设备 A 。此外在 A 上实现这个功能也比较怪异，例如 socket 要绑定非本机 IP ，并且可能要注入一个特定的 ebpf 程序来劫持目标 C 返回的特定包。

也有一些特殊的做法可以满足你的要求，例如一个叫做 dae 的代理软件使用 ebpf 来过滤直连的流量，只要确保不启用 SNAT ，就可以实现你需要的功能。这类代理软件在处理直连的流量时行为完全与路由器是一致的。https://github.com/daeuniverse/dae/blob/main/docs/zh/how-it-works.md

云服务器是一种特殊的商品，他的特点是当机房有余量时，不管是否销售出去成本都是固定的。幻兽帕鲁游戏服务器几乎没有什么带宽开销，机房的算力又普遍冗余，所以云厂商提供短期的特别套餐，本质上是区分市场，赚取额外收益。

@jsq2627 上行流量会在用户接入侧就因爲带宽限制而丢包，不会给骨干网造成压力。但是这种丢包可能会严重影响使用，用户没有明确感知可能还是要归功于日常上传需求就比较小。

@Fucter @ambition117 @MossFox

其实咱也只是想用于一些低带宽、低延时的场景的。专线一般都是这种应用场景。

@lcy630409 @huluhulu @huaseky

不是觉得他们技术不行，主要是考虑到不少游戏是基于 P2P 联机，所以并不能建立一个白名单把所有潜在游戏玩家的 IP 都包括进来吧？只要用类似的方式进行 P2P 连接，应该很难区分是否是游戏流量吧？