Access control

Whitelist has no effect

Cause: The ACL is not associated with the listener, or the ACL has no IP entries. An empty ACL allows all traffic.

Solution: On the Listener tab of the ALB instance, confirm that the Access Control column for the target listener shows Enabled. Also, confirm that the associated ACL contains IP entries.

Cannot add 0.0.0.0/0 to the whitelist

Cause: ACLs do not support adding the 0.0.0.0/0 entry. The console will report a format error.

Solution: The correct method is to disable access control and then re-enable it when needed.

Blacklist has no effect

Cause: Requests are forwarded to ALB through a CDN or WAF. The source IP visible to ALB is the source IP of the CDN or WAF, not the real client IP address.

Solution: ALB access control operates at Layer 4 and matches the source IP address in the request packet. When requests are forwarded by a proxy like a CDN or WAF, the source IP is the proxy's source IP. Therefore, an ALB blacklist cannot block the client IP address. Configure the blacklist at the WAF or CDN layer.

Blacklist cannot block the X-Forwarded-For IP

Cause: ALB access control operates at Layer 4 and matches only the source IP address in the request packet. It does not parse the Layer 7 X-Forwarded-For HTTP header.

Solution: You can implement this by using a custom rule in WAF. Set Match Field to X-Forwarded-For, Logical Operator to Contains, Match Content to the target IP address, and Rule Action to Block. For more information, see Configure match conditions for a custom rule.

Backend NGINX allow/deny rules have no effect

Cause: After traffic is proxied through ALB, the backend server receives the ALB instance's local IP (a private IP address assigned from the vSwitch where the ALB instance resides) as the source IP. NGINX's allow/deny rules are based on this source IP and therefore cannot match the client's IP address.

Solutions:

• (Recommended) Use the ALB access control feature to configure an IP whitelist or blacklist directly at the ALB layer.

• In NGINX, obtain the real client IP address from the X-Forwarded-For request header, then configure allow/deny rules based on the real IP address.

Restricting access by domain or path

Description: ACLs operate at the listener level and cannot differentiate by domain name or path. When enabled, an ACL affects all domains associated with the listener.

Alternative solution: For Standard or WAF-enabled ALB instances, you can use forwarding rules. In the forwarding condition, configure Domain Name/Path and SourceIp conditions to Return Fixed Responses (such as 403) for matching requests. A single forwarding rule's SourceIp condition supports up to five IP addresses or CIDR blocks and does not support the 0.0.0.0/x format. If you have a large number of IP addresses or use a Basic ALB instance, we recommend that you use WAF. You can create a custom rule in WAF to combine host/path and IP conditions for access control.

Blocking IP addresses from foreign countries

Description: ALB access control does not provide a geo-blocking feature and cannot automatically identify the country of an IP address.

Alternative solution: You can manually add known foreign IP ranges to a blacklist, but this method is not automatically updated and is subject to entry limits. We recommend that you use the geo-blocking feature of WAF.