GitLab.com Webhook白名单配置问题：AWS VPC NACL仅放行指定IP段后GitLab Runner无法正常连接

Let’s break down why your GitLab Runner is stuck even after adding the official GitLab/Cloudflare IP ranges to your public subnet NACL, and how to fix it:

1. Verify You’re Not Missing GitLab’s Active IPs #

First, check if the IP addresses your Runner is trying to reach are actually in the ranges you added. On your Runner instance, run:

dig gitlab.com +short
dig registry.gitlab.com +short

Compare these IPs against your NACL allowed ranges. GitLab occasionally updates their IP lists, so it’s possible the official docs you referenced are slightly outdated, or you missed ranges for auxiliary services like the container registry or LFS storage.

2. Check NACL Rule Priority #

AWS NACLs evaluate rules in order of their rule number—lower numbers run first. If you have a deny 0.0.0.0/0 rule (common as a default catch-all) that comes before your allow rules for GitLab IPs, it’ll block the traffic before the allow rules take effect.

Fix this by:

• Moving all your GitLab IP allow rules to lower numbers (e.g., 100, 200, 300)
• Ensuring the final catch-all deny rule has a much higher number (e.g., 1000)

3. Confirm Return Traffic Is Allowed #

While your outbound NACL allows 0.0.0.0/0, return traffic from GitLab to your Runner falls under inbound NACL rules. Make sure the source IPs of these return packets (which are GitLab’s service IPs) are included in your allowed inbound ranges. This should already be covered if you added the full GitLab/Cloudflare ranges, but it’s worth double-checking if you trimmed any ranges.

4. Validate Runner Instance Connectivity #

On your Runner instance, run a direct connectivity test to rule out other issues:

# Test HTTPS access to GitLab
curl -v https://gitlab.com/api/v4/projects
# Test container registry access (if your jobs use it)
curl -v https://registry.gitlab.com

If these commands time out, it confirms the traffic is being blocked by NACL. If they connect successfully, the issue might be with your Runner’s CI/CD job configuration (e.g., private modules, external dependencies not covered by the IP ranges).

5. Check for Hidden Dependencies #

Some CI/CD jobs pull dependencies from external sources (e.g., npm, PyPI) that aren’t hosted on GitLab. If your jobs rely on these, you’ll need to add those services’ IP ranges to your NACL too—but since you mentioned jobs work when 0.0.0.0/0 is allowed, this is less likely the main issue unless your jobs specifically call non-GitLab services.

Quick Recap of Fixes #

• Update your NACL with the latest GitLab IP ranges (double-check the official list for all services)
• Reorder NACL rules so allow rules take priority over deny rules
• Verify the actual IPs GitLab resolves to are in your allowed ranges

内容的提问来源于stack exchange，提问作者Frankster