Why is TikTok unable to access my website hosted on a DigitalOcean Droplet?

Question

Hello,

I am hosting my website, https://cizeex.com/, on a DigitalOcean Droplet, and I am experiencing an issue where TikTok is unable to access or validate my website URL.

TikTok rejected the Website URL field and provided the following message:

“Website is not accessible. Invalid Website URL.”

The URL I submitted is:

https://cizeex.com/

From my side, the website appears to be publicly accessible and works normally in browsers.

I have already checked and configured the following:

UFW Firewall is enabled and configured to allow web traffic.
My Droplet is publicly accessible.
HTTPS is enabled.
I created a static index.html page that is separate from my Angular SPA, in case TikTok’s crawler has issues rendering the SPA.
The domain is pointing to my DigitalOcean server.

Could there be anything at the DigitalOcean, network, firewall, SSL, DNS, or server configuration level that might prevent TikTok’s crawler or external services from accessing my website?

I would appreciate any guidance on how to test whether my website is accessible specifically to external crawlers or bots and whether there are any DigitalOcean settings I should check.

Thank you.

KFSys · Answer

Heya, Good news first: I tested https://cizeex.com/ from outside, and your server is not the problem . I ran through every layer you listed and it passes all of them. Let me show you the evidence, because it lets you stop looking at the Droplet and start looking in the right place. ## What I verified from outside your network Check Result DNS (A record) 146.190.48.71, DO nameservers, www CNAME correct ✅ TLS chain Complete — leaf → Let’s Encrypt YE1 → ISRG Root. Verify return code: 0 (ok) ✅ Cert coverage cizeex.com, www.cizeex.com, api.cizeex.com, valid to Oct 19 ✅ TLS versions 1.0, 1.1, 1.2, 1.3 all accepted ✅ SNI Handshake succeeds with and without SNI ✅ http:// → https:// Redirects cleanly, www and apex both land on the canonical URL ✅ Bot user-agents Bytespider, TikTokBot, facebookexternalhit, curl, empty UA — all HTTP 200 ✅ robots.txt Allow: / — nothing blocking a crawler from the homepage ✅ Rate limiting 20 sequential + 10 parallel requests, 0 failures ✅ Crawler-visible HTML Title, og:title, og:description, og:image, og:url, twitter:card all present, ~1,500 chars of real text with no JS required ✅ Domain age Registered 2024-07-22 — over two years old, not a “new domain” flag ✅ Your prerendered-for-bots approach worked, by the way. I fetched with ByteDance’s Bytespider UA and got a fully populated page with a real title and OG tags, no JS execution needed. That was the right instinct and it’s done correctly. So: UFW, DNS, SSL, and your nginx config are all fine. Nothing at the DigitalOcean level is blocking TikTok. ## The one command that settles this Before changing anything, check whether TikTok’s crawler ever actually reached you: sudo grep -iE 'bytespider|tiktok|bytedance' /var/log/nginx/access.log This is the whole ballgame: Hits appear → your server served them fine, and TikTok is rejecting the URL for content or policy reasons, not reachability. No amount of server config will fix that. Nothing at all → the request genuinely never arrived, and it’s a network/geo/reputation issue between them and you. Widen it if your logs rotate: sudo zgrep -ihE 'bytespider|tiktok|bytedance' /var/log/nginx/access.log* My strong suspicion is you’ll find hits, because the site answers every bot UA I threw at it. ## Three things worth fixing anyway 1. Your Droplet has no IPv6. There’s no AAAA record for the domain. That isn’t an error — crawlers dual-stack and fall back to IPv4 — but ByteDance’s infrastructure is heavily IPv6, and it’s cheap to rule out. Enable IPv6 on the Droplet (Networking tab → Enable IPv6), configure the interface, then add the AAAA record in DO’s DNS panel. Make sure nginx is actually listening: listen [::]:443 ssl; 2. Your TTFB is ~800 ms, and ~390 ms of that is server think time — for a static HTML file. Full breakdown from my location: tcp=0.200 tls=0.415 ttfb=0.805 total=1.002 nginx serving a static 64 KB file should have a think time in single-digit milliseconds, not 390. Something is proxying that request — likely proxy_pass to your Angular/Node backend even for the prerendered page. Worth checking, because your Droplet is in Santa Clara and TikTok validates largely from Asia. From Singapore you’re looking at ~180 ms RTT, tripled by the TLS handshake, plus your 390 ms — that can land near 1.5–2 s, which is uncomfortably close to the timeout some validators use. Serving that file directly with try_files instead of proxying would cut it dramatically. 3. HTTP/2 isn’t enabled — ALPN only offers http/1.1. Not a crawler blocker, but free to turn on: listen 443 ssl; http2 on; While you’re in there, TLS 1.0 and 1.1 are still accepted. Nothing to do with TikTok, but they’re deprecated and worth dropping: ssl_protocols TLSv1.2 TLSv1.3; ## Testing external accessibility properly Since you asked specifically how to test this — the trick is to test from outside your own network and region : # What a crawler sees, no JS curl -A "Mozilla/5.0 (compatible; Bytespider; https://zhanzhang.toutiao.com/)" -I https://cizeex.com/ # Full timing breakdown curl -s -o /dev/null -w "tcp=%{time_connect} tls=%{time_appconnect} ttfb=%{time_starttransfer}
" https://cizeex.com/ # Verify the TLS chain is complete for non-browser clients echo | openssl s_client -connect cizeex.com:443 -servername cizeex.com 2>/dev/null | grep "Verify return code" For the geography question specifically: spin up the cheapest Droplet in SGP1 (Singapore) for an hour, curl your site from it, then destroy it. That costs a few cents and tells you definitively whether the problem is regional routing. If it responds fine from Singapore, reachability is conclusively ruled out. ## The honest conclusion Everything you listed — firewall, DNS, SSL, Droplet accessibility, SPA rendering — checks out. You’ve already done the work correctly, including the static-page-for-bots fallback that a lot of people miss. TikTok’s URL validator is unfortunately a black box and is well known for rejecting perfectly reachable sites. Practical things that have worked for others: Submit https://cizeex.com without the trailing slash Try from the mobile app rather than the web dashboard, or vice versa Wait 24–48 hours and resubmit — the check is sometimes cached against an earlier failed attempt If your TikTok account is a Business account, make sure the domain matches whatever you used for business verification Start with the access log grep though. That single command tells you whether you’re debugging your server or debugging TikTok, and right now the evidence says it’s the latter. Hope that helps!Heya, Good news first: I tested https://cizeex.com/ from outside, and your server is not the problem . I ran through every layer you listed and it passes all of them. Let me show you the evidence, because it lets you stop looking at the Droplet and start looking in the right place. ## What I verified from outside your network Check Result DNS (A record) 146.190.48.71, DO nameservers, www CNAME correct ✅ TLS chain Complete — leaf → Let’s Encrypt YE1 → ISRG Root. Verify return code: 0 (ok) ✅ Cert coverage cizeex.com, www.cizeex.com, api.cizeex.com, valid to Oct 19 ✅ TLS versions 1.0, 1.1, 1.2, 1.3 all accepted ✅ SNI Handshake succeeds with and without SNI ✅ http:// → https:// Redirects cleanly, www and apex both land on the canonical URL ✅ Bot user-agents Bytespider, TikTokBot, facebookexternalhit, curl, empty UA — all HTTP 200 ✅ robots.txt Allow: / — nothing blocking a crawler from the homepage ✅ Rate limiting 20 sequential + 10 parallel requests, 0 failures ✅ Crawler-visible HTML Title, og:title, og:description, og:image, og:url, twitter:card all present, ~1,500 chars of real text with no JS required ✅ Domain age Registered 2024-07-22 — over two years old, not a “new domain” flag ✅ Your prerendered-for-bots approach worked, by the way. I fetched with ByteDance’s Bytespider UA and got a fully populated page with a real title and OG tags, no JS execution needed. That was the right instinct and it’s done correctly. So: UFW, DNS, SSL, and your nginx config are all fine. Nothing at the DigitalOcean level is blocking TikTok. ## The one command that settles this Before changing anything, check whether TikTok’s crawler ever actually reached you: sudo grep -iE 'bytespider|tiktok|bytedance' /var/log/nginx/access.log This is the whole ballgame: Hits appear → your server served them fine, and TikTok is rejecting the URL for content or policy reasons, not reachability. No amount of server config will fix that. Nothing at all → the request genuinely never arrived, and it’s a network/geo/reputation issue between them and you. Widen it if your logs rotate: sudo zgrep -ihE 'bytespider|tiktok|bytedance' /var/log/nginx/access.log* My strong suspicion is you’ll find hits, because the site answers every bot UA I threw at it. ## Three things worth fixing anyway 1. Your Droplet has no IPv6. There’s no AAAA record for the domain. That isn’t an error — crawlers dual-stack and fall back to IPv4 — but ByteDance’s infrastructure is heavily IPv6, and it’s cheap to rule out. Enable IPv6 on the Droplet (Networking tab → Enable IPv6), configure the interface, then add the AAAA record in DO’s DNS panel. Make sure nginx is actually listening: listen [::]:443 ssl; 2. Your TTFB is ~800 ms, and ~390 ms of that is server think time — for a static HTML file. Full breakdown from my location: tcp=0.200 tls=0.415 ttfb=0.805 total=1.002 nginx serving a static 64 KB file should have a think time in single-digit milliseconds, not 390. Something is proxying that request — likely proxy_pass to your Angular/Node backend even for the prerendered page. Worth checking, because your Droplet is in Santa Clara and TikTok validates largely from Asia. From Singapore you’re looking at ~180 ms RTT, tripled by the TLS handshake, plus your 390 ms — that can land near 1.5–2 s, which is uncomfortably close to the timeout some validators use. Serving that file directly with try_files instead of proxying would cut it dramatically. 3. HTTP/2 isn’t enabled — ALPN only offers http/1.1. Not a crawler blocker, but free to turn on: listen 443 ssl; http2 on; While you’re in there, TLS 1.0 and 1.1 are still accepted. Nothing to do with TikTok, but they’re deprecated and worth dropping: ssl_protocols TLSv1.2 TLSv1.3; ## Testing external accessibility properly Since you asked specifically how to test this — the trick is to test from outside your own network and region : # What a crawler sees, no JS curl -A "Mozilla/5.0 (compatible; Bytespider; https://zhanzhang.toutiao.com/)" -I https://cizeex.com/ # Full timing breakdown curl -s -o /dev/null -w "tcp=%{time_connect} tls=%{time_appconnect} ttfb=%{time_starttransfer}
" https://cizeex.com/ # Verify the TLS chain is complete for non-browser clients echo | openssl s_client -connect cizeex.com:443 -servername cizeex.com 2>/dev/null | grep "Verify return code" For the geography question specifically: spin up the cheapest Droplet in SGP1 (Singapore) for an hour, curl your site from it, then destroy it. That costs a few cents and tells you definitively whether the problem is regional routing. If it responds fine from Singapore, reachability is conclusively ruled out. ## The honest conclusion Everything you listed — firewall, DNS, SSL, Droplet accessibility, SPA rendering — checks out. You’ve already done the work correctly, including the static-page-for-bots fallback that a lot of people miss. TikTok’s URL validator is unfortunately a black box and is well known for rejecting perfectly reachable sites. Practical things that have worked for others: Submit https://cizeex.com without the trailing slash Try from the mobile app rather than the web dashboard, or vice versa Wait 24–48 hours and resubmit — the check is sometimes cached against an earlier failed attempt If your TikTok account is a Business account, make sure the domain matches whatever you used for business verification Start with the access log grep though. That single command tells you whether you’re debugging your server or debugging TikTok, and right now the evidence says it’s the latter. Hope that helps!

alexdo · Answer

Heya, One DigitalOcean-specific layer worth adding, since it wasn’t on the list yet: you mentioned UFW is configured, but DigitalOcean Cloud Firewalls are a separate, network-based firewall enforced before traffic ever reaches the Droplet’s network interface. They’re not something UFW or iptables running on the Droplet itself would show you, and they can restrict inbound traffic by source. If a Cloud Firewall is attached to this Droplet with a rule narrower than “allow everything on 80/443,” it would silently drop the blocked packets at the network edge. That distinction also changes how to read the access-log test above. Zero hits in nginx’s access.log was framed as meaning the request never reached you at all, a network or reputation issue outside your control. That’s true for most causes, but a Cloud Firewall rule blocking ByteDance’s crawler IP ranges specifically would produce the identical symptom, since traffic it drops never reaches nginx to be logged, while still being a DigitalOcean-level setting you can actually go fix. Worth checking Networking, then Firewalls, in the control panel for anything attached to this Droplet beyond a default allow-all, before concluding the block is entirely on TikTok’s side. Regards

Bobby · Answer

alexdo’s point is the one gap worth flagging. A Cloud Firewall rule and a nginx access log miss look identical from the inside, so it’s worth checking Networking > Firewalls before ruling out anything DigitalOcean-side. If nothing is attached beyond a default allow-all, the earlier conclusion stands and this is on TikTok’s validator.

Become a contributor for community

DigitalOcean Documentation

Resources for startups and AI-native businesses

The developer cloud

Start building today

Report this

Why is TikTok unable to access my website hosted on a DigitalOcean Droplet?

Related questions

How do I display an image file that is outside the roda root folder?

Odoo 16 Server – High Outbound Bandwidth, CPU 98%, Web Console & SSH Unresponsive

Post-Incident Security Validation: Rebuild or Trust the Existing Droplet

Bug Bounty Inquiry Before Submitting Security Report

Currently, outgoing SMTP ports 587 and 465 are blocked by default on my droplet. Could you please unblock outgoing SMTP ports for my droplet

VPS de UBUNTU a Windows

Not see memory usage graph in droplet monitoring

digital ocean charged $10 but my payment method does not get verified and droplet cannot be activated

DNS problem on one site today

new DNS issue today on a website, no changes for many years

View all droplets with tag

View all droplets with a tag

Report this

Why is TikTok unable to access my website hosted on a DigitalOcean Droplet?

Related questions

How do I display an image file that is outside the roda root folder?

Odoo 16 Server – High Outbound Bandwidth, CPU 98%, Web Console & SSH Unresponsive

Post-Incident Security Validation: Rebuild or Trust the Existing Droplet

Bug Bounty Inquiry Before Submitting Security Report

Currently, outgoing SMTP ports 587 and 465 are blocked by default on my droplet. Could you please unblock outgoing SMTP ports for my droplet

VPS de UBUNTU a Windows

Not see memory usage graph in droplet monitoring

digital ocean charged $10 but my payment method does not get verified and droplet cannot be activated

DNS problem on one site today

new DNS issue today on a website, no changes for many years

View all droplets with tag

View all droplets with a tag