有状态的代理 /VPN 适合把入口放在国内 VPS ， VPS 上再转发一下

TCP 有 Delayed ACK 还有 Nagle 。 TCP 是面向吞吐量和网络效率设计的，严格要求时延应该用 UDP 。

dig -t ns cn. 得到 CN 的权威 DNS ，随便去一个 dig @a.dns.cn. ns1.abc.cn ，这一步的结果里如果有 A/AAAA 记录，说明 NS 已经注册成功，如果只有 NS 记录，说明没有。例如，你可以对比下 dig @a.dns.cn. a.dns.cn 和 dig @a.dns.cn. ns1.abc.cn 的结果，前面一个会在 ADDITIONAL SECTION 里给出 a.dns.cn 的 IP 地址。

git reflog 里找到 rebase 操作前的 hash ， git check ${hash} 就可以回到操作前 master 所在的 commit ，重新建一个 master 分支，然后 git push --force origin master

ocserv[2604]: worker[666]: 12.236.177.110 reducing MTU due to TCP MSS to 1287 (from 1500)
看起来是网络路径上的设备的 mtu 比较小改小了 TCP MSS ， ocserv 自动把最终使得 VPN 设备的 mtu 缩小到 1193 。最佳解决办法应该是客户端换个网络了。也可以试试在服务器用 iptables 强行修改 MSS ，但是不排除会导致 TCP 传输问题。

http://www.ruanyifeng.com/blog/2011/03/url_hash.html

服务器收到的请求不包含 "#" 及后面的部分。

@DoraJDJ 缓存，把热点数据存到 redis 里，缓存命中就不需要查 db 了。适当的缓存设计对性能有巨大提升。

@mjikop1231 想不到什么办法，毕竟问题出在网关那里，把问题反馈给网管处理吧。

@mjikop1231 其实关键不是是不是一个内网，而是返回的包没用经过网关转发，参考下面的分析：
假设你的公网 IP 是 1.1.1.1 ，网关的三个网络接口分别为 wan0, lan0, lan1 。服务器所在的 DMZ 为 10.12.0.0/16 ，接到网关的 lan0 上，另有一个主机为 10.16.0.1/16 ，接到网关的 lan1 上
1. 从 10.16.0.1:12345 发起请求，四元组为 (10.16.0.1, 12345, 1.1.1.1:80)，从 wan0 进入网关
2. 网关机器收到该请求，进行了 DNAT ，四元组变为 (10.16.0.1, 12345, 10.12.17.201, 80)，从 lan0 发送给 服务器
3. 10.12.17.201 收到了这个请求，四元组为 (10.16.0.1, 12345, 10.12.17.201, 80)
4. 10.12.17.201 进行回复时，回复的包四元组为 (10.12.17.201, 80, 10.16.0.1, 12345)，从 lan0 发送给网关
5. 网关上配置了 10.16.0.0/16 走 lan1 ，因此这个包会通过 lan1 发送给 10.16.0.1
发送的链路为 lan1-wan0-lan0 ，其中在 wan0-lan0 上进行了 DNAT ，回来的链路却是 lan0-lan1 ，而不是 lan0-wan0-lan1 ，自然就失败了

https://onebitbug.me/2014/06/01/building-a-gateway-iptables/ 同网段内网无法访问 DNAT 端口

@Chrisplus GPL 不限制， AGPL 限制

@MasterMonkey 可以的，本质上是 OpenVPN ，不需要自己有公网 IP 。
@lbbdefy 挺好用的，能得到一个 IPv6 地址，所以还是要局域网还是要 NAT ，不过影响不大。我用的是同学几个月前买的一年期帐号，现在怎么卖不清楚了。

挂六年级的 IPv6 VPN ，可以给局域网加上 IPv6 支持，看 IPv6 电视

推荐一下 《程序员的数学思维修炼》，通俗易懂，讲的大部分是计算机相关的基础数学知识。

@xiaoz 另一个思路：写一个 setuid 程序专门去执行重启服务的操作，这样就不需要 sudo 了

如果你本身是移动那种上传比较好的线路+用国内 BGP 线路的 VPS 中转，那么体验还是不错的，就是国内的 VPS (尤其是带宽) 都比较贵了

@withlqs 如果保留触摸实体，但是显示在屏幕上，感觉还不错

@Lonely Touch Bar 可以显示 Fn 键

Touch ID 都有了。。。