Czy listener HTTP Squida obsługuje SOCKS?
Oddziel protokół proxy od numerów portów i odróżnij eksperymentalne prace Squida nad SOCKS od standardowego wsparcia listenera HTTP.
http_port Squida przyjmuje ruch proxy HTTP niezależnie od numeru portu. Ustawienie go na porcie 1080 pozostawia go listenerem HTTP; klient SOCKS wysyła inny handshake.
Aplikacja obsługująca proxy HTTP może użyć adresu i portu Squida w swoim ustawieniu proxy HTTP. Cele HTTPS mogą przechodzić przez CONNECT, więc to ustawienie jest odpowiednie także dla bezpiecznych witryn, gdy proxy zezwala na tunel.
Aplikacja wymagająca SOCKS potrzebuje usługi implementującej wymaganą wersję SOCKS i uwierzytelniania. Dla dozwolonych tras publicznych wybierz kandydatów z listy proxy SOCKS pasujących do tej wersji. Dedykowany serwer SOCKS lub odpowiednie lokalne dynamiczne przekierowanie SSH może zapewnić ten interfejs.
Wsparcie eksperymentalne i proxy nadrzędne
Strona rozwoju SOCKS Squida opisuje podejścia eksperymentalne i oparte na bibliotekach, wraz z ograniczeniami. Nie dowodzi, że standardowy spakowany listener HTTP akceptuje SOCKS5 przez przełącznik konfiguracji.
Zmuszenie Squida do używania SOCKS w górę strumienia to osobne wymaganie dotyczące jego połączeń wychodzących. Metoda wpływająca na te sockety nie dodaje obsługi przychodzącego SOCKS.
Przy niezgodności protokołu ustal, co aplikacja wysyła do Squida, a co Squid wysyła do celu lub nadrzędnego proxy. Zmiana samego numeru portu nie zmienia żadnej z tych dwóch rozmów.