I have a small node app that makes requests via Tor. My goal is to have a different exit IP for every request. in the torrc configuration file one can set MaxCircuitDirtiness 10, which will make it change exit ip every 10 seconds. This is the minimum value that can be imposed. However, if I want to make 1 request/second, this is not enough.

So I am figuring out how to configure & run multiple tor servers such that I have different exit IPs, which is already discussed here. But it just doesn't seem to work. Someone already mentions this in a comment on the accepted answer.

I have followed all steps: I have in my case 4 torrc files with seperate ports, 4 datadirectories (permissions are fixed), I start 4 different Tor servers all loading different config files.

I wrote a small app in nodejs to show that it doesn't work.

    var Agent   = require('socks5-https-client/lib/Agent');
    var request = require('request');
    var cheerio = require('cheerio');
    var url = "https://check.torproject.org/"
    function makereq(port){
            url: url,
            strictSSL: true,
            agentClass: Agent,
            agentOptions: {
                socksHost: '',
                socksPort: port
        }, function(err, res) {
            if (err == null){
                $ = cheerio.load(res.body)
                var ip = $('p strong').text()
                console.log("Request through PORT " + port + " with EXIT IP "+ ip)
            else {
                console.log("Something went wrong")

    var ports = [9050, 9060, 9070, 9080];
    counter = 0
        if (counter == ports.length){
            counter = 0
    }, 1000)

Naturally, my question: how do I get this set-up to work? How do I get different exit IPs for seperate Tor servers?

For completeness, one of the torrc files

    # 10 seconds is the shortest refresh time allowed by Tor.
    MaxCircuitDirtiness 10

    # puts a listener on localhost:9050
    SOCKSPort 9050
    ControlPort 9051
    DataDirectory /var/lib/tor_0

    # some policies of which I dont know they are important
    SOCKSPolicy accept
    SOCKSPolicy accept
    SOCKSPolicy accept6 FC00::/7
    SOCKSPolicy reject *
  • What, exactly, do you expect this to achieve except waste large amounts of resource?
    – cacahuatl
    Commented Nov 2, 2016 at 18:54
  • My guess is the funamental misconception that "exit IP" has anything to do with anonymity?
    – cacahuatl
    Commented Nov 3, 2016 at 0:45
  • 1
    @canonizingironize my goal is not anonymity. Just trying to have a different IP for reach request I do, which is claimed to be possible by the article I referred to. I want to monitor a website without making it a priori evident that it is being monitored (it checks for IP). I am aware this can be done with proxies as well, but I am also trying to play around with technologies. Commented Nov 3, 2016 at 21:18
  • The second circuit will be just as likely to pick the same exit as the first circuit was and thus it will likely within a short time-frame use the same IPs multiple times and all from within the same set of IPs.
    – cacahuatl
    Commented Nov 3, 2016 at 22:13
  • @canonizingironize why is it likely that the second circuit would obtain the exact same exit IP? This is not implied by the article that I refer to. I agree that for each circuit, the probability distribution for picking an exit node is the same. But in this regard, repeated selection of the same exit node has a very small probability. It would rather suggest that the selection is a function of system dependent variables, which does not feel very Tor-like to me: i.e. why not randomize? (The other suggestion is, indeed, that my configuration is bad, which is what I posted the question for) Commented Nov 6, 2016 at 14:49

2 Answers 2


I want to monitor a website without making it a priori evident that it is being monitored


  1. The set of exits isn't (very) large, you'll repeat after a given time scale.
  2. The exits are weighted, you're more likely to use high capacity ones.
  3. The timing and uniformity of the HTTP requests.
  4. The (likely) quite unique user-agent and chosen set of headers from http library.
  5. The lack of fetching of included resources (<img>,<style>, etc)?

These would likely all make it evident that the requests were all coming from the same source, and from a script. Some things you could to reduce thses might be to replicate the requests from Tor Browser (down to the headers and order of the headers), randomise the timing interval between requests. Ultimately however if the site would, if it put effort into it (often more effort than it's worth), be able to distinguish you from a legitimate browser.

As to the changing circuit issue and the torrc configuration there are a couple of approaches you can try.

First of all, you don't need to run multiple copies of Tor to use multiple SocksPort directives. You can specify multiple in one single torrc and they will be isolated (unless you specify a SessionGroup which is the same for each).

Second of all, instead of messing with MaxCircuitDirtiness you should use some kind of explicit directive. The simplest approach is to accept that you'll be re-using the same exits over time and use SOCKS auth as the isolation mechanism. Tor's SocksPort will accept username and password authentication, each unique username and password combination will be isolated by circuit. By picking some random seed value (e.g. reading 32 bytes of random data from the operating systems CSPRNG) then running it through a cryptographic hash function, like SHA3-256, you can generate a pretty unique and unlikely to collide string. By using this as the username and some arbitrary password, then setting the username to the hash of the old username you will have a unique username and password combination per request, meaning each request will use a new and distinct circuit. By picking N seeds to generate usernames from you can use a single SocksPort but have N requests running against it which are isolated from each other.

Other approaches would involve utilising the control port, parsing tor ExitPolicy descriptors to pick appropriate exits and then using the MapAddress and .exit options to reconfigure an exit associated with the host. This may allow you to utilize a uniform distribution of the full set of exits and use some algorithm to take a random walk through them to avoid repeating. For how to approach this, see this answer.

Consider however that while this behavior may seem benign scrapers and crawlers are one of the reason that Tor was entirely blocked from "CraigsList". Many sites consider the content they display to be their "intellectual property" and are actively hostile to attempts to scrape it, lest others copy and reproduce it. You actions may result in a negative outcome from other Tor users of the service, and ultimately yourself.


You need to make sure you will have 4 different external IP's not from single C-class network, ideally. And - use ORPort IP:Port and OutboundBindAddress IP in your corresponding configs. And that's it, by the way.

  • They're running a client, not a relay. Did you actually read the question?
    – cacahuatl
    Commented Dec 7, 2016 at 22:15
  • I did. It also applies to the clients too - and, to be more specific, using a relay/ClientOnly=0 makes network usage a way faster in my experience
    – Alexey Vesnin
    Commented Dec 7, 2016 at 23:21
  • How is that relevant to the question? How does use a bunch of IPs and become a relay answer "how do I get this set-up to work? How do I get different exit IPs for seperate Tor servers?" in any way at all what so ever?
    – cacahuatl
    Commented Dec 8, 2016 at 11:24
  • @canonizingironize try to make a "different exit IP for every request" yourself and you will see all the relation. I've solved this task some time ago and my implementation worked. Hint: try to measure time of exit switching after "signal newnym" - and try it with my advice and without it.
    – Alexey Vesnin
    Commented Dec 8, 2016 at 13:45

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .