The documentation below should be read to understand the concepts and the Linux implementation:Īlso this command implemented in shell script (and using similar mechanisms as in this answer) can really do wonders too:Ī police action is used to drop any excess packet matching ports (which is a crude method). delaying before having to drop), with an IFB interface to work around limitations of ingress. I'll give two kinds of answers: the simple and crude one doing policing (drop excess) only, and a more complex one, doing shaping (incl. Traffic Control is a complex topic, which I can barely scratch. There should be an application feedback to reduce bandwidth, this is out of this scope.Īnyway it would become much more complex, probably involving changes inside shadowsocks, to link remote/server's side traffic to client's side for tc usage.įor SOCKS5 clients only sending data, limiting ingress from them is required to limit bandwidth, and for SOCKS5 clients only receiving data, limiting egress to them is required to limit bandwidth: unless the application in use is well known, both ways should be traffic controlled. Eg: if two video feeds over simple UDP arrive from server side and exceed the limit on client side, both clients flows will likely be corrupted. UDP will not have such possibility, unless the application protocol can do it.TCP will typically adjust and behave like the traffic on the clients side.outgoing from proxy to remote server will of course be limited by clients' incoming,.There's no need or use to worry about the traffic with the remote server: Here's a packet flow ascii picture (the whole picture would typically represent one client activity resulting in two flows, one to the left and one to the right of the proxy): traffic controlled TCP self-adjusting / no UDP control TCP naturally using MTU for packet size limit (and doing path MTU discovery anyway) doesn't suffer this issue in most settings. The UDP port is not available in fragments, so no filter will be able to catch them and almost no limitation will happen. tc, which works earlier than netfilter in ingress and later than netfilter in egress, will see the fragments.
This solution works as is (see note 1) for both TCP and UDP, except UDP might give additional challenges: if a source is creating "bigger than MTU" sized UDP packets (which probably shouldn't be done by a well behaving client or server), they get fragmented. shadowsocks handles SOCKS5 UDP ASSOCIATE, and uses then (SOCKS5) UDP on the same port as the (SOCKS5) TCP port. Just to clarify, shadowsocks creates a tunnel with one side as a SOCKS5 proxy ( sslocal, I'm assuming that's what is running on the OP's server considering the given ports), communicating with a remote endpoint ( ssserver) which will itself communicate with the actual target servers. Traffic can be limited using only Linux's Traffic Control.