proxychains-ng/src/proxychains.conf

157 lines
5.4 KiB
Plaintext
Raw Normal View History

# proxychains.conf VER 4.x
2011-02-25 09:40:11 +00:00
#
# HTTP, SOCKS4a, SOCKS5 tunneling proxifier with DNS.
2011-02-25 09:40:11 +00:00
# The option below identifies how the ProxyList is treated.
# only one option should be uncommented at time,
# otherwise the last appearing option will be accepted
#
#dynamic_chain
#
# Dynamic - Each connection will be done via chained proxies
# all proxies chained in the order as they appear in the list
# at least one proxy must be online to play in chain
# (dead proxies are skipped)
# otherwise EINTR is returned to the app
#
strict_chain
#
# Strict - Each connection will be done via chained proxies
# all proxies chained in the order as they appear in the list
# all proxies must be online to play in chain
# otherwise EINTR is returned to the app
#
2013-06-23 05:16:14 +00:00
#round_robin_chain
#
# Round Robin - Each connection will be done via chained proxies
# of chain_len length
# all proxies chained in the order as they appear in the list
# at least one proxy must be online to play in chain
# (dead proxies are skipped).
# the start of the current proxy chain is the proxy after the last
# proxy in the previously invoked proxy chain.
# if the end of the proxy chain is reached while looking for proxies
# start at the beginning again.
# otherwise EINTR is returned to the app
# These semantics are not guaranteed in a multithreaded environment.
#
2011-02-25 09:40:11 +00:00
#random_chain
#
# Random - Each connection will be done via random proxy
# (or proxy chain, see chain_len) from the list.
# this option is good to test your IDS :)
2013-06-23 05:16:14 +00:00
# Make sense only if random_chain or round_robin_chain
2011-02-25 09:40:11 +00:00
#chain_len = 2
# Quiet mode (no output from library)
#quiet_mode
experimental new feature: proxy_dns_daemon since many users complain about issues with modern, ultracomplex clusterfuck software such as chromium, nodejs, etc, i've reconsidered one of my original ideas how to implement remote dns lookup support. instead of having a background thread serving requests via a pipe, the user manually starts a background daemon process before running proxychains, and the two processes then communicate via UDP. this requires much less hacks (like hooking of close() to prevent pipes from getting closed) and doesn't need to call any async-signal unsafe code like malloc(). this means it should be much more compatible than the previous method, however it's not as practical and slightly slower. it's recommended that the proxychains4-daemon runs on localhost, and if you use proxychains-ng a lot you might want to set ip up as a service that starts on boot. a single proxychains4-daemon should theoretically be able to serve many parallel proxychains4 instances, but this has not yet been tested so far. it's also possible to run the daemon on other computers, even over internet, but currently there is no error-checking/ timeout code at all; that means the UDP connection needs to be very stable. the library code used for the daemon sources are from my projects libulz[0] and htab[1], and the server code is loosely based on microsocks[2]. their licenses are all compatible with the GPL. if not otherwise mentioned, they're released for this purpose under the standard proxychains-ng license (see COPYING). [0]: https://github.com/rofl0r/libulz [1]: https://github.com/rofl0r/htab [2]: https://github.com/rofl0r/microsocks
2020-09-23 21:00:29 +00:00
## Proxy DNS requests - no leak for DNS data
# (disable all of the 3 items below to not proxy your DNS requests)
# method 1. this uses the proxychains4 style method to do remote dns:
# a thread is spawned that serves DNS requests and hands down an ip
# assigned from an internal list (via remote_dns_subset).
# this is the easiest (setup-wise) and fastest method, however on
# systems with buggy libcs and very complex software like webbrosers
# this might not work and/or cause crashes.
proxy_dns
experimental new feature: proxy_dns_daemon since many users complain about issues with modern, ultracomplex clusterfuck software such as chromium, nodejs, etc, i've reconsidered one of my original ideas how to implement remote dns lookup support. instead of having a background thread serving requests via a pipe, the user manually starts a background daemon process before running proxychains, and the two processes then communicate via UDP. this requires much less hacks (like hooking of close() to prevent pipes from getting closed) and doesn't need to call any async-signal unsafe code like malloc(). this means it should be much more compatible than the previous method, however it's not as practical and slightly slower. it's recommended that the proxychains4-daemon runs on localhost, and if you use proxychains-ng a lot you might want to set ip up as a service that starts on boot. a single proxychains4-daemon should theoretically be able to serve many parallel proxychains4 instances, but this has not yet been tested so far. it's also possible to run the daemon on other computers, even over internet, but currently there is no error-checking/ timeout code at all; that means the UDP connection needs to be very stable. the library code used for the daemon sources are from my projects libulz[0] and htab[1], and the server code is loosely based on microsocks[2]. their licenses are all compatible with the GPL. if not otherwise mentioned, they're released for this purpose under the standard proxychains-ng license (see COPYING). [0]: https://github.com/rofl0r/libulz [1]: https://github.com/rofl0r/htab [2]: https://github.com/rofl0r/microsocks
2020-09-23 21:00:29 +00:00
# method 2. use the old proxyresolv script to proxy DNS requests
# in proxychains 3.1 style. requires `proxyresolv` in $PATH
# plus a dynamically linked `dig` binary.
# this is a lot slower than `proxy_dns`, doesn't support .onion URLs,
# but might be more compatible with complex software like webbrowsers.
#proxy_dns_old
2011-02-25 09:40:11 +00:00
experimental new feature: proxy_dns_daemon since many users complain about issues with modern, ultracomplex clusterfuck software such as chromium, nodejs, etc, i've reconsidered one of my original ideas how to implement remote dns lookup support. instead of having a background thread serving requests via a pipe, the user manually starts a background daemon process before running proxychains, and the two processes then communicate via UDP. this requires much less hacks (like hooking of close() to prevent pipes from getting closed) and doesn't need to call any async-signal unsafe code like malloc(). this means it should be much more compatible than the previous method, however it's not as practical and slightly slower. it's recommended that the proxychains4-daemon runs on localhost, and if you use proxychains-ng a lot you might want to set ip up as a service that starts on boot. a single proxychains4-daemon should theoretically be able to serve many parallel proxychains4 instances, but this has not yet been tested so far. it's also possible to run the daemon on other computers, even over internet, but currently there is no error-checking/ timeout code at all; that means the UDP connection needs to be very stable. the library code used for the daemon sources are from my projects libulz[0] and htab[1], and the server code is loosely based on microsocks[2]. their licenses are all compatible with the GPL. if not otherwise mentioned, they're released for this purpose under the standard proxychains-ng license (see COPYING). [0]: https://github.com/rofl0r/libulz [1]: https://github.com/rofl0r/htab [2]: https://github.com/rofl0r/microsocks
2020-09-23 21:00:29 +00:00
# method 3. use proxychains4-daemon process to serve remote DNS requests.
# this is similar to the threaded `proxy_dns` method, however it requires
# that proxychains4-daemon is already running on the specified address.
# on the plus side it doesn't do malloc/threads so it should be quite
# compatible with complex, async-unsafe software.
# note that if you don't start proxychains4-daemon before using this,
# the process will simply hang.
#proxy_dns_daemon 127.0.0.1:1053
# set the class A subnet number to use for the internal remote DNS mapping
2012-01-26 11:44:42 +00:00
# we use the reserved 224.x.x.x range by default,
# if the proxified app does a DNS request, we will return an IP from that range.
# on further accesses to this ip we will send the saved DNS name to the proxy.
# in case some control-freak app checks the returned ip, and denies to
# connect, you can use another subnet, e.g. 10.x.x.x or 127.x.x.x.
# of course you should make sure that the proxified app does not need
# *real* access to this subnet.
# i.e. dont use the same subnet then in the localnet section
#remote_dns_subnet 127
#remote_dns_subnet 10
remote_dns_subnet 224
2011-02-25 09:40:11 +00:00
# Some timeouts in milliseconds
tcp_read_time_out 15000
tcp_connect_time_out 8000
### Examples for localnet exclusion
## localnet ranges will *not* use a proxy to connect.
2011-03-22 14:04:52 +00:00
## Exclude connections to 192.168.1.0/24 with port 80
# localnet 192.168.1.0:80/255.255.255.0
## Exclude connections to 192.168.100.0/24
# localnet 192.168.100.0/255.255.255.0
## Exclude connections to ANYwhere with port 80
# localnet 0.0.0.0:80/0.0.0.0
## RFC5735 Loopback address range
## if you enable this, you have to make sure remote_dns_subnet is not 127
## you'll need to enable it if you want to use an application that
## connects to localhost.
# localnet 127.0.0.0/255.0.0.0
## RFC1918 Private Address Ranges
# localnet 10.0.0.0/255.0.0.0
# localnet 172.16.0.0/255.240.0.0
# localnet 192.168.0.0/255.255.0.0
### Examples for dnat
## Trying to proxy connections to destinations which are dnatted,
## will result in proxying connections to the new given destinations.
## Whenever I connect to 1.1.1.1 on port 1234 actually connect to 1.1.1.2 on port 443
# dnat 1.1.1.1:1234 1.1.1.2:443
## Whenever I connect to 1.1.1.1 on port 443 actually connect to 1.1.1.2 on port 443
## (no need to write :443 again)
# dnat 1.1.1.2:443 1.1.1.2
## No matter what port I connect to on 1.1.1.1 port actually connect to 1.1.1.2 on port 443
# dnat 1.1.1.1 1.1.1.2:443
## Always, instead of connecting to 1.1.1.1, connect to 1.1.1.2
# dnat 1.1.1.1 1.1.1.2
2011-02-25 09:40:11 +00:00
# ProxyList format
# type ip port [user pass]
2011-02-25 09:40:11 +00:00
# (values separated by 'tab' or 'blank')
#
# only numeric ipv4 addresses are valid
#
2011-02-25 09:40:11 +00:00
#
# Examples:
#
# socks5 192.168.67.78 1080 lamer secret
# http 192.168.89.3 8080 justu hidden
# socks4 192.168.1.49 1080
# http 192.168.39.93 8080
#
#
# proxy types: http, socks4, socks5
# ( auth types supported: "basic"-http "user/pass"-socks )
#
[ProxyList]
# add proxy here ...
# meanwile
# defaults set to "tor"
socks4 127.0.0.1 9050