@heiher #16 s/也会 /不会

@LeeReamond #15 不套支持指定源站端口 CDN 的话，URL 只能带端口，也可以用 URL 跳转方法，但端口也会隐藏的。

公网 IP 盒子几乎都是采用流量从有公网 IP 的服务器中转的方案；如果你的宽带是 NAT1 的，试试打洞方法（相当于白嫖运营商的公网 IP ）：

https://github.com/heiher/natmap/wiki/NATMap
https://github.com/MikeWang000000/Natter

@MeteorVIP #37 我没有理解错，已经启动的 natmap 的 -p 参数还不能运行时修改，建议使用防火墙的端口转发实现 -t 172.16.1.111 -p 23456 的转发功能，性能更好，而且也方便更新目标端口。

如果暂时非要用 natmap 的应用程序端口转发，那么一种 workaround 方法是先后启动两个 natmap ，打同一个端口：

1. natmap -4 -d -i pppoe-wan -s stun.stunprotocol.org -h qq.com -b 48083 -t 172.16.1.111 -p 23456 -e script1
2. natmap -4 -d -i pppoe-wan -s stun.stunprotocol.org -h baidu.com -b 48083 -t 172.16.1.111 -p 54321 -e script2

script1 负责启动第二个 natmap ，并关闭第一个 natmap 。script2 实现同等的功能，当公网端口映射变更时。需要注意的是 -h 参数两个 natmap 需要不同，防止冲突。两个不同的 http server 可以交替使用。

还是建议使用防火墙方式，可以参考这个更新脚本：

https://github.com/Mythologyli/qBittorrent-NAT-TCP-Hole-Punching/blob/master/update.sh#L21

@TongNianShanHe #16 好的，hev-socks5-tunnel 的 udp 功能需要配合 hev-socks5-server 或兼容的服务端使用。

@TongNianShanHe #15 是的，hev-socks5-tunnel 的 udp relay 是采用扩展的 socks5 cmd 实现的 udp over tcp ，不是协议标准的 udp 方式，原因是为了让所有流量都走 tcp ，这样方便过 cdn 。

@MeteorVIP #35 应用程序的端口转发在程序启动后目前无法修改，将来可以增加方法；结合性能考虑，建议使用防火墙的端口转发，在映射建立获得公网端口，调整 BT 客户端侦听端口后，脚本里再更新防火墙的端口转发规则。

@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