Xiaohongshu (RedNote) note link returns 404 or error 300031? Check the xsec_token

Every row below was measured on 2026-11-02 (Malaysia time) from an ordinary home connection: curl requesting the page the way a phone browser does, no login, no cookies, one public note. Only results that repeated on every try are listed.

Short answer: a Xiaohongshu note page is served only with its share token, xsec_token. A bare /explore/<id> or /discovery/item/<id>, or a token with one character wrong, is redirected to /404/sec_… (the address says source=xhs_sec_server). In a browser that page reads 「页面不见了」, "page not found" — exactly what a deleted note shows. The fix is the same every time: open the note in the app, tap Share → 复制链接 (Copy link), and use that whole link.

One note, nine ways of writing its link

The link is the short link already published in our September post, https://xhslink.cn/o/AxnRePgIokn; the note id is 6a9d0eb2000000002a024480.

Three things follow:

1. The token is required, and xsec_source matters too. The same token without xsec_source failed on the /explore/ form.
2. The 404 does not say why. Missing token, wrong token, private note, deleted note: all land on the same /404/sec_….
3. The international domain behaves the same. rednote.com adds error code 300031, but the cause is just as hidden.

The three usual mistakes

Copying the address bar instead of the share link. Addresses typed from a screenshot, taken from a search result or "cleaned up" usually end at /explore/<id>. Only the app's Share → Copy link carries the token.

Code that strips the query string. URL normalisers often drop every parameter, or keep only the id as a cache key. For Xiaohongshu, xsec_token and xsec_source must travel with the request. Drop them from the cache key, never from the request.

Retrying in a loop. In this test the same full link returned the note on the first request and a 404 after a dozen requests in a row; a while later it opened again. When a read fails, pause instead of hammering. That is the platform's security layer, and pushing on it gets nowhere.

How long does a token last?

Xiaohongshu does not say. Two observations:

• The short link above, published on 2026-09-10, still opened on 2026-11-02, 53 days later, and still resolved to the same token.
• Another short link from 2026-09-08, xhslink.com/o/1WiQ1QI6Uc0, now resolves to /404/sec_…. From outside there is no telling whether the token expired or the note went private or was deleted.

So in practice: on a 404, get a freshly copied link first. If a fresh link also 404s, the note is most likely gone.

If you are writing the fetcher

• Keep the whole share link, xsec_token and xsec_source included. Never rebuild /explore/<id> yourself.
• Accept both short-link domains, xhslink.com and xhslink.cn (why).
• Treat a redirect to /404/sec_… or /login as an explicit failure that asks for a freshly copied link, not as a success with an empty body.
• Don't push through it with retries, rotating exits or someone else's cookies. What can be read is the public share page; when it can't be read, say so.

What LinkDigest answers in each case

LinkDigest reads Xiaohongshu from the public page a share link opens: the caption, the text in every image, a video's transcript and the top comments the share page shows, as text an AI can use. For the cases above its answers are fixed:

• No token in the link: it says the link carries no share token, that Xiaohongshu shows "page not found" for those exactly as for a deleted note, and asks for the link from Share → 复制链接. Nothing is charged.
• A token, and still refused: it says the token may have expired or the note is private or deleted, and asks for a fresh share. Nothing is charged.
• The home or explore feed: it says that is not a note link.

No account is logged in, nobody's cookies are used, no verification is bypassed. Connect it with one line of MCP or the HTTP API (docs), or paste one link on the home page to try it. Also in Chinese: 小红书链接打开是 404？.