hm.. here is my squid.conf
<code>
cache_replacement_policy heap GDSF
memory_replacement_policy heap GDSF
cache_dir aufs /usr/local/squid/var/cache 10240 256 256
cache_mem 1024 MB
cache_store_log stdio:/usr/local/squid/var/logs/cachelog
cache_peer 192.168.2.106 parent 9743 0 no-query originserver name=httpsAccel ssl login=PROXYPASS sslflags=DONT_VERIFY_PEER
cache_peer 192.168.2.106 parent 9843 0 no-query originserver name=httpsAccel1 ssl login=PROXYPASS sslflags=DONT_VERIFY_PEER
cache_peer 192.168.2.106 parent 9643 0 no-query originserver name=httpsAccel2 ssl login=PROXYPASS sslflags=DONT_VERIFY_PEER
https_port 9743 cert=/usr/local/squid/etc/server.pem accel key=/usr/local/squid/etc/privkey.pem vhost
https_port 9843 cert=/usr/local/squid/etc/server.pem accel key=/usr/local/squid/etc/privkey.pem vhost
https_port 9643 cert=/usr/local/squid/etc/server.pem accel key=/usr/local/squid/etc/privkey.pem vhost
acl ccm1 port 9743
acl ccm2 port 9843
acl ccm3 port 9643
#cache_peer_access httpsAccel allow ccm1
#cache_peer_access httpsAccel deny  ccm2 ccm3
#cache_peer_access httpsAccel allow all
#cache_peer_access httpsAccel1 allow ccm2
#cache_peer_access httpsAccel1 deny  ccm1 ccm3
#cache_peer_access httpsAccel2 allow ccm3
#cache_peer_access httpsAccel2 deny  ccm1 ccm2

coredump_dir /usr/local/squid/var/cache
http_access allow ccm1
#http_access allow ccm2
#http_access allow ccm3

refresh_pattern .              0       20%     40320
cachemgr_passwd disable all
maximum_object_size 5120 MB
maximum_object_size_in_memory 16 MB
buffered_logs on
visible_hostname 192.168.2.32

</code>

can u comment out your ACLs for a test?

I don't have any on mine, and can connect just fine from my build machines

Oh, there was also a bug introduced in squid v 3. I had to fall back to 2.8 I think
my build server is talking to the proxy as if it was the RTC server..

https://192.168.2.32:9743

correct.. the proxy IS the RTC server from all clients.  we do not use the formal 'passthru proxy' configuration.

on my dev system, I changed the DNS entry for the RTC server to use the IP address of the squid server and the clients didn't have to do anything.

the squid url rewrite cannot change the structure of the URL.. Eclipse is sensitive to that..
so
https://server:port/context

must remain
https://realserver/context,

it cannot change to
https://realserver
or
https://realserver/context/context2

the article says

Using a Reverse Accelerator Proxy

 You can also configure squid or apache httpd (with the mod_cache module) to run as a accelerator proxy server against your Jazz RTC Team Server.  The strategy here is that instead of referencing the Jazz RTC Team Server URI from your client, you would connect instead to a proxy server which forwards all requests onto the Jazz RTC Team Server. 

Note: For best results in using a reverse accelerator proxy, clients should start new eclipse, command line or visual studio sandboxes.  There can be issues in switching between different repository URIs pointing to the same repository from within the clients. 

Setting up Squid with HTTP as Accelerator Proxy

there is also talk of the forward proxy, at the beginning, but not much. The accelerator reverse caching proxy works.. we will have a number of them thruout our network. some near the servers in our central site, and one at some of our remote locations.  the proxy servers will also talk to each other as siblings (cache peers) 

this is a typical multi-proxy design used for web technology for years.

the design is twin purposed: 1. remove as much redundant traffic from the server as possible, and 2. for remote locations, provide as close to local lan speeds as possible.

For builds this reduces the loading time from hours to minutes. slightly slower that the original local lan setup the users had before moving to the central admin structure

the DNS server at the locations (local or remote) will direct the users application (eclipse, Windows, or Browser, or SCM tools) to the caching proxy nearest them, to provide the fastest speeds possible.