27

Tor service is not working

I have installed Tor on a command-line only environment (without the browser), so I can't type in check.torproject.org with a browser. Tor is used by a script to request data from clearnet.

I am using a RHEL-compatible Linux OS, and have Nyx (formerly ARM) installed. Tor is set in client-only mode, and Nyx does not show any issues whatsoever. The tor service is used by Privoxy proxy forwarding in order to relay data to my script. It's been working perfectly for months now, but a problem has just occurred in the setup which is preventing my script to access Tor.

Checking for issues from command line

Please guide me on how to check the Tor status from the command line, and where to look for errors to get my connection working again.

I used to use torify/torsocks to see if tor is working, but sadly it appears to be glitchy and torify curl http://.... doesn't seem work anymore. I know that The tor process is listening, but I have no way to see if it's working and troubleshoot the problem.

Additionally, is there a way I determine if Tor is blocked by my ISP and whether if I need to use bridges? How can I set up bridges on torrc using command-line?

UPDATE: I noticed my server's time had gone out of sync. If you have a similar problem, make sure your machine's time is correct. Here's what I did.

2
  • 1
    Please include your tor logs.
    – cacahuatl
    Sep 20, 2016 at 0:37
  • @canonizingironize I checked my logs, and turned out my server's time had gone out of sync. Did a ntpdate pool.ntp.org and now it works like a charm. No bridges required. Nov 11, 2016 at 14:52

2 Answers 2

41

You can use curl to check https://check.torproject.org/api/ip over tor:

curl -x socks5h://localhost:9050 -s https://check.torproject.org/api/ip

Note the h in socks5h. This will ensure dns resolution is done over tor too.

If everything goes well, the output will be something like:

{"IsTor":true,"IP":"185.220.101.169"}

If IsTor is false, or there is an error or no output, tor is probably not working. However, check.torproject.org is prone to false negatives (see comments), so you might want to retry the command a few times to be sure.

This is the script I use, which runs the check a second time if the first fails and returns true if either succeeds. It's pretty unlikely to get two false positives in a row, but if it becomes a problem, increase ATTEMPTS. The script requires jq, the json parser.

#!/bin/bash
# check_tor

LOCAL_PROXY='localhost:9050'
CHECK_URL='https://check.torproject.org/api/ip'
ATTEMPTS=2

false; for i in {1..$ATTEMPTS}; do
    if [ ${?} -ne 0 ]; then
        test "$(curl -x socks5h://${LOCAL_PROXY} -s ${CHECK_URL} | jq '.IsTor')" == 'true'
    fi
done
10
  • 5
    You should either --socks5-hostname localhost:9050 or -x socks5h://127.0.0.1:9050/ to avoid DNS leaks. Also there will be false positives.
    – cacahuatl
    Nov 8, 2016 at 5:09
  • 1
    What would cause the false positives?
    – ki9
    Nov 10, 2016 at 3:41
  • 1
    Not all exits exit from their advertised IP addresses, the Tor Project probes each exit periodically but some of them change the IP they exit from semi-frequently. This means that the check.tpo site will think it's not a Tor IP address in a small number of cases and report that you aren't using Tor when infact you are.
    – cacahuatl
    Nov 10, 2016 at 4:03
  • 2
    github.com/NullHypothesis/exitmap/blob/master/src/modules/… ExitMap has a module to check for these, I guess really they're false negatives, not false positives. False positives will happen if you are connecting from an exit or an IP that was used by an exit (maybe a VPN IP?) and are using a browser that is naively indistinguishable from Tor Browser. (e.g. user-agent string matches).
    – cacahuatl
    Nov 10, 2016 at 4:08
  • 2
    OK, false negatives are not as bad. I'll mention them in my answer. The full curl response does complain "However, it does not appear to be Tor Browser." But at least we know that tor is proxying correctly.
    – ki9
    Nov 10, 2016 at 13:20
0

Actually, using cURL and so-forth has a partial effect: you can tell that Tor is working only in a manner of true/false. To troubleshoot the problem automatically, you should use a pipe analyzer for its logs, and then - for example - you'll be able to fix the issue with time automatically (i.e. enforce the launch of ntpdate)

1
  • Thanks for the additional answer, but in this case I was really interested in the true/false manner if Tor was working (e. g. directing traffic through itself) Nov 11, 2016 at 21:25

You must log in to answer this question.

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