# The configfile is divided into two parts; first misc. settings, # then the routes. Objects in '[]' are optional. # # # recommended order is: # [debug] # [logoutput] # [resolveprotocol] # # routes: # from to via # [command] # [extension] # [protocol] # [proxyprotocol] #debug: 1 # uncomment to enable debugging #logoutput: stdout # users usually don't want to be bothered with that. # What protocol should be used for resolving hostnames? It's important # to set this right. #resolveprotocol: udp # default #resolveprotocol: tcp # set this if your socksserver only supports socksv4. #resolveprotocol: fake # set this if your clients can't access nameserver, # neither directly nor proxied. # # the routes # # specifying routes for accepting remote connections (via bind()) is # difficult since we can't know what the "to:" address is # until we actually get the connection Since we support letting # the client accept connections both via the proxyserver and # "directly" at the same time, we have two options though: # a) specify a route for bind (only) first going via the proxyserver. # This will also handle "direct" connections. # b) specify a route for bind (only) first going "direct". # This means clients will only be able to accept "direct" # connections. # we want to accept remote connections via the proxyserver. #route { # from: 0.0.0.0/0 to: 0.0.0.0/0 via: 10.1.1.1 port = 1080 # command: bind #} # we do not want to accept remote connections via the proxyserver. #route { # from: 0.0.0.0/0 to: 0.0.0.0/0 via: direct # command: bind #} # if you don't route all local connections via direct, you should # at least route nameserver connections via direct connections if you # can. That can make for much better performance, depending on # your setup. Make sure the nameserver line is the first. # # Assuming your nameserver runs on address 10.1.1.1, you can do it like this: #route { # from: 0.0.0.0/0 to: 10.1.1.1/32 port = domain via: direct #} # have a route making all connections to loopback addresses be direct. #route { # from: 0.0.0.0/0 to: 127.0.0.0/8 via: direct # command: connect udpassociate # everything but bind, bind confuses us. #} # Our net is the 10.0.0.0/8 net, let clients going to local address go # direct, not via server. #route { # from: 0.0.0.0/0 to: 10.0.0.0/8 via: direct #} # for poor souls trapped behind a msproxy server. #route { # from: 0.0.0.0/0 to: 0.0.0.0/0 via: 10.1.1.1 port = 1745 # protocol: tcp # server supports tcp # proxyprotocol: msproxy_v2 # server runs msproxy_v2 #} # clients going anywhere else go via server listening at # IP address 10.1.1.1, port 1080. Note that unless you have # specified a direct connection for DNS, or the socksserver is resolvable # without network traffic, you can't give a hostname for the socksserver, # you must give a IP address. (the reasons for that are logical enough, # you would create a loop otherwise.) #route { # from: 0.0.0.0/0 to: 0.0.0.0/0 via: 10.1.1.1 port = 1080 # protocol: tcp udp # server supports tcp and udp. # proxyprotocol: socks_v4 socks_v5 # server supports socks v4 and v5. # method: none #username # we are willing to authenticate via # # method "none", not "username". #} # this is identical to the above, but it matches hostnames instead. # This is if you have clients that are unable to resolve hostnames. # It can be important that hostname routes come after address routes. #route { # from: 0.0.0.0/0 to: . via: 10.1.1.1 port = 1080 # protocol: tcp udp # server supports tcp and udp. # proxyprotocol: socks_v4 socks_v5 # server supports socks v4 and v5. # method: none #username # we are willing to authenticate via # # method "none", not "username". #} # identical to above two routes, but using a httpproxy instead. # #route { # from: 0.0.0.0/0 to: 0.0.0.0/0 via: 10.1.1.1 port = 3128 # command: connect # only thing a httproxy supports. # proxyprotocol: http_v1.0 #} #route { # from: 0.0.0.0/0 to: . via: 10.1.1.1 port = 3128 # command: connect # only thing a httproxy supports. # proxyprotocol: http_v1.0 #}