如果先前的查詢傳回空白結果，且 GKE Pod 無法與外部 IP 位址通訊，請參閱下表，排解設定問題：
設定
疑難排解
Cloud NAT 設定為僅適用於子網路的主要 IP 位址範圍。
如果只為子網路的主要 IP 位址範圍設定 Cloud NAT，從叢集傳送至外部 IP 位址的封包就必須具備來源節點 IP 位址。在這個 Cloud NAT 設定中：
如果外部 IP 位址目的地受到 IP 位址偽裝限制，Pod 就能將封包傳送到這些外部 IP 位址。部署 ip-masq-agent 時，請確認 nonMasqueradeCIDRs 清單不含目的地 IP 位址和通訊埠。傳送至這些目的地的封包會先轉換為來源節點 IP 位址，再由 Cloud NAT 處理。
如要允許 Pod 透過這項 Cloud NAT 設定連線至所有外部 IP 位址，請確認已部署 ip-masq-agent，且 nonMasqueradeCIDRs 清單只包含叢集的節點和 Pod IP 位址範圍。傳送至叢集外部目的地的封包，會先轉換為來源節點 IP 位址，再由 Cloud NAT 處理。
如要防止 Pod 將封包傳送至某些外部 IP 位址，您必須明確封鎖這些位址，以免遭到偽裝。部署 ip-masq-agent 後，請將要封鎖的外部 IP 位址新增至 nonMasqueradeCIDRs 清單。傳送至這些目的地的封包會離開節點，並保留原始的 Pod IP 位址來源。Pod IP 位址來自叢集子網路的次要 IP 位址範圍。在這個設定中，Cloud NAT 不會對該次要範圍運作。
設定 Cloud NAT，只套用至用於 Pod IP 的子網路次要 IP 位址範圍。
如果 Cloud NAT 僅針對叢集 Pod IP 使用的子網路次要 IP 位址範圍設定，則從叢集傳送至外部 IP 位址的封包必須具有來源 Pod IP 位址。在這個 Cloud NAT 設定中：
使用 IP 偽裝代理程式會導致封包在 Cloud NAT 處理時遺失來源 Pod IP 位址。如要保留來源 Pod IP 位址，請在 nonMasqueradeCIDRs 清單中指定目的地 IP 位址範圍。部署 ip-masq-agent 後，傳送至 nonMasqueradeCIDRs 清單上目的地的任何封包，都會在 Cloud NAT 處理前保留來源 Pod IP 位址。
如要允許 Pod 透過這項 Cloud NAT 設定連線至所有外部 IP 位址，請確保已部署 ip-masq-agent，且 nonMasqueradeCIDRs 清單盡可能擴大 (0.0.0.0/0 會指定所有 IP 位址目的地)。傳送至所有目的地的封包，在 Cloud NAT 處理前會保留來源 Pod IP 位址。
[[["容易理解","easyToUnderstand","thumb-up"],["確實解決了我的問題","solvedMyProblem","thumb-up"],["其他","otherUp","thumb-up"]],[["難以理解","hardToUnderstand","thumb-down"],["資訊或程式碼範例有誤","incorrectInformationOrSampleCode","thumb-down"],["缺少我需要的資訊/範例","missingTheInformationSamplesINeed","thumb-down"],["翻譯問題","translationIssue","thumb-down"],["其他","otherDown","thumb-down"]],["上次更新時間：2025-07-15 (世界標準時間)。"],[],[],null,["# Troubleshoot Cloud NAT packet loss from a cluster\n\n[Standard](/kubernetes-engine/docs/concepts/choose-cluster-mode)\n\n*** ** * ** ***\n\nThis page shows you how to resolve issues with [Cloud NAT](/nat/docs/overview)\npacket loss from a [VPC-native](/kubernetes-engine/docs/concepts/alias-ips)\nGoogle Kubernetes Engine (GKE) cluster with private nodes enabled.\n\nNode VMs in VPC-native GKE clusters with private nodes\ndon't have external IP addresses. This means that clients on the internet cannot\nconnect to the IP addresses of the nodes. You can use Cloud NAT to allocate\nthe external IP addresses and ports that allow clusters with private nodes to make public\nconnections.\n\nIf a node VM runs out of its allocation of external ports and IP addresses from\nCloud NAT, packets will drop. To avoid this, you can reduce the\noutbound packet rate or increase the allocation of available\nCloud NAT source IP addresses and ports. The following\nsections describe how to diagnose and troubleshoot packet loss from\nCloud NAT in the context of GKE clusters with private nodes.\n\nDiagnose packet loss\n--------------------\n\nThe following sections explains how to log dropped packets using\nCloud Logging, and diagnose the cause of dropped packets using\nCloud Monitoring.\n\n### Log dropped packets\n\nYou can log dropped packets with the following query in Cloud Logging: \n\n```\nresource.type=\"nat_gateway\"\nresource.labels.region=REGION\nresource.labels.gateway_name=GATEWAY_NAME\njsonPayload.allocation_status=\"DROPPED\"\n```\n\nReplace the following:\n\n- \u003cvar translate=\"no\"\u003eREGION\u003c/var\u003e: the name of the region that the cluster is in.\n- \u003cvar translate=\"no\"\u003eGATEWAY_NAME\u003c/var\u003e: the name of the Cloud NAT gateway.\n\nThis command returns a list of all packets dropped by a Cloud NAT gateway,\nbut does not identify the cause.\n\n### Monitor causes for packet loss\n\nTo identify causes for dropped packets, query the\n[Metrics observer](https://console.cloud.google.com/monitoring/metrics-explorer) in\nCloud Monitoring. Packets drop for one of three reasons:\n\n- `OUT_OF_RESOURCES`\n- `ENDPOINT_INDEPENDENT_CONFLICT`\n- `NAT_ALLOCATION_FAILED`\n\nTo identify packets dropped due to `OUT_OF_RESOURCES` or\n`ENDPOINT_ALLOCATION_FAILED` error codes, use the following query: \n\n```\nfetch nat_gateway\n metric 'router.googleapis.com/nat/dropped_sent_packets_count'\n filter (resource.gateway_name == GATEWAY_NAME)\n align rate(1m)\n every 1m\n group_by [metric.reason],\n [value_dropped_sent_packets_count_aggregate:\n aggregate(value.dropped_sent_packets_count)]\n```\n\nIf you identify packets that drop because of these reasons, see\n[Packets dropped with reason: out of resources](/nat/docs/troubleshooting#insufficient-ports) and\n[Packets dropped with reason: endpoint independent conflict](/nat/docs/troubleshooting#endpoint-independent-conflict)\nfor troubleshooting advice.\n\nTo identify packets dropped due to the `NAT_ALLOCATION_FAILED` error code, use\nthe following query: \n\n```\nfetch nat_gateway\n metric 'router.googleapis.com/nat/nat_allocation_failed'\n group_by 1m,\n [value_nat_allocation_failed_count_true:\n count_true(value.nat_allocation_failed)]\n every 1m\n```\n\nIf you identify packets that dropped for this reason, see\n[Need to allocate more IP addresses](/nat/docs/troubleshooting#allocate-more-IPs).\n\n### Investigate Cloud NAT configuration\n\nIf the previous queries return empty results, and GKE Pods are\nunable to communicate to external IP addresses, use the following table to\nhelp you troubleshoot your configuration:\n\nReduce packet loss\n------------------\n\nAfter you have diagnosed the cause of your packet loss, consider using the\nfollowing recommendations to reduce the likelihood of the issue from recurring\nin the future:\n\n- Configure the Cloud NAT gateway to use\n [dynamic port allocation](/nat/docs/ports-and-addresses#dynamic-port) and\n [increase the maximum number of ports per VM](/nat/docs/tune-nat-configuration#change-dynamic-port).\n\n- If you're using\n [static port allocation](/nat/docs/ports-and-addresses#static-port),\n [increase the number of minimum ports per VM](/nat/docs/tune-nat-configuration#change-min-port).\n\n- Reduce your application's outbound packet rate. When an application makes\n multiple outbound connections to the same destination IP address and port,\n it can quickly consume all connections Cloud NAT can make to that\n destination using the number of allocated NAT source addresses and source\n port tuples.\n\n For details about how Cloud NAT uses NAT source addresses and\n source ports to make connections, including limits on the number of\n simultaneous connections to a destination, refer to [Ports and\n connections](/nat/docs/ports-and-addresses#ports-and-connections).\n\n To reduce the rate of outbound connections from the application, reuse open\n connections. Common methods of reusing connections include connection\n pooling, multiplexing connections using protocols such as\n [HTTP/2](https://datatracker.ietf.org/doc/html/rfc7540), or establishing\n persistent connections reused for multiple requests. For more information,\n see [Ports and\n Connections](/nat/docs/ports-and-addresses#ports-and-connections).\n\nWhat's next\n-----------\n\n- If you can't find a solution to your problem in the documentation, see\n [Get support](/kubernetes-engine/docs/getting-support) for further help,\n including advice on the following topics:\n\n - Opening a support case by contacting [Cloud Customer Care](/support-hub).\n - Getting support from the community by [asking questions on StackOverflow](http://stackoverflow.com/questions/tagged/google-kubernetes-engine) and using the `google-kubernetes-engine` tag to search for similar issues. You can also join the [`#kubernetes-engine` Slack channel](https://googlecloud-community.slack.com/messages/C0B9GKTKJ/) for more community support.\n - Opening bugs or feature requests by using the [public issue tracker](/support/docs/issue-trackers)."]]
