← ブログに戻る
RUENZHESARPTDEFRJAKOITTRIDVIFAHI

GitLabのプロキシ：チームとCI/CDパイプラインのアクセスを問題なく設定する方法

GitLabがあなたの地域でブロックされているか、利用できませんか？チーム全体が問題なく作業できるように、GitLabのプロキシ設定について説明します。CI/CDパイプラインが失敗しないようにします。

📅2026年7月19日
```html

GitLabは、世界中の数千のチームが使用するコードストレージとDevOpsプロセス管理のための人気プラットフォームです。しかし、プロバイダー、企業ネットワーク、または国全体でGitLabへのアクセスがブロックされている場合はどうすればよいでしょうか？さらに悪いことに、runnerがリポジトリにアクセスできないために、CI/CDパイプラインが真夜中に落ちてしまうことがあります。

この記事では、Gitクライアント、GitLab Runner、企業サーバーのレベルでGitLabのプロキシを設定する方法を説明します。これにより、チーム全体が世界のどこからでも安定して作業できるようになります。

GitLabのプロキシが必要な理由：実際のシナリオ

プロキシを設定する前に、どのような問題を解決しようとしているのかを理解することが重要です。状況はさまざまであり、それによってプロキシの種類と接続方法が決まります。

シナリオ1：プロバイダーまたは国レベルでGitLabがブロックされている

一部の国や企業ネットワークでは、gitlab.comへのアクセスが制限されています。開発者がターミナルを開き、git pullと入力すると、タイムアウトが発生します。この場合、プロキシは仲介者として機能します：トラフィックは直接gitlab.comに行くのではなく、制限のない国の中間サーバーを経由します。

シナリオ2：異なる国に分散したチーム

チームの一部がロシアから、別の部分がカザフスタンから、さらに別の部分がヨーロッパから作業していると想像してください。各自異なるネットワーク条件や制限があります。すべての人が安定して同じ速度で作業できるように、企業はすべてのトラフィックが単一のチャネルを介してGitLabに行くように企業プロキシサーバーを展開します。

シナリオ3：CI/CD runnerが外部依存関係にアクセスできない

GitLab Runnerがパイプラインを実行し、npm installまたはpip installの段階で全てが落ちてしまうのは、runnerがインターネットへの直接アクセスがない閉じられたネットワークにあるためです。プロキシを使用することで、runnerはサーバー全体にインターネットへの完全なアクセスを開かずに外部依存関係を取得できます。

シナリオ4：企業ファイアウォールの背後にある自己ホスト型GitLab

企業は内部ネットワークに独自のGitLabサーバーを保持しています。リモートで作業している開発者はそれに接続する必要があります。すべてのトラフィックにVPNを使用する代わりに、GitLabトラフィック専用のプロキシを設定することができます。これにより、管理が迅速かつ簡単になります。

シナリオ5：トラフィックの監視と監査

大企業は、トラフィックを企業プロキシを介してリポジトリに向けて流し、アクティビティをログに記録し、誰が何をプッシュしているかを監視し、望ましくない操作をブロックします。これはセキュリティ要件であり、ブロックを回避するためではありません。

設定前に理解しておくべきこと：

GitLabのプロキシは、開発者のマシン（Gitクライアント）、GitLab Runnerのサーバー（CI/CD）、および自己ホスト型GitLabサーバー（自己ホスト型の場合）で同時に必要になることがあります。各レベルは別々に設定されます。

GitLabに適したプロキシの種類

GitLabはHTTPSおよびSSHプロトコルで動作します。これにより、適用可能なプロキシの種類とそうでないものがすぐに決まります。オプションを見てみましょう。

プロキシの種類 プロトコル GitLabに適している 使用するタイミング
HTTP/HTTPSプロキシ HTTP, HTTPS ✓ はい HTTPS経由のGit、GitLabのウェブインターフェース
SOCKS5プロキシ TCP（任意） ✓ はい（最良の選択肢） HTTPSおよびSSH経由のGit、CI/CD
SOCKS4プロキシ TCP ~ 部分的に SOCKS5がない場合のみ
透過的プロキシ HTTP ✗ いいえ 適していません — ブロックを回避しません

GitLabでの作業には、最適な選択肢はSOCKS5です。これはTCPレベルで動作するため、HTTPS接続（ウェブインターフェース、HTTPS経由のgit clone）とSSH接続（ポート22または443でのgit push/pull）の両方を同様にプロキシします。

居住型プロキシ vs データセンター型プロキシ

ここは目的によります。目的がGeoIPによるブロックを回避することや、認証のための安定したIPを取得することであれば、データセンター型プロキシが適しています。これらはより速く、安価で、低遅延を提供し、大きなリポジトリでの作業において重要です。

しかし、企業のIPがGitLabのブロックリストに載ってしまった場合（攻撃的なスキャンやセキュリティインシデントの後に発生することがあります）、居住型プロキシを検討する価値があります。これらのIPアドレスは実際の家庭ユーザーに属しており、プラットフォームによってブロックされることは非常に稀です。

Gitクライアントのプロキシ設定（グローバルに）

これは最も一般的なシナリオです：開発者が自分のマシンからGitLabに接続できません。設定はGit自体の設定を通じて行われ、一度行えばすべてのリポジトリで機能します。

オプションA：Git用のHTTPSプロキシ

GitLabをHTTPS経由で使用している場合（リポジトリのアドレスがhttps://で始まる）、ターミナルで次のコマンドを実行します： 

# グローバルにHTTPプロキシを設定
git config --global http.proxy http://あなたのプロキシ_IP:ポート

# プロキシが認証を要求する場合
git config --global http.proxy http://ユーザー名:パスワード@あなたのプロキシ_IP:ポート

# SOCKS5プロキシの場合（推奨）
git config --global http.proxy socks5://あなたのプロキシ_IP:ポート

# 設定が適用されたか確認
git config --global --get http.proxy

オプションB：gitlab.com専用のプロキシ（他のリポジトリには影響しない）

プロキシがすべてのGit操作に適用されるのを望まない場合（たとえば、GitHubやBitbucketは正常に動作する場合）、特定のドメインのみにプロキシを設定できます： 

# gitlab.com専用のプロキシ
git config --global http.https://gitlab.com.proxy socks5://あなたのプロキシ_IP:ポート

# またはあなたの自己ホスト型GitLab用
git config --global http.https://git.yourcompany.com.proxy socks5://あなたのプロキシ_IP:ポート

オプションC：SSH経由のプロキシ（SSHで作業している人向け）

SSH経由でリポジトリをクローンする場合（[email protected]:...）、プロキシの設定はGitではなくSSHの設定ファイルで行います。~/.ssh/configを開き、次のように追加します： 

# Linux/macOSの場合 — nc（netcat）を使用
Host gitlab.com
    HostName gitlab.com
    User git
    ProxyCommand nc -X 5 -x あなたのプロキシ_IP:ポート %h %p

# Windowsの場合 — connect.exe（Git for Windows）を使用
Host gitlab.com
    HostName gitlab.com
    User git
    ProxyCommand connect -S あなたのプロキシ_IP:ポート %h %p

設定後、ssh -T [email protected]コマンドで接続を確認してください。すべてが正しく設定されていれば、GitLabからのウェルカムメッセージが表示されます。

プロキシが不要になった場合の無効化方法

# グローバルプロキシを削除
git config --global --unset http.proxy

# 特定のドメインのプロキシを削除
git config --global --unset http.https://gitlab.com.proxy

GitLab RunnerとCI/CDパイプラインのためのプロキシ

GitLab Runnerは、.gitlab-ci.ymlからのジョブを実行するエージェントです。runnerが閉じられたネットワークまたは制限されたインターネットアクセスのあるサーバーにある場合、プロキシを別途設定する必要があります。ここでは、開発者のGitクライアントの設定は役に立ちません。runnerは別のマシンで動作しています。

方法1：runnerの設定ファイルに環境変数を追加

GitLab Runnerの設定ファイル（通常は/etc/gitlab-runner/config.toml）を開き、[runners.env]セクションに環境変数を追加します： 

[[runners]]
  name = "my-runner"
  url = "https://gitlab.com/"
  token = "あなたのトークン"
  executor = "shell"
  environment = [
    "HTTP_PROXY=http://あなたのプロキシ_IP:ポート",
    "HTTPS_PROXY=http://あなたのプロキシ_IP:ポート",
    "NO_PROXY=localhost,127.0.0.1,あなたの内部ドメイン.com"
  ]

設定を変更した後、runnerを再起動します：sudo gitlab-runner restart

方法2：.gitlab-ci.yml内の変数（パイプラインレベル）

あなたがrunnerの管理者でない場合や、特定のプロジェクトのためだけにプロキシを設定したい場合は、パイプラインファイルに直接変数を追加します： 

variables:
  HTTP_PROXY: "http://あなたのプロキシ_IP:ポート"
  HTTPS_PROXY: "http://あなたのプロキシ_IP:ポート"
  NO_PROXY: "localhost,127.0.0.1,.internal.company.com"

stages:
  - build
  - test
  - deploy

build:
  stage: build
  script:
    - npm install   # これでプロキシを経由します
    - npm run build

方法3：GitLabプロジェクトの設定内の変数（リポジトリにコミットせずに）

機密データ（認証付きプロキシ）のための最良の方法：あなたのプロジェクトの設定 → CI/CD → 変数に移動し、HTTP_PROXY、HTTPS_PROXY、NO_PROXYを保護された（masked）変数として追加します。これらはすべてのパイプラインで自動的に利用可能になりますが、ログには表示されません。

NO_PROXYについて — 忘れないでください！

変数NO_PROXYは非常に重要です。これには、runnerがプロキシをバイパスして直接接続する必要があるすべての内部ドメインとIPを追加する必要があります。そうしないと、runnerは内部サービスに対してもプロキシを経由しようとし、パイプラインが失敗します。

Docker executor用のプロキシ

runnerがDocker executorを使用している場合、コンテナはデフォルトでホストのプロキシ設定を継承しません。config.tomlの[runners.docker]セクションに変数を追加するか、runnerのホストで/etc/systemd/system/docker.service.d/proxy.confファイルを作成する必要があります： 

[Service]
Environment="HTTP_PROXY=http://あなたのプロキシ_IP:ポート"
Environment="HTTPS_PROXY=http://あなたのプロキシ_IP:ポート"
Environment="NO_PROXY=localhost,127.0.0.1"

その後、次のコマンドを実行します：sudo systemctl daemon-reload && sudo systemctl restart docker

自己ホスト型GitLabサーバーのためのプロキシ

自分のGitLabサーバーを管理している場合（OmnibusまたはHelmを介してインストールされた）、プロキシはGitLabが外部サービスにアクセスできるようにするために必要です：通知を送信したり、外部CIシステムに接続したり、ユーザーのアバターをアップロードしたり、JiraやSlackと統合したりします。

gitlab.rbでの設定（Omnibusインストール）

/etc/gitlab/gitlab.rbファイルを開き、次の行を追加またはコメント解除します： 

# GitLab用のプロキシ（Omnibus）
gitlab_rails['env'] = {
  "http_proxy" => "http://あなたのプロキシ_IP:ポート",
  "https_proxy" => "http://あなたのプロキシ_IP:ポート",
  "no_proxy" => "localhost,127.0.0.1,あなたの内部ドメイン"
}

# プロキシが認証を必要とする場合：
gitlab_rails['env'] = {
  "http_proxy" => "http://ユーザー名:パスワード@あなたのプロキシ_IP:ポート",
  "https_proxy" => "http://ユーザー名:パスワード@あなたのプロキシ_IP:ポート",
  "no_proxy" => "localhost,127.0.0.1"
}

設定を変更した後、設定を適用します：sudo gitlab-ctl reconfigure

Admin Areaを通じたアウトバウンド接続の設定

GitLab 15.0以降、ウェブインターフェースを通じてプロキシを設定する機能が追加されました：Admin Area → 設定 → ネットワーク → アウトバウンドリクエストに移動します。ここで、アウトバウンドウェブフック用のプロキシを指定し、GitLabがアクセスできるIP範囲を制限できます。これはセキュリティに役立ち、ウェブフックを介したSSRF攻撃を防ぎます。

チーム全体のアクセスを整理するためのプロキシ

5〜50人のチームに対してGitLabへの安定したアクセスを確保する必要がある場合、各マシンでの個別設定は最良のアプローチではありません。よりスケーラブルなソリューションを考えてみましょう。

アプローチ1：企業プロキシサーバー

1つのプロキシサーバー（たとえば、Squidや3proxy）を展開し、インターネットにアクセスできるようにします。すべての開発者がこのサーバーを使用するようにGitを設定します。利点：中央集権的な管理、制御の単一ポイント、トラフィックをログに記録できます。欠点：サーバーが単一障害点になります。

アプローチ2：リポジトリのミラーリング

GitLabはリポジトリのミラーリングをサポートしています。内部ネットワークに自己ホスト型GitLabを設定し、gitlab.comのミラーとして機能させることができます。開発者は内部サーバーで作業し、それがプロキシを介して外部と同期します。これにより、各開発者のプロキシ接続の品質への依存が減ります。

アプローチ3：dotfilesやオンボーディングスクリプトによる自動設定

各開発者が自分の環境を設定するチームには、必要なGit設定を自動的に記述するオンボーディングスクリプトを作成するのが便利です。このスクリプトは企業リポジトリに保存され、新しい作業環境の設定時に実行されます。 

#!/bin/bash
# setup-git-proxy.sh — 新しい作業環境の設定時に実行

PROXY_HOST="proxy.company.com"
PROXY_PORT="3128"

echo "GitLabへのアクセスのためのGitプロキシを設定中..."
git config --global http.https://gitlab.com.proxy "socks5://${PROXY_HOST}:${PROXY_PORT}"
git config --global http.sslVerify true
echo "完了！確認してください：git config --global --list | grep proxy"

チーム展開のためのチェックリスト

  • 開発者、runner、またはGitLabサーバーのいずれか（またはすべて）のレベルでプロキシが必要かどうかを判断する
  • プロキシの種類を選択する：最大の互換性のためにSOCKS5を選択
  • すべての内部ドメインとサービスのためにNO_PROXYを設定する
  • プロキシを介してSSHキーが機能するか確認する（別のステップ！）
  • 企業のwikiに設定を文書化する
  • 新しい従業員のためのオンボーディングスクリプトを作成する
  • プロキシサーバーの可用性を監視する

一般的な問題とその解決策

正しく設定しても、時々何かがうまくいかないことがあります。以下は最も一般的な問題とその診断方法です。

問題1：SSL証明書の問題：ローカル発行者証明書を取得できません

このエラーは、プロキシサーバー（特に企業のもの）がSSL検査を実行し、GitLabの証明書を自分のものに置き換えると発生します。Gitはこの証明書を信頼しません。解決策：企業のルート証明書を信頼されたものに追加します。 

# 一時的な解決策（デバッグ用、プロダクション用ではありません！）
git config --global http.sslVerify false

# 正しい解決策：企業の証明書を追加
git config --global http.sslCAInfo /path/to/corporate-ca-bundle.crt

問題2：プロキシはHTTPSで機能するがSSHは機能しない

これは古典的な状況です：Gitでhttp.proxyを設定し、HTTPSクローンが機能したが、SSH操作は依然として失敗します。理由：SSHトラフィックはHTTPプロキシを経由しません。~/.ssh/configを別途設定する必要があります。

代替案：SSHの代わりにHTTPSでGitLabを使用するように切り替えます。そのためには、リモートURLを変更します： 

# 現在のリモートを確認
git remote -v

# SSHからHTTPSに変更
git remote set-url origin https://gitlab.com/username/repo.git

問題3：CI/CDパイプラインがリポジトリのクローン段階でハングする

RunnerはGitLabから直接リポジトリをクローンし、トークンを使用します。runnerがプロキシの背後にある場合、このクローンもプロキシを経由する必要があります。HTTP_PROXYとHTTPS_PROXYの変数がconfig.tomlに設定されていることを確認してください。.gitlab-ci.ymlのみに設定されているのではありません。CIファイルの変数はクローン後に適用されます。

問題4：プロキシは機能するが非常に遅い

push/pullは機能するが、通常の5〜10倍の時間がかかる場合、問題はプロキシサーバーの帯域幅または地理的位置にある可能性があります。大きなリポジトリ（100MB以上）で作業する場合は、低遅延で高帯域幅のプロキシを選択することが重要です。この場合、データセンター型プロキシが居住型プロキシよりも好まれます。より安定したチャネルを提供します。

問題5：プロキシを介した認証がパスワードの再入力を要求する

プロキシがBasic認証を要求し、Gitが毎回パスワードを要求する場合、credential helperを設定します： 

# macOS — Keychainを使用
git config --global credential.helper osxkeychain

# Windows — Windows Credential Managerを使用
git config --global credential.helper manager

# Linux — 1時間キャッシュ
git config --global credential.helper "cache --timeout=3600"

プロキシの問題を迅速に診断する方法：

次のコマンドを使用します：GIT_TRACE=1 GIT_CURL_VERBOSE=1 git clone https://gitlab.com/... — これにより、すべてのHTTPリクエストとレスポンスの詳細なログが出力され、プロキシに関する情報も含まれます。

結論と推奨事項

GitLabのプロキシ設定は、複数のレベルで同時に解決されるタスクです。開発者は自分の作業マシンでGitまたはSSHの設定に数行を記述するだけで済みます。CI/CDには、runnerの設定やプロジェクト設定に環境変数を追加する必要があります。自己ホスト型GitLabの場合は、gitlab.rbを更新し、設定を再構成します。

ほとんどの問題を回避するための主なルールは次のとおりです：

  • SOCKS5を使用してください — HTTPSとSSHの両方で機能します
  • 内部サービスのために常にNO_PROXYを設定してください
  • プロダクション環境でSSL検証を無効にしないでください — 企業の証明書を追加してください
  • CI/CDのためにconfig.tomlにプロキシを設定し、.gitlab-ci.ymlのみに設定しないでください
  • 設定を文書化してください — チームの新しい開発者は感謝するでしょう

どこからでもGitLabへの安定したアクセスを確保するための信頼できるプロキシを探している場合は、データセンター型プロキシを検討することをお勧めします。これらはデータ転送速度が高く、遅延が低く、大きなリポジトリや集中的なCI/CDパイプラインで作業する際に特に重要です。最大の匿名性やGeoIPブロックの回避が重要なチームには、実際の家庭ユーザーのIPを持つ居住型プロキシが適しています。

```