Telegram RegisterThe public register of Telegram

Channel

蛋总的圈

@emoegg

On this record: Growth · Engagement · What this channel posts · Reactions · Posts · Citations · Cite this entry

204subscribers

+0 since we began measuring on 7 August 2026

Risers and fallers across the register · movement among entries of Under 1,000.

Register entry

Telegram ID-1002070574431
TypeChannel
Username@emoegg
Description(本频道主攻安卓PC端,软件网站等应有尽有) ❶不定期分享有趣好玩的内容 ❷日更(看在我这么努力,不要下次一定哦) ❸内容覆盖范围广,各取所需就好啦 频道备份➡️ @emoegg1 私聊➡️ @doubleeggbot
CreatedBetween 1 November 2023 and 31 May 2024— estimated from Telegram’s id allocation, not measured. How this range is calculated.
First recorded8 August 2026
Last confirmed live8 August 2026
Measurements held2
On Telegramt.me/emoegg

Growth

2047 Aug 2026, 12:25 — 204 subscribers8 Aug 2026, 11:18 — 204 subscribers7 Aug 2026, 12:258 Aug 2026, 11:18
2 measurements taken within a single day. Dots are measurements; the straight line between them is drawn to join them, not to claim we know the path taken in between — snapshots are recorded only when a count changes, so gaps mean “no change observed”, never “interpolated”. The vertical axis spans 203–205 and does not start at zero.
Measurement log — every subscribers count we have recorded
Measured (UTC)SubscribersChange
8 Aug 2026, 11:18204no change
7 Aug 2026, 12:25204first reading

Engagement

18 posts held, back to 17 December 2024the reader has not yet reached the start of this channel’s public history, so older posts may sit further back, unread. Read across 1 pageof Telegram’s post history, 20 posts per page.

Nothing published in the last 30 days. ERR and ER are rolling 30-day measures, so there is nothing to compute — we hold 18 posts for this entry, the most recent from 10 October 2025. An engagement rate over an empty window would be a number about nothing.

What this channel posts

Photos
26
Videos
2
Links
144

Lifetime counters from Telegram’s own channel header, read 8 August 2026 — not the date at the top of this page, which is when the subscriber count was last read. Below Telegram’s rounding threshold, so these counts are exact.

Reaction mix

8 reactions across 3 posts, in 2 distinct kinds. The most used accounts for 87.5% of them.

Every reaction kind recorded on the sample, most used first
ReactionCountShareShare, drawn
❤‍🔥787.5%
112.5%

No sentiment is inferred, and none should be read in. This table is ordered by count and by nothing else. Emoji do not carry stable meaning across languages or communities — 🙏 is thanks in one channel and mourning in another — so we publish which ones were pressed and how often, and pass no judgement on what an audience meant by them.

Precision. Telegram publishes reaction counts per emoji and short-forms each one — 4.34K, 1.2M — so any single kind at or above 1,000 reaches us at three significant figures, and only counts below 1,000 are exact. The shares above are ratios of those figures and carry the same error. This is also why the total here can differ slightly from a reaction total printed elsewhere on the page: both are sums of the same rounded parts, taken over samples with different edges.

Coverage. Reactions were read on 4 of the 18 sampled posts in this sample. Summed by Telegram’s own count on each post — not by adding up the per-emoji breakdown above — those same posts carry 8reactions in total: the kind of figure the paragraph above means by “a reaction total printed elsewhere on the page”.

Measured over the 18 most recent posts we hold, published 17 December 2024 to 10 October 2025, using the newest reading held for each. Telegram Stars are excluded: they are a payment, not a reaction, and they have their own section.

Recent posts

10 Oct 2025, 17:07 UTC281 views0 reactionsread 8 August 2026
Forwarded from @haitun_channelFile

《SS / Trojan 刷网页的实际延迟对比:下篇》 可能有人想问 v2ex.com 不是有挂 Cloudflare CDN?难道CDN不能改善加载耗时吗? 3️⃣ 访问挂载 CDN 的网站,其 #动态文件 的加载延迟依然对「用户侧耗时」拖后腿,属于压死骆驼的最后一根稻草。 例如 v2ex,其静态文件(CSS、部分图片)可通过 CF 全球/就近分发,但动态内容(帖子、评论等)则必须从美国 #建站鸡 拉取。 ➤#动态文件 链路:🇺🇸源服务器 ➜节点 ➜你家,越接近 “直线” 就越快。 ➤#静态文件 链路:🌎临近CDN ➜节点 ➜你家,就近分发。 再回头看图,就不难理解为何从快到慢依次是 🇺🇸 <🇯🇵 <🇭🇰 <🇩🇪。 🇺🇸节点对 #美国鸡 有东道主优势。 4️⃣ 那么,所有的 CDN 都无法扭转东道主优势吗? 答案:未必,要看网站类型。例如 #油管 (某种程度上) 、#网飞 等以分发静态视频为主的网站,其体验又主要由

Signed 被强煎的蛋

9 Oct 2025, 19:36 UTC239 viewsread 8 August 2026
Forwarded from @haitun_channelFile

《SS / Trojan 刷网页的实际延迟对比:上篇》 不少一/二线同时提供 SS+Trojan 协议。众所周知的是,这俩虽然 RTT 相同,但因 Trojan 多一次握手,所以其 HTTP(S) 延迟 > SS协议。那么,优先选 SS 吗? 此时,有必要引入一个相关的问题/争议。不少人认为,HTTP(S) 延迟才最反映刷网页的实际体验。沿着这一逻辑,继而认为,SS 协议的 HTTP(S) 延迟更低,那么在日常使用中就应优先用 SS 节点。 部分人的观念:RTT 延迟对于日常网页毫无参考价值,仅供意淫之用…🥲 👉 问题来了,节点『HTTP(S) 延迟』真的最能反映 “刷网页的实际耗时” 吗⁉️ 省流:不能,其参考价值还不如 RTT ! ————— 对此,本文专门进行检验,得到了一些有趣的发现: 1️⃣ 相同入口-相同专线-相同落地,同时搭 #SS 和 #Trojan 节点,两者 HTTP 延迟差异较大(≈1次 RTT)

Signed 被强煎的蛋

9 Oct 2025, 12:59 UTC85 viewsread 8 August 2026
Forwarded from @haitun_channelFile

《参数汇总:代理工具的协议支持 & Apps与通用核心的隶属》 如两张图所示 VLESS 家族过于庞大,仅节选机场节点常用的特性/分支。 待有统计数据后,会再补充一些信息…… To be announced…… 网页版地址: https://www.haitunt.org/cheatsheet.html ⚠️ 这不是一份测评,而是纯粹的协议参数汇总表 #app #协议 #代理工具 #代理核心 #代理协议 #mihomo #singbox #xray #v2ray #v2fly #dae #大鹅 #surge #小火箭 #loon #stash #qx #surfboard #vless #reality #encryption #hy2 #anytls #windows #win #macos #linux #openwrt #路由器 #华硕 #小米 #软路由 #插件 #内网穿透 #参数 #速查手册 #cheatshe

Signed 被强煎的蛋

7 Oct 2025, 18:54 UTC116 viewsread 8 August 2026
Forwarded from @haitun_channelFile

《参数汇总:代理工具的协议支持 & Apps与通用核心的隶属》 如两张图所示 VLESS 家族过于庞大,仅节选机场节点常用的特性/分支。 待有统计数据后,会再补充一些信息…… To be announced…… ⚠️ 这不是一份测评,而是纯粹的协议参数汇总表 #app #协议 #代理工具 #代理核心 #代理协议 #mihomo #singbox #xray #v2ray #v2fly #dae #大鹅 #surge #小火箭 #loon #stash #qx #surfboard #vless #reality #encryption #hy2 #anytls #windows #win #macos #linux #openwrt #路由器 #华硕 #小米 #软路由 #插件 #内网穿透 #参数 #速查手册 #cheatsheet

Signed 被强煎的蛋

8 Aug 2025, 16:12 UTC342 viewsread 8 August 2026

TUN系统协议栈**不支持UDP**,只支持TCP。相关主流TUN堆栈(如 Clash、Mihomo 等)的协议栈说明如下: - system 堆栈**:使用系统协议栈,可以提供更稳定/全面的 TUN 体验,但只支持TCP流量,不支持UDP流量;UDP被操作系统直接处理,实际上不会被转发到 TUN 用户空间实现中[2]。 - **gvisor 堆栈**:通过用户空间实现协议栈,既能处理TCP,也能处理UDP,但在某些场景下性能略差[2]。 - **mixed 堆栈**:TCP 走 system 堆栈,UDP 走 gvisor 协议栈,这样可以实现更全面的协议支持[2]。 当前大多数 TUN 相关应用(比如 Clash Premium、Mihomo)都建议在需要 UDP 代理支持时,选择 gvisor 或 mixed 协议栈;如果只需要 TCP 代理,可以优先选择 system 协议栈以获得更低资源占用和更高兼容性[1][2]

Signed 被强煎的蛋

1 Jun 2025, 16:50 UTC358 views2 reactionsread 8 August 2026

#机场知识库 GFW的墙中之墙:地区防火墙审查 众所周知,中国通过“防火长城”(GFW)实施集中统一的互联网审查,主要手段包括DNS投毒污染、关键字过滤、IP封锁等。这些技术部署中国国家边界网关路由网络设备上,对进出境流量统一管理,国内流量通常不受影响。 但是在上篇末尾(中国防火长城(GFW)DNS 注入系统中存在严重的内存泄露漏洞) 来自本篇编辑的话中提到了新疆、河南、福建、江苏4个省份地区性防火墙, 本篇就已劳务中心河南省、反诈系统先锋江苏省、 独立反向墙新疆维吾尔自治区的地区性防火墙审查进行一定的研究。 河南省防火墙部署于省内运营商出口,单向过滤(仅拦截出省流量)、统一基于TLS SNI与HTTP Host字段的域名过滤、只能注入带10字节Payload的RST封包,不支持TCP/TLS重组等特点,同时存在解析TCP报头长度的缺陷。 相对来说河南防火墙技术局限于简单的关键字匹配和单向拦截。 但是河南防火墙的黑名单封锁策

❤‍🔥2

Signed 被强煎的蛋

1 Jun 2025, 16:49 UTC298 views2 reactionsread 8 August 2026

#机场知识库 中国防火长城(GFW)DNS 注入系统中存在严重的内存泄露漏洞 中国防火长城(GFW)的DNS注入系统部署在网络边界的中间设备上,该系统监控并干扰DNS查询,通过发送伪造的DNS响应来阻断对特定网站的访问。这些伪造的响应速度较快,从而使客户端优先处理它们。GFW的DNS注入既处理来自中国境内的查询,也处理进入中国的查询。例如,如果境外的主机向一个位于中国大陆的IP地址发送DNS请求,只要请求中包含了被封锁的域名,GFW就会在流量进入中国时插入伪造的响应。 Wallbleed是GFW DNS注入模块中的一个严重漏洞,类似于Heartbleed。该漏洞源于DNS报文解析代码的缺陷,尤其是在处理DNS查询的域名(QNAME)时,未能正确检查域名标签的长度是否超出了报文的实际长度。当发送畸形的DNS查询,其域名标签的长度字节被故意设置得过大时,就会触发这个漏洞。这导致GFW的注入器错误地读取了报文末尾之外的内存内容,

1❤‍🔥1

Signed 被强煎的蛋

24 Jan 2025, 03:08 UTC689 viewsread 8 August 2026
File

#QQ音乐 flyme定制版 v11.3.1 作者:wushidi 频道:某不知名杂货铺

Signed 被强煎的蛋

Showing the 12 most recent of 18 posts we hold for @emoegg. View and reaction counts are the latest single reading for each post, not a live figure, and a recent post is still accumulating both. A view count marked was rounded by Telegram before we ever saw it — t.me prints views in full below 1,000 and to three significant figures above, so ≈1,200,000 means somewhere between 1,150,000 and 1,249,999. Unmarked counts are exact. Text is reproduced from the public post preview and truncated for length.

Citation-graph rank

Citation-graph rank — 1,227,935 of 1,478,351entries in the measured graph. A weighted position computed from the forward and mention edges below — republished posts weigh more than named mentions — and recomputed periodically, over the whole graph. Published only as this ordinal position, never as a score: a position is a fact, and a score printed beside one channel’s name would read as a verdict this register does not make. The two counts beneath stay separate for the same reason mentions are never summed with forwards anywhere else on this page — a named-by count costs nothing to manufacture. The top 100 by this measure, or how it is computed.

Forward network

Republishes

Channels on the register whose posts this channel has forwarded.

Built only from forwarded posts we have actually read, on both sides. Coverage is early and deliberately incomplete: a missing link means we have not read the post that would prove it, never that the relationship does not exist. Counts are distinct forwarded posts observed, so they only ever go up as we read more.

Mentions

Named by 1 registered channel — every channel on the register whose own posts have named this one, by its current username or any other username it currently holds, merged from two separately captured readings of the same fact so a namer caught by only one of them is not missed and a namer both caught is not counted twice. A username this channel has since dropped is not matched — that handle may belong to someone else now, and crediting today’s namer to yesterday’s owner would misattribute it.

Named by

Channels on the register whose posts name this channel's handle.

A mention is a weaker signal than a forward and is counted separately for that reason — naming a channel is not republishing it, and a handle in a post body is easy to place deliberately. The post counts beside each row below are distinct posts in which the handle appeared, from posts we have read on both sides — the “Named by N registered channels” figure above is a different count, of distinct NAMING CHANNELS rather than posts, and is not the sum of the rows under it.

Cite this entry

A live page changes as we take new readings, so a citation should name the measurement it is based on, not just the URL. The line below cites the subscriber count as measured 8 August 2026 — this entry's latest reading, not the date you are reading this.

“蛋总的圈” (@emoegg), 204 subscribers as measured 8 August 2026. Telegram Register, tgregister.com/channel/emoegg.

Full measurement history, CC BY 4.0. Every reading this register holds for this entry, not just the latest one, as a dated, downloadable record: CSV · JSON. Free to use with attribution to tgregister.com. Each file carries its own generation timestamp, which is the figure to cite for exactly when the data was retrieved.