diff --git a/web/src/features/messages/ConversationView.tsx b/web/src/features/messages/ConversationView.tsx
index f182d932..2f390b54 100644
--- a/web/src/features/messages/ConversationView.tsx
+++ b/web/src/features/messages/ConversationView.tsx
@@ -157,6 +157,27 @@ export function ConversationView() {
         // the URL to the real name the instant it's known makes every later `getTopic(topicId)` in
         // this component resolve the SAME object subscribe() just populated, not a fresh impostor.
         if (topic.name !== topicId) navigate(`/messages/${topic.name}`, { replace: true });
+        // Real, live-confirmed gap on top of the rename issue above: for exactly this brand-new-P2P-
+        // via-alias case, `openConversation`'s own `withLaterDesc()` (an incremental "only if changed
+        // since I last knew" fetch) can come back with the subscribe successful but NO desc AND no
+        // presence at all -- `topic.public` stays permanently `null` and `topic.online` stays falsy
+        // (confirmed live: still true 10+ seconds later, no amount of waiting fixes either one),
+        // which is why the header/chat-list fall back to the raw topic id and "离线" forever on THIS
+        // specific path (reached live via a friend's profile "发消息" button, never through a fresh
+        // page load -- a full reload's own `subscribeMeTopic()` happens to paper over this by
+        // fetching every contact's full subscription state unconditionally, which is exactly why this
+        // was never caught by any test that reloaded the page as part of "opening" a conversation).
+        // `me.getMeta(withOneSub(topic))` is the same targeted-refresh call the SDK's own presence
+        // routing (`_routePres`, tinode.dev.js) uses for "just learned about this topic" -- unlike a
+        // plain desc fetch on the topic itself, this one comes back with BOTH desc AND online status
+        // in the same `sub` entry (confirmed live capturing the raw frame during an earlier
+        // investigation), and `TopicMe`'s own `_processMetaSubs` merges both onto this exact topic
+        // object before notifying -- wireTopicCallbacks already wired `me`'s `onMetaSub`/
+        // `onSubsUpdated` at login, so the response correctly invalidates the chat list once it lands.
+        if (!topic.public) {
+          const me = tinode.getMeTopic();
+          me.getMeta(me.startMetaQuery().withOneSub(undefined, topic.name).build()).catch(() => {});
+        }
       })
       .catch((err) => showError(err, '加载会话失败，请重试'));
     return () => {