starred/goproxy
1
0
Fork 0
mirror of https://github.com/snail007/goproxy.git synced 2026-04-27 00:15:51 +03:00
Code Issues 144 Projects Releases 3 Packages Wiki Activity

[GH-ISSUE #520] 我在使用贵项目做socket5代理支撑FTP传输时发现，底层用TCP协议可以通，但是KCP协议WARN handshake fail, ERR: new methods request fail,ERR: timeout，希望解决这个问题 #423

New issue
Open
opened 2026-02-27 23:16:51 +03:00 by kerem · 1 comment
kerem commented 2026-02-27 23:16:51 +03:00
Owner
Copy link

Originally created by @jzbg on GitHub (Jan 10, 2023).
Original GitHub issue: https://github.com/snail007/goproxy/issues/520

我在使用贵项目做socket5代理支撑FTP传输时发现，底层用TCP协议可以通，但是KCP协议不通，希望解决这个问题

Expected Behavior

我在使用贵项目做socket5代理支撑FTP传输时发现，底层用TCP协议可以通，但是KCP协议不通，希望解决这个问题

Current Behavior

这是我的一级代理日志，kcp用38080端口，ftp客户端在握手时，代理日志出现WARN handshake fail, ERR: new methods request fail,ERR: timeout
C:\Users\Administrator\Desktop\proxy124>proxy socks -t kcp -p ":38080" --kcp-key
mypassword
2023/01/10 17:20:36.450980 INFO kcp socks proxy on 0.0.0.0:38080
2023/01/10 17:20:41.491480 INFO use parent false : 192.168.1.112:21
2023/01/10 17:20:41.492480 INFO conn 192.168.1.31:60263 - 0.0.0.0:38080 <-> 192.
168.1.32:55278 - 192.168.1.32:55278 connected [192.168.1.112:21]
2023/01/10 17:20:42.411480 INFO use parent false : 192.168.1.112:62186
2023/01/10 17:20:42.411480 INFO conn 192.168.1.31:60264 - 0.0.0.0:38080 <-> 192.
168.1.32:55279 - 192.168.1.32:55279 connected [192.168.1.112:62186]
2023/01/10 17:20:42.412480 INFO conn 192.168.1.31:60264 - 0.0.0.0:38080 <-> 192.
168.1.32:55279 - 192.168.1.32:55279 released [192.168.1.112:62186]
2023/01/10 17:20:47.451480 WARN handshake fail, ERR: new methods request fail,ER
R: timeout
2023/01/10 17:20:52.531480 WARN handshake fail, ERR: new methods request fail,ER
R: timeout
2023/01/10 17:20:57.611480 WARN handshake fail, ERR: new methods request fail,ER
R: timeout
2023/01/10 17:21:02.571480 INFO use parent false : 192.168.1.112:21
2023/01/10 17:21:02.572480 INFO conn 192.168.1.31:60271 - 0.0.0.0:38080 <-> 192.
168.1.32:55282 - 192.168.1.32:55282 connected [192.168.1.112:21]
2023/01/10 17:21:02.691480 WARN handshake fail, ERR: new methods request fail,ER
R: timeout
2023/01/10 17:21:03.412480 INFO use parent false : 192.168.1.112:62187
2023/01/10 17:21:03.412480 INFO conn 192.168.1.31:60272 - 0.0.0.0:38080 <-> 192.
168.1.32:55283 - 192.168.1.32:55283 connected [192.168.1.112:62187]
2023/01/10 17:21:03.413480 INFO conn 192.168.1.31:60272 - 0.0.0.0:38080 <-> 192.
168.1.32:55283 - 192.168.1.32:55283 released [192.168.1.112:62187]

2023/01/10 17:21:03.412480 INFO use parent false : 192.168.1.112:62187
2023/01/10 17:21:03.412480 INFO conn 192.168.1.31:60272 - 0.0.0.0:38080 <-> 192.
168.1.32:55283 - 192.168.1.32:55283 connected [192.168.1.112:62187]
2023/01/10 17:21:03.413480 INFO conn 192.168.1.31:60272 - 0.0.0.0:38080 <-> 192.
168.1.32:55283 - 192.168.1.32:55283 released [192.168.1.112:62187]
一下是ftp客户端日志
状态: 连接到 192.168.1.112，通过代理 SOCKS5
状态: 正在连接 192.168.1.31:8083...
状态: 与代理连接建立，进行握手...
状态: 连接建立，等待欢迎消息...
状态: 不安全的服务器，不支持 FTP over TLS。
状态: 已连接
状态: 读取“/”的目录列表...
状态: 正在连接 192.168.1.31:8083...
状态: 与代理连接建立，进行握手...
响应: 150 Connection accepted
响应: 226 Transfer OK
错误: 20 秒后无活动，连接超时
错误: 读取目录列表失败

Possible Solution

Steps to Reproduce

1.在112启动ftp服务端
1.在32启动一级代理
1.在31启动二级代理
1.在111启动ftp客户端
客户端 连接超时

Context (Environment)

  1. proxy version is : v12.4
  2. full command is :proxy socks -t kcp -p ":38080" --kcp-key mypassword
  3. proxy socks -t tcp -p ":8083" -T kcp -P "x.x.x.x:38080" --kcp-key mypasswor
  4. system is :win7
  5. full log is: 上边已提交
  6. ftp服务端使用FileZilla0.9.41
  7. ftp客户端使用FileZilla3.14

Detailed Description

用kcp支撑socket5代理，连接ftp时，出现连接超时

Possible Implementation

Originally created by @jzbg on GitHub (Jan 10, 2023). Original GitHub issue: https://github.com/snail007/goproxy/issues/520 <!--- Provide a general summary of the issue in the Title above --> 我在使用贵项目做socket5代理支撑FTP传输时发现，底层用TCP协议可以通，但是KCP协议不通，希望解决这个问题 ## Expected Behavior <!--- Tell us what should happen --> 我在使用贵项目做socket5代理支撑FTP传输时发现，底层用TCP协议可以通，但是KCP协议不通，希望解决这个问题 ## Current Behavior <!--- Tell us what happens instead of the expected behavior --> 这是我的一级代理日志，kcp用38080端口，ftp客户端在握手时，代理日志出现WARN handshake fail, ERR: new methods request fail,ERR: timeout C:\Users\Administrator\Desktop\proxy124>proxy socks -t kcp -p ":38080" --kcp-key mypassword 2023/01/10 17:20:36.450980 INFO kcp socks proxy on 0.0.0.0:38080 2023/01/10 17:20:41.491480 INFO use parent false : 192.168.1.112:21 2023/01/10 17:20:41.492480 INFO conn 192.168.1.31:60263 - 0.0.0.0:38080 <-> 192. 168.1.32:55278 - 192.168.1.32:55278 connected [192.168.1.112:21] 2023/01/10 17:20:42.411480 INFO use parent false : 192.168.1.112:62186 2023/01/10 17:20:42.411480 INFO conn 192.168.1.31:60264 - 0.0.0.0:38080 <-> 192. 168.1.32:55279 - 192.168.1.32:55279 connected [192.168.1.112:62186] 2023/01/10 17:20:42.412480 INFO conn 192.168.1.31:60264 - 0.0.0.0:38080 <-> 192. 168.1.32:55279 - 192.168.1.32:55279 released [192.168.1.112:62186] 2023/01/10 17:20:47.451480 WARN handshake fail, ERR: new methods request fail,ER R: timeout 2023/01/10 17:20:52.531480 WARN handshake fail, ERR: new methods request fail,ER R: timeout 2023/01/10 17:20:57.611480 WARN handshake fail, ERR: new methods request fail,ER R: timeout 2023/01/10 17:21:02.571480 INFO use parent false : 192.168.1.112:21 2023/01/10 17:21:02.572480 INFO conn 192.168.1.31:60271 - 0.0.0.0:38080 <-> 192. 168.1.32:55282 - 192.168.1.32:55282 connected [192.168.1.112:21] 2023/01/10 17:21:02.691480 WARN handshake fail, ERR: new methods request fail,ER R: timeout 2023/01/10 17:21:03.412480 INFO use parent false : 192.168.1.112:62187 2023/01/10 17:21:03.412480 INFO conn 192.168.1.31:60272 - 0.0.0.0:38080 <-> 192. 168.1.32:55283 - 192.168.1.32:55283 connected [192.168.1.112:62187] 2023/01/10 17:21:03.413480 INFO conn 192.168.1.31:60272 - 0.0.0.0:38080 <-> 192. 168.1.32:55283 - 192.168.1.32:55283 released [192.168.1.112:62187] 2023/01/10 17:21:03.412480 INFO use parent false : 192.168.1.112:62187 2023/01/10 17:21:03.412480 INFO conn 192.168.1.31:60272 - 0.0.0.0:38080 <-> 192. 168.1.32:55283 - 192.168.1.32:55283 connected [192.168.1.112:62187] 2023/01/10 17:21:03.413480 INFO conn 192.168.1.31:60272 - 0.0.0.0:38080 <-> 192. 168.1.32:55283 - 192.168.1.32:55283 released [192.168.1.112:62187] 一下是ftp客户端日志 状态: 连接到 192.168.1.112，通过代理 SOCKS5 状态: 正在连接 192.168.1.31:8083... 状态: 与代理连接建立，进行握手... 状态: 连接建立，等待欢迎消息... 状态: 不安全的服务器，不支持 FTP over TLS。 状态: 已连接 状态: 读取“/”的目录列表... 状态: 正在连接 192.168.1.31:8083... 状态: 与代理连接建立，进行握手... 响应: 150 Connection accepted 响应: 226 Transfer OK 错误: 20 秒后无活动，连接超时 错误: 读取目录列表失败 ## Possible Solution <!--- Not obligatory, but suggest a fix/reason for the bug, --> ## Steps to Reproduce <!--- Provide a link to a live example, or an unambiguous set of steps to --> <!--- reproduce this bug. Include code to reproduce, if relevant --> 1.在112启动ftp服务端 1.在32启动一级代理 1.在31启动二级代理 1.在111启动ftp客户端 客户端 连接超时 ## Context (Environment) <!--- How has this issue affected you? What are you trying to accomplish? --> <!--- Providing context helps us come up with a solution that is most useful in the real world --> 1. proxy version is : v12.4 1. full command is :proxy socks -t kcp -p ":38080" --kcp-key mypassword 2. proxy socks -t tcp -p ":8083" -T kcp -P "x.x.x.x:38080" --kcp-key mypasswor 1. system is :win7 1. full log is: 上边已提交 2. ftp服务端使用FileZilla0.9.41 3. ftp客户端使用FileZilla3.14 <!--- Provide a general summary of the issue in the Title above --> ## Detailed Description <!--- Provide a detailed description of the change or addition you are proposing --> 用kcp支撑socket5代理，连接ftp时，出现连接超时 ## Possible Implementation <!--- Not obligatory, but suggest an idea for implementing addition or change -->
kerem commented 2026-02-27 23:16:51 +03:00
Author
Owner
Copy link

@sbarnoud commented on GitHub (Jan 12, 2026):

We had the same. The root cause was from the kubernetes load balancer used to expose the goproxy port.

https://support.hashicorp.com/hc/en-us/articles/25729009951123-How-to-disable-AKS-Azure-Standard-Load-Balancer-health-probes-for-specific-ports

Doing so, all such logs related to the probe disappear:
2026/01/12 09:56:10.176 WARN handshake fail, ERR: new methods request fail,ERR: read tcp 10.244.8.180:38080->10.2.182.8:59919: i/o timeout

<!-- gh-comment-id:3738704238 --> @sbarnoud commented on GitHub (Jan 12, 2026): We had the same. The root cause was from the kubernetes load balancer used to expose the goproxy port. https://support.hashicorp.com/hc/en-us/articles/25729009951123-How-to-disable-AKS-Azure-Standard-Load-Balancer-health-probes-for-specific-ports Doing so, all such logs related to the probe disappear: 2026/01/12 09:56:10.176 WARN handshake fail, ERR: new methods request fail,ERR: read tcp 10.244.8.180:38080->10.2.182.8:59919: i/o timeout
Sign in to join this conversation.
No Branch/Tag specified
Branches Tags
master
v15.2
v15.1
v15.0
Labels
Clear labels   
TODO

   
bug

   
duplicate

   
enhancement

   
good first issue

   
help wanted

   
helpful

   
invalid

   
need-confirm

   
pull-request

Mirrored from GitHub Pull Request

  
question

   
wontfix
No labels
TODO
bug
duplicate
enhancement
good first issue
help wanted
helpful
invalid
need-confirm
pull-request
question
wontfix
Milestone
Clear milestone
No items
No milestone
Projects
Clear projects
No items
No project
Assignees
Clear assignees
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
starred/goproxy#423
No description provided.