@echoless 不了解底层确实很难过面试，去年面过一家小私募量化，被问了什么 go 的什么染色。当时我还信心满满地去面的因为我 go 用得挺熟的，结果反手就被问的哑口无言然后被挂。感觉 go 应该是没什么问题的（虽然我本人很不喜欢），就是面试太爱问实际开发用不到、且不懂也无所谓的东西了。我不理解既然 go 都已经带一个 runtime 了，我为什么还要了解 runtime 的底层机制，总不能反过来预判 runtime 的行为来做些什么所谓优化吧……

（纯好奇，非引战）深入学习 go 是指什么？因为 go 的官方手册都不是很长来着，感觉 go 是一门设计相对简单的语言？

我个人的建议是 C++，虽然我本人其实更喜欢 Rust ，但考虑到楼主不是专业出身（我猜应该不是？因为熟悉的语言是 JS 和 C#），还是更推荐 C/C++。不推荐 Rust 的理由是：

1. 如果直接学 Rust ，可能并不能加强对底层的理解，因为 Rust 的魅力在于其编译器优化，编译器为程序员做了太多事情，导致底层很多东西都被隐藏起来了。
2. Rust 和 C++ 都很难，但是 Rust 学习曲线的前期非常陡峭，C++ 前期简单后期陡峭。考虑到楼主自称年纪大了可能没那么有精力，而且 C++ 跟 C#（毕竟 C# 就是 C++++）有相似之处，所以推荐 C++。
3. 有 C/C++ 基础之后就对内存管理有一些理解，此时再学习 Rust 会自然、简单很多。

不过楼上也有人说 C++ 太杂乱、内容太多之类的，反正楼主又不是想做一个专业的 C++ 程序员把各种新标准新特性玩得转，作为兴趣来说，学个差不多就足以 get 到底层的东西了（何况很多底层代码是纯 C 写的跟 C++ 没什么关系）。

@tgich 我没有 NFC 的需求所以没有关注过。是的三星好像有硬件级别或者反正非常底层的机制，使得 root 之后就有部份功能用不了了。GitHub 上有个 LSPosed 模块叫 [KnoxPatch]( https://github.com/XDABlackMesa123/KnoxPatch) ，root 了之后装这个模块就可以绕过大部份三星的检测机制，但是 Samsung Wallet 和 Samsung Pass （密码管理 app ）还是不能绕过

自己买的是三星，买回来刷了港版，使用体验很好。后面由于有抓包需求，也能相对比较方便地 root 了

一样的情况，也是深圳联通，之前打电话请求 v4 ，不给，说只有 v6 ，现在用 v6 用的还行，就是公司网络没有 v6 ，在公司需要手机开热点，然后就可以 ssh 到家里的设备

@heganyuliang 我现在感觉显示路由器的 v6 地址才是正确的行为，「透明代理」这个词里的「透明」应该是仅对 TCP 服务发起端来说的。

就像传统的 IPv4 世界里，你用一个境外的主机建了个机场（代理），然后自己电脑上连接他，那他就是一个不透明的代理，相同点是「都是代理」，既然代理了，那么就会「代替」、「取代」你（ IP 包的 Src IP 会被替换为代理的 IP ），来跟目标服务器通信，然后再把结果发回给你。

不太清楚 www.ip5.me/ipv6 是什么原理…… 感觉跟其他的测试网站似乎不太一样。

然后我现在已经关掉了 ShellClash 的 IPv6 透明代理，直接让所有 v6 的流量直连了，目前运行良好，测试自己的 IP 也都是我的本机 IP 而不是路由器 IP ，境外流量也都顺利地解析为 IPv4 然后走了节点。现在的 ShellClash IPv6 相关配置是：

ipv6 内核支持：已开启； ipv6 透明代理：未开启； ipv6-DNS 解析：已开启； CNIP 绕过内核：未开启

楼上们说的应该是正解，内核不支持，按照我的理解，原因如下：

TCP 是全双工保证按序交付的传输层协议，所以 Linux 内核支持获取 REDIRECT 之前的 destination 。一个 TCP 连接是以 (Src IP, Src Port, Dst IP, Dst Port) 四元组作为唯一标识的，当真实 destination 发送 TCP 数据包到透明代理时，透明代理知道要把数据返回给 source IP ，因为透明代理内部把 (Src IP, Src Port, Proxy IP, Proxy Port) 和 (Proxy IP, Proxy Client Port, Dst IP, Dst Port) 这两个四元组建立了联系，代理程序清楚地知道，当自己的 Proxy Port 收到来自 source 的数据时，要原封不动地通过第二个 TCP 连接发送给 destination ；当自己的 Proxy Client Port 收到来自 destination 的数据时，要原封不动地通过第一个 TCP 连接发送给 source 。

UDP 几乎就只是在 IP 的基础上加了 Src Port 和 Dst Port ，什么其他功能都没有（不是双工、不保证交付、不一定按序）。假设采取了跟 TCP 一样的原理，当 Proxy Client Port 收到来自 destination 的数据时，能理所当然地直接用 Proxy Port 发回给 source 吗？举个例子，一个人通过 email 投递简历到某公司的 HR 邮箱里（ source 是这个人，destination 是 HR ），HR 读了之后感觉很优秀，认为需要直接让 CEO 跟你对接，于是他把 email 转发给了 CEO （ destination 把数据发给了 thirdparty)，CEO 看完了之后，回了你一封邮件（ thirdparty 发数据给 source ）。假设在 source 前面有一个透明代理，如果他收到的是 HR 的回信那还好，直接理所当然地转回给 source 。但如果是刚刚的情况呢？ HR 没有直接回你，而是让 CEO 回复你，这时透明代理就不知道应该转回给谁了。正因如此，内核就直接不支持获取 REDIRECT 之前的 destination 是什么，因为 UDP 本来是一种不需要建立连接的协议，仅从 UDP 这一层的角度（而不从应用层协议的角度）出发，REDIRECT 之前的 IP 是没意义的。当然应用层的协议可能刚好规定，若 source 给 destination 发数据，那么 destination 必然要跟 source 回复，但是无论应用层怎么规定，UDP 这个传输层的协议是不知道的，也不能做任何乐观假设。

感觉 tproxy 或者其他能代理 UDP 的解决方案，应该就是乐观假设了「 CEO 给你回信」这个场景不会发生？有了这个假设之后，透过其他技术手段（毕竟内核不直接支持）获取到 REDIRECT 之前的 destination 之后，就可以用类似 TCP 的方式把来自 destination 的数据回复给 source 了。

不知道说得对不对，希望大佬能纠正我 =_=

@xclrr 谢谢大佬！`dig` 了一下 test-ipv6.com , 确实没有 v6 地址，而 www.ip5.me 是有 v6 地址的。但是有点没理解跟 NAT 有什么关系，请问下「过了 NAT 」是什么意思呀？ NAT 不是仅仅是个 IPv4 的概念吗？而且，https://ipv6.test-ipv6.com 是个纯 v6 网站，我访问这个网站时，显示我的 v6 地址仍然是 `RouterIP`……

之前在微软工作过，公司发的邮件有时候都会进 spam ，作为个人完全不敢用