GitHub Actions용 프록시: CI/CD 파이프라인 설정

```html

GitHub Actions는 강력한 자동화 도구입니다: 테스트를 실행하고, 애플리케이션을 배포하며, 데이터를 수집하고 수십 가지 다른 작업을 수행합니다. 그러나 워크플로우가 외부 리소스—마켓플레이스, 광고 플랫폼, 해외 API—에 접근하기 시작하면 즉시 지리적 차단 및 IP 제한에 직면하게 됩니다. 해결책은 하나입니다: 파이프라인에 프록시를 직접 연결하는 것입니다.

GitHub Actions에서 프록시가 필요한 이유: 실제 시나리오

많은 팀들이 GitHub Actions를 코드 배포뿐만 아니라 비즈니스 작업 자동화에도 사용합니다: 경쟁사 가격 모니터링, 마켓플레이스 데이터 수집, 광고 계정 자동 점검 및 다양한 지역에서 웹사이트 테스트. 이러한 모든 작업은 하나의 문제를 공유합니다—GitHub Actions의 러너는 Microsoft Azure의 고정 IP를 가지고 있으며, 많은 서비스가 이를 차단하거나 제한합니다.

다음은 프록시 없이는 해결할 수 없는 구체적인 상황입니다:

Wildberries, Ozon, Avito 파싱 — 이러한 플랫폼은 오래전부터 클라우드 제공자의 IP 범위를 블랙리스트에 올렸습니다. GitHub Actions의 러너로부터의 요청은 2-3번의 시도에서 차단되거나 CAPTCHA를 받게 됩니다.
지리적 타겟팅 테스트 — 마케터와 QA 엔지니어는 모스크바, 베를린 또는 뉴욕의 사용자에게 사이트나 광고가 어떻게 보이는지 확인합니다. 프록시가 없으면 러너는 항상 하나의 지역에 대한 콘텐츠만 "볼" 수 있습니다.
지역 제한이 있는 API 작업 — 일부 API(예: 특정 설정이 있는 Google Ads의 지역 버전, Facebook Marketing API)는 요청의 지리적 위치에 따라 다른 데이터를 반환합니다.
경쟁사 모니터링 — 가격, 프로모션 및 제품 목록의 자동 수집은 반복되는 데이터 센터 IP로 쉽게 감지되는 정기적인 요청을 요구합니다.
광고 점검 자동화 — 중재자와 성과 마케터는 CI/CD의 스크립트를 통해 광고 상태, 잔액 및 메트릭을 자동으로 점검합니다.
외부 서비스와의 통합 테스트 — 일부 서비스는 보안상의 이유로 Azure 범위의 요청을 차단하며, 테스트는 설명 없이 실패합니다.

이러한 모든 경우에서 프록시는 문제를 근본적으로 해결합니다: 워크플로우는 필요한 도시의 일반 사용자로부터의 요청처럼 보이게 되며, Microsoft의 클라우드 서버로부터의 요청처럼 보이지 않게 됩니다.

GitHub Actions가 네트워크와 작동하는 방식

프록시를 설정하기 전에 GitHub Actions의 네트워크 아키텍처를 이해하는 것이 중요합니다. 표준 ubuntu-latest 러너에서 워크플로우를 실행하면, 작업은 Microsoft Azure의 인프라 내 가상 머신에서 수행됩니다. 이러한 각 머신은 Azure 범위의 공용 IP를 가지고 있으며, 외부 서비스는 바로 이 IP를 봅니다.

GitHub Actions의 네트워크 주요 특징:

각 실행 시 IP가 변경됨 — 그러나 알려진 Azure 범위 내에 남아 있으며, 쉽게 감지됩니다.
프록시에 대한 내장 지원 없음 — GitHub는 트래픽 프록시를 위한 기본 메커니즘을 제공하지 않습니다.
환경 변수가 전역적으로 작동함 — HTTP_PROXY를 job 수준에서 설정하면, 해당 job 내의 모든 단계가 프록시를 사용합니다.
자체 호스팅 러너 — 서버에서 러너를 실행하는 대안입니다. 이 경우 프록시는 워크플로우가 아닌 서버 수준에서 설정됩니다.

대부분의 작업에 대한 최적의 접근 방식은 워크플로우 파일(.github/workflows/your-workflow.yml) 내에서 환경 변수를 통해 프록시를 설정하는 것입니다. 이는 curl, wget, Python requests, Node.js http, Go net/http 및 기타 대부분의 도구에서 작동하는 보편적인 방법입니다.

CI/CD에 적합한 프록시 유형 선택하기

프록시 유형 선택은 작업에 따라 달라집니다. CI/CD 파이프라인에 적합한 세 가지 옵션이 있으며, 각기 다른 용도가 있습니다:

프록시 유형	어떤 작업에 적합한가	속도	신뢰 수준
주거용 프록시	보안 사이트 파싱, 지리적 타겟팅, 마켓플레이스 모니터링	중간	높음 — 실제 가정 IP
모바일 프록시	모바일 버전 테스트, 소셜 미디어 작업, Facebook/TikTok API	중간	최대 — 통신사 IP
데이터 센터 프록시	통합 테스트, 비보안 API 요청, 높은 부하	높음	중간

실용적인 규칙: 만약 귀하의 워크플로우가 Wildberries, Ozon 또는 기타 안티봇 보호가 있는 마켓플레이스를 파싱한다면—주거용 프록시를 선택하세요. Facebook Ads 또는 TikTok Ads 광고 계정을 테스트하는 경우—모바일 프록시를 사용하세요. 간단한 통합 테스트 및 공개 API 요청에는 데이터 센터 프록시가 충분합니다: 이들은 더 빠르고 저렴합니다.

💡 프로토콜에 대한 중요 사항

GitHub Actions에서는 HTTP/HTTPS 프록시를 사용하는 것이 바람직합니다—이는 대부분의 도구에서 추가 설정 없이 지원됩니다. SOCKS5도 작동하지만 각 도구에서 명시적으로 지정해야 합니다. 귀하의 제공자가 두 프로토콜을 모두 지원하는 경우—HTTP부터 시작하세요.

환경 변수를 통한 프록시 설정

GitHub Actions에서 프록시를 연결하는 가장 보편적인 방법은 표준 환경 변수 HTTP_PROXY, HTTPS_PROXY 및 NO_PROXY를 설정하는 것입니다. 대부분의 커맨드라인 도구와 프로그래밍 언어는 이를 자동으로 인식합니다.

프록시가 설정된 워크플로우의 기본 구조는 다음과 같습니다:

name: 프록시와 함께하는 워크플로우

on:
  schedule:
    - cron: '0 9 * * *'
  workflow_dispatch:

jobs:
  scrape-data:
    runs-on: ubuntu-latest

    env:
      HTTP_PROXY: http://${{ secrets.PROXY_USER }}:${{ secrets.PROXY_PASS }}@${{ secrets.PROXY_HOST }}:${{ secrets.PROXY_PORT }}
      HTTPS_PROXY: http://${{ secrets.PROXY_USER }}:${{ secrets.PROXY_PASS }}@${{ secrets.PROXY_HOST }}:${{ secrets.PROXY_PORT }}
      NO_PROXY: localhost,127.0.0.1,github.com

    steps:
      - name: 리포지토리 체크아웃
        uses: actions/checkout@v4

      - name: 현재 IP 확인 (확인용)
        run: curl -s https://api.ipify.org

      - name: 주요 스크립트 실행
        run: python scripts/scraper.py

NO_PROXY 블록에 주목하세요—여기에는 트래픽을 프록시하지 않아야 하는 주소를 추가해야 합니다. 최소한 localhost와 127.0.0.1를 포함해야 합니다. 또한 github.com을 추가하는 것이 좋습니다, 이렇게 하면 리포지토리 작업(checkout, push)이 직접 진행됩니다.

인증이 없는 프록시(IP와 포트만 있는 경우)에서는 형식이 간단해집니다:

env:
  HTTP_PROXY: http://203.0.113.10:8080
  HTTPS_PROXY: http://203.0.113.10:8080
  NO_PROXY: localhost,127.0.0.1

SOCKS5 프록시의 경우 URL에서 스킴만 변경됩니다:

env:
  HTTP_PROXY: socks5://user:password@proxy-host:1080
  HTTPS_PROXY: socks5://user:password@proxy-host:1080

curl, wget 및 shell에서 HTTP 요청을 위한 프록시

환경 변수가 job 수준에서 설정되면(위와 같이) curl과 wget은 이를 자동으로 인식합니다. 그러나 때때로 특정 단계에서 또는 디버깅 시 프록시를 명시적으로 전달해야 할 필요가 있습니다.

curl에서 프록시를 명시적으로 지정하는 방법:

- name: 프록시를 사용하여 데이터 가져오기
  run: |
    curl -x http://${{ secrets.PROXY_USER }}:${{ secrets.PROXY_PASS }}@${{ secrets.PROXY_HOST }}:${{ secrets.PROXY_PORT }} \
      -s \
      -o output.json \
      https://api.example.com/data

    # 프록시를 통한 확인
    curl -x http://${{ secrets.PROXY_USER }}:${{ secrets.PROXY_PASS }}@${{ secrets.PROXY_HOST }}:${{ secrets.PROXY_PORT }} \
      -s https://api.ipify.org?format=json

wget의 경우:

- name: 프록시를 통해 wget으로 다운로드
  run: |
    wget -e "https_proxy=http://${{ secrets.PROXY_USER }}:${{ secrets.PROXY_PASS }}@${{ secrets.PROXY_HOST }}:${{ secrets.PROXY_PORT }}" \
      -q \
      -O data.html \
      https://target-site.com/page

디버깅을 위한 유용한 단계는 워크플로우의 시작 부분에 IP 주소를 확인하는 것입니다. 프록시가 제대로 작동하면 Azure가 아닌 프록시 서버의 IP를 볼 수 있습니다:

- name: 프록시 활성화 확인
  run: |
    echo "=== 프록시 없이 IP ==="
    curl -s --noproxy '*' https://api.ipify.org || echo "직접 요청 실패"
    echo ""
    echo "=== 프록시를 통한 IP ==="
    curl -s https://api.ipify.org

워크플로우 내 Python 스크립트의 프록시 설정

Python은 CI/CD에서 가장 인기 있는 스크립트 언어 중 하나입니다. requests 라이브러리는 환경 변수 HTTP_PROXY 및 HTTPS_PROXY를 자동으로 읽습니다. 그러나 보다 유연한 제어를 위해 프록시를 명시적으로 전달하는 것이 좋습니다.

프록시를 명시적으로 전달하는 Python 스크립트 예제:

import os
import requests

# 환경 변수에서 프록시 데이터 읽기
proxy_host = os.environ.get('PROXY_HOST')
proxy_port = os.environ.get('PROXY_PORT')
proxy_user = os.environ.get('PROXY_USER')
proxy_pass = os.environ.get('PROXY_PASS')

proxies = {
    'http': f'http://{proxy_user}:{proxy_pass}@{proxy_host}:{proxy_port}',
    'https': f'http://{proxy_user}:{proxy_pass}@{proxy_host}:{proxy_port}',
}

# 요청에 프록시 사용
response = requests.get(
    'https://www.wildberries.ru/catalog/123456/detail.aspx',
    proxies=proxies,
    timeout=30,
    headers={
        'User-Agent': 'Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36'
    }
)

print(f"상태: {response.status_code}")
print(f"콘텐츠 길이: {len(response.content)}")

워크플로우 파일에서는 변수를 개별 비밀로 전달해야 합니다(전체 URL 형태가 아님), 그래야 스크립트가 이를 수집할 수 있습니다:

- name: Python 스크레이퍼 실행
  env:
    PROXY_HOST: ${{ secrets.PROXY_HOST }}
    PROXY_PORT: ${{ secrets.PROXY_PORT }}
    PROXY_USER: ${{ secrets.PROXY_USER }}
    PROXY_PASS: ${{ secrets.PROXY_PASS }}
  run: python scripts/scraper.py

Playwright 또는 Selenium을 사용하여 Python에서 프록시를 설정하는 구성은 약간 다릅니다:

# Playwright
from playwright.sync_api import sync_playwright
import os

proxy_url = f"http://{os.environ['PROXY_USER']}:{os.environ['PROXY_PASS']}@{os.environ['PROXY_HOST']}:{os.environ['PROXY_PORT']}"

with sync_playwright() as p:
    browser = p.chromium.launch(
        proxy={
            "server": proxy_url
        }
    )
    page = browser.new_page()
    page.goto("https://target-site.com")
    # ... 추가 로직
    browser.close()

Node.js 및 npm 작업의 프록시 설정

Node.js는 시스템 변수를 HTTP_PROXY를 자동으로 읽지 않습니다—특별한 라이브러리를 사용하거나 프록시를 명시적으로 설정해야 합니다. 가장 편리한 방법은 https-proxy-agent 패키지 또는 proxy 구성이 있는 axios입니다.

// axios 사용
const axios = require('axios');

const proxyConfig = {
  host: process.env.PROXY_HOST,
  port: parseInt(process.env.PROXY_PORT),
  auth: {
    username: process.env.PROXY_USER,
    password: process.env.PROXY_PASS
  }
};

async function fetchData(url) {
  try {
    const response = await axios.get(url, {
      proxy: proxyConfig,
      timeout: 30000,
      headers: {
        'User-Agent': 'Mozilla/5.0 (compatible; MyBot/1.0)'
      }
    });
    return response.data;
  } catch (error) {
    console.error(`요청 실패: ${error.message}`);
    throw error;
  }
}

fetchData('https://api.example.com/prices')
  .then(data => console.log(JSON.stringify(data, null, 2)))
  .catch(() => process.exit(1));

npm 명령(예: npm이 기업 프록시를 통해 패키지를 다운로드하려고 할 때)의 경우 구성은 더 간단합니다:

- name: npm 프록시 구성
  run: |
    npm config set proxy http://${{ secrets.PROXY_USER }}:${{ secrets.PROXY_PASS }}@${{ secrets.PROXY_HOST }}:${{ secrets.PROXY_PORT }}
    npm config set https-proxy http://${{ secrets.PROXY_USER }}:${{ secrets.PROXY_PASS }}@${{ secrets.PROXY_HOST }}:${{ secrets.PROXY_PORT }}

- name: 종속성 설치
  run: npm install

- name: npm 프록시 재설정 (사용 후 정리)
  run: |
    npm config delete proxy
    npm config delete https-proxy

GitHub Secrets에서 프록시 데이터 안전하게 저장하기

프록시 데이터(호스트, 포트, 로그인, 비밀번호)를 워크플로우 파일에 공개적으로 저장하지 마십시오. 이는 보안상의 중대한 실수입니다: 워크플로우 파일은 리포지토리에 저장되며 프로젝트의 모든 참가자가 볼 수 있거나 공개적으로 노출될 수 있습니다.

올바른 접근 방식은 GitHub Secrets입니다. 다음은 단계별 지침입니다:

GitHub에서 리포지토리를 엽니다
Settings → Secrets and variables → Actions로 이동합니다
New repository secret를 클릭합니다
네 개의 비밀을 생성합니다: PROXY_HOST, PROXY_PORT, PROXY_USER, PROXY_PASS
워크플로우에서 ${{ secrets.PROXY_HOST }} 구문을 통해 이들에 접근합니다

🔒 추가 보안 조치

환경 비밀을 사용하여 서로 다른 환경(staging/production)이 서로 다른 프록시를 사용하는 경우
비밀에 대한 접근을 환경 보호 규칙을 통해 제한—production에 대한 수동 확인 요구
프록시 자격 증명을 정기적으로 회전—30-90일마다 비밀번호 변경
echo를 통해 비밀 값을 로그에 출력하지 마십시오—GitHub이 자동으로 마스킹하지만, 위험을 감수하지 않는 것이 좋습니다

회전하는 프록시를 사용하는 경우(각 요청 시 IP가 변경되거나 일정에 따라), 종종 하나의 엔드포인트만 저장하면 충분합니다—프록시 제공자가 IP 풀을 관리합니다. 이 경우 비밀에는 회전 게이트웨이의 호스트와 포트만 포함됩니다.

프록시 회전 및 오류 처리

품질이 좋은 프록시도 때때로 실패합니다: IP가 임시 차단에 걸리거나 세션이 끊기거나 서버가 응답하지 않을 수 있습니다. 자동으로 작동하는 CI/CD 파이프라인의 경우 이러한 상황을 처리할 수 있도록 설계하는 것이 중요합니다.

전략 1: 동일 프록시로 재시도

import requests
import time
import os

def fetch_with_retry(url, max_retries=3, delay=5):
    proxies = {
        'http': f"http://{os.environ['PROXY_USER']}:{os.environ['PROXY_PASS']}@{os.environ['PROXY_HOST']}:{os.environ['PROXY_PORT']}",
        'https': f"http://{os.environ['PROXY_USER']}:{os.environ['PROXY_PASS']}@{os.environ['PROXY_HOST']}:{os.environ['PROXY_PORT']}",
    }

    for attempt in range(max_retries):
        try:
            response = requests.get(url, proxies=proxies, timeout=30)
            response.raise_for_status()
            return response
        except requests.exceptions.RequestException as e:
            print(f"시도 {attempt + 1} 실패: {e}")
            if attempt < max_retries - 1:
                print(f"{delay}초 후 재시도...")
                time.sleep(delay)
                delay *= 2  # 지수적 지연
    raise Exception(f"{url}에 대한 모든 {max_retries} 시도가 실패했습니다.")

전략 2: 프록시 목록으로 스위칭

여러 개의 프록시 서버가 있는 경우, 이를 하나의 비밀(쉼표로 구분)로 저장하고 오류 발생 시 전환할 수 있습니다:

import os
import requests
import random

# 비밀 PROXY_LIST에는: "host1:port1:user1:pass1,host2:port2:user2:pass2"가 포함됩니다.
proxy_list_raw = os.environ.get('PROXY_LIST', '').split(',')

def parse_proxy(proxy_str):
    parts = proxy_str.strip().split(':')
    if len(parts) == 4:
        host, port, user, password = parts
        return {
            'http': f'http://{user}:{password}@{host}:{port}',
            'https': f'http://{user}:{password}@{host}:{port}',
        }
    return None

proxies = [p for p in [parse_proxy(raw) for raw in proxy_list_raw] if p]

def fetch_with_proxy_rotation(url):
    random.shuffle(proxies)  # 무작위 순서
    for proxy in proxies:
        try:
            response = requests.get(url, proxies=proxy, timeout=20)
            if response.status_code == 200:
                return response
        except Exception as e:
            print(f"프록시 실패: {e}, 다음으로 시도...")
    raise Exception("모든 프록시가 소진되었습니다.")

전략 3: 회전 엔드포인트 사용

가장 간단한 방법은 단일 회전 게이트웨이를 가진 프록시 제공자를 사용하는 것입니다. 이 경우 하나의 주소에 연결하면 제공자가 자동으로 풀에서 다양한 IP를 제공합니다. 코드에서 회전 로직이 필요 없으며, 연결 문자열 하나로 충분합니다.

실제 사례: 파싱, 테스트, 가격 모니터링

GitHub Actions와 프록시를 사용하는 팀에서 가장 자주 발생하는 세 가지 구체적인 시나리오를 살펴보겠습니다.

시나리오 1: Wildberries의 가격 모니터링

마켓플레이스 판매자는 종종 경쟁사 가격을 자동으로 수집하는 설정을 합니다. 워크플로우는 일정에 따라 실행되며(예: 매일 아침 7:00), 데이터를 수집하여 Google Sheets에 저장하거나 Telegram으로 전송합니다.

name: 일일 가격 모니터

on:
  schedule:
    - cron: '0 4 * * *'  # 07:00 MSK (UTC+3)

jobs:
  monitor-prices:
    runs-on: ubuntu-latest

    env:
      HTTP_PROXY: http://${{ secrets.PROXY_USER }}:${{ secrets.PROXY_PASS }}@${{ secrets.PROXY_HOST }}:${{ secrets.PROXY_PORT }}
      HTTPS_PROXY: http://${{ secrets.PROXY_USER }}:${{ secrets.PROXY_PASS }}@${{ secrets.PROXY_HOST }}:${{ secrets.PROXY_PORT }}
      NO_PROXY: github.com,api.github.com

    steps:
      - uses: actions/checkout@v4

      - name: Python 설정
        uses: actions/setup-python@v5
        with:
          python-version: '3.11'

      - name: 종속성 설치
        run: pip install requests beautifulsoup4 gspread

      - name: 가격 스크레이퍼 실행
        env:
          GOOGLE_SHEETS_KEY: ${{ secrets.GOOGLE_SHEETS_KEY }}
          TELEGRAM_BOT_TOKEN: ${{ secrets.TELEGRAM_BOT_TOKEN }}
          TELEGRAM_CHAT_ID: ${{ secrets.TELEGRAM_CHAT_ID }}
        run: python scripts/price_monitor.py

      - name: 결과 아티팩트 업로드
        uses: actions/upload-artifact@v4
        with:
          name: price-data-${{ github.run_id }}
          path: output/prices.json

시나리오 2: 지리적 타겟팅 웹사이트 테스트

마케터와 QA 팀은 프록시를 사용하여 사이트나 광고가 다양한 도시의 사용자에게 어떻게 보이는지 확인합니다. 특히 지역 가격, 콘텐츠 및 리디렉션을 확인하는 데 유용합니다.

name: 지리적 타겟팅 사이트 테스트

on:
  push:
    branches: [main]
  pull_request:

jobs:
  test-moscow:
    runs-on: ubuntu-latest
    name: 모스크바에서 테스트
    steps:
      - uses: actions/checkout@v4
      - name: 지리 테스트 실행 (RU/모스크바 프록시)
        env:
          HTTP_PROXY: http://${{ secrets.PROXY_RU_USER }}:${{ secrets.PROXY_RU_PASS }}@${{ secrets.PROXY_RU_HOST }}:${{ secrets.PROXY_RU_PORT }}
          HTTPS_PROXY: http://${{ secrets.PROXY_RU_USER }}:${{ secrets.PROXY_RU_PASS }}@${{ secrets.PROXY_RU_HOST }}:${{ secrets.PROXY_RU_PORT }}
        run: |
          python tests/geo_test.py --region=RU --city=Moscow

  test-germany:
    runs-on: ubuntu-latest
    name: 독일에서 테스트
    steps:
      - uses: actions/checkout@v4
      - name: 지리 테스트 실행 (DE 프록시)
        env:
          HTTP_PROXY: http://${{ secrets.PROXY_DE_USER }}:${{ secrets.PROXY_DE_PASS }}@${{ secrets.PROXY_DE_HOST }}:${{ secrets.PROXY_DE_PORT }}
          HTTPS_PROXY: http://${{ secrets.PROXY_DE_USER }}:${{ secrets.PROXY_DE_PASS }}@${{ secrets.PROXY_DE_HOST }}:${{ secrets.PROXY_DE_PORT }}
        run: |
          python tests/geo_test.py --region=DE

시나리오 3: 광고 계정 자동 점검

중재자와 성과 마케터는 종종 GitHub Actions를 사용하여 Facebook Ads 광고 계정의 상태, 잔액 및 메트릭을 자동으로 점검합니다. Azure 범위에서의 Facebook Marketing API 요청은 추가 보안 검사를 유발할 수 있으며—프록시가 이를 우회하는 데 도움이 됩니다.

name: 광고 계정 상태 점검

on:
  schedule:
    - cron: '*/30 6-22 * * *'  # 매일 6시부터 22시까지 30분마다

jobs:
  check-accounts:
    runs-on: ubuntu-latest

    steps:
      - uses: actions/checkout@v4

      - name: Python 설정
        uses: actions/setup-python@v5
        with:
          python-version: '3.11'

      - name: 종속성 설치
        run: pip install requests

      - name: Facebook Ads 계정 점검
        env:
          HTTP_PROXY: http://${{ secrets.PROXY_USER }}:${{ secrets.PROXY_PASS }}@${{ secrets.PROXY_HOST }}:${{ secrets.PROXY_PORT }}
          HTTPS_PROXY: http://${{ secrets.PROXY_USER }}:${{ secrets.PROXY_PASS }}@${{ secrets.PROXY_HOST }}:${{ secrets.PROXY_PORT }}
          FB_ACCESS_TOKEN: ${{ secrets.FB_ACCESS_TOKEN }}
          ACCOUNT_IDS: ${{ secrets.FB_ACCOUNT_IDS }}
          TELEGRAM_BOT_TOKEN: ${{ secrets.TELEGRAM_BOT_TOKEN }}
          TELEGRAM_CHAT_ID: ${{ secrets.TELEGRAM_CHAT_ID }}
        run: python scripts/check_fb_accounts.py

📋 프록시와 함께 워크플로우 실행 전 체크리스트

✅ 프록시 데이터가 GitHub Secrets에 추가됨 (워크플로우 파일에 아님)
✅ NO_PROXY 변수에 github.com 포함됨
✅ 디버깅을 위한 IP 확인 단계 추가됨
✅ 오류 처리 및 재시도 로직 구현됨
✅ 프록시 유형이 작업에 적합함 (보안 사이트에 대해 주거용)
✅ 오류 알림 설정됨 (Telegram, Slack 또는 이메일)
✅ 워크플로우가 workflow_dispatch를 통해 수동으로 테스트됨 후 일정 추가됨

결론

GitHub Actions에서 프록시를 설정하는 것은 올바른 접근 방식을 알면 복잡하지 않은 작업입니다. 이 가이드의 주요 결론은 다음과 같습니다:

환경 변수 HTTP_PROXY / HTTPS_PROXY — 대부분의 도구에서 코드 변경 없이 작동하는 보편적인 방법입니다.
GitHub Secrets — 프록시 자격 증명을 저장하는 유일한 올바른 장소입니다.
프록시 유형은 중요합니다: 보안 마켓플레이스를 파싱할 때는 주거용 IP가 필요하고, 광고 플랫폼에는 모바일 프록시가 필요하며, 간단한 API 요청에는 데이터 센터 프록시가 적합합니다.
재시도 로직은 필수입니다 자동으로 작동하는 파이프라인에 대해.
IP 확인 단계는 워크플로우 시작 부분에서 디버깅 시간을 절약합니다.

만약 귀하의 GitHub Actions 워크플로우가 마켓플레이스, 광고 플랫폼 또는 안티봇 보호가 있는 서비스와 작업한다면, 주거용 프록시를 사용하는 것이 좋습니다—이들은 실제 가정 사용자의 IP를 가지고 있으며 GitHub 서버의 클라우드 주소에 비해 차단될 가능성이 훨씬 적습니다. Facebook Ads, TikTok 또는 기타 소셜 플랫폼과 관련된 작업에는 모바일 프록시가 최적의 선택입니다—이들은 플랫폼 측에서 최대한의 신뢰를 제공합니다.