Proxy trong GitHub Actions và quy trình CI/CD: Hướng dẫn chi tiết với ví dụ mã

```html

GitHub Actions là một công cụ tự động hóa mạnh mẽ: nó chạy các bài kiểm tra, triển khai ứng dụng, thu thập dữ liệu và thực hiện hàng chục tác vụ khác. Nhưng ngay khi workflow bắt đầu truy cập vào các tài nguyên bên ngoài — các chợ trực tuyến, nền tảng quảng cáo, API nước ngoài — nó ngay lập tức gặp phải các hạn chế địa lý và giới hạn IP. Giải pháp duy nhất: kết nối proxy ngay trong pipeline.

Tại sao cần proxy trong GitHub Actions: các kịch bản thực tế

Nhiều đội ngũ sử dụng GitHub Actions không chỉ để triển khai mã mà còn để tự động hóa các nhiệm vụ kinh doanh: giám sát giá cả của đối thủ, thu thập dữ liệu từ các chợ trực tuyến, kiểm tra tự động các tài khoản quảng cáo và kiểm tra các trang web từ các khu vực khác nhau. Tất cả những nhiệm vụ này đều gặp phải một vấn đề — runner GitHub Actions có một IP cố định từ dải địa chỉ Microsoft Azure, và nhiều dịch vụ chặn hoặc giới hạn nó.

Dưới đây là những tình huống cụ thể mà không thể thiếu proxy:

• Phân tích Wildberries, Ozon, Avito — các nền tảng này đã đưa dải IP của các nhà cung cấp đám mây vào danh sách đen từ lâu. Yêu cầu từ runner GitHub Actions sẽ bị chặn hoặc nhận captcha ngay từ lần thử thứ 2–3.
• Kiểm tra nhắm mục tiêu địa lý — các nhà tiếp thị và kỹ sư QA kiểm tra cách trang web hoặc quảng cáo hiển thị cho người dùng từ Moscow, Berlin hoặc New York. Nếu không có proxy, runner sẽ luôn "nhìn thấy" nội dung cho một khu vực duy nhất.
• Thao tác với API bị giới hạn theo khu vực — một số API (ví dụ, các phiên bản khu vực của Google Ads, Facebook Marketing API với các thiết lập nhất định) trả về dữ liệu khác nhau tùy thuộc vào vị trí địa lý của yêu cầu.
• Giám sát đối thủ — việc thu thập tự động giá cả, khuyến mãi và danh mục sản phẩm yêu cầu các yêu cầu thường xuyên, dễ dàng bị phát hiện qua IP lặp lại từ trung tâm dữ liệu.
• Tự động hóa kiểm tra quảng cáo — các nhà tiếp thị và các nhà quảng cáo thực hiện kiểm tra tự động trạng thái quảng cáo, số dư và các chỉ số thông qua các script trong CI/CD.
• Kiểm tra tích hợp với các dịch vụ bên ngoài — một số dịch vụ chặn các yêu cầu từ các dải Azure vì lý do bảo mật, và các bài kiểm tra sẽ bị lỗi mà không có lời giải thích.

Trong tất cả những trường hợp này, proxy giải quyết vấn đề một cách triệt để: workflow bắt đầu trông giống như một yêu cầu từ người dùng thông thường ở thành phố cần thiết, chứ không phải từ một máy chủ đám mây của Microsoft.

Cách GitHub Actions hoạt động với mạng

Trước khi cấu hình proxy, quan trọng là phải hiểu kiến trúc mạng trong GitHub Actions. Khi bạn chạy workflow trên runner ubuntu-latest tiêu chuẩn, nhiệm vụ được thực hiện trên một máy ảo trong cơ sở hạ tầng Microsoft Azure. Mỗi máy như vậy có một IP công cộng từ các dải Azure — và chính IP này được các dịch vụ bên ngoài nhìn thấy.

Những đặc điểm chính của mạng trong GitHub Actions:

• IP thay đổi mỗi khi khởi động — nhưng vẫn nằm trong các dải IP đã biết của Azure, dễ dàng bị phát hiện.
• Không có hỗ trợ proxy tích hợp — GitHub không cung cấp cơ chế bản địa để proxy hóa lưu lượng.
• Các biến môi trường hoạt động toàn cầu — nếu thiết lập HTTP_PROXY ở cấp job, tất cả các bước bên trong job này sẽ sử dụng proxy.
• Self-hosted runners — một lựa chọn khác, trong đó bạn chạy runner trên máy chủ của riêng bạn. Trong trường hợp này, proxy được cấu hình ở cấp máy chủ, không phải workflow.

Đối với hầu hết các nhiệm vụ, cách tiếp cận tối ưu là cấu hình proxy qua các biến môi trường ngay trong tệp workflow (.github/workflows/your-workflow.yml). Đây là phương pháp phổ quát, hoạt động cho hầu hết các công cụ: curl, wget, Python requests, Node.js http, Go net/http và các công cụ khác.

Loại proxy nào để chọn cho CI/CD

Việc chọn loại proxy phụ thuộc vào nhiệm vụ. Đối với các pipeline CI/CD, có ba tùy chọn phù hợp, mỗi loại có một vị trí riêng:

Quy tắc thực tiễn: nếu workflow của bạn phân tích Wildberries, Ozon hoặc các chợ trực tuyến khác với bảo vệ chống bot — hãy chọn proxy cư trú. Nếu bạn kiểm tra các tài khoản quảng cáo Facebook Ads hoặc TikTok Ads — hãy chọn proxy di động. Đối với các bài kiểm tra tích hợp đơn giản và yêu cầu đến các API mở, proxy trung tâm dữ liệu là đủ: chúng nhanh hơn và rẻ hơn.

Cấu hình proxy qua biến môi trường

Cách kết nối proxy trong GitHub Actions phổ biến nhất là thiết lập các biến môi trường chuẩn HTTP_PROXY, HTTPS_PROXY và NO_PROXY. Hầu hết các công cụ dòng lệnh và ngôn ngữ lập trình tự động nhận diện chúng.

Cấu trúc cơ bản của workflow với proxy như sau:

name: Workflow với Proxy

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: Checkout repository
        uses: actions/checkout@v4

      - name: Kiểm tra IP hiện tại (để kiểm tra)
        run: curl -s https://api.ipify.org

      - name: Chạy script chính
        run: python scripts/scraper.py

Lưu ý về khối NO_PROXY — cần thêm các địa chỉ mà không cần proxy hóa lưu lượng. Ít nhất là localhost và 127.0.0.1. Cũng nên thêm github.com, để các thao tác với kho (checkout, push) diễn ra trực tiếp.

Nếu proxy không cần xác thực (chỉ IP và cổng), định dạng sẽ đơn giản hơn:

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

Đối với proxy SOCKS5, chỉ cần thay đổi giao thức trong URL:

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

Proxy cho curl, wget và HTTP requests trong shell

Nếu các biến môi trường được thiết lập ở cấp job (như đã trình bày ở trên), curl và wget sẽ tự động nhận diện chúng. Nhưng đôi khi cần chỉ định proxy một cách rõ ràng — ví dụ, cho một bước cụ thể hoặc khi gỡ lỗi.

Chỉ định rõ ràng proxy trong curl:

- name: Lấy dữ liệu với proxy
  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

    # Kiểm tra qua proxy
    curl -x http://${{ secrets.PROXY_USER }}:${{ secrets.PROXY_PASS }}@${{ secrets.PROXY_HOST }}:${{ secrets.PROXY_PORT }} \
      -s https://api.ipify.org?format=json

Đối với wget:

- name: Tải xuống với wget qua proxy
  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

Một bước hữu ích để gỡ lỗi — thêm vào đầu workflow kiểm tra địa chỉ IP. Nếu proxy hoạt động chính xác, bạn sẽ thấy địa chỉ IP của máy chủ proxy, chứ không phải Azure:

- name: Xác minh proxy đang hoạt động
  run: |
    echo "=== IP không có proxy ==="
    curl -s --noproxy '*' https://api.ipify.org || echo "Yêu cầu trực tiếp thất bại"
    echo ""
    echo "=== IP qua proxy ==="
    curl -s https://api.ipify.org

Proxy trong các script Python bên trong workflow

Python là một trong những ngôn ngữ phổ biến nhất cho các script trong CI/CD. Thư viện requests tự động đọc các biến môi trường HTTP_PROXY và HTTPS_PROXY, nếu chúng được thiết lập. Nhưng để quản lý linh hoạt hơn, tốt hơn là truyền proxy một cách rõ ràng.

Ví dụ về script Python với việc truyền proxy rõ ràng qua các biến môi trường:

import os
import requests

# Đọc dữ liệu proxy từ các biến môi trường
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}',
}

# Sử dụng proxy trong yêu cầu
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"Trạng thái: {response.status_code}")
print(f"Chiều dài nội dung: {len(response.content)}")

Trong tệp workflow, cần truyền các biến như các bí mật riêng biệt (không phải dưới dạng URL đầy đủ), để script có thể thu thập chúng:

- name: Chạy scraper 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

Đối với việc làm việc với Playwright hoặc Selenium trong Python, cấu hình proxy hơi khác:

# 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")
    # ... logic tiếp theo
    browser.close()

Proxy trong Node.js và npm tasks

Node.js không tự động đọc các biến hệ thống HTTP_PROXY — bạn cần sử dụng các thư viện đặc biệt hoặc cấu hình proxy một cách rõ ràng. Tùy chọn thuận tiện nhất là gói https-proxy-agent hoặc axios với cấu hình proxy.

// Sử dụng 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(`Yêu cầu thất bại: ${error.message}`);
    throw error;
  }
}

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

Đối với các lệnh npm (ví dụ, nếu npm cố gắng tải xuống các gói qua proxy doanh nghiệp), cấu hình đơn giản hơn:

- name: Cấu hình proxy 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: Cài đặt các phụ thuộc
  run: npm install

- name: Đặt lại proxy npm (dọn dẹp sau khi sử dụng)
  run: |
    npm config delete proxy
    npm config delete https-proxy

Lưu trữ an toàn dữ liệu proxy trong GitHub Secrets

Không bao giờ lưu trữ dữ liệu proxy (host, port, tên đăng nhập, mật khẩu) trực tiếp trong tệp workflow dưới dạng văn bản rõ. Đây là một lỗi bảo mật nghiêm trọng: các tệp workflow được lưu trữ trong kho và có thể được nhìn thấy bởi tất cả các thành viên trong dự án hoặc thậm chí công khai.

Cách tiếp cận đúng là GitHub Secrets. Dưới đây là hướng dẫn từng bước:

1. Mở kho trên GitHub
2. Đi tới Cài đặt → Bí mật và biến → Hành động
3. Nhấn Bí mật kho mới
4. Tạo bốn bí mật: PROXY_HOST, PROXY_PORT, PROXY_USER, PROXY_PASS
5. Trong workflow, hãy tham chiếu đến chúng qua cú pháp ${{ secrets.PROXY_HOST }}

Nếu bạn sử dụng các proxy xoay vòng (khi IP thay đổi mỗi khi yêu cầu hoặc theo lịch), thường chỉ cần lưu trữ một endpoint duy nhất — nhà cung cấp proxy tự quản lý nhóm IP. Trong trường hợp này, trong các bí mật chỉ có một host và cổng của gateway xoay vòng.

Xoay vòng proxy và xử lý lỗi trong pipeline

Ngay cả các proxy chất lượng cũng đôi khi gặp sự cố: IP có thể bị tạm thời cấm, phiên có thể bị ngắt, máy chủ có thể không phản hồi. Đối với các pipeline CI/CD hoạt động tự động mà không có sự giám sát, điều quan trọng là phải dự đoán xử lý các tình huống như vậy.

Chiến lược 1: Retry với cùng một proxy

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"Cố gắng {attempt + 1} thất bại: {e}")
            if attempt < max_retries - 1:
                print(f"Thử lại trong {delay} giây...")
                time.sleep(delay)
                delay *= 2  # Đợi theo cấp số nhân
    raise Exception(f"Tất cả {max_retries} lần cố gắng đều thất bại cho {url}")

Chiến lược 2: Danh sách proxy với chuyển đổi

Nếu bạn có nhiều máy chủ proxy, có thể lưu trữ danh sách của chúng trong một bí mật (qua dấu phẩy) và chuyển đổi khi có lỗi:

import os
import requests
import random

# Bí mật PROXY_LIST chứa: "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)  # Thứ tự ngẫu nhiên
    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"Proxy thất bại: {e}, thử proxy tiếp theo...")
    raise Exception("Tất cả các proxy đều đã cạn kiệt")

Chiến lược 3: Sử dụng endpoint xoay vòng

Tùy chọn đơn giản nhất là sử dụng nhà cung cấp proxy với một gateway xoay vòng duy nhất. Trong trường hợp này, bạn kết nối với một địa chỉ, và nhà cung cấp tự động cung cấp các IP khác nhau từ nhóm. Không cần bất kỳ logic xoay vòng nào trong mã — chỉ cần một dòng kết nối.

Các kịch bản thực tế: phân tích, kiểm tra, giám sát giá

Hãy xem xét ba kịch bản cụ thể thường gặp ở các đội ngũ sử dụng GitHub Actions với proxy.

Kịch bản 1: Giám sát giá hàng ngày trên Wildberries

Các người bán trên các chợ trực tuyến thường thiết lập việc thu thập tự động giá cả của đối thủ. Workflow được khởi động theo lịch (ví dụ, mỗi sáng lúc 7:00), thu thập dữ liệu và lưu trữ chúng trong Google Sheets hoặc gửi đến Telegram.

name: Giám sát Giá Hàng Ngày

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: Cài đặt Python
        uses: actions/setup-python@v5
        with:
          python-version: '3.11'

      - name: Cài đặt các phụ thuộc
        run: pip install requests beautifulsoup4 gspread

      - name: Chạy scraper giá
        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: Tải lên artifact kết quả
        uses: actions/upload-artifact@v4
        with:
          name: price-data-${{ github.run_id }}
          path: output/prices.json

Kịch bản 2: Kiểm tra nhắm mục tiêu địa lý cho trang web

Các nhà tiếp thị và đội ngũ QA sử dụng proxy để kiểm tra cách trang web hoặc quảng cáo hiển thị cho người dùng từ các thành phố khác nhau. Điều này đặc biệt quan trọng để kiểm tra giá cả khu vực, nội dung và chuyển hướng.

name: Kiểm Tra Trang Web Nhắm Mục Tiêu Địa Lý

on:
  push:
    branches: [main]
  pull_request:

jobs:
  test-moscow:
    runs-on: ubuntu-latest
    name: Kiểm tra từ Moscow
    steps:
      - uses: actions/checkout@v4
      - name: Chạy kiểm tra địa lý (proxy RU/Moscow)
        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: Kiểm tra từ Đức
    steps:
      - uses: actions/checkout@v4
      - name: Chạy kiểm tra địa lý (proxy 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

Kịch bản 3: Kiểm tra tự động trạng thái tài khoản quảng cáo

Các nhà quảng cáo và các nhà tiếp thị hiệu suất thường sử dụng GitHub Actions để kiểm tra tự động trạng thái của các tài khoản quảng cáo Facebook Ads, số dư và các chỉ số. Các yêu cầu đến Facebook Marketing API từ các dải Azure có thể gây ra các kiểm tra bảo mật bổ sung — proxy giúp vượt qua điều này.

name: Kiểm Tra Sức Khỏe Tài Khoản Quảng Cáo

on:
  schedule:
    - cron: '*/30 6-22 * * *'  # Mỗi 30 phút từ 6 đến 22 MSK

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

    steps:
      - uses: actions/checkout@v4

      - name: Cài đặt Python
        uses: actions/setup-python@v5
        with:
          python-version: '3.11'

      - name: Cài đặt các phụ thuộc
        run: pip install requests

      - name: Kiểm tra các tài khoản 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

Kết luận

Cấu hình proxy trong GitHub Actions không phải là một nhiệm vụ khó khăn nếu biết cách tiếp cận đúng. Những điểm chính từ hướng dẫn này:

• Các biến môi trường HTTP_PROXY / HTTPS_PROXY — cách phổ quát hoạt động cho hầu hết các công cụ mà không cần thay đổi mã.
• GitHub Secrets — nơi duy nhất đúng để lưu trữ thông tin xác thực proxy.
• Loại proxy quan trọng: để phân tích các chợ trực tuyến bảo mật cần IP cư trú, cho các nền tảng quảng cáo — cần proxy di động, cho các yêu cầu API đơn giản có thể sử dụng proxy trung tâm dữ liệu.
• Logic retry là bắt buộc cho các pipeline hoạt động mà không có sự giám sát theo lịch.
• Bước kiểm tra IP ở đầu workflow sẽ tiết kiệm hàng giờ gỡ lỗi.

Nếu workflow GitHub Actions của bạn làm việc với các chợ trực tuyến, nền tảng quảng cáo hoặc bất kỳ dịch vụ nào có bảo vệ chống bot, chúng tôi khuyên bạn nên sử dụng proxy cư trú — chúng có IP thực tế từ người dùng hộ gia đình và hiếm khi bị chặn hơn so với các địa chỉ đám mây của máy chủ GitHub. Đối với các nhiệm vụ liên quan đến Facebook Ads, TikTok hoặc các nền tảng xã hội khác, lựa chọn tối ưu sẽ là proxy di động với IP từ nhà mạng — chúng cung cấp mức độ tin cậy tối đa từ các nền tảng.