Special IP proxy service timeout problems

```
#cat checkip.py  #To streamline the code
def check(ip, port, timeout=30):
    proxies = {
      "http": "http://%s:%s" % (ip, str(port)),
      "https": "http://%s:%s" % (ip, str(port)),
    }
    requests.get(check_url, proxies=proxies, timeout=timeout, verify=False)

` #python2.7
>>> import requests                                                                                                                                                                        
>>> requests.__version__                                                                                                                                                                   
'2.10.0'  
>>> from checkip import check                                                                                                                                                              
>>> check("164.132.52.143",3128,timeout=1)                                                                                                                                                 
False                                                                                                                                                                                      
>>> check("164.132.52.143",3128,timeout=10)  
Here is the infinite waiting for...`


#ss  #The state is ESTAB
```


@toadzhou Does this actually have anything to do with the timeout? If you change the second timeout to `1`, does the error still occur?


Of time is very short is no problem, the problem may appear in he has established a connection!


To be clear, if you're calling `requests.get` then there is no state being shared: there is no way for two calls to `requests.get` to interact with each other on your machine. The proxy might be screwing it up, but Requests cannot. The only way to have that behaviour is if you're using a `Session`, which this code is not.


I am a single independent connections. 
Try the requests.Session() still won't do
What method can solve the problem


@toadzhou Right now it's still not really clear what's happening in your connection. Can you run the script above with something like Wireshark and send me the packet capture?


@Lukasa 

#tcpdump -i eth0 -vnn 164.132.52.143
16:54:31.440888 IP (tos 0x0, ttl 64, id 52147, offset 0, flags [DF], proto TCP (6), length 44)
    x.x.x.x.62004 > 164.132.52.143.3128: Flags [S], cksum 0x4aa1 (correct), seq 1499401970, win 5840, options [mss 1460], length 0
16:54:31.749509 IP (tos 0x0, ttl 52, id 0, offset 0, flags [DF], proto TCP (6), length 44)
    164.132.52.143.3128 > x.x.x.x.62004: Flags [S.], cksum 0x203b (correct), seq 3958367012, ack 1499401971, win 29200, options [mss 1460], length 0
16:54:31.749549 IP (tos 0x0, ttl 64, id 52148, offset 0, flags [DF], proto TCP (6), length 40)
    x.x.x.x.62004 > 164.132.52.143.3128: Flags [.], cksum 0x9338 (correct), ack 1, win 5840, length 0
16:54:31.749663 IP (tos 0x0, ttl 64, id 52149, offset 0, flags [DF], proto TCP (6), length 80)
    x.x.x.x.62004 > 164.132.52.143.3128: Flags [P.], cksum 0xd039 (incorrect -> 0x5679), seq 1:41, ack 1, win 5840, length 40
16:54:32.057972 IP (tos 0x0, ttl 52, id 42614, offset 0, flags [DF], proto TCP (6), length 40)
    164.132.52.143.3128 > x.x.x.x.62004: Flags [.], cksum 0x37d0 (correct), ack 41, win 29200, length 0
16:54:32.058005 IP (tos 0x0, ttl 64, id 52150, offset 0, flags [DF], proto TCP (6), length 42)
    x.x.x.x.62004 > 164.132.52.143.3128: Flags [P.], cksum 0xd013 (incorrect -> 0x85fc), seq 41:43, ack 1, win 5840, length 2
16:54:32.366473 IP (tos 0x0, ttl 52, id 42615, offset 0, flags [DF], proto TCP (6), length 40)
    164.132.52.143.3128 > x.x.x.x.62004: Flags [.], cksum 0x37ce (correct), ack 43, win 29200, length 0
16:54:32.488958 IP (tos 0x0, ttl 52, id 42616, offset 0, flags [DF], proto TCP (6), length 79)
    164.132.52.143.3128 > x.x.x.x.62004: Flags [P.], cksum 0x2de6 (correct), seq 1:40, ack 43, win 29200, length 39
16:54:32.488986 IP (tos 0x0, ttl 64, id 52151, offset 0, flags [DF], proto TCP (6), length 40)
    x.x.x.x.62004 > 164.132.52.143.3128: Flags [.], cksum 0x92e7 (correct), ack 40, win 5840, length 0
16:54:32.490157 IP (tos 0x0, ttl 64, id 52152, offset 0, flags [DF], proto TCP (6), length 337)
    x.x.x.x.62004 > 164.132.52.143.3128: Flags [P.], cksum 0xd13a (incorrect -> 0xf979), seq 43:340, ack 40, win 5840, length 297
16:54:32.798673 IP (tos 0x0, ttl 52, id 42617, offset 0, flags [DF], proto TCP (6), length 40)
    164.132.52.143.3128 > x.x.x.x.62004: Flags [.], cksum 0x334e (correct), ack 340, win 30016, length 0
16:54:35.254479 IP (tos 0x0, ttl 52, id 42618, offset 0, flags [DF], proto TCP (6), length 41)
    164.132.52.143.3128 > x.x.x.x.62004: Flags [P.], cksum 0x1d45 (correct), seq 40:41, ack 340, win 30016, length 1
16:54:35.295080 IP (tos 0x0, ttl 64, id 52153, offset 0, flags [DF], proto TCP (6), length 40)
    x.x.x.x.62004 > 164.132.52.143.3128: Flags [.], cksum 0x91bd (correct), ack 41, win 5840, length 0
16:54:38.045490 IP (tos 0x0, ttl 52, id 42619, offset 0, flags [DF], proto TCP (6), length 41)
    164.132.52.143.3128 > x.x.x.x.62004: Flags [P.], cksum 0x3044 (correct), seq 41:42, ack 340, win 30016, length 1
16:54:38.045518 IP (tos 0x0, ttl 64, id 52154, offset 0, flags [DF], proto TCP (6), length 40)
    x.x.x.x.62004 > 164.132.52.143.3128: Flags [.], cksum 0x91bc (correct), ack 42, win 5840, length 0
16:54:40.817095 IP (tos 0x0, ttl 52, id 42620, offset 0, flags [DF], proto TCP (6), length 41)
    164.132.52.143.3128 > x.x.x.x.62004: Flags [P.], cksum 0x3043 (correct), seq 42:43, ack 340, win 30016, length 1
16:54:40.817125 IP (tos 0x0, ttl 64, id 52155, offset 0, flags [DF], proto TCP (6), length 40)
    x.x.x.x.62004 > 164.132.52.143.3128: Flags [.], cksum 0x91bb (correct), ack 43, win 5840, length 0
16:54:43.574452 IP (tos 0x0, ttl 52, id 42621, offset 0, flags [DF], proto TCP (6), length 41)
    164.132.52.143.3128 > x.x.x.x.62004: Flags [P.], cksum 0x2242 (correct), seq 43:44, ack 340, win 30016, length 1
16:54:43.574483 IP (tos 0x0, ttl 64, id 52156, offset 0, flags [DF], proto TCP (6), length 40)
    x.x.x.x.62004 > 164.132.52.143.3128: Flags [.], cksum 0x91ba (correct), ack 44, win 5840, length 0
16:54:46.349464 IP (tos 0x0, ttl 52, id 42622, offset 0, flags [DF], proto TCP (6), length 41)
    164.132.52.143.3128 > x.x.x.x.62004: Flags [P.], cksum 0xc140 (correct), seq 44:45, ack 340, win 30016, length 1
16:54:46.349495 IP (tos 0x0, ttl 64, id 52157, offset 0, flags [DF], proto TCP (6), length 40)
    x.x.x.x.62004 > 164.132.52.143.3128: Flags [.], cksum 0x91b9 (correct), ack 45, win 5840, length 0
16:54:48.247303 IP (tos 0x0, ttl 64, id 52158, offset 0, flags [DF], proto TCP (6), length 40)
    x.x.x.x.62004 > 164.132.52.143.3128: Flags [F.], cksum 0x91b8 (correct), seq 340, ack 45, win 5840, length 0
16:54:48.556321 IP (tos 0x0, ttl 52, id 42623, offset 0, flags [DF], proto TCP (6), length 40)
    164.132.52.143.3128 > x.x.x.x.62004: Flags [F.], cksum 0x3347 (correct), seq 45, ack 341, win 30016, length 0
16:54:48.556358 IP (tos 0x0, ttl 64, id 52159, offset 0, flags [DF], proto TCP (6), length 40)
    x.x.x.x.62004 > 164.132.52.143.3128: Flags [.], cksum 0x91b7 (correct), ack 46, win 5840, length 0


My code is to check all kinds of proxy IP is available, the timeout of which is directly to give up. But because the timeout is not effective, result in the process of my pool into a zombie process


Sorry, can you run that tcpdump with body capture turned on? `tcpdump -nnvvXSs 1514 -i eth0 164.132.52.143` should do it.


@toadzhou Is that log _with_ or _without_ Sessions?


requests.get()
r = requests.Session()
r.get()

The result is the same


Or you can try with the local agent 164.132.52.143:3128


@toadzhou The _result_ is the same, but what happens is not. To be clear, I'd like a packet capture where you're using `requests.get`, not `session.get`.


I grab bag is running on this code

``` python
#!/usr/bin/env python
import requests
import socket
#import eventlet
#eventlet.monkey_patch()
check_url = 'https://xxx.com/'
check_key = 'test_key.'

from requests.packages import urllib3
urllib3.disable_warnings()

def check(ip, port, timeout=30):
    proxies = {
      "http": "http://%s:%s" % (ip, str(port)),
      "https": "http://%s:%s" % (ip, str(port)),
      "Accept": "text/html, application/xhtml+xml, */*",
      "Accept-Language": "zh-CN",
      "User-Agent": "Mozilla/5.0 (Windows NT 6.1; WOW64; Trident/7.0; rv:11.0) like Gecko",
      "Accept-Encoding": "gzip, deflate",
      "Connection": "Keep-Alive"
    }

    try:
        r = requests.get(check_url, proxies=proxies, timeout=timeout, verify=False)
        #import pdb;pdb.set_trace()
        if r.ok and check_key in r.content:
            return True
        else:
            return False
    except:
        return False


check("164.132.52.143",3128,timeout=10)  
```


Ok, and what _exactly_ is the result of running that code? Does it hang forever, raise exceptions, or what?


Relative to 164.132.52.143:3128 agent timeout does not work 


Right, but to be clear, can you break down into a) what you _expect_ this code to do, and b) what it _actually_ does? Try to avoid giving a high level explanation and be as literal as possible.


I'm sorry!Also please forgive me  
Verbal ability Determine the need to strengthen


@toadzhou You don't need to apologise, I appreciate that English isn't your first language. =) I'm just trying to find a way to explain what I need from you as clearly as possible.

In this case, I think I need to understand exactly what happens when you run that code, and what you think should happen.


This has been inactive for well over a month. I'm going to close this for now @toadzhou since we're unable to determine what the problem is. If you can gather more information and provide it, we can reopen this if we determine there's a bug in requests.

Thanks for filing this bug!