hmgle / socks5_c

一个轻量级的 socks5 代理, 带简单加密传输功能, 可穿透 GFW

socks5_c

一个轻量级的 socks5 代理, 采用单进程多路复用 IO 模式. 可用于科学上网.

目前仅支持 UNIX/Linux 平台

编译:

$ make

生成的目标文件有:

• local: 运行在本地, 是沟通浏览器等应用程序与 server 的桥梁, 处理使用 socks5 代理的应用程序的请求, 转发给 server
• server: 响应 local 的请求, 获取网站数据处理后返回给 local

使用方法

$ ./server -h
usage: ./server [-p server_port] [-m xor|rc4] [-e key]
$ ./local -h
usage: ./local [-l remote_ip] [-p remote_port] [-s listen_port] [-m xor|rc4] [-e key]

运行实例:

假设服务器 IP 地址为: 104.167.51.31, 在服务器上运行 server:

$ # 在 1984 端口监听等待连接, 使用 rc4 方法加密,  密钥为 "test"
$ ./server -p 1984 -m rc4 -e "test"

在本地运行 local:

$ # 连接服务器的 1984 端口, 在本地 2080 端口监听, 使用 rc4 方法加密, 密钥为"test"
$ ./local -l 104.167.51.31 -p 1984 -s 2080 -m rc4 -e "test"

• Firefox 浏览器设置: socks 主机填写 127.0.0.1, 端口填写: 2080, 选择 SOCKS v5 代理.

• Chromium/Chrome 可以通过启动参数加载 PAC:

$ cd socks5_c
$ PAC_URL=$(pwd)
$ chromium-browser -proxy-pac-url="file://"${PAC_URL}"/test.pac"

• 使用 curl 测试:

$ curl -v --socks5-hostname 127.0.0.1:2080 http://www.fanfou.com

授权协议

socks5_c 在 MIT license 协议下发布. 参见 LICENSE.md 文件.

socks5_c's Issues

将所有阻塞io改为非阻塞io操作

select/poll/epoll 的阻塞io会严重影响性能.

Unable to build on Mac OS X

fd_set is no available on Mac

➜  socks5_c git:(master) make
cc -Wall -O0 -DDEBUG=1 -g   -c -o local.o local.c
cc -Wall -O0 -DDEBUG=1 -g   -c -o buffer.o buffer.c
cc -Wall -O0 -DDEBUG=1 -g   -c -o encrypt.o encrypt.c
cc -Wall -O0 -DDEBUG=1 -g   -c -o socket_wrap.o socket_wrap.c
cc -Wall -O0 -DDEBUG=1 -g   -c -o socks.o socks.c
In file included from socks.c:1:
./socks.h:24:2: error: unknown type name 'fd_set'
        fd_set rfds, wfds;
        ^
./socks.h:27:2: error: unknown type name 'fd_set'
        fd_set _rfds, _wfds;
        ^
2 errors generated.
make: *** [socks.o] Error 1

不稳定啊，才翻墙不到一分钟，服务器上出现如下提示，怎么解决？

root@ar:~/socks5_c# debug_print: socks.c: 347: ss_request_handle():ss_get_requests() failed: Success
debug_print: server.c: 101: ss_io_handle():close
debug_print: socks.c: 347: ss_request_handle():ss_get_requests() failed: Success
debug_print: server.c: 101: ss_io_handle():close
debug_print: socks.c: 347: ss_request_handle():ss_get_requests() failed: Success
debug_print: server.c: 101: ss_io_handle():close
debug_print: socks.c: 347: ss_request_handle():ss_get_requests() failed: Success
debug_print: server.c: 101: ss_io_handle():close
debug_print: socks.c: 347: ss_request_handle():ss_get_requests() failed: Success
debug_print: server.c: 101: ss_io_handle():close
debug_print: socks.c: 347: ss_request_handle():ss_get_requests() failed: Success
debug_print: server.c: 101: ss_io_handle():close
debug_print: socks.c: 347: ss_request_handle():ss_get_requests() failed: Success
debug_print: server.c: 101: ss_io_handle():close
debug_print: socks.c: 347: ss_request_handle():ss_get_requests() failed: Success
debug_print: server.c: 101: ss_io_handle():close
debug_print: socks.c: 347: ss_request_handle():ss_get_requests() failed: Success
debug_print: server.c: 101: ss_io_handle():close
debug_print: socks.c: 347: ss_request_handle():ss_get_requests() failed: Success
debug_print: server.c: 101: ss_io_handle():close
debug_print: socks.c: 347: ss_request_handle():ss_get_requests() failed: Success
debug_print: server.c: 101: ss_io_handle():close
debug_print: socks.c: 347: ss_request_handle():ss_get_requests() failed: Success
debug_print: server.c: 101: ss_io_handle():close
debug_print: socks.c: 347: ss_request_handle():ss_get_requests() failed: Success
debug_print: server.c: 101: ss_io_handle():close
debug_print: socks.c: 347: ss_request_handle():ss_get_requests() failed: Success
debug_print: server.c: 101: ss_io_handle():close

root@ar:~/socks5_c#

client_connect() 阻塞: 一个页面连接不上就导致其他连接都等待在此

socket_wrap.c 中的 client_connect() 函数中, 当某个套接字阻塞在 gethostbyname() 或 connect() 时, 其他连接事件得不到及时处理, 一个打不开的网页就导致了其他正常页面都不能及时打开.
应改为非阻塞实现.

不要调用 gethostbyname(3)

gethostbyname(3) 是阻塞的, 而且不支持 IPv6. 非阻塞 DNS 查询可以参考 TADNS

ss_remote_io_handle() 和 client_to_remote() 调用 ss_server_del_conn() 问题

假如 conn_fd 和 remote_fd 在一个 select() 返回后都可读, 而且都是关闭文件事件, 事件循环处理器稍后执行到 client_fo_remote() -> recv(conn_fd, ...) -> ss_server_del_conn() 会把这个 conn 结构体释放掉, 但在同一轮的事件循环处理中, 就要执行到 ss_remote_io_handle() -> recv(remote_fd, ...) -> ss_server_del_conn(), 这个 conn 在前面已经释放掉, 于是 segmentation fault (core dumped)!!!