ā† Kembali ke blog
RUENZHESARPTDEFRJAKOITTRIDVIFAHI

Proxy untuk GitLab: cara mengatur akses untuk tim dan pipeline CI/CD tanpa gangguan

GitLab diblokir atau tidak tersedia di wilayah Anda? Kami membahas cara mengatur proxy untuk GitLab agar seluruh tim dapat bekerja tanpa gangguan dan pipeline CI/CD tidak terputus.

šŸ“…19 Juli 2026
```html

GitLab adalah platform populer untuk penyimpanan kode dan manajemen proses DevOps yang digunakan oleh ribuan tim di seluruh dunia. Tapi apa yang harus dilakukan jika akses ke GitLab diblokir di tingkat penyedia, jaringan perusahaan, atau bahkan seluruh negara? Apalagi jika pipeline CI/CD gagal di tengah malam hanya karena runner tidak dapat mengakses repositori.

Dalam artikel ini, kita akan membahas cara mengatur proxy untuk GitLab di tingkat klien Git, GitLab Runner, dan server perusahaan ā€” sehingga seluruh tim dapat bekerja dengan stabil dari mana saja di dunia.

Mengapa diperlukan proxy untuk GitLab: skenario nyata

Sebelum mengatur proxy, penting untuk memahami masalah apa yang sebenarnya Anda coba selesaikan. Situasi bisa berbeda-beda, dan ini akan mempengaruhi pilihan jenis proxy dan cara menghubungkannya.

Skenario 1: GitLab diblokir oleh penyedia atau di tingkat negara

Di beberapa negara dan jaringan perusahaan, akses ke gitlab.com dibatasi. Seorang pengembang membuka terminal, mengetik git pull ā€” dan mendapatkan timeout. Proxy dalam hal ini berfungsi sebagai perantara: lalu lintas tidak langsung menuju gitlab.com, tetapi melalui server perantara di negara yang tidak memiliki pembatasan.

Skenario 2: Tim terdistribusi di berbagai negara

Bayangkan: sebagian tim bekerja dari Rusia, sebagian dari Kazakhstan, dan sebagian dari Eropa. Setiap orang memiliki kondisi jaringan yang berbeda, dengan batasan yang berbeda. Agar semua orang dapat bekerja dengan stabil dan dengan kecepatan yang sama, perusahaan mengembangkan server proxy perusahaan, di mana semua lalu lintas ke GitLab berjalan melalui saluran yang sama.

Skenario 3: CI/CD runner tidak dapat mengakses ketergantungan eksternal

GitLab Runner menjalankan pipeline, dan pada tahap npm install atau pip install semuanya gagal ā€” karena server tempat runner berjalan berada di jaringan tertutup tanpa akses langsung ke internet. Proxy memungkinkan runner untuk mendapatkan ketergantungan eksternal tanpa memberikan akses penuh ke internet untuk seluruh server.

Skenario 4: GitLab yang di-host sendiri di belakang firewall perusahaan

Perusahaan memiliki server GitLab sendiri di jaringan internal. Pengembang yang bekerja jarak jauh harus terhubung ke server tersebut. Alih-alih menggunakan VPN untuk semua lalu lintas, Anda dapat mengatur proxy hanya untuk lalu lintas GitLab ā€” ini lebih cepat dan lebih mudah untuk dikelola.

Skenario 5: Pemantauan dan audit lalu lintas

Perusahaan besar mengarahkan semua lalu lintas ke repositori melalui proxy perusahaan untuk mencatat aktivitas, mengontrol siapa yang melakukan push, dan memblokir operasi yang tidak diinginkan. Ini adalah persyaratan keamanan, bukan untuk mengatasi pemblokiran.

Penting untuk dipahami sebelum pengaturan:

Proxy untuk GitLab mungkin diperlukan di tiga tingkat sekaligus: di mesin pengembang (klien Git), di server dengan GitLab Runner (CI/CD), dan di server GitLab itu sendiri (jika di-host sendiri). Setiap tingkat diatur secara terpisah.

Jenis proxy yang cocok untuk GitLab

GitLab beroperasi melalui protokol HTTPS dan SSH. Ini langsung menentukan jenis proxy yang dapat diterapkan dan yang tidak. Mari kita bahas opsi-opsinya.

Jenis Proxy Protokol Cocok untuk GitLab Kapan digunakan
Proxy HTTP/HTTPS HTTP, HTTPS āœ“ Ya Git melalui HTTPS, antarmuka web GitLab
Proxy SOCKS5 TCP (apa saja) āœ“ Ya (opsi terbaik) Git melalui HTTPS dan SSH, CI/CD
Proxy SOCKS4 TCP ~ Sebagian Hanya jika SOCKS5 tidak tersedia
Proxy Transparan HTTP āœ— Tidak Tidak cocok ā€” tidak mengatasi pemblokiran

Untuk bekerja dengan GitLab, pilihan optimal adalah SOCKS5. Ini beroperasi di tingkat TCP, sehingga dengan baik memproxy baik koneksi HTTPS (antarmuka web, git clone melalui HTTPS) maupun koneksi SSH (git push/pull melalui SSH di port 22 atau 443).

Proxy Residen vs Data Center untuk GitLab

Di sini semuanya tergantung pada tugas. Jika tujuannya adalah untuk mengatasi pemblokiran berdasarkan GeoIP atau mendapatkan IP yang stabil untuk otorisasi, proxy data center akan cocok ā€” mereka lebih cepat, lebih murah, dan memberikan latensi rendah, yang sangat penting saat bekerja dengan repositori besar.

Namun, jika IP perusahaan Anda masuk dalam daftar blokir GitLab (ini bisa terjadi saat pemindaian agresif atau setelah insiden keamanan), maka sebaiknya pertimbangkan proxy residen ā€” alamat IP mereka dimiliki oleh pengguna rumah yang nyata dan sangat jarang diblokir oleh platform.

Pengaturan proxy untuk klien Git (secara global)

Ini adalah skenario yang paling umum: pengembang di mesin mereka tidak dapat terhubung ke GitLab. Pengaturan dilakukan melalui konfigurasi Git itu sendiri ā€” satu kali, dan berlaku untuk semua repositori.

Opsi A: Proxy HTTPS untuk Git

Jika Anda bekerja dengan GitLab melalui HTTPS (alamat repositori dimulai dengan https://), jalankan di terminal: 

# Mengatur proxy HTTP secara global
git config --global http.proxy http://IP_PROXY_ANDA:PORT

# Jika proxy memerlukan otorisasi
git config --global http.proxy http://USERNAME:PASSWORD@IP_PROXY_ANDA:PORT

# Untuk proxy SOCKS5 (disarankan)
git config --global http.proxy socks5://IP_PROXY_ANDA:PORT

# Memeriksa bahwa pengaturan diterapkan
git config --global --get http.proxy

Opsi B: Proxy hanya untuk gitlab.com (tidak mempengaruhi repositori lain)

Jika Anda tidak ingin proxy diterapkan untuk semua operasi Git (misalnya, GitHub atau Bitbucket berfungsi dengan baik), Anda dapat mengatur proxy hanya untuk domain tertentu: 

# Proxy hanya untuk gitlab.com
git config --global http.https://gitlab.com.proxy socks5://IP_PROXY_ANDA:PORT

# Atau untuk GitLab yang di-host sendiri
git config --global http.https://git.yourcompany.com.proxy socks5://IP_PROXY_ANDA:PORT

Opsi C: SSH melalui proxy (untuk yang bekerja melalui SSH)

Jika Anda mengkloning repositori melalui SSH ([email protected]:...), pengaturan proxy dilakukan di konfigurasi SSH, bukan di Git. Buka file ~/.ssh/config dan tambahkan: 

# Untuk Linux/macOS ā€” melalui nc (netcat)
Host gitlab.com
    HostName gitlab.com
    User git
    ProxyCommand nc -X 5 -x IP_PROXY_ANDA:PORT %h %p

# Untuk Windows ā€” melalui connect.exe (Git for Windows)
Host gitlab.com
    HostName gitlab.com
    User git
    ProxyCommand connect -S IP_PROXY_ANDA:PORT %h %p

Setelah pengaturan, periksa koneksi dengan perintah ssh -T [email protected]. Jika semuanya diatur dengan benar, Anda akan melihat pesan sambutan dari GitLab.

Cara menonaktifkan proxy ketika sudah tidak diperlukan

# Menghapus proxy global
git config --global --unset http.proxy

# Menghapus proxy untuk domain tertentu
git config --global --unset http.https://gitlab.com.proxy

Proxy untuk GitLab Runner dan pipeline CI/CD

GitLab Runner adalah agen yang menjalankan tugas dari .gitlab-ci.yml. Jika runner berada di jaringan tertutup atau di server dengan akses internet yang terbatas, proxy perlu diatur secara terpisah. Pengaturan klien Git pengembang tidak akan membantu di sini ā€” runner berjalan di mesin lain.

Metode 1: Variabel lingkungan dalam konfigurasi runner

Buka file konfigurasi GitLab Runner (biasanya /etc/gitlab-runner/config.toml) dan tambahkan variabel lingkungan di bagian [runners.env]: 

[[runners]]
  name = "my-runner"
  url = "https://gitlab.com/"
  token = "TOKEN_ANDA"
  executor = "shell"
  environment = [
    "HTTP_PROXY=http://IP_PROXY_ANDA:PORT",
    "HTTPS_PROXY=http://IP_PROXY_ANDA:PORT",
    "NO_PROXY=localhost,127.0.0.1,domain-internal-anda.com"
  ]

Setelah mengubah konfigurasi, restart runner: sudo gitlab-runner restart

Metode 2: Variabel di .gitlab-ci.yml (di tingkat pipeline)

Jika Anda bukan administrator runner atau ingin mengatur proxy hanya untuk proyek tertentu, tambahkan variabel langsung ke file pipeline: 

variables:
  HTTP_PROXY: "http://IP_PROXY_ANDA:PORT"
  HTTPS_PROXY: "http://IP_PROXY_ANDA:PORT"
  NO_PROXY: "localhost,127.0.0.1,.internal.company.com"

stages:
  - build
  - test
  - deploy

build:
  stage: build
  script:
    - npm install   # sekarang akan melalui proxy
    - npm run build

Metode 3: Variabel di pengaturan proyek GitLab (tanpa commit ke repositori)

Cara terbaik untuk data sensitif (proxy dengan otorisasi): pergi ke Settings ā†’ CI/CD ā†’ Variables proyek Anda dan tambahkan variabel HTTP_PROXY, HTTPS_PROXY, NO_PROXY sebagai variabel yang dilindungi (masked). Mereka akan secara otomatis tersedia di semua pipeline, tetapi tidak akan terlihat di log.

Tentang NO_PROXY ā€” jangan lupa!

Variabel NO_PROXY sangat penting. Anda perlu menambahkan semua domain dan IP internal yang harus diakses langsung oleh runner, tanpa melalui proxy. Jika tidak, runner akan mencoba menggunakan proxy bahkan untuk layanan internal ā€” dan pipeline akan gagal.

Proxy untuk executor Docker

Jika runner menggunakan executor Docker, kontainer secara default tidak mewarisi pengaturan proxy dari host. Anda perlu menambahkan variabel di config.toml di bagian [runners.docker], atau membuat file /etc/systemd/system/docker.service.d/proxy.conf di host dengan runner: 

[Service]
Environment="HTTP_PROXY=http://IP_PROXY_ANDA:PORT"
Environment="HTTPS_PROXY=http://IP_PROXY_ANDA:PORT"
Environment="NO_PROXY=localhost,127.0.0.1"

Setelah itu: sudo systemctl daemon-reload && sudo systemctl restart docker

Proxy untuk server GitLab yang di-host sendiri

Jika Anda mengelola server GitLab sendiri (diinstal melalui Omnibus atau Helm), proxy diperlukan agar GitLab itu sendiri dapat mengakses layanan eksternal: mengirimkan notifikasi, terhubung ke sistem CI eksternal, mengunggah avatar pengguna, berintegrasi dengan Jira atau Slack.

Pengaturan di gitlab.rb (instalasi Omnibus)

Buka file /etc/gitlab/gitlab.rb dan tambahkan atau hapus komentar pada baris berikut: 

# Proxy untuk GitLab (Omnibus)
gitlab_rails['env'] = {
  "http_proxy" => "http://IP_PROXY_ANDA:PORT",
  "https_proxy" => "http://IP_PROXY_ANDA:PORT",
  "no_proxy" => "localhost,127.0.0.1,DOMAIN_INTERNAL_ANDA"
}

# Jika proxy dengan otorisasi:
gitlab_rails['env'] = {
  "http_proxy" => "http://USERNAME:PASSWORD@IP_PROXY_ANDA:PORT",
  "https_proxy" => "http://USERNAME:PASSWORD@IP_PROXY_ANDA:PORT",
  "no_proxy" => "localhost,127.0.0.1"
}

Setelah mengubah konfigurasi, terapkan pengaturan: sudo gitlab-ctl reconfigure

Pengaturan koneksi keluar melalui Admin Area

Di GitLab 15.0+, ada opsi untuk mengatur proxy langsung melalui antarmuka web: pergi ke Admin Area ā†’ Settings ā†’ Network ā†’ Outbound requests. Di sini Anda dapat menentukan proxy untuk webhook keluar dan membatasi rentang IP yang dapat diakses oleh GitLab. Ini berguna untuk keamanan ā€” mencegah serangan SSRF melalui webhook.

Organisasi akses untuk seluruh tim melalui proxy

Ketika perlu memastikan akses stabil ke GitLab untuk tim yang terdiri dari 5ā€“50 orang, pengaturan individu di setiap mesin bukanlah pendekatan terbaik. Mari kita lihat solusi yang lebih skalabel.

Pendekatan 1: Server proxy perusahaan

Satu server proxy (misalnya, Squid atau 3proxy) dengan akses internet disiapkan. Semua pengembang mengatur Git untuk menggunakan server ini. Keuntungannya: manajemen terpusat, satu titik kontrol, dapat mencatat lalu lintas. Kekurangan: server menjadi titik kegagalan tunggal.

Pendekatan 2: Cermin (mirror) repositori

GitLab mendukung pencerminan repositori. Anda dapat mengatur GitLab yang di-host sendiri di jaringan internal sebagai cermin dari gitlab.com. Pengembang bekerja dengan server internal, dan server tersebut disinkronkan dengan eksternal melalui proxy. Ini mengurangi ketergantungan pada kualitas koneksi proxy untuk setiap pengembang.

Pendekatan 3: Pengaturan otomatis melalui dotfiles atau skrip onboarding

Untuk tim di mana setiap pengembang mengatur lingkungan mereka sendiri, nyaman untuk membuat skrip onboarding yang secara otomatis menulis pengaturan Git yang diperlukan. Skrip disimpan di repositori perusahaan dan dijalankan saat mengatur tempat kerja baru. 

#!/bin/bash
# setup-git-proxy.sh ā€” jalankan saat mengatur tempat kerja baru

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

echo "Mengatur proxy Git untuk akses ke GitLab..."
git config --global http.https://gitlab.com.proxy "socks5://${PROXY_HOST}:${PROXY_PORT}"
git config --global http.sslVerify true
echo "Selesai! Periksa: git config --global --list | grep proxy"

Daftar periksa untuk penyebaran tim

  • Tentukan apakah proxy diperlukan di tingkat pengembang, runner, atau server GitLab (atau ketiga-tiganya)
  • Pilih jenis proxy: SOCKS5 untuk kompatibilitas maksimum
  • Atur NO_PROXY untuk semua domain dan layanan internal
  • Periksa fungsi kunci SSH melalui proxy (langkah terpisah!)
  • Dokumentasikan pengaturan di wiki perusahaan
  • Buat skrip onboarding untuk karyawan baru
  • Atur pemantauan ketersediaan server proxy

Masalah umum dan solusinya

Bahkan setelah pengaturan yang benar, kadang-kadang ada yang tidak beres. Berikut adalah masalah yang paling umum dan cara mendiagnosisnya.

Masalah 1: Masalah sertifikat SSL: tidak dapat mendapatkan sertifikat penerbit lokal

Kesalahan ini terjadi ketika server proxy (terutama yang perusahaan) melakukan inspeksi SSL ā€” mengganti sertifikat GitLab dengan sertifikatnya sendiri. Git tidak mempercayai sertifikat ini. Solusi: tambahkan sertifikat root perusahaan ke dalam daftar yang dipercaya. 

# Solusi sementara (untuk debugging, bukan untuk produksi!)
git config --global http.sslVerify false

# Solusi yang benar: tambahkan sertifikat perusahaan
git config --global http.sslCAInfo /path/to/corporate-ca-bundle.crt

Masalah 2: Proxy berfungsi untuk HTTPS, tetapi SSH tidak berfungsi

Ini adalah situasi klasik: Anda telah mengatur http.proxy di Git, kloning HTTPS berhasil, tetapi operasi SSH masih tidak berjalan. Penyebabnya: lalu lintas SSH tidak melewati proxy HTTP. Anda perlu mengatur ~/.ssh/config secara terpisah seperti yang dijelaskan di bagian tentang klien Git.

Alternatif: beralih untuk bekerja dengan GitLab melalui HTTPS alih-alih SSH. Untuk ini, ubah URL remote: 

# Periksa remote saat ini
git remote -v

# Ubah dari SSH ke HTTPS
git remote set-url origin https://gitlab.com/username/repo.git

Masalah 3: Pipeline CI/CD terhenti pada tahap kloning repositori

Runner mengkloning repositori langsung dari GitLab, menggunakan token. Jika runner berada di belakang proxy, kloning ini juga harus melalui proxy. Pastikan variabel HTTP_PROXY dan HTTPS_PROXY diatur di config.toml, dan bukan hanya di .gitlab-ci.yml ā€” variabel dari file CI diterapkan setelah kloning, bukan sebelum.

Masalah 4: Proxy berfungsi, tetapi sangat lambat

Jika push/pull berfungsi, tetapi memakan waktu 5ā€“10 kali lebih lama dari biasanya, masalahnya mungkin terletak pada bandwidth server proxy atau lokasi geografisnya. Untuk bekerja dengan repositori besar (100+ MB), penting untuk memilih proxy dengan latensi rendah dan bandwidth tinggi. Proxy data center dalam hal ini lebih disukai dibandingkan dengan residen ā€” mereka menyediakan saluran yang lebih stabil.

Masalah 5: Autentikasi melalui proxy memerlukan pengulangan input kata sandi

Jika proxy memerlukan autentikasi dasar, dan Git meminta kata sandi setiap kali, atur credential helper: 

# macOS ā€” menggunakan Keychain
git config --global credential.helper osxkeychain

# Windows ā€” menggunakan Windows Credential Manager
git config --global credential.helper manager

# Linux ā€” menyimpan cache selama 1 jam
git config --global credential.helper "cache --timeout=3600"

Cara cepat untuk mendiagnosis masalah dengan proxy:

Gunakan GIT_TRACE=1 GIT_CURL_VERBOSE=1 git clone https://gitlab.com/... ā€” ini akan menampilkan log rinci dari semua permintaan dan respons HTTP, termasuk informasi tentang proxy.

Kesimpulan dan rekomendasi

Mengatur proxy untuk GitLab adalah tugas yang diselesaikan di beberapa tingkat sekaligus. Pengembang di mesin kerja cukup menulis beberapa baris di konfigurasi Git atau SSH. Untuk CI/CD, Anda perlu menambahkan variabel lingkungan di konfigurasi runner atau pengaturan proyek. Dan untuk GitLab yang di-host sendiri ā€” memperbarui gitlab.rb dan membangun kembali konfigurasi.

Aturan utama yang akan membantu menghindari sebagian besar masalah:

  • Gunakan SOCKS5 ā€” ini berfungsi baik dengan HTTPS maupun SSH
  • Selalu atur NO_PROXY untuk layanan internal
  • Jangan nonaktifkan verifikasi SSL di produksi ā€” tambahkan sertifikat perusahaan
  • Untuk CI/CD, atur proxy di config.toml, dan bukan hanya di .gitlab-ci.yml
  • Dokumentasikan pengaturan ā€” pengembang baru di tim akan berterima kasih

Jika Anda mencari proxy yang andal untuk mengatur akses stabil ke GitLab dari mana saja di dunia, kami merekomendasikan untuk mempertimbangkan proxy data center ā€” mereka memberikan kecepatan transfer data tinggi dan latensi rendah, yang sangat penting saat bekerja dengan repositori besar dan pipeline CI/CD yang intensif. Untuk tim yang mengutamakan anonimitas maksimum atau mengatasi pemblokiran GeoIP, proxy residen dengan IP pengguna rumah yang nyata akan cocok.

```