認証代行プロキシサーバーをDockerを使って構築する

2025/12/28更新：リポジトリ側で、最新のDocker環境でも動くように修正しつつ細かな改善を重ね、立ち上げ手順も簡易化したため、今回はその変更内容を反映して全面的に書き直しました。

背景

社内の認証ありプロキシは、開発の現場ではかなり厄介です。
認証に対応していないアプリ、パスワード変更のたびの再設定、メンバーごとの設定差分など、地味に時間を消耗します。

以前はMac上でSquidを立てて回避していましたが、運用の属人化や他チームへの展開に課題が残りました。
そこで今回は、Dockerだけで完結する認証代行プロキシを用意したので、その仕組みを整理して紹介します。

つくったもの

以下のリポジトリです。
最新の情報はここを参照してください。

前提条件

• Docker
• Docker Compose

全体像

Dockerコンテナ上に認証代行プロキシ（Squid）を立て、上流の認証ありプロキシに対してBasic認証のヘッダ（ Authorization: Basic xxx ）を付与します。
アプリ側は 認証なし でこのコンテナに接続するだけで、上流プロキシには認証付きで接続できます。

Squidの設定

squid.conf.template の設定を順に説明します。

基本的な設定

待受ポートは8080です。
visible_hostname は設定が無いと警告が出るため none にします。
DNSを有効にして、ドメイン名でプロキシを指定できるようにしています。

http_port 8080
visible_hostname none
dns_defnames on

ACLの定義

localnet はローカルネットワークからのアクセス、to_localnet_fast はローカルネットワーク宛のアクセスを定義します。
to_localhost_fast はローカルホスト宛、to_direct_access_domains は直接アクセスするドメイン群です。

dst -n は DNS lookup を無効化するための指定で、遅延を避けるために付けています。

acl localnet src 0.0.0.1-0.255.255.255
acl localnet src 10.0.0.0/8
acl localnet src 100.64.0.0/10
acl localnet src 169.254.0.0/16
acl localnet src 172.16.0.0/12
acl localnet src 192.168.0.0/16
acl localnet src fc00::/7
acl localnet src fe80::/10

acl to_localnet_fast dst -n 0.0.0.1-0.255.255.255
acl to_localnet_fast dst -n 10.0.0.0/8
acl to_localnet_fast dst -n 100.64.0.0/10
acl to_localnet_fast dst -n 169.254.0.0/16
acl to_localnet_fast dst -n 172.16.0.0/12
acl to_localnet_fast dst -n 192.168.0.0/16
acl to_localnet_fast dst -n fc00::/7
acl to_localnet_fast dst -n fe80::/10

acl to_localhost_fast dst -n 127.0.0.0/8

acl to_direct_access_domains dstdomain -n "/.direct_access_domains"

.direct_access_domains に書いたドメインは 直接アクセス します。
社内ポータルなど、プロキシ除外が必要なドメインをここに書きます。

Squidへのアクセス許可

ローカルネットワークからのアクセスのみを許可します。

http_access allow localhost
http_access allow localnet

認証ありプロキシサーバーへの転送設定

Squidはデフォルトで「上流プロキシを試し、ダメなら直接接続」を行います。
ここでは never_direct を使って、原則すべて上流プロキシ経由 にしています。

never_direct allow !to_localhost_fast !to_localnet_fast !to_direct_access_domains
cache_peer $proxy_host parent $proxy_port 0 proxy-only no-digest no-netdb-exchange login=$proxy_auth

to_direct_access_domains に該当するものだけは直接接続にします。

Squidを秘匿化する設定

Squidはデフォルトで Via や X-Forwarded-For などを付与します。
上流で通信ヘッダが厳密にチェックされる環境では不具合の原因になるため削除しています。
また、転送のみの用途なのでキャッシュも無効化しています。

forwarded_for delete
via off
cache deny all
request_header_access Cache-Control deny all
request_header_access Connection deny all
request_header_add Proxy-Connection "Keep-Alive" all

Dockerでの認証代行プロキシ立ち上げ

イメージのビルドと起動は Docker Compose 経由で行います。
ビルドにもプロキシ設定が必要なので、HTTP_PROXY_FOR_PROXY を .env に設定してから起動します。

また、ベースイメージ（Alpine）の pull もプロキシが必要になるため、
リポジトリに同梱した alpine.tar を docker load で読み込みます。

<proxy_user> と <proxy_password> に記号が入る場合は URLエンコード が必要です。

cd proxy-docker

docker load -i ./alpine.tar
cp .env.example .env
vi .env

docker compose up -d

動作確認：

curl -x localhost:8080 https://www.google.com

HOST_BIND_PORT を変更した場合は、その値を指定してください。

Docker Composeの設定

compose.yaml にビルド時・起動時のプロキシ設定を定義します。
HTTP_PROXY_FOR_PROXY は ビルド時（args） と 起動時（environment） の両方で使います。

x-proxy_settings: &proxy_settings
    HTTP_PROXY: "${HTTP_PROXY_FOR_PROXY:?HTTP_PROXY_FOR_PROXY must be set. Prease read README}"
    HTTPS_PROXY: "${HTTP_PROXY_FOR_PROXY}"

services:
    proxy:
        restart: unless-stopped
        build:
            context: .
            args:
                <<: *proxy_settings
        environment:
            <<: *proxy_settings
        ports:
            - "${HOST_BIND_PORT:-8080}:8080"

HOST_BIND_PORT を使って、ホスト側のポートを切り替えられます。

Dockerfileの設定

Dockerfileでは以下を行っています。

• ビルド時
  • HTTP_PROXY を使って apk add でSquidをインストール
• 起動時
  • HTTP_PROXY から proxy_host / proxy_port / proxy_auth を抽出
  • squid.conf.template を envsubst で展開して起動

この構成により、起動時に上流プロキシ情報を差し替え できます。

まとめ

• Dockerだけで完結する認証代行プロキシを用意しました
• Squidの設定は ACL / never_direct / cache_peer がポイントです
• .env と .direct_access_domains を変えるだけで運用できます

この記事の情報で、世の中の認証ありプロキシのストレスが少しでも減らせれば嬉しいです。