@TongNianShanHe #13 好，不客气哈~ 也可以试试在 htproxy 上改改 socks5 server address 来验证。

@mac100 #11 跑在容器内经过多层转发后情况稍微有点复杂，还是建议直接跑在拨号的路由器上。

@TongNianShanHe #11 看你描述的现象，我怀疑是没有处理好访问 socks5 server 要加入例外(不通过 VPN)的情况。Android VpnService 给出了 protect(Socket)的[方法]( https://developer.android.com/reference/android/net/VpnService#protect(java.net.Socket))，但 socks5-tunnel 在 jni 里创建 socket ，所以我的 demo 里是把当前应用加入到 disallow 列表里，当处于全局模式时。在 per app 模式是是不允许选择当前应用的。

https://github.com/heiher/hev-htproxy/blob/master/app/src/main/java/hev/htproxy/TProxyService.java#L99-L105

@TongNianShanHe #9 重点检查配置文件对不对，可以先用生成的配置文件在 Linux 上验证一遍。另外一个需要注意的地方是 JNI 的 PKGNAME ，我不知道你改了没有，可以在 Makefile 中用宏定义覆盖为你的项目包名。

@TongNianShanHe #7 https://github.com/heiher/hev-htproxy

@aa51513 #5 自动创建 tun 网卡设备，但不会自动创建路由规则，主要是考虑到使用需求不同，比如最简单的用法是直接创建一个默认路由，而有些用户可能用策略路由只针对 TCP 、UDP 协议或指定用户下的进程的网络流量。

@nmap 简述原理：创建 tun 虚拟网卡，配置策略路由使网络应用程序的 TCP 和 UDP 流量经过虚拟网卡，前向链路上 tun2socks 程序从虚拟网卡接收经过操作系统网络协议栈分片的 TCP/IP(UDP/IP)报文，程序再通过用户态网络协议栈 LwIP 将 TCP 分片重组成流，转发至连接着 socks5 服务端的 socket 上。反向链路，程序从 socks5 服务端接收到流数据后，通过 LwIP 的 TCP 写 API 送到用户态网络协议栈进行分片，再将分片后的报文送入虚拟网卡，随后被操作系统重组，最终送到网络应用程序。

@missdeer 确实，Linux 上我也是使用 tproxy 方案，性能更好，我也主要是用在 Android 系统上的。可惜底层的协程框架目前还不支持 Windows [Doggy]

江苏电信不丢

@LeeReamond 最好跑在路由器上，跑在内网主机上也行，只是防火墙配置稍复杂一些，Linux/BSD/macOS 系统都可以跑。

ipv6 or 私网 ipv4 打洞: https://github.com/heiher/natmap/wiki/NATMap

试试 NAT1 端口打洞： https://github.com/heiher/natmap/issues/13

@MeteorVIP #46 不需要，其它提供商的域名也可以在 cloudflare 使用。

@MeteorVIP #37

使用 NATMap 在 NAT-1 私网 IP 宽带上部署 Web 服务:

https://github.com/heiher/natmap/wiki/web

包含 natmap 调用脚本通过 API 自动更新 Cloudflare DDNS 的域名解析的 IP ，以及在脚本中更新 Origin rule 的端口。

@llinge #42 https://man7.org/linux/man-pages/man3/scanf.3.html

@llinge #33

https://github.com/heiher/natmap/blob/master/src/hev-misc.c#L70-L234

细节上还是有些不同的，具体见 tfwd 和 ufwd 的差别。

@llinge #31
模式 a 由于 natmap 和业务服务端进行在同一网络空间上，需要绑定同一个源端口，是需要开启 reuseport 的，但是即使服务端没开启这一特性，在 Linux 5.6 及之后内核上，natmap 也会尝试跨进程打开 reuseport ，故业务服务端无需特别配置。

是的，模式 b 由 natmap 在用户态转发，tcp 协议建立两路 tcp 流，由 natmap 进行 splice 。udp 则相对复杂一点点，在用户态维护对应关系，natmap 与业务服务端之间为每一组不同的客户端 srcip:srcport 建立一路 connected 的 udp“连接”。

本着能跑就行的目标写的代码，见笑啦~ :D

@llinge #29 你好

1. 同时支持 TCP 和 UDP ，不加 -u 参数是 TCP 模式，加上 -u 参数是 UDP 模式。
2. 服务端侧的程序无需要特殊修改。
3. 运行 TCP 服务端有三种形式：
a. 无转发模式，natmap 和服务端(如 nginx)都运行在路由器，natmap 负责打通端口映射，nginx 直接侦听并接受连接。
b. natmap 转发模式，natmap 运行在路由器，服务端运行在其它主机，natmap 负责打通端口映射和侦听并接受连接，再建立与服务端的连接，并桥接两路连接，该模式服务端不能拿到真实客户端 IP 。
c. 防火墙转发模式，natmap 运行在路由器，服务端进行在其它主机，natmap 负责打通运营商侧的端口映射，路由器额外配置防火墙的端口转发，负责将路由器侧的入站请求转发至服务端主机，该模式服务端可以拿到真实客户端 IP 。
4. UDP 模式与 TCP 完全相同，也是三种形式。