msysgit / git

msysGit-based Git for Windows 1.x is now superseded by Git for Windows 2.x
http://github.com/git-for-windows/git
Other
1k stars 316 forks source link

localhost proxy is slow, 127.0.0.1 is fast #328

Closed adamkerz closed 9 years ago

adamkerz commented 9 years ago

When I set my .gitconfig to contain:

[http]
    proxy = http://localhost:8080

And then run git clone "http://github.com/blah" blah

Takes exactly 2.5 minutes without ever connecting to the proxy server before presumably timing out and then connects to the proxy server and completes quickly.

Changing to:

[http]
    proxy = http://127.0.0.1:8080

The 2.5 minute delay disappears and git connects to the proxy straight away.

nslookup localhost resolves to 127.0.0.1 quicker than I can blink.

Also described here: http://stackoverflow.com/questions/5060437/configuring-git-on-windows-to-use-ntlm-proxy-authentication/23349704#23349704

Using Windows 7, git version 1.9.5.msysgit.0 and CNTLM.

DavidWhittingham commented 9 years ago

I see the same slow behaviour, same software setup.

dscho commented 9 years ago

Git uses cURL internally to perform (almost) all HTTP communication. You could try to run

curl -x http://localhost:8080 <url>

to see whether cURL without Git shows the same behavior, and then continue investigating from there.

adamkerz commented 9 years ago

Using git's own curl binary, I see a connection to the proxy within a second and the response dumped to stdout straight after. Would a more complicated curl command be being used that could influence this or is it more likely to be whatever git's doing beforehand?

dscho commented 9 years ago

Would a more complicated curl command be being used

No, Git uses cURL as a library. Well, I guess that was what you're driving at: Git does not use that executable.

There are some facilities included in Git that should help debugging this: setting the environment variables GIT_TRACE=1 and GIT_CURL_VERBOSE=1.

adamkerz commented 9 years ago

BAM! IPv6: I'm not listening on ::1, only 127.0.0.1

* About to connect() to proxy localhost port 38080 (#1)
*   Trying ::1...
* Connection refused
*   Trying 127.0.0.1...
* Connected to localhost (127.0.0.1) port 38080 (#1)
* Establish HTTP proxy tunnel to github.com:443

Between * Trying ::1... and * Connection refused is the delay.

Interestingly, I was initially telling Cntlm to listen on 38080 only:

section: global, Listen = '38080'
cntlm: Proxy listening on 127.0.0.1:38080

and then I tried:

section: global, Listen = 'localhost:38080'
Resolve localhost:
  -> 127.0.0.1
cntlm: Proxy listening on 127.0.0.1:38080

But both times it only bound to 127.0.0.1. Not sure what the expected behaviour is, more an inconsistency between cURL and Cntlm (and between the cURL library and the curl binary).

I think you probably DO want to try IPv6 first if the os supports it, so I doubt there's much more to do. It's documented and hopefully others with the same problem can find this page easily enough.

@dscho, thanks for the hints on getting more info to debug the problem! Should this be closed or do you have a different opinion to me about resolving this issue?

dscho commented 9 years ago

Good catch! The only thing to be done before closing this ticket might be to enhance the FAQ. How about giving it a try?

kusma commented 9 years ago

Do we really wait 2.5 minutes to realize the connection is refused? That sounds like a problem, IMO.

dscho commented 9 years ago

@kusma well, if a connection is refused, cURL does not wait to let the user know. So my guess is that the firewall tries to fend off port scanning (and thereby causes the delays). But you're correct, this is just a guess on my part.

In any case, I think it would make sense to describe in the FAQ how to debug such situations.

adamkerz commented 9 years ago

Done (towards the bottom of the FAQ page), any feedback is welcome and then close the issue :-)

dscho commented 9 years ago

For interested parties: it is here.

@adamkerz Thanks!