Jason Lyu
Jason Lyu
之前似乎也有人和你有类似的情况，但是造成原因不明。我是直接刷新元数据就好了。
你服务器设置了吗，你用的是默认无效的服务器地址
Hi, any progress on this enhancement?
It’s expected in symmetric NAT, but I don’t understand why it received local udp packet instead of 8.8.8.8. Did you try other proxy servers? Mine works fine with querying DNS.
> Also doesn't RFC 1928 state that the DST address field in the reply from the proxy server should be the real destination which the relay should send the packet...
> Why the from variable [here](https://github.com/xjasonlyu/tun2socks/blob/1ecd587857d10423865205b9f658fd94e5af184b/tunnel/udp.go#L124) (which in my case was 192.168.100.72:40689) is compared with dst (which in my case is 8.8.8.8:53)? To make sure that the address is NAT’s...
理论上一侧连接结束时，另一侧会在tcp wait timeout之后关闭，这是为了避免某些write操作结束了但是read还没结束就直接退出的情况发生。 目前tcp wait timeout默认为5秒，影响应该不大吧？感觉一侧结束就马上关闭另一侧太过激进了，v2ray里也有这个延迟关闭的实现。
> SetReadDeadline 似乎对阻塞在 Read 操作中的连接可能不会生效，不会在 tcp wait timeout 5s 后超时退出。 这就有点奇怪了，如果是这样那问题就属于这块的bug了。
那这是不是就属于它SetReadDeadline实现的bug呢？不过tun2socks里的SetReadDeadline都是系统与gVisor的TCP实现，我之前测试是没问题的。
什么叫集中在一起？是通过tcp连在一起，还是直接整合到一个binary里？前者的话应该也是没问题的。