ciaoSora

@tpxcer 我的 IPv6 是刚需，打运营商电话根本要不到公网 v4 地址

我个人的建议是 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 了。

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