Dependabot hangs when checking nuget packages

[niels-vd-k]

🏷️ Discussion Type

Question

💬 Feature/Topic Area

ARC (Actions Runner Controller)

Discussion Details

Hey,

Not sure if this belongs here or in dependabot-core but I figured I'll start here and see where that gets me.

I'm trying to set up Dependabot using my own self-hosted action runner set. For OpenTofu and NPM packages this already works great, but when I try to have it check for nuget packages it seems to get stuck in a loop because it can't access the nuget API;

proxy | 2026/09/16 10:49:45 [018] GET [https://api.nuget.org:443/v3/index.json](https://api.nuget.org/v3/index.json)
proxy | 2026/09/16 10:50:03 [020] POST [https://dc.services.visualstudio.com:443/v2/track](https://dc.services.visualstudio.com/v2/track)
proxy | 2026/09/16 10:50:04 [020] 200 [https://dc.services.visualstudio.com:443/v2/track](https://dc.services.visualstudio.com/v2/track)
proxy | 2026/09/16 10:50:31 Posting metrics to remote API endpoint
proxy | 2026/09/16 10:50:32 Successfully posted metrics data via api client
proxy | 2026/09/16 10:51:26 [022] GET [https://api.nuget.org:443/v3/index.json](https://api.nuget.org/v3/index.json)
proxy | 2026/09/16 10:51:31 Posting metrics to remote API endpoint
proxy | 2026/09/16 10:51:32 Successfully posted metrics data via api client
proxy | 2026/09/16 10:51:53 [018] WARN: Cannot read response from mitm'd server read tcp 172.18.0.2:47196->150.171.109.34:443: read: connection reset by peer
proxy | 2026/09/16 10:53:07 [024] GET [https://api.nuget.org:443/v3/index.json](https://api.nuget.org/v3/index.json)
proxy | 2026/09/16 10:53:18 [022] WARN: Cannot read response from mitm'd server read tcp 172.18.0.2:52934->150.171.109.34:443: read: connection reset by peer
proxy | 2026/09/16 10:53:31 Posting metrics to remote API endpoint
proxy | 2026/09/16 10:53:32 Successfully posted metrics data via api client
proxy | 2026/09/16 10:54:48 [026] GET [https://api.nuget.org:443/v3/index.json](https://api.nuget.org/v3/index.json)

As far as I can tell this seems to be a networking issue related to DIND, which I guess might mean that I'm installing ARC incorrectly somehow? I've installed it as follows;

echo "Installing controller..."
helm install arc oci://ghcr.io/actions/actions-runner-controller-charts/gha-runner-scale-set-controller \
    --namespace "arc-systems" \
    --version="0.14.2" \
    --create-namespace

kubectl create namespace arc-runners
kubectl create secret generic github-arc-secret \
   --namespace="arc-runners" \
   --from-literal=github_app_id=$APP_ID \
   --from-literal=github_app_installation_id=$INSTALL_ID \
   --from-file=github_app_private_key=$PEM_FILE

helm install arc-runner-set oci://ghcr.io/actions/actions-runner-controller-charts/gha-runner-scale-set \
    --namespace "arc-runners" \
    --version="0.14.2" \
    --set githubConfigUrl="https://github.com/notilyze" \
    --set githubConfigSecret="github-arc-secret" \
    --set scaleSetLabels[0]=arc-runner-set \
    --set scaleSetLabels[1]=dependabot \
    --set containerMode.type="dind"

My dependabot.yml is very simple;

version: 2

updates:
  - package-ecosystem: "nuget"
    directory: "/"
    target-branch: development
    schedule:
      interval: "weekly"

  - package-ecosystem: "npm"
    directory: "/TestProject"
    target-branch: development
    schedule:
      interval: "weekly"

Does anyone have any idea what I might be doing wrong? Or is this maybe a bug within dependabot somehow?

Thanks in advance.

[RaJharit77]

Maybe it's a bug ?

[felipebridge]

This one's a known rough edge with self-hosted Dependabot + ARC in dind mode, and it's worth knowing upfront: this isn't really a "community" bug, it lives in dependabot-core (the actual updater code), not in this repo. Worth searching/filing there directly — issues tagged nuget + connection reset + self-hosted do show up periodically and get real engineering attention, which a discussion here won't get.

On the "connection reset by peer" specifically: that's the dependabot proxy sidecar's own MITM layer failing mid-TLS-handshake with api.nuget.org, not your dependabot.yml (which looks fine as-is — no registries block needed for public nuget.org). A few things worth isolating before assuming it's ARC misconfiguration:

Is it network-level or proxy-level? Shell into the job pod and curl -v https://api.nuget.org/v3/index.json directly, bypassing the dependabot proxy entirely. If that also resets, it's your cluster's egress path (CNI MTU mismatch is a classic dind-on-k8s gotcha — Calico/Flannel default to 1450 vs the host's 1500, and large TLS server-hello / cert-chain packets from nuget.org's CDN get fragmented and dropped, which shows up as a reset rather than a timeout). If curl works fine but the proxy still resets, it's the mitm proxy sidecar specifically.

Resource starvation on the proxy container: dind mode runs an extra proxy sidecar per job, and ARC's default resource requests/limits are tuned for the runner, not for a proxy doing TLS termination on every registry call. If that pod is getting CPU-throttled, it can be slow enough to trip nuget.org's/Front Door's own idle-connection reset on their end. Worth checking if bumping requests/limits on the runner pod changes anything, since NPM and OpenTofu working fine doesn't rule this out — nuget.org's index response is notably larger than a typical npm registry call.

If you rule both of those out, it really is worth opening it as an issue on dependabot-core with these exact proxy logs — that's the team that owns this code path.