Network connectivity FAQ

Cannot open websites with IE on Windows instances

If you cannot open websites by using Internet Explorer after you log on to a Windows instance, see Cannot access external websites with Internet Explorer on a Windows instance.

Access blocked by security threat message

• Symptom: When you access a website that is deployed on an ECS instance, the message "Sorry, your access is blocked because the URL may pose a security threat to the website" is displayed.

• Cause: The Security Center application firewall identifies your URL access as an attack and blocks it.

• Solution: Add your local public IP address to the application firewall whitelist in Security Center. For more information, see Use a whitelist to resolve IP address blocking due to false positives.

Internet access failure with secondary private IP

• Symptom: A Windows instance cannot access the Internet after a secondary private IP address is configured for the instance.

• Cause: In Windows Server 2008 and later, the outbound IP address selection policy is changed to select the IP address that has the shortest prefix match with the next-hop IP address. This may cause network connection failures.

• Solution: Use the Netsh command to configure the secondary private IP address and set the skipassource parameter to true.

  The command is as follows:

  Netsh int ipv4 add address <Interface> <IP Addr> [<Netmask>] [skipassource=true]

  The following table describes the parameters.

  Secondary IP information	Description	Example
  <Interface>	The network interface for the secondary private IP address.	'Ethernet'
  <IP Addr>	The secondary private IP address.	192.168.0.100
  <Netmask>	The subnet mask of the secondary private IP address.	255.255.255.0

  The following example shows how to configure a secondary private IP address by using Netsh:

  Netsh int ipv4 add address 'Ethernet' 192.168.0.100 255.255.255.0 skipassource=true

IP address blocking in Security Center

Applying for reverse DNS lookup

Reverse DNS lookup, often used for email services, helps reduce spam. It works by rejecting messages from IP addresses without a registered domain name, a common tactic used by spammers. You can configure your mail server to perform this check.

To apply for reverse DNS lookup, submit a ticket. To accelerate processing, include the region, public IP address, and registered domain name of your ECS instance in the ticket.

To apply for a reverse DNS lookup, submit a ticket. In the ticket, specify the region, public IP address, and registered domain name of the ECS instance to accelerate the processing.

dig -x 121.196.255.** +trace +nodnssec

1.255.196.121.in-addr.arpa. 3600 IN PTR ops.alidns.com.

Multiple reverse DNS lookups per IP

No, an IP address can map to only one reverse DNS lookup domain name. For example, you cannot configure mail.abc.com, mail.ospf.com, and mail.zebra.com as reverse DNS lookups for the same IP address 121.196.255.**.

What is a security group?

A security group is a virtual firewall that controls inbound and outbound traffic for ECS instances. You can place instances that have the same security requirements and trust each other into the same security group to create security domains and ensure the security of your cloud resources.

Each ECS instance must belong to at least one security group. Rules from all associated groups are evaluated by priority to allow or deny traffic.

For more information, see Security group overview.

Creating an instance without a security group

If no security groups exist in the VPC where you want to create the ECS instance, the system creates a default security group when you create the instance. For more information, see Default security groups.

Troubleshooting rule quota exceeded errors

The total number of inbound and outbound rules across all security groups that are associated with a single elastic network interface of an ECS instance cannot exceed 1,000.

If the The operation cannot be performed because the maximum number of security group rules that can take effect on the instance is reached. message appears, the total number of rules on the instance has exceeded the quota. We recommend that you check for and remove redundant security group rules.

Use cases for default security group rules

Default security group rules are used in the following circumstances:

• Use the default rules of a default security group: When you create an ECS instance in a region for the first time in the ECS console, if you have not created a security group, you can select the default basic security group that is automatically created by the system. The default security group uses default security rules. The inbound rules allow traffic over ICMP (IPv4), SSH on TCP port 22, and RDP on TCP port 3389 from all CIDR blocks (0.0.0.0/0). The priority of the rules is 100. You can also select to allow traffic over HTTP port 80 and HTTPS port 443. The outbound rules allow all traffic. For more information, see Default security groups.

  Important

  The default rules allow access from all IP addresses (0.0.0.0/0) on SSH port 22, RDP port 3389, and all ICMP ports. This exposes ECS instances to brute-force attacks and other security risks. We recommend that you restrict access to specific IP addresses and create custom security groups or modify the default rules based on your business requirements.

• Create a security group that uses default rules: When you create a security group in the ECS console, the default security group rules allow inbound traffic over ICMP (IPv4) and from all CIDR blocks (0.0.0.0/0) on TCP ports 22 (SSH), 3389 (RDP), 80 (HTTP), and 443 (HTTPS).

You can query security group rules in the ECS console or by calling an API operation. For more information, see Query security group rules.

Internal communication between security groups

For more information about use cases in which you want to enable internal network communication between different security groups, see Case 5: Enable internal network communication between instances in different security groups.

Instance isolation within a security group

In a basic security group, instances in the same group can access each other over the internal network by default. You can change this by modifying the internal access policy. In an advanced security group, instances are isolated by default, and this policy cannot be changed.

For more information, see Internal network connectivity.

Isolating ENI traffic on the same instance

Isolating traffic between two elastic network interfaces on the same ECS instance by using only security groups will fail. This is because security groups are applied to virtual network devices outside the operating system of an ECS instance. By default, traffic between two elastic network interfaces of the same ECS instance is routed and forwarded within the operating system. The traffic does not pass through security groups. Therefore, you cannot use security groups to isolate the traffic.

You can use the namespace mechanism of the operating system to add the two elastic network interfaces of the ECS instance to different namespaces. This way, traffic between the two elastic network interfaces is sent outside the operating system and passes through security groups. Then, you can use security groups to isolate the traffic.

Troubleshooting service inaccessibility

If you cannot access a service after you configure security group rules, you must check whether the service is started and whether the service port and the security group rules are correctly configured. For more information, see Troubleshooting security group rules of an ECS instance that do not take effect.

Changing an ENI's security group

• The rules of a security group associated with an ECS instance apply to the instance's primary ENI. The primary ENI is always in the same security group as the instance, and you cannot change its security group association independently. To change the primary ENI's security group, you must change the instance's security group. For details, see Move an instance to a security group.

• You can associate a secondary ENI attached to an ECS instance with any security group in the same VPC and zone. This security group can be different from the instance's security group. You can specify the security group when you create an ENI, or you can change the security group of an existing ENI.

Converting between basic and advanced security groups

No, you cannot convert a basic security group to an advanced security group, or vice versa.

You can create a security group of the desired type, and then export rules from the source security group and import them to the new security group.

An advanced security group supports more resources than a basic security group in a VPC. Use an advanced security group for large clusters that exceed the basic group's IP capacity.

For more information, see Basic security groups and advanced security groups.

When to add security group rules

After a security group is associated with an ECS instance, implicit default access control rules such as allowing internal network communication between instances in the same basic security group are enabled by default. If your business scenarios require cross-security-group instance communication, public access control, remote connections by using Workbench, source IP address-based access control, or access on specific ports, you must explicitly configure the corresponding rules. Otherwise, access control may fail due to default rule restrictions. For more information, see Security group application guide and cases.

Protocols and ports in security group rules

In security group rules, protocols and ports are core parameters that work together to define traffic access permissions. When you add a security group rule, you must specify a communication protocol and port. Then, the security group determines whether to forward data to the ECS instance based on an allow or deny policy. For more information, see Components of a security group rule.

For more information about common ports and their use cases, see Common ports.

Troubleshooting access to TCP port 25

TCP port 25 is the default email service port. For security reasons, access to port 25 on ECS instances is restricted by default. We recommend that you use port 465 to send emails. For more information, see Use SSL to encrypt port 465 for sending emails.

For more use cases, see Security group application guide and cases.

Troubleshooting access to port 80

To troubleshoot port 80 issues, see Check whether TCP port 80 is working properly.

Automatic addition of security group rules

A large number of rules may be automatically added to your security group in the following cases:

• If you add a self-managed database on an ECS instance to Data Management (DMS), the system automatically adds the IP address blocks of DMS to the security group that is associated with the instance. As a result, the corresponding rules are automatically added to the security group.

• If you have recently migrated data by using Data Transmission Service (DTS), rules related to the DTS service IP addresses are added to the security group.

Impacts of misconfigured security group rules

Are inbound and outbound rules counted separately?

No.

The total number of inbound and outbound rules across all security groups that are associated with a single elastic network interface of an ECS instance cannot exceed 1,000.

For more information, see Limits.

Increasing the security group rule quota

No.

The total number of inbound and outbound rules across all security groups that are associated with a single elastic network interface of an ECS instance cannot exceed 1,000.

Auditing non-compliant rule changes

A security group rule that opens high-risk ports like 22 (SSH) or 3389 (RDP) to all sources (0.0.0.0/0) creates a severe security risk. You can use Cloud Config to continuously check security group configurations and automatically fix non-compliant configurations to ensure system security. For more information, see Automatically audit and fix non-compliant security group rules.

Preventing RAM users from configuring rules

• To prevent a RAM user from configuring security group rules, you can create the following custom policy and attach the policy to the RAM user to deny the API operations related to security group rule configuration.

  {
    "Version": "1",
    "Statement": [
      {
        "Effect": "Deny",
        "Action": [
          "ecs:AuthorizeSecurityGroup",
          "ecs:AuthorizeSecurityGroupEgress",
          "ecs:RevokeSecurityGroup",
          "ecs:RevokeSecurityGroupEgress",
          "ecs:ModifySecurityGroupRule",
          "ecs:ModifySecurityGroupEgressRule",
          "ecs:ModifySecurityGroupPolicy",
          "ecs:ModifySecurityGroupAttribute",
          "ecs:ConfigureSecurityGroupPermissions"
        ],
        "Resource": "*"
      }
    ]
  }

• You can also attach one or more custom policies that contain RAM condition keys to a RAM user to restrict their permissions when they create security groups or add security group rules. For example, you can prohibit the RAM user from adding security group rules that contain specific IP addresses and protocols, restrict the scope of security group rules that can be added, or prohibit the use of the default security group when an ECS instance is created. This improves the security of your Alibaba Cloud account. For more information, see Prohibit RAM users from creating high-risk security group rules.

How do I manage security group rule backup, restoration, and auditing?

Rule backup

Export security group rules from the console in JSON or CSV format, or use the security group snapshot feature for automatic backup and rollback. After a security group rule change, the system creates a snapshot after 5 minutes. If multiple changes occur within 5 minutes, only one snapshot is created based on the rules before the first change. You can use snapshots to restore security group rules to a specific point in time. Security group snapshots are stored in OSS and incur corresponding OSS storage and request fees.

Rule restoration

• When snapshots are enabled: You can roll back to a specified point in time before the change.

• When snapshots are not enabled: Direct restoration is not possible. You can re-import rules from previously exported JSON/CSV files.

Notes on importing rules:

• The target security group must already exist.

• Cross-region import does not support authorization objects that reference security groups or prefix lists, nor does it support port lists.

• A maximum of 200 rules can be imported at a time.

Auditing limitations

• Historical resource associations of a security group cannot be queried (the console only shows current associations).

• The native console does not display who modified a rule or when (the creation time of a rule is not updated by subsequent modifications). To audit change history, enable ActionTrail to record API call logs and trace the modifier and time.

Rule synchronization

Security groups do not support direct merging. To synchronize rules, export rules from the source security group and import them into the target security group.

Why does the server log contain access requests from IPs blocked by security groups?

Security groups operate at the network layer (L3/L4) and filter traffic based on the source IP of TCP connections. When CDN, WAF, SLB, or a reverse proxy is deployed in front of the ECS instance:

• Source IP seen by security groups: The proxy node IP (not the user's real IP).

• IP recorded in application logs (such as Nginx access logs): The user's real IP passed through the X-Forwarded-For request header.

Therefore, application logs may record access requests from malicious IPs, but the security group did not block those IPs — because the security group filters the proxy node IP, not the actual source IP.

Resolution:

• Only when traffic does not pass through SLB/CDN, you can block the attacker's direct IP range in the security group. If SLB/CDN is in use, blocking proxy node IPs would disrupt normal traffic. Do not block Alibaba Cloud SLB/CDN node IPs at the security group level.

• Recommended approach: Configure access control rules based on real IPs (X-Forwarded-For) at the WAF/CDN layer.

Security groups block new connections. Failed connection attempts recorded in system logs are normal protective behavior and do not indicate a successful intrusion.

Why do security group rules not take effect or get bypassed after configuration?

The following scenarios may cause security group rules to appear ineffective. Troubleshoot each one.

Scenario 1: SLB backend traffic is allowed by default

When an ECS instance serves as a load balancer backend, traffic forwarded through ALB, NLB, or CLB to the backend ECS is identified and allowed by default by the security group. To restrict access to backend instances, configure access control (ACL) on the load balancer side, or use OS-level firewalls.

Scenario 2: Default internal communication within the same security group makes deny rules ineffective

Instances in a basic security group can communicate with each other over the internal network by default. Adding deny rules within the group will not take effect. You must first enable internal isolation in the security group policy, then use allow rules to permit specific ports and sources. Enterprise security groups use internal isolation by default and do not have this issue.

Scenario 3: Multi-security-group rules are matched by priority, with deny taking precedence over allow

When an instance belongs to multiple security groups, the system aggregates all security group rules, sorts them by priority, and then matches traffic sequentially.

Single-rule matching: The system compares the traffic's protocol type, port range, and authorization object (source/destination IP) against each rule. A match is found only when all three conditions are met. Once matched, the system executes the rule's action (allow or deny) and stops checking subsequent rules.

Multi-rule sorting and sequential matching:

1. Rules with smaller priority values are checked first (valid range: 1–100).

2. At the same priority level, deny (Drop) rules are placed before allow (Accept) rules.

Traffic is matched sequentially against the sorted rule list. Once the first matching rule is hit, its action is executed. If no custom rules match, the security group's default access control rules apply (the default behavior differs between basic and enterprise security groups. For details, see Basic and enterprise security groups).

When troubleshooting, check all security groups associated with the instance: a high-priority allow rule in one security group may override a low-priority deny rule in another, and vice versa. This is not a simple union of rules, but a priority-sorted, deny-first matching policy.

Scenario 4: Managed security groups are hidden or read-only

Some cloud products create managed security groups that are hidden or read-only in the console by default. To view them, switch the security group list filter to the "All" view. To modify them, follow the management procedures of the corresponding product — direct editing is not supported.

Viewing resource quotas

For information about resource usage limits and quotas, see Limits.

Adding a static route on Ubuntu startup

1. Log on to an ECS instance.

   1. Go to ECS console - Instances. In the top-left corner, select the region and resource group for the target instance.

   2. Navigate to the details page of the target instance. Click Connect and select Workbench. Follow the on-screen prompts to access the terminal.

2. Create the /etc/systemd/system/add-route.service file and add the following content. Replace <CIDR block> and <gateway> with your destination CIDR block and gateway address.

   Example: CIDR block 172.xxx.xxx.0/20 and gateway 172.xxx.xxx.253.

   /sbin/route add -net 172.18.xxx.0/20 gw 172.30.xxx.253 dev eth0

   /sbin/route del -net 172.18.xxx.0/20 gw 172.30.xxx.253 dev eth0

   [Unit]
   Description=Add custom route 
   After=network.target
   [Service]
   Type=oneshot
   ExecStart=/sbin/route add -net <CIDR block> gw <gateway> dev eth0
   ExecStop=/sbin/route del -net <CIDR block> gw <gateway> dev eth0
   RemainAfterExit=yes
   [Install]
   WantedBy=multi-user.target

3. Enable auto-startup. The static route is automatically added each time the system starts.

   systemctl enable add-route.service

Why nslookup shows 127.0.0.53 on Ubuntu

By default, Ubuntu uses the systemd-resolved service as a local DNS resolver. All DNS queries are first sent to this local address (127.0.0.53) and then forwarded to the actual upstream DNS servers.

To view the upstream DNS servers that systemd-resolved is currently using, run the following command:

• Ubuntu 20.04

  systemd-resolve --status

• Ubuntu 22.04 and later

  resolvectl status

Configure a custom DNS server on Ubuntu

1. To prevent cloud-init from automatically overwriting network settings, edit the /etc/cloud/cloud.cfg file and add the following content to the end of the file:

   network:
     config: disabled

2. Modify the Netplan configuration file /etc/netplan/50-cloud-init.yaml and add a nameservers block under the network interface configuration, such as for eth0.

   nameservers: 
     addresses: ["<Custom_DNS1>", "<Custom_DNS2>"]

3. Apply the new configuration.

   sudo netplan apply

Use only custom DNS servers on Ubuntu

Disable DHCP and configure a static network to ensure that the system uses only the specified DNS servers.

Modify the Netplan network configuration by editing the /etc/netplan/50-cloud-init.yaml file.

Change the configuration for the network interface, such as eth0, to the following static mode. Replace <DNS1> and <DNS2> with the actual DNS addresses.

network:
    ethernets:
        eth0:
            dhcp4: false
            dhcp6: false
            match:
                macaddress: XX:XX:XX:XX
            addresses:
              - XXX.XXX.XXX.XXX/XX
            routes:
              - to: default
                via: XXX.XXX.XXX.XXX
            set-name: eth0
            nameservers:
                addresses: [<DNS1>, <DNS2>]
    version: 2

Why ping's "Received" count includes "unreachable"

When you run the ping command in Windows, if a Destination net unreachable reply is received, the reply is counted in the Received statistics instead of the Lost statistics. This behavior can lead to a misinterpretation of the network status.

This occurs because the Windows ping command's implementation counts ICMP unreachable packets from an intermediate router as successfully received replies.

You can configure an inbound rule in Windows Firewall to block such ICMP packets.

New-NetFirewallRule -DisplayName "Block ICMP Unreachable" -Direction Inbound -Protocol ICMPv4 -IcmpType 3 -Action Block