> ## Documentation Index
> Fetch the complete documentation index at: https://docs.coreweave.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Why are my Tailscale proxy Pods in CrashLoopBackOff?

Tailscale proxy Pods can enter `CrashLoopBackOff` when carrier-grade network address translation (CGNAT) filtering prevents access to the Kubernetes API. Start with the affected Pod's logs to distinguish this connectivity problem from other causes. Then check its configuration and rollout.

In the following commands, replace `[NAMESPACE]` with the operator's namespace, `[PROXY-POD]` with the affected proxy Pod, and `[STATEFULSET]` with its owning StatefulSet. The chart guide uses the `tailscale` namespace.

## Check the proxy logs

To inspect the failure that caused a restart, read the previous container's logs:

```bash theme={"system"}
kubectl logs --namespace "[NAMESPACE]" "[PROXY-POD]" --container tailscale --previous
```

Connection timeouts to `kubernetes.default.svc` or the API server ClusterIP can indicate a CGNAT configuration problem. These timeouts can appear during permission checks or reads of the proxy's state Secret. A timeout while checking permissions doesn't establish that Kubernetes denied access. If the logs report a permissions denial or an out-of-memory failure, investigate that error separately.

## Check the carrier-grade NAT configuration

Tailscale's CGNAT drop rule matches traffic from `100.64.0.0/10` arriving outside the Tailscale interface. CoreWeave Kubernetes Service (CKS) uses `100.124.0.0/18` within that range for internal services. This filtering can prevent a proxy from reaching the Kubernetes API.

CoreWeave's customized proxy image supports `TS_CGNAT_OVERRIDE_RANGE` to exempt the CKS range from this drop rule. This setting is separate from the [Tailnet `ipPool`](/products/cks/clusters/coreweave-charts/tailscale-operator#tailnet-ippool), which controls address allocation to Tailnet devices.

Check the configuration in your Helm values or GitOps repository:

1. Use CoreWeave's [`tailscale-operator` chart and customized images](/products/cks/clusters/coreweave-charts/tailscale-operator). If an image doesn't implement the extension, setting `TS_CGNAT_OVERRIDE_RANGE` doesn't provide the exemption.
2. Identify the ProxyClass selected by the resource that creates the failing proxy. The chart supplies a default ProxyClass with the override, but a resource-specific class replaces that selection rather than inheriting its settings.
3. In the selected ProxyClass, set `TS_CGNAT_OVERRIDE_RANGE` to `100.124.0.0/18` while preserving its other configuration. Apply the change through your deployment's source of truth.

The override belongs in the proxy container's environment configuration:

```yaml title="ProxyClass specification excerpt" theme={"system"}
spec:
  statefulSet:
    pod:
      tailscaleContainer:
        env:
          - name: TS_CGNAT_OVERRIDE_RANGE
            value: "100.124.0.0/18"
```

API-server health problems can coexist with a Tailscale configuration problem. If other workloads also lose API access, investigate the control plane as well.

## Check the rollout before recreating a Pod

The operator reconciles ProxyClass changes into the proxy's StatefulSet. Environment changes require replacement Pods, and StatefulSets use rolling updates by default.

Before recreating a Pod, confirm that the StatefulSet's Pod template contains the corrected proxy image and environment configuration. Inspect the rollout and affected Pod for errors:

```bash theme={"system"}
kubectl get statefulset --namespace "[NAMESPACE]" "[STATEFULSET]" -o yaml
kubectl rollout status statefulset/"[STATEFULSET]" --namespace "[NAMESPACE]" --timeout=120s
kubectl describe pod --namespace "[NAMESPACE]" "[PROXY-POD]"
```

If a failed rollout remains blocked after the template is corrected, recreate only the affected proxy Pod. Recreation can interrupt traffic through that proxy:

```bash theme={"system"}
kubectl delete pod --namespace "[NAMESPACE]" "[PROXY-POD]"
```

Check that the replacement Pod becomes `Ready` and its logs no longer show the API connection timeouts:

```bash theme={"system"}
kubectl get pod --namespace "[NAMESPACE]" "[PROXY-POD]"
kubectl logs --namespace "[NAMESPACE]" "[PROXY-POD]" --container tailscale
```

## Check image versions if crashes continue

If API connectivity is restored but the proxy still crashes, inspect the current error and compare the running operator and proxy images with your intended chart configuration:

```bash theme={"system"}
kubectl get pods --namespace "[NAMESPACE]" \
  -o custom-columns='NAME:.metadata.name,IMAGES:.spec.containers[*].image'
```

Check for custom image tags or digests in Helm values and the selected ProxyClass. These can override chart defaults, so a chart upgrade alone doesn't establish that every proxy image changed. Apply any upgrade through your Helm or GitOps configuration and verify the resulting images and rollout.

If the Pods still crash, [contact Support](/support/contact) with the Pod logs, chart version, running images, and relevant ProxyClass configuration.

***

<Badge stroke shape="pill" color="blue" size="md">[Server Errors](/support/cks/tags/server-errors)</Badge>


## Related topics

- [Tailscale Operator](/products/cks/clusters/coreweave-charts/tailscale-operator.md)