Bunny CDN IP Ranges
Bunny is the content delivery network run by BUNNYWAY d.o.o. of Ljubljana, trading as bunny.net. AS200325 carries the as-name BunnyCDN in the RIPE database, where the aut-num object was created on 7 August 2018 under organisation record ORG-BISD2-RIPE, and the operator's PeeringDB entry names AS200325:AS-BUNNY as its IRR as-set, types the network as content with a heavy outbound traffic ratio, and sets peering policy to selective. The ASN is a poor proxy for the service, because most of the addresses Bunny actually serves from are announced by somebody else.
- Provider
- Bunny CDN
- Primary ASN
- AS200325
- Category
- CDN
- Headquarters
- Ljubljana, Slovenia
- Announced IPv4 prefixes
- 14
- Registry
- RIPE
Known IP ranges
These prefixes are currently announced to the global routing table by AS200325 (BunnyCDN BUNNYWAY, informacijske storitve d.o.o.). Prefix sets change over time - use WHOIS Lookup for the authoritative record on any specific address.
109.224.230.0/23
109.224.228.0/23
109.104.147.0/24
109.104.146.0/24
157.53.226.0/24
91.200.176.0/24
103.180.115.0/24
38.92.173.0/24
194.156.156.0/24
107.150.176.0/24
2400:52e0:1e05::/48
2400:52e0:1e02::/48
2400:52e0:1502::/48 (IPv6)
What does a Bunny CDN IP mean in a privacy test?
Bunny publishes the list of addresses its edge servers use, and holding that list against the routing table is the fastest way to see what an AS200325 lookup does and does not prove. The IPv4 list held 588 addresses when it was read for this page. Twenty-nine of them originate on AS200325, while 303 originate on AS60068, CDN77 Datacamp Limited, and a further 33 on AS212238, a second Datacamp ASN, which puts more than half the published fleet under one third-party company. Another 73 sit on AS24940 Hetzner and 34 on AS21859 Zenlayer, and the 588 addresses spread across 47 distinct origin ASNs in total. A request reaching an origin server from a Bunny edge will therefore usually look up as some other operator entirely, so membership of the published list, not the ASN, is the test that works.
The two address lists Bunny publishes
The main one is the edge server list, served as a JSON array from api.bunny.net/system/edgeserverlist, as newline-separated text from the same path with /plain appended, and as an IPv6 array from /ipv6. All three answered when fetched for this page. It is a list of individual addresses rather than CIDR blocks, which is what makes it usable as an origin firewall allowlist and useless as anything else: there is no country, no city, no point-of-presence code and no ASN on any line. The IPv4 array held 588 entries and the IPv6 array 323, every one distinct. Treat both counts as a snapshot, because addresses are added and retired without notice.
The second list is separate and carries a trap. Bunny's Magic Containers product publishes its node addresses at api.bunny.net/mc/nodes, and the documentation for it says plainly that the list is dynamic and should be requested periodically so that newly added addresses are not missed. What it does not stress is that the JSON form is paginated: one fetch returns an object with an items array of twenty addresses, a cursor, and meta.totalItems reading 135. Fetch it once without following the cursor and you have allowlisted twenty of 135. The /mc/nodes/plain variant returns all 135 in a single response. Neither file maps an address to a location, so the RIPE registry record and the routing table stay the only sources for who announces a given Bunny address.
Edge cache, customer container, or neither
The distinction Bunny draws is between its two published lists, and they do not overlap: comparing the 588 edge addresses against the 135 Magic Containers addresses for this page returned zero in common, so one membership test settles it. An address on the edge list is Bunny's own cache, either answering a visitor or fetching from an origin. An address on the Magic Containers list is a customer's container running on Bunny's platform, which means customer code, customer behaviour and a different set of addresses. Nothing in the ASN or the reverse DNS separates those two cases, so an origin log that needs to tell a cache fill from a tenant workload has to compare against the files rather than against a whois lookup.
The IPv6 side shows why the ASN fails even more clearly than IPv4 does. Of the 323 published IPv6 edge addresses, 233 sit inside 2400:52e0::/32, which is Bunny's own space, registered through APNIC as inet6num BISD-AP to BUNNYWAY in Slovenia rather than alongside the ASN at RIPE. But the /48s inside that /32 are split between operators: 2400:52e0:1500::/48 is announced by AS200325, while 2400:52e0:1e00::/48, which holds 31 of the published addresses, is announced by AS60068. Only 202 of the 323 fall inside a /48 that AS200325 announces, and twenty are not in Bunny space at all but inside Hetzner's 2a01:4f8::/29. Neither the announcing ASN nor the holder of the covering prefix identifies a Bunny node; the published list is the only thing that does.
Related tools
Frequently asked questions
How do I allowlist Bunny CDN on my origin server?
Fetch the edge server list from api.bunny.net/system/edgeserverlist, or append /plain for a newline-separated form that feeds straight into a firewall configuration, and /ipv6 for the IPv6 addresses. The entries are individual addresses rather than ranges and they change without notice, so the fetch needs to be automated. If you also run Magic Containers, take that list from api.bunny.net/mc/nodes/plain, because the JSON endpoint returns only twenty addresses per page behind a cursor.
Why does a Bunny CDN edge server address look up as CDN77 or Datacamp?
Because most of the fleet is announced by Datacamp Limited. Of the 588 IPv4 addresses on Bunny's published edge list when it was read for this page, 303 originated on AS60068, which is CDN77 Datacamp Limited, and another 33 on AS212238, a second Datacamp ASN, against 29 on AS200325 itself. The lookup is correct; the ASN simply is not the identifier for a Bunny node.
Does Bunny publish a geofeed or a list of point-of-presence locations?
No. Both published files are bare address lists with no country, region, city or point-of-presence code attached, and the AS200325 aut-num object carries no geofeed remark. The lists answer whether an address is Bunny, not where it is.
What is the difference between the edge server list and the Magic Containers list?
They cover different products and they do not overlap. The edge server list is Bunny's own CDN caches and held 588 IPv4 addresses when checked; the Magic Containers list, published at api.bunny.net/mc/nodes, is the nodes running customer containers and held 135. Comparing the two returned zero addresses in common, so the two products can be told apart by list membership alone.
Would a VPN exit run on AS200325?
It would be out of character for the network. AS200325 is registered as BunnyCDN and self-described in PeeringDB as a content network with a heavy outbound traffic ratio, and the machines Bunny publishes addresses for are edge caches and customer containers rather than anonymising exits. If a test shows AS200325 as a visible address, checking it against the two published lists is the first useful step, since only 29 of the 588 published edge addresses are on this ASN in any case.