proxy 会给 http 请求加个 x_forwarded_for 的头，标注了真实来源。
你有 proxy 的管理权的话，可以配置下去掉这个头

租呗
严格意义上，同城市内，只要出了园区，就得是租的，马路对面都不行。
@lcy630409

买 BGP 线路就好了，中国除了三大运营商外，就军队有铺裸线的资格了

@LGA1150 +1 ，然后用 tcp + bbr ，放了 443 端口上，稍微可用度好一丢丢

你家猫是什么牌子的？ nokia 的比较好用，可以让客服给换一个

@DarkCat123 用户名是 support ，密码是猫背后密码倒过来

singtel 给的是公网 IP ，在路由器上，用超管密码进去可以改桥接，路由器 WAN 口设 DHCP 就行了。IPv6 可以打电话找客服要，实测不好用，还不如套个 he 的 tunnel 。
但 sintel 到大陆的质量不太行，我自己也是套了一个阿里云再用的，如果你女朋友的是中国移动可能好一丢丢

你想问非以太网，还是非 TCP/IP 网？非以太网太多了，之前拨号 PPP ，各种 VPN ，都是非以太网，体验没啥区别

好奇你搞这么多隧道做啥

@qingmuhy0 腾讯那个看起来绕北京了，阿里那个不会绕北京的，绕北京延迟么那么低

@Spoter 啥卡，这么便宜，有多少 G 的漫游流量？

基本不会的，同城带宽很充足。但是流量大了可能会被当 PCDN 查了

@Tianao OLT 是参与 PPP 的，报文里插入点啥很简单的

这个事很简单啊，找个能看 pppoe 拨号日志的设备就行了，会告诉你为啥的。原因嘛，也很简单，就是 olt 请求 bras 的时候，会带上端口号，bras 会判断账号和端口的绑定关系，如果对不上就拒绝接入。

参考
https://support.huawei.com/enterprise/zh/doc/EDOC1100419262/3594afc3
如图 19-22 所示，用户发起 PPPoE 拨号。OLT 设备上使能 PPPoE+功能，在透传 PPPoE 报文的时候向报文中插入用于标识用户物理位置的 access-line-id （ PPPoE+）信息。BRAS 设备上使能 Option82 功能，信任客户端上传的 access-line-id 信息，向 RADIUS 服务器发送报文时不改变客户端上报的报文中携带的 access-line-id 信息。RADIUS 服务器上需要预先加载 RADIUS 属性字典文件，RADIUS 服务器在收到用户认证请求报文时，根据报文中携带的 access-line-id 信息，在认证回应报文中通过属性 Framed-Pool 下发 IPv4 地址池属性，通过属性 Framed-IPv6-Pool(100)和 HW-Delegated-IPv6-Prefix-Pool(HUAWEI-191)下发 IPv6 地址池属性。BRAS 设备上配置的地址池名称要与 RADIUS 服务器上一致，根据认证回应报文携带的地址池为用户分配地址。

找别人 ping 下你的 IP ，ping 的中间关了你的猫，看看会不会 ping 不通。如果还能 ping 通，贵运营商搞了 NAT4444 了 https://www.v2ex.com/t/875867

@huaxie1988 你猜当交换机在 mac 表里找不到数据包的 mac 地址，不知道该向哪个口转发的时候，交换机会怎么办？

你看看你 ICMP reject ，回包的 IP ，应该就是你那个 nft 的 reject 导致的。交换机的 mac 表只是看了一眼报文里的 mac 地址和 ip 地址，就把对应关系记录下来了。而你的机器开了 ip_forward ，回个别的 IP 给网关很正常啊

@AEnjoyable 你这玩意就是一个普通的 bgp 呀，和 anycast 没啥关系。楼上说的很清楚，就是 IP 地址段登记信息的问题。这个也没啥办法，整个美国 native ip 做 NAT 吧

@MFWT 不光是 SLA ，而且特别稳，你去 ping 一下，延迟很低而且几乎不带变的。适合跑个语音啥的对延迟丢包敏感的业务。缺点就是真的贵