[{"data":1,"prerenderedAt":178},["ShallowReactive",2],{"publication:en:P176":3},{"meta":4,"copy":17,"relatedArticles":138,"terms":170,"term":171,"resourceParent":172,"glossaryParent":175},{"id":5,"path":6,"kind":7,"keyword":8,"title":9,"seoTitle":10,"description":11,"incoming":12,"updated":15,"preparedOn":16},"P176","\u002Fblog\u002Fdiagnose-ddos-vs-overload","article","DDoS attack or website overload","DDoS attack or website overload? Compare the evidence","DDoS attack or website overload? Diagnosis guide","Compare traffic, origin resources, errors and recent changes before calling an outage DDoS. Match protection to the affected layer and verify key workflows.",[13,14],"\u002Fservices\u002Fcloudflare","\u002Fservices\u002Flinux-vps","2026-05-15","2026-10-30",{"intro":18,"sections":19,"checklist":95,"faq":103,"links":113,"sources":130,"cta":133},"To distinguish a DDoS attack from website overload or an application fault, compare traffic, errors, origin resources and recent changes within the same time window. A slow or unavailable site and a high request count are not proof of an attack. Review edge and origin evidence together, then match the response to the affected layer and business function.",[20,26,62,75,81,89],{"title":21,"paragraphs":22},"Define what is unavailable and when it changed",[23,24,25],"Start with the business symptom: the whole site is unreachable, only checkout times out, administrators cannot log in or one integration fails. Record the first observation, timezone, affected routes and sources of the report. One monitoring location can fail for reasons that do not affect every customer.","Compare with a relevant baseline. Traffic, cache behavior and resource use can differ during campaigns, scheduled jobs or routine business peaks. A recent release or provider issue may coincide with a traffic increase. Preserve those alternative explanations until the evidence supports narrowing them.","Identify the technical owner, hosting provider and edge-provider contacts. If service is impaired, coordinate proportionate operational action while collecting evidence. Do not create a live traffic spike, repeatedly submit orders or invite others to “test the attack” as part of an informal diagnosis.",{"title":27,"paragraphs":28,"table":31},"Compare competing explanations rather than counting symptoms",[29,30],"Use several signals tied to the same interval. Request distribution, routes, methods, response errors, application work and database behavior help explain which component is under pressure. The most visible chart may describe only part of the path.","The original matrix below keeps plausible alternatives and the next evidence together. It is not a formula that classifies every outage automatically. Record uncertainty when the logs, metrics or relevant baseline are missing.",{"caption":32,"headers":33,"rows":37},"Outage signal and competing-explanation matrix",[34,35,36],"Observation","Another plausible explanation","Evidence to compare next",[38,42,46,50,54,58],[39,40,41],"Request count rises","Marketing activity or expected automated access","Affected routes, distribution, timing and normal traffic pattern",[43,44,45],"CPU or database pressure rises","Expensive query, job or application change","Process, query, release and resource timeline",[47,48,49],"Only checkout fails","Gateway delay or integration defect","Route-specific logs and provider evidence",[51,52,53],"Many edge mitigations occur","Protection acting on traffic before the origin","Origin load and actual customer impact in the same interval",[55,56,57],"Origin is busy without the same edge spike","Another route, background work or infrastructure issue","Coverage, host\u002Fnetwork evidence and job schedule",[59,60,61],"One uptime probe fails","Probe location, resolver or monitoring-route issue","Independent authorized observations and service telemetry",{"title":63,"paragraphs":64,"sources":68},"Know which traffic the edge dashboard actually describes",[65,66,67],"Cloudflare distinguishes HTTP and network-layer protection and analytics. The relevant view depends on the product and traffic path. Its documentation also describes plan-dependent visibility and situations where a handled request or packet does not expose a public managed-rule identifier.","Do not equate edge request totals, origin access logs and host network traffic without understanding their populations and timing. Cached or mitigated traffic can have different origin effects, while an unprotected route or background job may not appear in the expected edge view at all. Check which hostnames and services are actually covered.","Cloudflare describes using multiple request, packet and response signals for DDoS detection. That explains the provider’s approach; it does not prove that the symptoms on a particular website are an attack. A provider alert is relevant evidence to correlate with business impact, not a replacement for understanding the affected service.",[69,72],{"label":70,"url":71},"Cloudflare: DDoS analytics, coverage and plan-dependent visibility","https:\u002F\u002Fdevelopers.cloudflare.com\u002Fddos-protection\u002Freference\u002Fanalytics\u002F",{"label":73,"url":74},"Cloudflare: DDoS detection signals and mitigation layers","https:\u002F\u002Fdevelopers.cloudflare.com\u002Fddos-protection\u002Fabout\u002Fhow-ddos-protection-works\u002F",{"title":76,"paragraphs":77},"Check origin work and business dependencies",[78,79,80],"Review recent application, component, database and infrastructure changes with the responsible administrator. A resource bottleneck may arise from legitimate traffic made expensive by a regression, a job that runs unexpectedly or a downstream service that delays responses. The corrective action depends on that cause.","For a store, distinguish browsing from cart, checkout, server notifications and fulfillment. Some routes cannot be cached like public content, and some automated callbacks are necessary business traffic. A blanket challenge or restriction can make a chart look quieter while breaking a required process.","Keep inspection proportionate and authorized. Use existing telemetry and controlled observations before proposing load testing. Any performance or security assessment that generates significant traffic needs a separate scoped plan, provider coordination and clear limits. This diagnostic guide does not authorize live stress tests.",{"title":82,"paragraphs":83,"example":86},"Choose mitigation for the layer and verify legitimate work",[84,85],"The responsible providers may need to address network saturation, HTTP traffic patterns, application work or an external dependency. Use the controls appropriate to the evidenced problem. A WAF rule is not every network protection mechanism, and scaling resources is not proof that malicious activity has been addressed.","For a suspected false positive or a protection adjustment, define the permitted workflow, scope and review conditions. Verify the intended route and the protection boundary with controlled checks. Keep a record of what improved and what remains unexplained instead of closing the case solely because the homepage responds again.",{"title":87,"text":88},"Illustrative example: checkout overload follows a component change","A fictional shop’s public pages remain responsive while checkout becomes slow after an update. The same interval shows increased database work, without corresponding evidence establishing a DDoS attack. The owner investigates the changed checkout dependency and preserves the attack hypothesis as unconfirmed. This is a hypothetical diagnostic scenario, not a measured benchmark or customer outage.",{"title":90,"paragraphs":91},"Close with evidence, limits and owned follow-up",[92,93,94],"Record the affected interval, systems observed, relevant signals, provider findings, authorized changes and functional verification. Separate a confirmed attack, a suspected attack and an unresolved outage. Where metrics are sampled, missing or unavailable, preserve that limitation in the conclusion.","CyberFixCrew is an Israeli cybersecurity company serving businesses worldwide. Our practical Israeli website and infrastructure knowledge helps connect Cloudflare, hosting, application and integration evidence within an agreed scope. Describe the URL, affected workflow, timing and available provider reports. Do not send secrets or customer payloads with the initial enquiry.","After service is stable, assign monitoring and remediation actions that address the actual gap: a coverage issue, inefficient workflow, rule mismatch or incident-control problem. The objective is a defensible diagnosis and maintainable response, not an attack label for every traffic peak or a promise that one protection product prevents every outage.",[96,97,98,99,100,101,102],"Define the affected route, business function, time and timezone.","Compare the interval with relevant normal activity and changes.","Correlate traffic, errors, host resources and provider observations.","Establish what each edge and origin view actually covers.","Investigate application jobs, database work and external dependencies.","Match authorized action to the evidenced layer and verify legitimate use.","Record confirmed findings, uncertainty and follow-up owners.",[104,107,110],{"question":105,"answer":106},"Does a sudden traffic increase prove a DDoS attack?","No, campaigns, normal automated activity and inefficient processing can also increase traffic or load. Compare distribution, routes, resource work and provider evidence before deciding.",{"question":108,"answer":109},"Why can Cloudflare and origin request counts differ?","They may cover different stages, populations and sampling conditions. Caching, mitigation, routing and background work affect what reaches or appears at each layer.",{"question":111,"answer":112},"Should I generate traffic to see whether the server survives?","Not as an informal live diagnostic step. Use available telemetry first. Any load test needs an explicitly authorized environment, provider coordination and operational limits.",[114,117,120,123,126,128],{"path":115,"label":116},"\u002Fblog\u002Fcloudflare-waf-false-positives","Investigate a legitimate-request block",{"path":118,"label":119},"\u002Fblog\u002Fcloudflare-origin-exposure","Review edge coverage and origin routes",{"path":121,"label":122},"\u002Fblog\u002Fwebsite-log-review","Build a consistent evidence timeline",{"path":124,"label":125},"\u002Fblog\u002Fwoocommerce-incident","Triage suspected compromise affecting the shop",{"path":13,"label":127},"Discuss edge-protection review",{"path":14,"label":129},"Review hosting and origin-resource scope",[131,132],{"label":70,"url":71},{"label":73,"url":74},{"title":134,"description":135,"button":136,"type":137},"Investigate the cause of a website outage","Describe the affected functions, time window, recent changes and available provider evidence. CyberFixCrew can scope the edge, origin and application review without generating live load.","Discuss outage diagnosis","fix",[139,147,155,163],{"id":140,"path":115,"title":141,"description":142,"category":143,"artwork":144,"order":145,"publishedOn":146},"P056","Cloudflare WAF false positives: restore a legitimate workflow safely","Investigate a legitimate-request block using Cloudflare events and origin evidence. Plan a narrow exception and verification without disabling all protection.","infrastructure","security",26,"2026-05-31",{"id":148,"path":149,"title":150,"description":151,"category":143,"artwork":152,"order":153,"publishedOn":154},"P185","\u002Fblog\u002Fhosting-security-responsibility","Shared hosting vs VPS security responsibility: who owns each task?","Compare hosting responsibility across updates, access, backups and incident support. Use a task-owner matrix rather than assume a hosting label means managed.","servers",30,"2026-06-16",{"id":156,"path":157,"title":158,"description":159,"category":143,"artwork":160,"order":161,"publishedOn":162},"P187","\u002Fblog\u002Fdocker-security-checklist","Docker security checklist for small business: verify the boundaries","Review Docker daemon access, users, mounts, published ports, images and recovery. Separate container configuration from host and application security.","integrations",35,"2026-07-02",{"id":164,"path":165,"title":166,"description":167,"category":143,"artwork":152,"order":168,"publishedOn":169},"P101","\u002Fblog\u002Flinux-ssh-hardening","SSH hardening for Linux servers without losing authorized access","Review SSH users, keys, privileges and network exposure. Plan recovery access, syntax checks and fresh-session tests before retiring the old access route.",42,"2026-07-18",[],null,{"path":173,"label":174},"\u002Fresources","Website security resources and templates",{"path":176,"label":177},"\u002Fglossary","Cybersecurity glossary for small businesses",1794134058526]