REJECT Policy

To meet different needs, Surge has multiple built-in REJECT policies. In most cases, using REJECT directly is sufficient. If there are special requirements, consider derivative policies.

REJECT

Reject the request. If the request is HTTP, an error page is returned. This behavior can be controlled by the show-error-page-for-reject parameter.

REJECT-DROP

Reject the request. Unlike REJECT, this policy will silently discard the connection. Some applications have very aggressive retry logic, where they immediately retry after a connection failure, leading to a request storm. Using this policy can mitigate the issue.

REJECT-NO-DROP

If a large number of requests to a hostname trigger the REJECT/REJECT-TINYGIF policy within a short period of time (the threshold is 50 times within 30 seconds in the current version), Surge will automatically upgrade the policy to REJECT-DROP in order to avoid wasting a lot of resources.

You may use REJECT-NO-DROP policy to avoid this behavior.

REJECT-TINYGIF

Reject the request. If the request is HTTP, a 1px transparent GIF is returned for ad blocking.

Pre-matching Reject iOS 5.14.0+ Mac 5.9.0+

Due to the extensive range of properties that Surge's rule system can evaluate, rule determination can only occur after receiving the first TCP packet. This results in excessive unnecessary overhead when dealing with storm requests or ad-blocking needs.

In the new version, Surge has added a Pre-matching feature to quickly reject requests with low overhead. For rules using the REJECT policy, this feature can be enabled through pre-matching tagging.

[Rule]
DOMAIN,ad.com,REJECT,pre-matching

Rules marked with pre-matching will take effect before the normal rule matching process, thus having the highest priority.

All rules marked with pre-matching are extracted for prioritized matching and executed during the DNS resolution and TCP SYN phases. If a DNS domain is matched, Surge returns No Record directly. If a TCP SYN is matched, Surge generates a TCP RST response immediately. In case of numerous requests, Surge escalates to packet loss. UDP is handled similarly.

Additionally, each rule will only appear once in the recent request list every 5 minutes to avoid flooding due to numerous requests.

The types of rules that can be marked with pre-matching include:

  • DOMAIN types: DOMAIN, DOMAIN-SUFFIX, DOMAIN-KEYWORD, DOMAIN-SET, DOMAIN-WILDCARD.
  • IP types: IP-CIDR, IP-CIDR6, GEOIP, IP-ASN.
  • Logical rules: AND, OR, NOT
  • Others: SUBNET, DEST-PORT, SRC-PORT, SRC-IP

RULE-SET can also be used but its content is subject to the above restrictions as well.

Pre-matching Technical Details

For optimal user experience, rejections are made during the pre-matching phase. Different derivative rules have slightly different behavior.

For DNS queries

  • If a REJECT policy is matched, Surge returns a No Record DNS response. If the frequency limit built into the REJECT policy is triggered, the DNS query is discarded without a response.

  • If a REJECT-DROP policy is matched, the DNS query is discarded without a response.

  • If a REJECT-NO-DROP policy is matched, it will return a special IP address 198.18.0.244; Surge will generate TCP RST responses for all TCP connections accessing this address.

For TCP requests using IP

  • If a REJECT policy is matched, it will directly generate TCP RST responses; if the frequency limit built into the REJECT policy is triggered, it will discard the corresponding TCP SYN handshake packet.

  • If a REJECT-DROP policy is matched, it will directly discard the TCP SYN handshake packet.

  • If a REJECT-NO-DROP policy is matched, it will directly generate TCP RST responses.

Please note that due to some software potentially having aggressive retry logic, which immediately retries after a request fails and causes abnormal CPU usage, even for the REJECT-NO-DROP policy, when Surge generates a large number of TCP RST packets in a short period of time (the threshold is 100 times within 3 seconds in the current version), it will also trigger a protection mechanism to pause returning TCP RST and directly drop packets instead.

For UDP packets

Since UDP packets have no handshake overhead, there is no pre-matching phase; they are directly matched using the main rule set:

  • If a REJECT policy is matched, an ICMP Administratively Prohibited response is generated. If the frequency limit built into the REJECT policy is triggered, packets are discarded.

  • If a REJECT-DROP policy is matched, packets are directly discarded.

  • If a REJECT-NO-DROP policy is matched, an ICMP Administratively Prohibited response is generated.

results matching ""

    No results matching ""