Google Cloud 會嘗試為靜態路徑尋找內部直通式網路負載平衡器，該路徑的下一個躍點內部直通式網路負載平衡器 IP 位址，會使用下列程序：
如果下一個躍點 IP 位址位於本機子網路路徑的目的地範圍內： Google Cloud 系統會專門搜尋轉送規則 IP 位址位於對應本機子網路的內部直通式網路負載平衡器。如果找到下一個躍點為內部直通式網路負載平衡器，則靜態路徑和下一個躍點都位於相同的虛擬私有雲端網路。
如果下一個躍點 IP 位址位於網路連線中心子網路路徑的目的地範圍內 (從中樞匯入)： Google Cloud 專門搜尋 Google Cloud 轉送規則 IP 位址位於另一個虛擬私有雲輪輻對應子網路的內部直通式網路負載平衡器。如果找到下一個躍點內部直通式網路負載平衡器，則靜態路徑位於一個虛擬私有雲輪輻，下一個躍點則位於另一個虛擬私有雲輪輻。
如果下一個躍點 IP 位址位於對等互連子網路路徑的目的地範圍內 (從使用 VPC 網路對等互連的其他網路匯入)：Google Cloud 系統會專門搜尋轉送規則 IP 位址位於對等互連 VPC 網路相應子網路中的內部直通式網路負載平衡器。如果找到下一個躍點內部直通式網路負載平衡器，則靜態路徑位於一個虛擬私有雲端網路，下一個躍點則位於對等互連的虛擬私有雲端網路。
如果找不到下一個躍點內部直通式網路負載平衡器，系統就會捨棄傳送至靜態路徑目的地範圍的封包。
更新下一個躍點內部直通式網路負載平衡器
Google Cloud 持續嘗試找出下一個躍點內部直通式網路負載平衡器。在下列範例情況中，靜態路徑的下一個躍點會自動更新。
取代下一個躍點內部直通式網路負載平衡器：如果靜態路徑的下一個躍點是內部直通式網路負載平衡器的 IP 位址，您可以刪除下一個躍點內部直通式網路負載平衡器，不必先刪除靜態路徑。如果 Google Cloud 找到 IP 位址相同的替代內部直通式網路負載平衡器， Google Cloud 會切換至替代內部直通式網路負載平衡器下一個躍點。
如果現有靜態路徑沒有有效的下一個躍點內部直通式網路負載平衡器，該路徑可以運作：找到有效的下一個躍點內部直通式網路負載平衡器後， Google Cloud就會開始使用該內部直通式網路負載平衡器下一個躍點。
調整 Network Connectivity Center 設定：將 VPC 輻式網路移至其他輻式網路群組，或調整匯出篩選器，可能會導致系統找不到下一個躍點內部直通式網路負載平衡器，或找到並使用其他下一個躍點內部直通式網路負載平衡器。
如果下一個躍點內部直通式網路負載平衡器未啟用全域存取權，就無法從負載平衡器所在區域以外的區域連線。如果 Google Cloud 已在指定的下一個躍點 IP 位址識別出下一個躍點負載平衡器，且符合網路連線中心連線需求，但負載平衡器未啟用全域存取權， Google Cloud 則會捨棄從 VM 執行個體、VLAN 連結和 Cloud VPN 通道傳送的所有封包，這些資源位於與負載平衡器區域不同的區域。
[[["容易理解","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-09-05 (世界標準時間)。"],[],[],null,["This document describes how Network Connectivity Center supports static routes in\nVPC spokes.\n\nBefore reading this page, ensure that you're familiar with the following resources:\n\n- [Routes](/vpc/docs/routes) for a general overview of routes in Google Cloud\n- [Static routes](/vpc/docs/static-routes) for an overview of static routes\n\nIntroduction\n\nUnlike subnet routes and dynamic routes, Network Connectivity Center hubs don't exchange\nstatic routes. Instead, a hub provides additional configuration flexibility for\nstatic routes created in each VPC spoke.\n\nA static route in one VPC spoke can use a next hop in a\ndifferent VPC spoke if all of the following are true:\n\n- The static route doesn't use a network tag.\n- The destination range of the static route is an IPv4 range.\n- The specified next hop of the static route is an IPv4 address of an internal passthrough Network Load Balancer.\n- Google Cloud is able to [identify a next hop\n internal passthrough Network Load Balancer](#identify-nh) at the specified next hop IP address.\n- [Network Connectivity Center connectivity requirements](#ncc-reqs) have been met.\n\nThe additional configuration flexibility for static routes applies only to\nVPC spokes, not to VPC networks that are purely\nrouting VPC networks (containing only hybrid spokes).\n\nFor a comparison to other types of static route next hops, see [Next hop\nproject and network](/vpc/docs/static-routes#static-route-next-hop-loc).\n\nIdentifying the next hop internal passthrough Network Load Balancer\n\nGoogle Cloud attempts to find an internal passthrough Network Load Balancer for a static route that\nhas a next hop internal passthrough Network Load Balancer IP address by using the following process:\n\n- If the next hop IP address is in the destination range of a local subnet\n route: Google Cloud exclusively searches for an internal passthrough Network Load Balancer whose\n forwarding rule IP address is in the corresponding local subnet. If a next\n hop internal passthrough Network Load Balancer is found, both the static route and next hop are in the\n same VPC network.\n\n- If the next hop IP address is in the destination range of a Network Connectivity Center\n subnet route (imported from the hub): Google Cloud exclusively searches\n for an internal passthrough Network Load Balancer whose forwarding rule IP address is in the corresponding\n subnet of another VPC spoke. If a next hop internal passthrough Network Load Balancer\n is found, the static route is in one VPC spoke, and the next\n hop is in a different VPC spoke.\n\n - For details about how an internal passthrough Network Load Balancer in another VPC spoke\n can be found, see [Network Connectivity Center requirements for\n connectivity](#ncc-reqs).\n\n - If you want to use a next hop internal passthrough Network Load Balancer in a routing\n VPC network (containing hybrid spokes), you must add the\n routing VPC network to the hub as a VPC\n spoke. For more limitations relevant to using a routing VPC\n network as a VPC spoke, see [Limitations of dynamic route\n exchange](/network-connectivity/docs/network-connectivity-center/concepts/vpc-spokes-overview#limitations-of-route-exchange).\n\n- If the next hop IP address is in the destination range of a peering subnet\n route (imported from another network that is using VPC Network Peering):\n Google Cloud exclusively searches for an internal passthrough Network Load Balancer whose forwarding\n rule IP address is in the corresponding subnet of the peered VPC\n network. If a next hop internal passthrough Network Load Balancer is found, the static route is in one\n VPC network, and the next hop is in the peered VPC\n network.\n\nIf no next hop internal passthrough Network Load Balancer is found, packets sent to the destination\nrange of the static route are dropped.\n\nUpdates to the next hop internal passthrough Network Load Balancer\n\nGoogle Cloud continuously attempts to identify a next hop internal passthrough Network Load Balancer.\nIn the following example situations, the next hop for a static route is updated\nautomatically.\n\n- Replacing the next hop internal passthrough Network Load Balancer: when the next hop for a static route is\n the IP address of an internal passthrough Network Load Balancer, you can delete the next hop internal passthrough Network Load Balancer\n without needing to first delete the static route. If Google Cloud finds a\n replacement internal passthrough Network Load Balancer with the same IP address, Google Cloud switches\n to the replacement internal passthrough Network Load Balancer next hop.\n\n- An existing static route without a valid next hop internal passthrough Network Load Balancer can become\n operational: when a valid next hop internal passthrough Network Load Balancer is found, Google Cloud\n begins using that internal passthrough Network Load Balancer next hop.\n\n- Adjusting Network Connectivity Center configuration: moving a VPC spoke to\n a different spoke group or adjusting export filters can result in a next hop\n internal passthrough Network Load Balancer no longer being found or a different next hop internal passthrough Network Load Balancer being\n found and used.\n\nNetwork Connectivity Center requirements for connectivity\n\nTo find a next hop internal passthrough Network Load Balancer in another VPC spoke, the\nsubnet used by the internal passthrough Network Load Balancer forwarding rule must be accessible in the\nVPC spoke where the static route is defined. Both the following\nconditions must be true:\n\n1. The [hub\n topology](/network-connectivity/docs/network-connectivity-center/concepts/connectivity-topologies)\n must allow exchange of subnet routes that contain the next hop internal passthrough Network Load Balancer.\n\n - If you use the mesh topology, all VPC spokes are part of the\n same spoke group. The static route can exist in any VPC\n spoke, and its next hop internal passthrough Network Load Balancer can exist in any VPC\n spoke.\n\n - If you use the star topology, the following requirements apply:\n\n - If the static route is in a VPC spoke of the edge\n spoke group, the next hop internal passthrough Network Load Balancer can be in that edge\n VPC spoke or in any VPC spoke of the\n center spoke group. The next hop can't be in a different\n VPC spoke of the edge spoke group.\n\n - If the static route is in a VPC spoke of the center\n spoke group, its next hop internal passthrough Network Load Balancer can be in any\n VPC spoke (in either the edge spoke group or the center\n spoke group).\n\n2. The subnet range used by the internal passthrough Network Load Balancer forwarding rule must be exported\n to the hub. For more information, see [VPC connectivity with\n export\n filters](/network-connectivity/docs/network-connectivity-center/concepts/vpc-spokes-overview#vpc-connectivity-with-export-filters).\n\nEffect of global access\n\nNext hop internal passthrough Network Load Balancers that don't have global access enabled aren't reachable\nfrom regions outside of the load balancer's region. If Google Cloud has\nidentified a next hop load balancer at the specified next hop IP address,\nand Network Connectivity Center connectivity requirements are met, but the load balancer\ndoesn't have global access enabled, Google Cloud drops all packets sent\nfrom VM instances, VLAN attachments, and Cloud VPN tunnels in regions\ndifferent from the load balancer's region.\n\nTo change this behavior and make the next hop load balancer reachable from all\nregions, [enable global\naccess](/load-balancing/docs/internal/setting-up-internal#ilb-global-access).\n\nWhat's next\n\n- [Configure static routes](/network-connectivity/docs/network-connectivity-center/how-to/configure-static-routes)"]]
