[Support Feedback] Improve IUAM, DDoS triage, and origin protection docs (DDoS Protection)

src/content/docs/ddos-protection/best-practices/proactive-defense.mdx

@@ -1,6 +1,6 @@
 ---
 pcx_content_type: how-to
 source: https://support.cloudflare.com/hc/en-us/articles/200170196-Responding-to-DDoS-attacks
 title: Proactive DDoS defense
 sidebar:
   order: 3
@@ -30,4 +30,52 @@
 
 ## Magic Transit customers
 
-In addition to the steps for all customers, Cloudflare Magic Transit customers should ensure that the [Advanced TCP Protection](/ddos-protection/advanced-ddos-systems/overview/advanced-tcp-protection/), [Advanced DNS Protection](/ddos-protection/advanced-ddos-systems/overview/advanced-dns-protection/), and [Programmable Flow Protection](/ddos-protection/advanced-ddos-systems/overview/programmable-flow-protection/) are enabled and that their configurations are optimized.
+In addition to the steps for all customers, Cloudflare Magic Transit customers should ensure that the [Advanced TCP Protection](/ddos-protection/advanced-ddos-systems/overview/advanced-tcp-protection/), [Advanced DNS Protection](/ddos-protection/advanced-ddos-systems/overview/advanced-dns-protection/), and [Programmable Flow Protection](/ddos-protection/advanced-ddos-systems/overview/programmable-flow-protection/) are enabled and that their configurations are optimized.
+
+---
+
+## Protect your origin server
+
+Cloudflare edge protection is only effective if attackers cannot bypass it by reaching your origin directly.
+
+1. Verify that all hostnames serving traffic are [proxied (orange-clouded)](/dns/proxy-status/) through Cloudflare.
+2. Check whether your origin IP is reachable from non-Cloudflare sources. If it is, attackers can send traffic directly to the origin and bypass all Cloudflare protections.
+3. Before restricting access, identify any non-Cloudflare sources that must still reach your origin (for example, third-party vendors, monitoring services, CI/CD pipelines, or partner integrations).
+4. Restrict your origin firewall to accept HTTP/HTTPS traffic only from [Cloudflare IP ranges](https://www.cloudflare.com/ips/) and any explicitly trusted IPs you identified.
+5. As an extra precaution, if your origin IP has been previously targeted or exposed, contact your hosting provider to request a new origin IP address.
+
+For a comprehensive list of origin protection methods (including Cloudflare Tunnel, authenticated origin pulls, and more), refer to [Protect your origin server](/fundamentals/security/protect-your-origin-server/).
+
+---
+
+## DDoS response triage
+
+If you are experiencing a DDoS attack or suspect elevated attack traffic, use the following checklist to assess impact and choose the next mitigation.
+
+### Quick triage questions
+
+1. Are you experiencing service impact (timeouts, 5xx errors) or mainly observing high traffic volume in logs and analytics?
+2. Which hostname(s) are affected, and are they [proxied (orange-clouded)](/dns/proxy-status/)?
+3. What is the timeframe that should be investigated? Provide times in UTC.
+
+### If your site or origin is impacted
+
+Use this checklist to identify where requests are failing:
+
+- What errors are you seeing (5xx status codes, connection timeouts) and where (browser, Cloudflare analytics, origin logs)?
+- What are your origin server metrics during the timeframe: CPU load, memory, bandwidth usage?
+- Do you have origin or access log samples showing the problematic traffic?
+
+### If you mainly observe high traffic volume but the site is up
+
+Use this checklist to choose the right mitigation:
+
+- Where do you observe the traffic: [Cloudflare analytics](/analytics/), origin access logs, or both?
+- What are the top attacked endpoints, URI paths, and User-Agent strings?
+- What outcome do you want: reduce cost, reduce noise, add challenges, or block traffic entirely?
+
+### Common targeted mitigations
+
+- **One or a few endpoints targeted**: Create [rate limiting rules](/waf/rate-limiting-rules/) and [WAF custom rules](/waf/custom-rules/) scoped to the affected paths.
+- **Specific User-Agent or request fingerprint dominates**: Create [WAF custom rules](/waf/custom-rules/) to challenge or block matching requests.
+- **Origin needs protection from direct access**: Ensure all hostnames are proxied and restrict origin access to [Cloudflare IP ranges](https://www.cloudflare.com/ips/) (refer to [Protect your origin server](#protect-your-origin-server) above).

src/content/docs/fundamentals/reference/under-attack-mode.mdx

@@ -1,6 +1,6 @@
 ---
 pcx_content_type: reference
 source: https://support.cloudflare.com/hc/en-us/articles/200170076-Understanding-Cloudflare-Under-Attack-mode-advanced-DDOS-protection-
 title: Under Attack mode
 ---
 
@@ -65,6 +65,37 @@
 
 ---
 
+## Configuration strategies
+
+You can scope Under Attack mode to match your needs rather than enabling it globally for your entire zone.
+
+### Site-wide
+
+Turn on Under Attack mode for your entire zone via the dashboard **Quick Actions** sidebar. This is the fastest way to respond when your whole site is under attack.
+
+### Scope to specific pages
+
+If only certain pages or sections are under attack, use a [configuration rule](/rules/configuration-rules/) to apply Under Attack mode selectively. Check your access logs or [analytics](/analytics/) to identify which paths are receiving attack traffic, then target only those paths.
+
+### Selectively disable for specific areas
+
+If you have enabled Under Attack mode site-wide but it breaks certain parts of your site (for example, API endpoints or areas that serve non-browser traffic), use a [configuration rule](/rules/configuration-rules/) to set the security level to a lower value for those paths.
+
+### Use WAF custom rules for targeted challenges
+
+When attack traffic clusters from a specific source, use [WAF custom rules](/waf/custom-rules/) to apply challenges selectively based on ASN, country, IP range, or other request attributes. This is useful when you can identify a pattern in the attack traffic but do not want to challenge all visitors globally.
+
+---
+
+## Important considerations
+
+- **Under Attack mode applies challenges at Cloudflare's edge.** Challenge outcomes are recorded in [Cloudflare security analytics](/waf/analytics/security-events/). Requests reach your origin only after a challenge is solved, via a valid `cf_clearance` cookie, or when traffic is excluded from Under Attack mode through configuration rules.
+- **Non-browser traffic will be blocked.** Under Attack mode requires JavaScript execution, so API clients, mobile apps, and automated integrations will fail the challenge. Use configuration rules or WAF custom rules to exclude these paths or traffic types.
+- **Disable when the attack subsides.** Under Attack mode is designed as a temporary measure. Once attack traffic returns to normal, turn it off to avoid unnecessarily challenging legitimate visitors.
+- **Consider customizing the challenge page.** You can brand the interstitial page shown to visitors during the challenge. Go to **Configurations** > **Custom Pages** > **Managed Challenge / I'm Under Attack Mode** to configure a custom page.
+
+---
+
 ## Potential issues
 
 Since the Under Attack mode requires your browser to support JavaScript to display and pass the interstitial page, it is expected to observe impact on third party analytics tools.

src/content/docs/support/troubleshooting/restoring-visitor-ips/restoring-original-visitor-ips.mdx

@@ -1,6 +1,6 @@
 ---
 pcx_content_type: troubleshooting
 source: https://support.cloudflare.com/hc/en-us/articles/200170786-Restoring-original-visitor-IPs
 title: Restoring original visitor IPs
 ---
 
@@ -316,11 +316,11 @@
 
 Which would result in your logs looking like this:
 
 `Visitor IP - Cloudflare IP - [04/Dec/2014:23:18:15 -0500] - "GET / HTTP/1.1" - 200 - 1895 - 193d704b85200296-SJC`
 
 ### Magento
 
 Refer to this third-party tutorial on restoring original visitor IP with [Magento and Cloudflare](https://tall-paul.co.uk/2012/03/02/magento-show-remote-ip-when-using-cloudflare/).
 
 Similarly, Cloudflare did not write this [Magento extension](https://marketplace.magento.com/), but some of our customers have found it helpful.
 
@@ -493,6 +493,24 @@
 ```
 ---
 
+## Cloudflare IPs in your server logs
+
+When your site is proxied through Cloudflare, your origin server logs will show Cloudflare edge IP addresses instead of original visitor IPs by default. This is expected behavior and does not mean Cloudflare is originating traffic to your site. Cloudflare does not generate or originate attack traffic to customer origins.
+
+### Scenario 1: Cloudflare IPs in origin HTTP logs (expected when proxied)
+
+If your site is proxied through Cloudflare and your origin logs show Cloudflare IP addresses, this is normal. Your origin sees Cloudflare edge server IPs because Cloudflare acts as a reverse proxy between visitors and your origin.
+
+To log the original visitor IP instead, follow the [web server instructions](#web-server-instructions) on this page to extract the IP from the [`CF-Connecting-IP` header](/fundamentals/reference/http-headers/#cf-connecting-ip).
+
+### Scenario 2: Cloudflare IPs on non-HTTP protocols (likely IP spoofing)
+
+Cloudflare's standard reverse proxy for proxied DNS records handles HTTP and HTTPS traffic. Cloudflare also supports non-HTTP traffic through [Spectrum](/spectrum/) (TCP/UDP) and [Magic Transit](/magic-transit/about/). If you are not using Spectrum or Magic Transit, non-HTTP traffic appearing from [Cloudflare IP addresses](https://www.cloudflare.com/ips/) is consistent with IP spoofing or amplification attacks, not Cloudflare-originated traffic.
+
+In IP spoofing attacks, the attacker forges the source IP address of packets to make them appear to come from a different source. Cloudflare IP addresses, like any other public IP ranges, can be used as spoofed source addresses by attackers. This does not indicate that Cloudflare systems sent the traffic.
+
+---
+
 ## Related Resources
 
 - [Cloudflare HTTP headers](/fundamentals/reference/http-headers/)