Bundler "Net::OpenTimeout" Fetching Gems in CI

Bundler could not open a connection to the gem source before the timeout elapsed. Net::OpenTimeout is raised at the TCP-connect stage, before any data transfers - a transient network condition that usually clears on retry.

What this error means

bundle install stalls while connecting to rubygems.org and fails with an underlying Net::OpenTimeout (often shown as "execution expired"). The same job typically passes on a re-run.

Retrying fetcher due to error (3/4): Bundler::HTTPError Could not fetch specs
from https://rubygems.org/ due to underlying error <Net::OpenTimeout:
execution expired (https://index.rubygems.org/versions)>

Common causes

Transient network or DNS slowness

The runner could not establish the TCP connection in time - a brief network blip, slow DNS, or a congested egress path. It is timing, not configuration.

Egress through a slow proxy or firewall

A proxy or firewall in front of the runner adds latency to connection setup, occasionally pushing it past Bundler’s connect timeout.

How to fix it

Retry and raise the timeout

More attempts plus a longer connect budget absorb a transient slow connection.

bundle config set --global retry 5
bundle config set --global timeout 60
bundle install

Confirm and configure egress

1. Verify the runner can reach rubygems.org (curl -I https://rubygems.org).
2. If traffic goes through a proxy, set https_proxy/HTTPS_PROXY so Bundler uses it.
3. For locked-down networks, point Bundler at an internal mirror it can reach quickly.

How to prevent it

• Set a Bundler retry count and a generous timeout in CI.
• Cache vendor/bundle so most installs do not hit the network.
• Use a closer mirror or pull-through cache to cut connection latency.

Related guides