How to fix remote: Your IP address is not allowed to access this resource in Git

First, find the public IP address GitHub sees when you connect. This is the address you will need to add to the allow list.

# IPv4 public address
curl -4 -s https://api.ipify.org && echo

# IPv6 public address (if your network has IPv6)
curl -6 -s https://api64.ipify.org && echo

# On Windows without curl
nslookup myip.opendns.com resolver1.opendns.com

Note both addresses if your network is dual-stack. Git may connect over IPv6 even when you expect IPv4, so the IPv6 address can matter (see the IPv6 step below). Record these to give to your administrator or to add yourself if you have admin access.

The quickest workaround is to connect from a network already on the allow list.

Option 1: Use your corporate VPN

# Connect to the company VPN, then confirm your new public IP
curl -4 -s https://api.ipify.org && echo

# Retry the Git operation
git pull origin main

Option 2: Work from the office network if it is on the allow list.

Option 3: Use an approved jump host

ssh [email protected]
cd /path/to/repo
git pull origin main

Verify connectivity to GitHub:

# SSH access
ssh -T [email protected]

# HTTPS access
git ls-remote https://github.com/org/repo.git

If you need regular access from your current location, ask an org or enterprise owner to add your IP.

Provide your administrator with:
- Your current public IP (from step 1)
- Whether the IP is static or dynamic
- A CIDR range if it is dynamic (see the CIDR step)
- The business justification

Organization owners - add an IP:
1. Go to your organization on GitHub
2. Settings > Authentication security
3. Find the IP allow list section and ensure it is enabled
4. Enter the address in IP address or range in CIDR notation
- Single IPv4: 203.0.113.50 (stored as 203.0.113.50/32)
- Range: 203.0.113.0/24
5. Add a description (e.g. "Jane home office") and click Add

Enterprise owners:
1. Profile photo > Your enterprises > select the enterprise
2. Settings > Authentication security > IP allow list
3. Add the address there

Changes can take a few minutes to take effect.

Standard GitHub-hosted runners use large, changing IP ranges that cannot be allow-listed, so CI jobs against an org with restrictions will fail. Move to runners with known, static egress IPs.

Self-hosted runners (recommended):

# .github/workflows/build.yml
jobs:
  build:
    runs-on: self-hosted   # your infrastructure, known egress IP
    steps:
      - uses: actions/checkout@v4

Register the runner on a host with a static IP:

# Use a token generated from the org/repo runner settings page
./config.sh --url https://github.com/your-org --token YOUR_RUNNER_REGISTRATION_TOKEN
./run.sh

Larger runners with a static IP: On GitHub Team/Enterprise you can assign a fixed public IP to larger runners in the org's Actions > Runners settings, then add that IP to the allow list. Selecting a larger runner label alone does not give a static IP - you must enable the static IP option for the runner group.

Then add the runner's egress IP to the allow list:

198.51.100.20/32   # self-hosted runner / NAT gateway

Other platforms (GitLab CI, Jenkins, CircleCI, Azure DevOps): run jobs on infrastructure with a fixed egress IP (often a NAT gateway) and add that IP/CIDR to the allow list.

If a GitHub App is being blocked, GitHub can automatically allow traffic from Apps that declare their own IP allow list.

App developers - declare the app's IPs:
1. Settings > Developer settings > GitHub Apps > select the app
2. Add the addresses your app runs from in the app's IP allow list field

Org owners - honor App IP allow lists:
1. Organization settings > Authentication security > IP allow list
2. Enable Enable IP allow list configuration for installed GitHub Apps

This only works if the App has published its own IP allow list. Otherwise add the App's egress IPs to the org allow list manually.

Verify API access from the App:

curl -H "Authorization: Bearer YOUR_APP_INSTALLATION_TOKEN" \
     -H "Accept: application/vnd.github+json" \
     https://api.github.com/orgs/YOUR_ORG/repos

If your IP changes frequently, ask for a CIDR range rather than re-adding single IPs.

Find your ISP's allocation:

MY_IP=$(curl -4 -s https://api.ipify.org)
echo "Current IP: $MY_IP"
whois "$MY_IP" | grep -Ei "CIDR|inetnum|NetRange|netname|descr"

CIDR sizes:
- /32 - single IPv4 address
- /24 - 256 addresses
- /16 - 65,536 addresses

Use the smallest range that reliably covers your address. Broad ranges (for example /8) weaken the protection the allow list provides, so avoid them unless absolutely necessary. If you need stability, ask your ISP about a static IP, which makes allow-list management far simpler.

If only your IPv4 address is on the allow list but your machine prefers IPv6 (or the reverse), Git can be blocked even though the "right" address is allowed. There is no git flag or http.ipversion config key to control this - address selection happens at the OS resolver level. Fix it by adding both addresses, or by forcing IPv4 at the OS/resolver level.

Best fix - add both addresses to the allow list:

203.0.113.50/32              # IPv4
2001:db8:85a3::8a2e/128      # IPv6

Force IPv4 system-wide on Linux (glibc resolver) by preferring IPv4 in /etc/gai.conf:

# /etc/gai.conf
precedence ::ffff:0:0/96  100

This makes the resolver hand back IPv4 addresses first for all programs, including git over HTTPS and SSH. No restart is needed; new connections pick it up.

Force IPv4 for a one-off test by pinning the resolved address:

# Confirm whether you reach GitHub over IPv6
curl -6 -sv https://github.com 2>&1 | head

# Test connectivity using an explicit IPv4 (curl supports --ipv4)
curl --ipv4 -sv https://github.com 2>&1 | head

Avoid disabling IPv6 entirely as a fix - it can break other services on the host. The durable solution is to add the correct address (IPv4 and/or IPv6) to the allow list.

If you administer the org, confirm the list is correct.

1. Organization settings > Authentication security > IP allow list
2. Confirm the allow list is enabled and review every entry
3. Use the Check IP address box: enter an IP and click Check to see whether it would be allowed

Common misconfigurations:
- List enabled but the user's IP never added
- Typo in an address, or text put in the description instead of the address field
- IPv4 entry while the user connects over IPv6
- Wrong CIDR (e.g. 203.0.113.0/24 intended but 203.0.113.100/32 entered)

Review the audit log to see allow-list changes:

Organization settings > Logs > Audit log
Filter: action:ip_allow_list

This shows when entries or the feature itself were added, removed, enabled, or disabled.