Summary

  • CDN-MizbanCloud is best read as an Iranian cloud-infrastructure service whose CDN is one part of a wider DNS, cache, HTTPS, security, reporting, load-balancing and support surface.
  • The strongest evidence is operational and repeatable: official product pages, user documentation, terms, public support contacts, AS34412 network records and independent business-profile surfaces all point to a real service operator, not only a brand name.
  • The public record is still thinner than a buyer should accept for mission-critical assurance. It shows how the service is meant to work, but not independent latency, outage, incident-response or customer-remedy performance.
  • The practical decision is therefore not whether the name exists. It is whether MizbanCloud can keep identity, DNS, edge IPs, support records, cache behavior and recovery obligations fresh enough for repeated operational use.

A CDN name is not an operating assurance

CDN-MizbanCloud sits in a category where names can easily outrun evidence. A content delivery network is a promise about the path between a user and an origin server. It suggests distributed cache, DNS control, certificate handling, security filtering, reporting, support and enough routing discipline to make the public edge behave predictably. That is a large claim for any provider, and a still larger one when the provider serves customers in a market where locality, sanctions exposure, payment rails, domestic connectivity and language-specific support can matter as much as raw page speed.

The public record around MizbanCloud does not leave the buyer starting from zero. The company controls a live Persian-language product site. It publishes documentation for CDN onboarding, DNS record management, cache settings, HTTPS settings, page rules, reporting, DDoS controls, rate limiting, web acceleration, origin whitelisting and load balancing. It lists support channels, a Tehran presence and product terms. Public network data associates AS34412 with Saba Abr Mizban LLC and the mizbancloud.com domain.

Business-profile material describes MizbanCloud as a Tehran-based private company in computer and network security, founded in 2021, with CDN, cloud computing and cloud security among its specialties.

That is meaningful evidence. It also has limits. Product documentation tells a reader what the control surface is designed to do. It does not prove how quickly support answers a weekend outage, how accurately the dashboard detects regional degradation, how often edge IP lists change, how consistently cache headers behave under mixed dynamic and static content, or how the service performs against alternative Iranian or self-managed designs. The company can have a documented feature and still leave the buyer carrying part of the operational burden.

The more useful question is therefore narrower and more testable: does the public record around MizbanCloud create enough attributable surface for repeatable service decisions? A buyer needs to know who operates the network, which legal and support names are used, how a domain is onboarded, how DNS and proxy choices affect origin exposure, where cache and certificate controls live, how reports can be queried, what happens when an origin fails, which routes and prefixes appear in public resource records, and what the terms say about backup, free services, pricing and support plans. That is the frame in which CDN-MizbanCloud should be assessed.

Read this way, MizbanCloud is neither a ghost nor a fully proven global edge. It is an Iranian cloud service with a visible operating surface and a set of controls that could be useful to domestic and region-sensitive customers. Its risk is not that there is no evidence at all. Its risk is that the evidence is mostly controlled by the provider, while independent service-proof material is modest. The buyer's job is to turn the public record into a test plan before migrating DNS authority, security filtering or cache-sensitive production traffic.

The identity surface has several layers

MizbanCloud's public identity is layered rather than perfectly singular. The brand-facing site uses MizbanCloud for the service, presents a cloud-infrastructure portfolio and describes a mission around secure, faster and more reliable web presence for startups, small businesses, medium businesses and organizations. The same public website associates the copyright line with Saba Hour Yeganeh Co., a private joint-stock company. The public network record around AS34412, by contrast, identifies Saba Abr Mizban LLC as the organization.

Independent business-profile material lists MizbanCloud as a privately held company headquartered in Tehran, founded in 2021, with a stated company-size band of 51 to 200 employees.

This does not automatically indicate a problem. Cloud and hosting groups often carry a brand name, a product name, a legal company name, an RIR organization name and older hosting or reseller names at the same time. But it does create work for the customer. If the buyer is putting a production web estate behind the service, the support account, invoice, legal terms, abuse contact, RIR organization, domain, portal and network entities should be matched in procurement records.

A CDN decision is partly a trust decision, and trust becomes easier to maintain when the accountable entity is the same across contract, routing, billing and incident response.

The public record gives several places to start. MizbanCloud's own pages list the product family: cloud CDN, cloud servers, cloud security or defensive services, cloud DNS, video cloud and live streaming, with object storage and infrastructure services presented as future or upcoming in some navigation areas.

The about page says the company has a mission to provide cloud infrastructure for businesses inside and outside the country and lists claimed credentials such as a knowledge-based technology ranking, quality-management and information-security management references, an organizational-management reference, computer trade organization licensing and e-commerce licensing. These should be treated as provider claims unless a buyer verifies the underlying certificates directly, but their presence adds to the identity surface.

The support surface is also public. The documentation footer lists a Tehran address, 24-hour support even on holidays, a telephone number, an email address and a ticket route. The main website and about page expose similar support claims, including phone, ticket, chat and email channels. The LinkedIn profile lists a Tehran location and repeats the integrated-cloud-infrastructure positioning. Together, those records make the brand easier to contact than a thin landing page would. They also reveal one of the audit tasks: public pages do not always present the exact same address string.

A buyer should record the address on the contract and in the customer portal rather than relying on whatever footer a crawler sees first.

The network-resource identity is more concrete in one sense and more technical in another. AS34412 is publicly associated with Saba Abr Mizban LLC, with the AS name SABA-HOST in some records. It is shown as active and allocated under RIPE, with Iranian country attribution. Public BGP views identify a set of IPv4 prefixes originated by the AS, with RPKI-valid status shown by at least one major BGP observation surface. Some independent views differ in the exact number of prefixes, peers and IPv6 announcements they display at a given moment.

That discrepancy is normal in public routing views, but it means the buyer should not copy a static prefix count from a profile page and call the network verified. Live RIR, BGP, DNS and origin tests should remain part of the operating record.

The identity surface is therefore usable but not self-closing. It says there is an Iranian brand, a broader hosting-cloud group, a RIPE-visible AS, public support channels and product documentation. It does not remove the need to map brand, legal party, account owner, invoice name, AS owner and abuse contact before the service becomes a dependency. For low-risk static content, that gap may be acceptable. For payments, public-sector traffic, media streaming, authentication flows or politically sensitive content, the gap is part of the risk assessment.

What the product record actually proves

The product record proves that MizbanCloud offers, or at least documents, a conventional reverse-proxy CDN model. Its CDN page says a site can be connected to the service in minutes and presents the value proposition in terms of security, speed and more efficient resource consumption. The page lists plan levels, including a free base plan, paid monthly tiers and an enterprise route that requires contact. That structure matters because it shows the CDN is not only a brochure claim. It is packaged as a metered or plan-based product with different support and capability expectations.

The onboarding documentation is more important than the marketing headline. MizbanCloud's step-by-step CDN setup guide says the customer creates an account, enters the user area, selects cloud CDN, adds the site and receives two nameserver records. The customer then replaces the existing domain nameservers at the registrar or domain provider. The guide notes that nameserver updates may take up to 24 hours depending on the top-level domain and registrar, and that nameserver status can be checked in the DNS records area of the cloud CDN menu. That is a standard DNS-authority handoff, and it is a real operational commitment.

Once the customer delegates nameservers, the provider is no longer just accelerating a web route. It is part of domain control.

The DNS documentation reinforces that point. It says that when a domain is connected to MizbanCloud CDN, DNS records previously configured in cPanel or DirectAdmin must be moved manually or uploaded through a zone file into the MizbanCloud panel. It also says records can be created, viewed, edited and deleted, and that a cloud icon controls whether a record is proxied through the CDN. Guidance for MX and FTP records warns that those records should not be sent through the proxy path.

This is useful documentation because it acknowledges a common failure mode: customers turn on proxying for the wrong record and break mail, file transfer or non-HTTP services.

The cache documentation describes the core service mechanics. It says MizbanCloud stores copies of static content on distributed servers, while dynamic content is generally not cacheable. It describes factors used to decide cache behavior, including cache level, origin cache-control headers, origin headers that indicate dynamic content, file extension, query string and cookies. It describes response states such as HIT, Miss and Expired and explains edge and browser time-to-live controls. It also says the minimum cache time depends on plan, with the free plan having a much higher minimum than enterprise.

Those details are commercially relevant. They mean that a free or entry-level test may not behave like an enterprise configuration, especially for sites with rapidly changing assets.

The cache documentation also exposes recovery features and responsibility boundaries. It describes selective purge and full purge, and warns that full cache clearing can slow the site while content is cached again. It describes an "always available" mode where previously cached content can be served if the origin server is unavailable, until the origin returns. That is a useful resilience feature, but it is bounded by cache state. It does not replace origin backup, application recovery or database continuity. It is best read as a last-known-good static delivery tool for cacheable responses, not a general disaster-recovery guarantee.

HTTPS controls add another layer. MizbanCloud's documentation separates the connection between browser and edge from the connection between edge and origin. It says customers can use a free MizbanCloud SSL certificate or upload their own certificate. It describes HSTS, automatic HTTP-to-HTTPS behavior and the ability to set a minimum TLS version. These are normal CDN controls, and their presence matters. A buyer should still test certificate issuance time, renewal behavior, CAA interactions, origin certificate validation, HSTS scope and rollback procedures before sending production traffic through the edge.

Security documentation lists four CDN-related security surfaces: firewall, web application firewall, DDoS protection and rate limiting. DDoS documentation says default rules address layer 3 and layer 4 attacks after the domain is connected to the CDN, while stronger layer 7 strategies involve cookie, JavaScript and captcha challenges. Rate-limit documentation describes per-IP limits over a chosen interval and says excess requests can produce HTTP 429 responses. Page-rule documentation shows that some security choices can be scoped to particular paths. That is a useful control surface, especially for login pages, forms and API-like endpoints.

It also introduces risk if rules are changed without change control or if a security level blocks legitimate users during an attack.

Reporting documentation is one of the better signs of an operating product because it describes the customer's view after traffic is flowing. MizbanCloud says CDN reports include traffic analysis, geographic location, WAF log analysis, error analysis and status analysis. The traffic section says the dashboard can show detailed visitor information from the past three hours to the past 30 days, and can distinguish traffic answered by the CDN from traffic sent to origin. The language around cached and missed requests gives customers a basis for measuring cache effectiveness.

It does not prove the accuracy of the reports, but it gives a buyer something to compare against server logs, synthetic probes and analytics data during a pilot.

Taken together, the product record proves a complete intended workflow: domain delegation, DNS record migration, proxy toggles, cache rules, HTTPS controls, page-specific policies, reports, DDoS controls, rate limits and edge-origin whitelisting. That is far more than a bare CDN logo. The buyer's caution should be proportional to the role the CDN will play. If MizbanCloud is used for cacheable brochure content, the documented controls may be enough for a modest pilot. If it is used as the security front door for commerce, login, streaming or government-facing services, the public product record is only the first layer of assurance.

Network-resource evidence is useful, but it should not be overread

Network-resource evidence is the part of the MizbanCloud record that can be repeated outside the company's own website. Public BGP and IP intelligence sources identify AS34412 with Saba Abr Mizban LLC, the AS name SABA-HOST and Iranian country attribution. BGP observation pages show the AS as active and allocated under RIPE, with originated IPv4 space and upstream or peer relationships. Several listed prefixes use MizbanCloud or Saba Abr Mizban descriptions, and at least one BGP view marks the visible originated prefixes with valid RPKI certificates.

That evidence supports a basic conclusion: MizbanCloud is associated with an attributable network operator rather than only reselling another provider's front-end brand. It has public Internet number resources, visible routing and an abuse or network contact surface in downstream copies of RIPE data. Some reverse-DNS and IP intelligence pages show hostnames using cdn-by.mizbancloud.com patterns. That is relevant because a CDN's promise depends on edge addresses, route origination and origin-facing proxy behavior, not only on a dashboard.

The same evidence should not be stretched into claims it cannot support. An AS record does not prove CDN capacity, cache-hit quality, geographic coverage, DDoS scrubbing effectiveness, uptime or customer satisfaction. It says a network exists and originates address space. Prefix counts differ across public observers. One public view may show a certain number of originated IPv4 prefixes and no IPv6 at the time it is fetched; another may show additional IPv4 or IPv6 visibility. Such differences can result from vantage point, update timing, route filtering, source methodology or changed announcements.

They are not automatically evidence of instability. They are evidence that a buyer should perform live checks instead of treating a directory snapshot as a service-level statement.

The resource record also matters for origin protection. MizbanCloud's own documentation explains that when DNS records are proxied, traffic for uncached content reaches the origin from MizbanCloud edge servers rather than from the end user's IP address. It warns that the origin firewall or hosting provider may misread this traffic as hostile and block or limit MizbanCloud edge IPs, causing users to see failures. The documentation tells customers to whitelist the edge IP ranges at the origin or ask their hosting provider to do so. This is an unusually practical admission of shared responsibility.

A CDN migration fails not only when the edge fails, but also when the origin refuses the edge.

For a buyer, this turns network evidence into an operating checklist. Before a migration, the buyer should capture the current MizbanCloud edge IP range list from the provider, compare it with the AS and prefix evidence, record where the list came from, apply the list at the origin firewall, then verify that real requests reach the origin only where expected. After migration, the buyer should monitor for changed ranges, expired allowlists, proxy-off records and direct-origin leaks. The public AS record gives context, but the active edge list and origin logs decide whether the deployment is controlled.

The public resource evidence also shapes locality claims. MizbanCloud markets itself as an Iranian cloud and CDN provider and presents local support. Network records associate its AS and organization country with Iran, and several address and support records place the operating footprint in Tehran. That supports a strong Iranian-service identity. It does not prove that every edge, DNS node, upstream, support process or data path stays inside Iran. The company itself mentions datacenters and global or international reach in some product language.

A customer with data-sovereignty requirements should ask for explicit data-location, logging-location and support-access terms, then test DNS and traffic paths from the relevant user populations.

This distinction is central. For many Iranian businesses, a domestic cloud provider can reduce language friction, improve support hours, fit local payment methods and make domestic reach easier than using a purely foreign provider. For other workloads, a domestic provider may increase concentration risk, limit international performance or complicate resilience planning. Public BGP records cannot decide that trade-off. They provide the first repeatable facts on which a better test can be built.

The control surface is an automation product

Although CDN decisions are often sold around speed, MizbanCloud's public documentation makes the service look more like an automation layer for web operations. The customer is not only buying cached files. The customer is moving DNS, cache headers, proxy status, certificate handling, firewall policy, page-specific routing, reports, origin allowlists and support decisions into one provider account. That is the enterprise-software dimension of the product.

The DNS panel is the first automation point. The customer adds the domain, migrates records and chooses which records are proxied. The cloud-icon model simplifies operation for a small team, but it also centralizes risk. A wrong toggle can expose origin addresses, bypass the CDN or break services that should not be proxied. A mature use of the service therefore needs role controls, change logs, a record naming convention, staged changes and a rollback method. The public documentation describes the functions; the buyer has to ask how account permissions, audit history and emergency recovery are handled in practice.

Page rules are the second automation point. MizbanCloud documents controls for browser cache TTL, edge cache TTL, add-header and remove-header behavior, redirects, IP and country access management, rate limits, cluster assignment, connection timeouts, host-header modification, ignoring cache-control and wildcard matching. This is a powerful set of levers.

It lets a team treat different paths differently: long-lived static assets can have different cache rules from a checkout path; an administrative page can have stricter IP policy; an image-heavy section can use acceleration; a sensitive endpoint can have a rate limit; a legacy URL can be redirected without touching the origin application.

The same power raises governance questions. Page-rule conflicts can be hard to see. A wildcard can catch more paths than intended. An edge TTL can keep stale content alive after a legal, security or pricing change. A redirect can move search traffic incorrectly. Host-header modification can hide origin misconfiguration until a failover event. An ignore-cache-control rule can override application intent. These are not reasons to avoid the service. They are reasons to manage it like production configuration rather than like a marketing add-on.

Load balancing and clustering deepen that point. MizbanCloud's documentation describes distributing requests among multiple origins, with policies such as least connections, plus failover and health checks. If implemented well, that can reduce dependence on a single origin and improve resilience for high-traffic sites. But load balancing also creates state, session, data consistency and observability problems. A multi-origin deployment must answer questions about sticky sessions, database writes, file synchronization, health-check paths, maintenance windows and how the CDN decides that an origin is unhealthy.

The public page explains the concept and some controls. It does not prove that a customer's application is ready for that model.

Reporting closes the automation loop. MizbanCloud describes traffic reporting, geographic views, WAF logs, errors and status analysis, with windows from three hours to 30 days for some traffic views. That is useful for operations because it can show cache saved traffic, requests passed to origin, errors and attack-related patterns. A buyer should still compare dashboard data with origin logs and independent probes. If the CDN reports cache hits but the origin sees high load, there may be bypass paths, cookie behavior or query-string settings defeating cache.

If WAF logs show many blocked requests, the team needs a process for tuning false positives. If reports only retain a short window, the customer needs its own export or archival method for incident review.

Security controls are also automation controls. DDoS strategy levels, WAF, firewall rules and rate limits determine how the edge behaves under pressure. During normal operation, strict rules may look successful because they reduce unwanted traffic. During a real attack or flash crowd, those same rules may block legitimate users, search crawlers, payment callbacks or partner integrations. The public documentation describes challenges such as cookie, JavaScript and captcha strategies for layer 7 defense.

A buyer should test them with real browsers, mobile networks, assistive technologies and important third-party callbacks before enabling them broadly.

The automation value is clearest for organizations without a large network engineering team. A small Iranian business can move DNS, CDN, security and reports into a single Persian-language support ecosystem. That can be a rational decision if the alternative is unmanaged origin exposure and no caching discipline. The risk is that the same simplification may hide complexity until something breaks. A CDN turns many invisible web assumptions into explicit provider-managed settings. MizbanCloud documents many of those settings, which is good.

It should still be evaluated as a production control plane, with the same change discipline a buyer would apply to cloud infrastructure, DNS hosting or firewall management.

Locality and sovereignty are benefits with boundaries

MizbanCloud's Iranian identity is a core part of the commercial case. A local provider can be attractive when customers, developers, regulators, finance teams and support staff operate primarily in Iran. Persian documentation lowers training cost. Local phone and ticket support can reduce escalation friction. Domestic billing and procurement may be simpler than contracts with global hyperscale or CDN providers. If a customer mainly serves Iranian users, domestic network paths and local operational knowledge may matter more than a global map of edge locations.

The public record supports that local identity. Product and documentation pages are written for Persian-speaking operators. Support channels list Iranian phone numbers and Tehran addresses. Business-profile material identifies Tehran headquarters. Network records associate the relevant AS with Iran. MizbanCloud's own product family is built around web hosting, CDN, cloud servers, DNS, web security and video delivery for businesses that need an integrated infrastructure supplier. This makes the service commercially coherent for domestic web operations.

Data sovereignty, however, requires more than local branding. A buyer must know where logs are stored, who can access them, how long they are retained, whether support staff can inspect customer traffic metadata, where DNS data is hosted, where edge nodes are located, how origin IP addresses are protected, whether traffic for domestic users stays domestic, and what happens to data in cross-border failover or international delivery. The public pages give useful hints but not a full legal or technical answer. They say the service uses distributed infrastructure, datacenters and Anycast-like DNS language in some places.

They do not provide a complete data-processing map in the public material reviewed here.

This matters because CDN data is sensitive even when the CDN does not store application databases. DNS records reveal infrastructure layout. Cache logs reveal user behavior, paths, user agents and error patterns. WAF logs can contain request details. TLS termination can put encrypted traffic into a provider-managed edge environment. Page rules can redirect or reshape user flows. If the customer handles healthcare, finance, public-sector, media, authentication or sanctions-sensitive content, locality must be specified rather than assumed.

The locality benefit is also not the same as reliability. A domestic provider may improve some domestic paths and simplify support, but it may not match the global resilience, interconnection density or tooling of larger international networks. Conversely, a global provider may struggle with local procurement, domestic reach, Persian support or regional regulatory expectations. The right comparison is not abstract.

It depends on the traffic mix: Iranian users versus diaspora users; static content versus logged-in application flows; domestic payment integrations versus international APIs; video delivery versus low-bandwidth pages; tolerance for cache staleness versus need for immediate update.

MizbanCloud's public documentation gives enough to design a locality test. A customer can delegate a non-critical domain or subdomain, configure representative DNS records, enable proxying for web paths, set cache and HTTPS rules, apply origin allowlists, then test from Iranian networks and international vantage points. The team can compare latency, TLS behavior, cache status, error rate, origin load, WAF false positives, report accuracy and support response. That test turns locality from a slogan into a measured operating attribute.

The sovereignty question also includes exit. If the customer has moved nameservers, cache rules, redirects, WAF policies and certificates into MizbanCloud, leaving the service is not only a DNS change. The customer must export records, recreate rules elsewhere, remove edge IP allowlists, issue or move certificates, check mail and FTP records, clear stale DNS, and make sure origin services can handle direct or alternative-CDN traffic. A local provider can reduce day-to-day support friction, but the customer should preserve enough documentation and access to leave without a crisis.

Support, recovery and commercial terms are part of the service

For a CDN, support is not a side feature. DNS changes, certificate errors, WAF blocks, DDoS events, origin allowlists and cache anomalies are urgent by nature. MizbanCloud's public pages emphasize 24-hour support, including holidays, and provide phone, email and ticket channels. The about page describes phone, ticket, chat and email contact routes. That public support posture is a positive sign. It gives the customer named channels before purchase and indicates that MizbanCloud sees service support as part of its market position.

The terms narrow the picture. MizbanCloud states that advanced support plans are charged immediately for one month from the wallet when activated, and that if the wallet lacks sufficient credit while an advanced support plan is active, the plan is automatically downgraded to a lower plan. That is commercially important. A customer cannot assume advanced support remains in force if billing credit is not maintained. For a production buyer, support-plan status should be monitored like a service dependency. The finance team and operations team need shared visibility, because a wallet-balance issue can become an incident-response issue.

The same terms state that users are responsible for backing up data and installation files connected to MizbanCloud services, and that backup is not performed by MizbanCloud. This is a clear responsibility boundary. It does not necessarily apply to every cached response in the same way it applies to server or hosting data, but the practical meaning is broad: customers should not treat MizbanCloud as the sole copy of anything important. DNS zone exports, page-rule documentation, certificate materials, origin configurations, source assets, application backups and cache-purge procedures should live outside the provider account.

The free-service terms are also important. MizbanCloud says it has no obligation to continue providing free services and may modify them or make them paid. It also says dedicated support and some other services may not be available for free services. This is a normal commercial clause, but it limits how much confidence a customer should draw from a free plan. A free CDN or DNS test can prove basic workflow and compatibility. It should not be the basis for assumptions about production support, minimum TTL, service continuity or pricing stability.

Pricing terms add another operating condition. MizbanCloud says customers are responsible for knowing tariffs before using services and should continuously visit the pricing page for updates; it also says changes are communicated by email or site news and apply after notification. That means a cost-sensitive buyer should automate or calendar pricing review, especially if traffic, request volume or support plan status can shift costs materially. CDN economics can change quickly when cache misses rise, video delivery grows, attacks inflate requests or a campaign creates traffic spikes.

Recovery features exist but are bounded. The cache documentation's "always available" behavior can serve previously cached responses when the origin is down. Load-balancing documentation describes failover among origins. DDoS and rate-limit controls can reduce unwanted traffic. These are useful resilience tools. They do not remove the customer's need for origin backup, data recovery, application failover, monitoring, incident communications and an exit plan. A CDN can buy time during an outage. It cannot recover uncached dynamic data or guarantee that every user path remains functional if the origin application is unhealthy.

Support accountability should therefore be tested before commitment. A buyer should open pre-sales and support tickets with specific technical questions: How are edge IP ranges updated? How are emergency DNS changes handled? Is there an account recovery path if the main administrator is unavailable? What is the procedure for certificate failure? Can page rules be exported? How are WAF false positives escalated? What support response is included at each plan level? The quality of those answers will say as much about the service as the feature list.

The local-support labor theme is especially relevant here. MizbanCloud's value may depend on people who can answer in Persian, understand local hosting panels, coordinate with domestic networks and help small teams execute CDN changes safely. That human support layer can be a strength if it is staffed, trained and accountable. It can also be a weak point if support is opaque, plan-gated or poorly documented. The public record confirms support channels and some terms. It does not prove support quality. Buyers should make that a testable part of procurement.

The buyer's verification plan

A practical MizbanCloud evaluation should begin with identity. The customer should record the brand, legal counterparty, billing entity, contract name, AS owner, domain, support contact and abuse or network contact. The record should explain how Saba Abr Mizban LLC, Saba Hour Yeganeh Co., MizbanCloud and any related hosting brand appear in the customer's documents. This may feel administrative, but it matters during disputes, abuse reports, outages and renewals.

The next step is DNS. The customer should create a non-critical pilot domain or subdomain, move the relevant records into MizbanCloud, enable proxying only for intended HTTP and HTTPS records, keep mail and FTP outside the proxy path, and document the nameserver change. The team should measure propagation, record any mismatch between provider dashboard status and public DNS, and rehearse rollback to the previous DNS host. If the customer cannot roll back safely during a test, it should not attempt a production migration.

Cache testing should use real assets and real edge cases. Static images, JavaScript, CSS, query-string assets, cookie-sensitive pages, dynamic pages and private pages should each be tested. The customer should inspect HIT, Miss and Expired behavior, compare edge cache TTL and browser cache TTL with origin headers, test selective purge and full purge, and confirm that "always available" behavior does not serve unacceptable stale content. For news, pricing, legal pages, inventory or account states, stale cache is not a minor defect. It can be a business risk.

HTTPS testing should cover certificate issuance, custom certificate upload, renewal, minimum TLS settings, HSTS behavior and HTTP-to-HTTPS redirects. The customer should verify the path from browser to edge and from edge to origin, because a green lock at the browser does not prove the origin leg is configured as intended. The team should know how to recover from a certificate mistake without waiting for a crisis.

Security testing should be deliberate rather than theatrical. Rate limits should be tested against normal users, search crawlers, payment callbacks and API clients before being used to block attackers. WAF and DDoS strategies should be piloted on selected paths, then monitored for false positives. IP and country rules should be treated as sensitive production changes. The question is not whether a rule can block traffic. It is whether the rule blocks the right traffic while preserving important user flows.

Network testing should compare public resource records with observed behavior. The customer should record the current AS and prefix evidence, retrieve the provider's edge IP list, apply origin allowlists, then confirm through origin logs that proxied requests arrive from expected ranges. Synthetic tests from Iranian and non-Iranian vantage points should measure latency, availability, TLS negotiation, cache status and error rates. The results should be archived with dates, because routing and edge behavior can change.

Support testing should happen before an incident. The customer should ask a technical question through ticket, email and phone, record response time and answer quality, and compare the result with the promised support plan. It should also verify account recovery, emergency contact options, weekend support and escalation routes. If advanced support depends on wallet credit, the customer should monitor wallet status and identify who can top it up.

Finally, exit testing should be part of onboarding. The customer should export or document DNS records, page rules, cache settings, certificate choices, WAF rules, origin allowlists and reporting needs. It should know how to move away from MizbanCloud without losing mail, breaking redirects, exposing origin addresses or leaving stale nameservers behind. A provider becomes safer when the customer knows how to leave it calmly.

Verdict

CDN-MizbanCloud deserves neither dismissal nor blind confidence. The public record shows a real Iranian cloud-infrastructure service with a coherent CDN control surface. The documentation is practical in places where weak providers often stay vague: nameserver migration, DNS record proxying, origin whitelisting, cache behavior, HTTPS settings, page rules, reporting, DDoS strategy, rate limiting, clustering and support terms. Public network records give the service an attributable AS and route-resource footprint. The company is easier to evaluate than a thin reseller page.

The caution is that most of this evidence is provider-authored or directory-style. It tells a buyer what MizbanCloud says it offers and how the service is meant to be configured. It does not independently prove real-world edge performance, outage behavior, support quality, attack handling, report accuracy, data-location guarantees or migration outcomes. Public BGP evidence supports the existence of a network operator; it does not certify the CDN as reliable for every workload.

The best commercial case for MizbanCloud is specific. It may fit Iranian organizations that value Persian documentation, local support, domestic procurement, integrated DNS and security controls, and a provider familiar with local hosting practices. It may be less suitable for customers that need globally benchmarked edge reach, independently audited service levels, complex multi-region failover or strict data-processing contracts that are not visible in public material.

For a buyer, the decision should be made through a staged service test, not through the CDN label alone. Start with a low-risk domain. Verify identity and support. Move DNS carefully. Test cache and TLS behavior. Compare reports with origin logs. Confirm edge IP ranges and allowlists. Exercise WAF, rate-limit and DDoS controls on narrow paths. Measure domestic and international performance. Document exit. If MizbanCloud passes those tests, the public record gives enough surface to justify a broader deployment.

If it fails them, the problem is not that the company lacks a website or an AS; it is that the operating proof did not keep pace with the assurance implied by the name.