ByteDance IP Ranges
ByteDance is the company behind TikTok, and AS396986 is the autonomous system its own servers answer from. ARIN registered the AS number to Bytedance Inc. on 16 August 2018, made the company a direct allocation of 71.18.0.0/16 on 16 December 2021, and had already recorded the IPv6 block 2605:340::/32 as BYTED-IPV6-01 on 18 October 2018. The same AS number also announces space that is not ARIN's: 202.52.240.0/21 falls inside an APNIC allocation held by Byteplus Pte Ltd in Singapore and registered in April 2025, so a whois on one address here and a whois on another can name two different companies in two different registries. A third record, AS138699, is registered at APNIC to TikTok Pte. Ltd. and is a separate network from this one.
- Provider
- ByteDance
- Primary ASN
- AS396986
- Category
- Cloud
- Headquarters
- Beijing, China
- Announced IPv4 prefixes
- 227
- Registry
- ARIN
Known IP ranges
These prefixes are currently announced to the global routing table by AS396986 (BYTEDANCE - Bytedance Inc.). Prefix sets change over time - use WHOIS Lookup for the authoritative record on any specific address.
202.52.240.0/21
71.18.96.0/22
71.18.84.0/22
71.18.140.0/22
71.18.108.0/22
71.18.56.0/22
71.18.16.0/22
71.18.88.0/23
71.18.36.0/23
71.18.90.0/23
2605:340:f016::/48
2605:340:f087::/48
2605:340:f0cb::/48 (IPv6)
What does a ByteDance IP mean in a privacy test?
Nothing on this network is a person's connection. ByteDance classes AS396986 as a content network in the PeeringDB entry it maintains itself, which is why an address here reaches your logs as an inbound request rather than as your own visible address. If a leak test names AS396986 as the address you are testing from, the readings worth considering are a proxy or instance rented through ByteDance's commercial arm, or a geolocation database that has misattributed the block, not an ordinary consumer line. In inbound logs the traffic is content fetching and automated crawling, and ByteDance publishes no address list to check either against, so the registry record and the routing are the only verification available. That answer differs by block, and deliberately so: part of this space is ARIN-registered to Bytedance Inc. in the United States, part is APNIC-registered to Byteplus Pte Ltd in Singapore, and both point abuse at the same mailbox.
What ByteDance publishes about its address space
ByteDance publishes no address list of any kind - no geofeed on the ARIN or APNIC objects, no firewall allowlist, and nothing that identifies which of its addresses run a crawler. What it does publish is a peering page at bytedance.com/en/peering, which names AS396986 as the network, states that ByteDance also manages AS138699, asks peers to set a max-prefix of at least 30 IPv4 and 10 IPv6 routes, requires that routes sent to it pass ROA validation as valid rather than unknown, and directs requests to peering@bytedance.com. Its PeeringDB entry adds an IRR AS-SET of AS-BD, a selective peering policy, and a note pointing at a portal at peering.byteintl.com.
Those max-prefix figures are guidance for bringing up a session and they sit well below the number of prefixes this AS number carries today, so read the page as a contact point rather than an inventory. To verify an address, run RDAP against the address itself and read which registry answers. Space inside 71.18.0.0/16 returns the ARIN handle NET-71-18-0-0-1, netname BYTED, a direct allocation to Bytedance Inc.; the Singapore space returns an APNIC object named BYTEPLUS-SG held by Byteplus Pte Ltd, with its own incident response team object IRT-BYTEPLUS-SG. The two records share an abuse address, bd_abuse@bytedance.com, which is the single field that ties them to the same operator without relying on a third-party attribution list.
ByteDance servers, BytePlus tenants and TikTok's other network
Hostname-based attribution does not work on this network, because no name comes back at all. A reverse lookup inside 71.18.0.0/16 does not return NXDOMAIN the way genuinely undelegated space would; the delegated nameservers refuse the query outright, and the Singapore space behaves the same way, so there is nothing here resembling the subscriber pool naming that fills a consumer ISP's zones. There is also no carrier-grade NAT layer to reason about and no household sharing an exit, because there are no subscribers: every address is a machine ByteDance or one of its business units runs, which is also why inbound connections from this space are normal and outbound sessions from a consumer device are not.
Separating ByteDance's own traffic from a tenant's therefore comes down to the registry. ARIN records 71.18.0.0/16 as a direct allocation to Bytedance Inc. rather than to a downstream, and the smaller prefixes this AS number announces out of it resolve back to that one handle rather than to separate registrations, so an address there is ByteDance's own. The Singapore space is held by a different legal entity, Byteplus Pte Ltd, the name under which ByteDance sells cloud and delivery services, so traffic from it can belong to a paying customer's workload rather than to TikTok. AS138699, registered at APNIC to TikTok Pte. Ltd. on 13 March 2019 as TIKTOK-AS-AP, is a different network again: an address on it is not on AS396986, and its registry record and contacts are its own.
Related tools
Frequently asked questions
Does an address on AS396986 belong to TikTok?
It belongs to ByteDance, which owns TikTok, and ByteDance lists TikTok as the alternate name on its own PeeringDB entry. TikTok also has a network of its own, AS138699, registered at APNIC to TikTok Pte. Ltd., so an address can be TikTok-related without being on either one.
Should I worry about a ByteDance address in my logs?
Nothing on this network is a person's connection. ByteDance classes AS396986 as a content network in the PeeringDB entry it maintains itself, which is why an address here reaches your logs as an inbound request rather than as your own visible address. If a leak test names AS396986 as the address you are testing from, the readings worth considering are a proxy or instance rented through ByteDance's commercial arm, or a geolocation database that has misattributed the block, not an ordinary consumer line. In inbound logs the traffic is content fetching and automated crawling, and ByteDance publishes no address list to check either against, so the registry record and the routing are the only verification available. That answer differs by block, and deliberately so: part of this space is ARIN-registered to Bytedance Inc. in the United States, part is APNIC-registered to Byteplus Pte Ltd in Singapore, and both point abuse at the same mailbox.
Does ByteDance publish a list of its IP ranges?
No. There is no geofeed on its ARIN or APNIC records, no allowlist file, and no published set of crawler addresses. The nearest thing is the peering page at bytedance.com/en/peering, which names the AS numbers and a contact but lists no prefixes, so verification has to be done by looking up the address in the registry.
Why does whois return Byteplus Pte Ltd for some of these addresses?
Because AS396986 announces space registered in two places. The United States blocks are ARIN allocations to Bytedance Inc., while blocks such as 202.52.240.0/21 sit in an APNIC allocation to Byteplus Pte Ltd in Singapore. Both records send abuse to the same address at bytedance.com.
Can a VPN exit or proxy run on this network?
Not on the space ByteDance runs for itself, which carries its own servers. The Singapore side is held by the entity that sells ByteDance cloud and delivery services, so a customer workload there could in principle answer as a proxy, which is the one route by which a test might report this network as your visible address.