Most people only learn how DNS and proxy protection work the day they desperately need it. So instead of another generic “what is Cloudflare” explainer, here’s an honest, step-by-step look at what actually happens when a site owner calls Tremhost mid-crisis and we run an emergency Armor SOS cutover start to finish.
https://tremhost.com/clientarea/store/tremhost-armor-powered-by-cloudflare
Why “Normal” Setup Timelines Don’t Work in an Emergency
A standard Cloudflare onboarding the kind done for Armor Lite is deliberately unhurried. DNS records get mapped carefully, SSL modes get tested, cache rules get tuned to the specific site type, and everything is verified before go-live. That process usually takes a few days, and for a healthy site, that pace is a feature, not a flaw it avoids downtime from misconfiguration.
None of that timeline is acceptable when a site is actively being attacked. Every hour of delay is an hour of lost sales, exposed customer data, or search rankings quietly draining away from downtime. Armor SOS exists because “we’ll get to it this week” isn’t an answer to “my site is down right now.”
https://tremhost.com/clientarea/store/tremhost-armor-powered-by-cloudflare
Hour 0: Triage Call and Origin Assessment
The first thing we determine isn’t “what package do you want” it’s what’s actually happening. Is the origin server still reachable? Is traffic volume the problem, or is it unauthorized access? Is the domain’s current DNS provider going to cooperate with a fast change, or is propagation going to be a fight?
This assessment decides the order of operations. A DDoS-only situation and a compromised-origin situation get handled differently even though both start with the same emergency call.
https://tremhost.com/clientarea/store/tremhost-armor-powered-by-cloudflare
Hour 0–1: Emergency DNS Cutover
This is the step most people picture when they hear “cutover” but the value isn’t just “add Cloudflare,” it’s doing it fast and correctly under pressure, which is exactly where DIY attempts go wrong. Common mistakes we see from site owners trying this alone mid-attack:
- Leaving old A records active alongside the new proxy setup, giving attackers a second, unprotected path straight to the origin
- Missing subdomains (mail servers, staging environments, API endpoints) that stay exposed while the main domain looks “protected”
- SSL mode misconfigurations that either break the site entirely or leave a gap attackers can exploit
We map every record before touching anything, so the origin isn’t just partially shielded — it’s fully behind the proxy, including the parts of the domain people forget about.
Hour 1–2: Under Attack Mode + Emergency WAF Rules
Once traffic is routed through Cloudflare, Under Attack Mode is activated immediately this adds a browser verification challenge in front of every visitor, which filters out a large share of automated attack traffic before it ever reaches the server.
Alongside that, we deploy custom emergency WAF rules specific to what’s actually happening not generic templates. If it’s a login brute-force, we rate-limit and lock down the login endpoint specifically. If it’s an XML-RPC abuse pattern, that gets closed off directly. This is the difference between a firewall that’s “on” and a firewall that’s actually stopping this attack.
Hour 2–3: Origin IP Rotation (If Compromised)
If there’s reason to believe the attacker has the site’s real server IP from before protection was in place, or from a misconfiguration elsewhere — a proxy alone doesn’t fully solve the problem, because traffic can still be sent directly to that exposed IP, bypassing Cloudflare entirely.
In that case, we rotate the origin IP, which effectively cuts the attacker’s direct line to the server. Combined with the DNS cutover already in place, this closes the loop the only path to the site is now through the protected proxy.
Hour 3+: Stabilization Check and Monitoring
Once the immediate rules are live, we watch traffic and server load to confirm the site has actually stabilized not just theoretically protected, but genuinely handling load and rejecting malicious requests as expected. Adjustments get made in real time if something isn’t behaving as intended.
After Stabilization: The Post-Incident Summary
Once things are calm, the site owner gets a written summary of what happened and exactly what was changed — DNS records modified, rules added, IP changes made. This isn’t just documentation for its own sake; it matters for:
- Explaining to customers or stakeholders what happened, if disclosure is needed
- Compliance and audit trails, particularly for ecommerce or PCI-relevant sites
- Deciding what ongoing protection makes sense going forward
What Comes Next
Armor SOS is designed to stop the emergency it’s not meant to be the permanent state of a site’s security. Once stabilized, most site owners move to Armor Lite or Armor Pro, where the same protections (WAF, rate limiting, proxy, DDoS mitigation) run continuously, tuned and monitored, instead of reactively deployed under pressure.
| Armor SOS | Ongoing Protection (Lite/Pro) |
|---|---|
| Deployed same-day, reactively | Configured proactively, before an incident |
| $150 one-time | From $35/month (Lite) |
| Stops an active emergency | Prevents the next one |
