A Lightweight and Super Fast Server for shadowsocks.
C Python
Latest commit 13a4a18 Mar 6, 2013 @dndx libuv: update

README.md

shadowsocks-libuv

Build Status

Shadowsocks is a lightweight tunnel proxy to help you get through firewalls.

Protocol made by clowwindy, libuv port by dndx

This is only a server, it should work with any shadowsocks client.

Current version: 0.2

This is an Open Source project and released under The MIT License

Features

  • Super fast and low resource consumption (thanks to libuv), it runs smoothly on almost any VPS.
  • Fully compatible with other ports of shadowsocks.
  • Supports the latest RC4 encryption method.
  • Fully IPv6 Ready

About IPv6 Support

Instead of creating two separate file descriptors for IPv4 and IPv6, shadowsocks-libuv only creates one. It works because it uses the Linux kernel 2.4.21 and 2.6, and we can use IN6ADDR_ANY (aka. ::0) to accept connections from both the IPv4 and IPv6 stacks. Those connections come from the IPv4 stack will be mapped to IPv4-mapped IPv6 addresses automatically. For example, IPv4 address 192.168.1.2 will be mapped to ::ffff:192:168:1:2 and will work whether your machine has an IPv6 link or not.

If you want your shadowsocks to listen on a specific IPv4 address, listen using ::ffff:192:168:1:2.

When connecting to a remote server, shadowsocks prefers to use an IPv6 address if both your server and remote supports IPv6. This will work even if your connection to the server is using IPv4. Thus you can use shadowsocks as an IPv4 to IPv6 or IPv6 to IPv4 tunnel.

Diagram

+------+    IPv4    +------+    IPv4    +------+
|Client| <---OR---> |Server| <---OR---> |Remote|
+------+    IPv6    +------+    IPv6    +------+

Client is any compatible shadowsocks client

Server is shadowsocks-libuv or other compatible server

Remote is the service you are trying to access

Attention

Please open an issue if you encounter any bugs. Be sure to attach the error message so I can identify it.

How to Build

$ yum install openssl-devel
$ git clone --recursive https://github.com/dndx/shadowsocks-libuv.git
$ cd shadowsocks-libuv/
$ vim config.h
$ make

Note that you need to rebuild it every time you modify config.h, just run make again and it will do rest of the work.

Tested and confirmed to work on:

  • Mac OS X 10.8.2 x64 using Clang 4.1
  • CentOS 5.8 x86 using GCC 4.1.2
  • CentOS 6.3 x64 using GCC 4.4.6
  • Ubuntu Linux 12.04 using GCC 4.6.x and Clang 3.1.x (Travis Environment)

How to Use

After you build shadowsocks successfully, you can rename the file server and move it to anywhere you want.

Also there are command line options that can be used to override settings in config.h:

$ ./server -?
./server: invalid option -- ?
Shadowsocks Version:0.2 libuv(0.9) Written by Dndx(idndx.com)
Usage: ./server [-l listen] [-p port] [-k keyfile] [-f pidfile] [-m rc4|shadow]

Options:
  -l : Override the listening IP
  -p : Override the listening port
  -k : Override the listening password
  -f : Override the pidfile path
  -m : Override the encryption method

If you want to run server in background, you can:

$ nohup /path/to/server &

Note this will redirect all logs generated by program to nohup.out. If you do not want logs to be saved, you can run:

$ nohup /path/to/server > /dev/null 2>&1 &

This will delete all messages.

If your program does not run as expected, log files will help identify the bug.

Known Issues

Build Failed

src/unix/linux/syscalls.h:74: error: expected specifier-qualifier-list before ‘__u64’
  1. First, make sure you have the latest kernel-headers by running yum install kernel-headers
  2. Try make again, if it still complains, see next
  3. cd to shadowsocks-libuv and $ vim libuv/config-unix.mk
  4. At about line 22, you will see CSTDFLAG=--std=c89 -pedantic -Wall -Wextra -Wno-unused-parameter
  5. Change it to CSTDFLAG=--std=gnu99 -pedantic -Wall -Wextra -Wno-unused-parameter
  6. Save the file and run make again

Can not using static link

Thanks to @cyfdecy

Do not use -static to compile this project. The problem is that libuv is using pthread and getaddrinfo(3) for async DNS resolve. But this will cause getaddrinfo(3) Segment Fault.

More information can be found at issue #3

CPU 100%

There is a possibility that the process will sometimes consume 100% of CPU and can not be restored. The cause of problem is not clear but I am working for a solution. Including re-design the way connection is handled, please stay tuned.

Performance

I did not fully benchmark it yet, but according to my use on TinyVZ (OpenVZ 128M RAM and CentOS 5.8 x86). When streaming YouTube 1080p vedio at about 20Mbit/s bandwidth, it use at most 3% of RAM (RSS about 7500) and almost no CPU time. While browsing it uses less than 0.7% RAM (RSS about 1164).

Contributors

I appreciate all the people who have made this project better. Contribution is always welcome!

TODO List

  • Fully IPv6 Support (accomplished)
  • RC4 Crypto Support (accomplished)
  • Multi Port Support
  • Client Implement
  • …to be continued…