Стандартный
net/http умеет в прокси ровно одно — прочитать HTTP_PROXY из окружения. А за корпоративным прокси начинается боль: настройки спрятаны в реестре Windows, в GNOME/KDE, в scutil на маке; авторизация по NTLM или Kerberos; маршрут выбирает PAC-скрипт. proxykit закрывает именно этот разрыв.Что умеет:
🔌 Транспорты: HTTP/HTTPS CONNECT, SOCKS5, Direct
🔍 Автодетект системного прокси на всех трёх ОС: env-переменные, Windows WinINET + WinHTTP (реестр + IE), Linux /etc/environment + GNOME + KDE, macOS scutil
🔐 Авторизация: Basic и NTLM с явными кредами — или доменный SSO без пароля (Negotiate/Kerberos: на Windows через SSPI, на Linux/macOS через gokrb5)
📜 PAC/WPAD: выбор прокси под каждый адрес назначения (opt-in)
🪶 Без cgo, статичный бинарь, минимум зависимостей
API drop-in: Dialer в стиле net.Dial + адаптер под http.RoundTripper. Три строчки — и приложение само берёт прокси из системы:
d := proxykit.NewDialer(proxykit.Config{AutoDetect: true})
conn, err := d.DialContext(ctx, "tcp", "example.com:443")А если прокси за корпоративной аутентификацией — отдаёшь цепочку, и proxykit сам подберёт схему под то, что прокси просит в ответ 407 (аутентификаторы — в подпакете proxykit/auth):
d := proxykit.NewDialer(proxykit.Config{
Manual: "http://proxy.corp:8080",
Auth: []auth.Authenticator{
auth.Negotiate("HTTP/proxy.corp.local"), // доменный SSO, без пароля
auth.NTLM("CORP", "alice", "secret"), // иначе — NTLM
auth.Basic("alice", "secret"), // иначе — Basic (только под https)
},
})В комплекте CLI proxytest — покажет, откуда какой прокси прилетел.
Пока v0.x, API ещё устаканивается. MIT, чистый Go.
👉 github.com/durck/proxykit
