Service eligibility and regional restrictions
PuppyIP serves only compliant overseas businesses and their authorized personnel. Proxy services are not available in mainland China. The service may only be used for lawful business activities outside mainland China. Use of this service within mainland China is prohibited.
Hosting a proxy IP or server overseas does not change these restrictions. The service must not be provided to end users in mainland China through relaying, forwarding, sharing or resale. Before use, read the Terms of Service.
Key Takeaways
- Microsoft's October 7 announcement asks classic-tier internal/external VNet users to review NSGs, UDRs and firewalls by November 30, 2026. It specifies no timezone or cutover time.
- The additional control-plane IPs are included in the ApiManagement service tag. Replace hard-coded management IPs where tags are supported; firewalls without tag support need rules synchronized with the latest official address list.
- The VNet reference lists management access as inbound TCP 3443 from ApiManagement to VirtualNetwork for both internal and external modes. This differs from the external-mode client HTTPS 443 rule.
- The announcement explicitly limits this change to the management plane and says runtime API calls are unaffected. It does not establish one network-change requirement for all Azure services or all v2 tiers.
Confirm the classic tier, VNet mode and deadline
Microsoft's October 7, 2026 announcement says Azure API Management is adding control-plane IP addresses to improve resiliency and scalability. These addresses are included in the ApiManagement service tag. The announcement's body addresses classic (v1) instances using VNet internal or VNet external mode and asks teams to make the relevant network-rule changes by November 30, 2026.
The accompanying VNet configuration reference explicitly applies to VNet injection in the classic Developer and Premium tiers, with Premium v2 injection documented separately. Record the instance's tier and internal or external mode before deciding whether these management-endpoint rules apply. Do not apply them automatically to every v2 instance. The announcement gives a deadline date, but no hour, timezone or regional IP activation schedule.
Separate management access from runtime API calls
The announcement warns that rules blocking the management endpoint after the deadline could prevent teams from managing API Management configuration, including APIs, operations and policies, through the Azure portal or CLI. The review therefore concerns control-plane connectivity and the rules along its path, rather than only whether business requests succeed.
Microsoft explicitly says this change affects management-plane traffic only and does not impact runtime traffic, including API calls to your services. That scope statement is not a guarantee of runtime health for an arbitrary instance. If business APIs are failing, investigate their actual responses and network evidence separately rather than attributing the failure to this announcement alone.
Find every rule that contains fixed management IPs
For each instance, inventory the relevant network security groups (NSGs), user-defined routes (UDRs) and firewalls. Identify entries containing hard-coded API Management IP addresses. Record each rule's purpose, scope and owner so that changing one NSG does not leave a fixed-address restriction elsewhere on the path.
The announcement asks teams to replace hard-coded addresses with the ApiManagement service tag wherever supported. The rule location must actually support service tags; the same configuration cannot be assumed to work in every route or third-party firewall. During the transition, the tag includes both existing and new addresses. This does not establish that a particular old address can already be removed.
Check the direction and source for 3443, separately from client 443
The official VNet reference lists the management-endpoint rule as inbound TCP 3443, with source ApiManagement and destination VirtualNetwork, for both internal and external VNet modes. Check the direction, source tag, destination network and port together. Finding a matching port number alone does not establish that the rule is correct.
The same table separately lists client communication for external mode, including HTTPS 443 from Internet to VirtualNetwork. That is not the management-plane 3443 rule. Opening the management port to the entire Internet is not a requirement stated in this announcement. Preserve the distinct purposes of other existing network dependencies instead of reducing this review to a single allow rule.
Plan address synchronization for firewalls without tag support
The announcement points to Microsoft's Azure service tags overview and Azure IP Ranges and Service Tags JSON download as official places to find ApiManagement addresses. If a firewall does not support service tags, Microsoft asks teams to use the published list and keep IP rules synchronized with its latest version, rather than relying on a fixed snapshot downloaded at one point in time.
Record the list's source, an update owner and a way to review changes. Preserve the previous configuration and rollback arrangements through your organization's existing process. The announcement gives no exact activation schedule for every additional IP, so treat address synchronization as ongoing work.
A hypothetical example: working APIs do not complete the management review
Suppose a classic Premium instance uses internal VNet mode. Business APIs remain reachable, but a firewall allows only a previously saved set of management IPs. Successful business calls do not prove that the additional control-plane addresses are permitted. This hypothetical example illustrates the difference between the two traffic paths; it is not a reported customer incident.
Return to the instance's actual path: review the ApiManagement source and TCP 3443 management rule, locate hard-coded addresses and confirm whether service tags are supported. Where they are not, arrange ongoing address synchronization. Assign owners for the change and subsequent verification, and complete applicable rule changes by November 30 rather than waiting for a management operation to fail.
Sources
Frequently Asked Questions
Must every Premium v2 instance use this same port table?
No. The announcement's body addresses classic (v1) tiers in internal or external VNet mode. The accompanying reference applies to classic Developer/Premium VNet injection and documents Premium v2 separately. Use the documentation for the instance's actual tier and network configuration rather than extending classic-tier requirements to all v2 deployments.
Does saving an official IP list once complete the review?
Not necessarily. The announcement explicitly asks firewalls without service-tag support to stay synchronized with the latest published list, rather than relying on a snapshot. Also check that the list feeds the correct management-traffic rules and that someone owns future updates. A one-time download does not prove that subsequent addresses will enter your firewall automatically.
Can I keep only the 3443 rule and remove other outbound and DNS rules?
This announcement provides no basis for doing so. The VNet configuration reference also lists dependencies such as DNS, certificate validation and storage, with requirements depending on the deployment and features. Port 3443 identifies the management endpoint reviewed here; it is not a complete VNet dependency list or a reason to delete other existing rules.