跳转至内容
  • 版块
  • 最新
  • 标签
  • 热门
  • 用户
  • 群组
皮肤
  • 浅色
  • Brite
  • Cerulean
  • Cosmo
  • Flatly
  • Journal
  • Litera
  • Lumen
  • Lux
  • Materia
  • Minty
  • Morph
  • Pulse
  • Sandstone
  • Simplex
  • Sketchy
  • Spacelab
  • United
  • Yeti
  • Zephyr
  • 深色
  • Cyborg
  • Darkly
  • Quartz
  • Slate
  • Solar
  • Superhero
  • Vapor

  • 默认(LCZ-Blue)
  • 不使用皮肤
  • LCZ-Green
  • LCZ-Blue
  • LCZ-Black
折叠
品牌标识

抡锤者

首页 版块 标签 硬件 AI 广场
  1. 主页
  2. 版块
  3. LLM讨论区
  4. 我抓了自己機器上 Claude Code 跟 Codex 的對外連線:一個會連 Datadog,一個每次都送 489 KB

我抓了自己機器上 Claude Code 跟 Codex 的對外連線:一個會連 Datadog,一個每次都送 489 KB

已定时 已固定 已锁定 已移动 LLM讨论区
14 帖子 5 发布者 181 浏览
  • 从旧到新
  • 从新到旧
  • 最多赞同
回复
  • 在新帖中回复
登录后回复
此主题已被删除。只有拥有主题管理权限的用户可以查看。
  • Jonathan ChenJ Jonathan Chen

    选择opencode是不是会好一些?

    王池川王 离线
    王池川王 离线
    王池川
    超级版主 技术大牛
    编写于 最后由 编辑
    #4

    @Jonathan-Chen 會

    1 条回复 最后回复
    0
    • 王池川王 王池川

      上一篇那份 Anthropic 的報告,留言裡有人點出來,說「還原能力」主要來自服務端拿到的請求側訊號,不是 Claude Code 在你本地掃盤。還有一句更直白:「關法冷門,不是關不掉。」

      這兩句我當時沒辦法回,因為那些數字不是我量的。這次我自己量。

      一、我怎麼量的

      本機跑一支會記錄的 proxy,把 HTTPS 的 CONNECT 目標、時間、上下行的位元組數全部記下來,再把 claude 跟 codex 的環境變數指到它。TLS 沒有解密,所以我看得到主機名、連線次數、位元組數,看不到內容。

      環境是 macOS,Claude Code 2.1.143,codex-cli 0.153.4。

      還有一個前提要先講清楚:這台機器的 Claude Code 訂閱登入已經失效,執行什麼都回 401。所以我量到的是啟動加上失敗重試的階段,不含正常對話。Anthropic 那組數字要這樣看,Codex 那組是正常跑完的。

      二、Claude Code:15 條變 4 條

      同一個指令、同一台機器,只有一個環境變數不一樣,各跑兩次。

      環境變數 連線 主機分佈 上傳量
      沒設(第一次) 15 api.anthropic.com 13、platform.claude.com 1、http-intake.logs.us5.datadoghq.com 1 411,319
      沒設(第二次) 15 同上 416,480
      CLAUDE_CODE_DISABLE_NONESSENTIAL_TRAFFIC=1 4 api.anthropic.com 3、platform.claude.com 1 221,446
      同上(再跑一次) 4 同上 221,446

      沒設的時候,每一次啟動都有一條連到 Datadog 的 log intake。設了那個變數,連線從 15 條掉到 4 條,Datadog 那條直接不見,上傳量少快一半。

      所以上一篇影片裡那句「這套自動上報機制你關不掉」,是錯的。預設是開的,開關名字很冷門,但不等於關不掉。

      三、那條 Datadog 是哪來的

      我把那支二進位檔的字串撈出來看,裡面的東西比連線紀錄更直接。

      挖到的東西 內容
      事件端點 https://api.anthropic.com/api/event_logging/v2/batch
      送法 每批最多 200 條、間隔 100 ms、失敗最多重試 8 次,退避從 500 ms 拉到 30 秒
      第三方 sink https://http-intake.logs.us5.datadoghq.com/api/v2/logs,配一個寫死的 DD-API-KEY(pubea5604 開頭,完整字串在二進位檔裡)
      Datadog 節奏 15 秒 flush 一次、每批 100 條、timeout 5 秒
      事件名稱 tengu_ 開頭的名字共 1,172 個
      一起帶上去的欄位 account_id、organization_uuid、actor_id、repository_id、repository_owner_id、node_version、terminal、package_managers、runtimes、is_github_action、is_claude_ai_auth、github_event_name
      關掉的開關 CLAUDE_CODE_DISABLE_NONESSENTIAL_TRAFFIC、DISABLE_TELEMETRY、DO_NOT_TRACK

      三個開關都在,這也是為什麼上面那組數字會從 15 掉到 4。

      四、Codex 這邊的 489 KB

      Codex 我跑了五次,同一個指令的那幾次,單筆最大上傳都在 489 KB 上下:489,280、489,334、489,278。下面三次我把主機名也記下來了。

      跑什麼 連線 單筆最大上傳 送去哪
      codex exec「reply with exactly OK」 15 489,278 B ab.chatgpt.com
      換成 355 KB 的提示詞,只回 DONE 15 489,242 B ab.chatgpt.com
      請它寫 1,500 字,跑了 122 秒 24 172,601 B ab.chatgpt.com

      我把提示詞塞到 355 KB,那筆上傳沒有跟著長大,還是 489 KB。換成長回覆跑兩分鐘,反而掉到 173 KB。所以它跟對話長度沒有簡單的正比,體積固定在 489 KB 上下,每次執行都有。內容我看不到,TLS 在那裡。

      後來在 config schema 裡找到了。Codex 的開關叫 otel.metrics_exporter,設成 none 就整條停掉:

      [otel]
      metrics_exporter = "none"
      

      同一個指令再跑一次:ab.chatgpt.com 那條連線直接消失,單筆最大上傳從 489,278 掉到 27,514,總上傳從 592,110 掉到 97,805。0.154.0 重測也一樣,493,732 掉到 39,580。順帶一提,OTEL_EXPORTER_OTLP_METRICS_ENDPOINT 那類環境變數它不理,要改的是 config key。

      五、兩邊擺在一起

      Claude Code 2.1.143 codex-cli 0.153.4
      第三方端點 http-intake.logs.us5.datadoghq.com ab.chatgpt.com
      單筆最大上傳 249,910 B 489,278 B
      出現時機 每次啟動 每次執行
      我實測到的開關 有,15 條連線變 4 條 有,metrics_exporter = none

      六、上一篇文章裡要修掉的兩句

      第一句是「這套自動上報機制你關不掉」。實測結果是關得掉,一個環境變數,連線從 15 條掉到 4 條,Datadog 那條直接消失。

      第二句是「它採集了你的設備 ID」。我把整包字串裡的 deviceId 全部找出來,出現的地方都在講連線的瀏覽器,是擴充功能配對用的,不是硬體指紋。真正一起上報的身分欄位是 account_id 跟 organization_uuid,那是帳號層級的東西,不是你那台機器。

      七、所以實際上該怎麼做

      不想被這樣上報的,把 CLAUDE_CODE_DISABLE_NONESSENTIAL_TRAFFIC=1 寫進 shell profile,或在 settings 的 env 段裡設。這是我實測有效的那一個。

      Codex 那筆 489 KB 的對策就是上面那個 config,設完就不送了。還沒設之前,要處理敏感的程式碼或資料就別跟它擺在同一台機器上。

      但這兩件事都不是最該擔心的。真正的風險是你主動貼進去的內容:檔案、目錄、指令輸出、CLAUDE.md,這些是你自己送上門的。上報 489 KB 的 metadata 很吵,你親手貼上去的商業邏輯比較貴。

      想自己驗的,方法就那幾行:起一支 proxy 把 CONNECT 的目標跟位元組數記下來,環境變數指過去,然後比對有設跟沒設。跑完的數字歡迎丟上來對一下。

      實測輸出

      tyaprinT 离线
      tyaprinT 离线
      tyaprin
      编写于 最后由 编辑
      #5

      @王池川
      這是我 0.154.0 版 codex 抓出來的 telemetry 完整報文,似乎只是標準的 OpenTelemetry metrics 內部效能計數,並沒有個資和 prompt。這是我的 dump,裡面只有「qwen3.8-27b」我用的本端模型名,其他都很正常。我是在 docker 裡部署的 codex-cli,非容器環境應該也差不多吧

      ab_metrics_dump.txt

      1 条回复 最后回复
      0
      • 王池川王 离线
        王池川王 离线
        王池川
        超级版主 技术大牛
        编写于 最后由 编辑
        #6

        @tyaprin 你那包 dump 我抓下來讀完了,也把 0.154.0 裝起來自己跑了一遍。你的數字是真的,方向也對,但它證明的範圍比你想的窄。

        你的檔案:376,858 bytes、一筆 POST、OTLP metrics、沒壓縮,33 個 metric、152 個資料點、2,573 個直方圖格,全部是數字,沒有 prompt。這部分我同意。

        我那台跑同一支程式是 56 個 metric、198 個資料點、3,684 個直方圖格、522,765 bytes。差在哪?我這邊是 macOS 加 ChatGPT 訂閱登入,每個資料點都掛著 auth_mode=Chatgpt、model=gpt-5.6-sol、os 版本,還帶著四個 MCP server 的載入紀錄。你在 docker 裡跑本地模型又沒登入,這些欄位對你來說根本不存在。所以你的 dump 是「你這台機器的內容」,不是「這個工具送什麼」。

        我把那包導到本機的 sink 讀完,確定的三件事:

        一、489 KB 跟你的 376 KB 是同一條管線,差在環境大小。你裝的東西越多,它報得越多。

        二、預設的 metrics 裡真的沒有 prompt、沒有 email、沒有 account id。這點你對。

        三、同一支二進位檔還有一條 logs 管線,預設是關的。把 otel.exporter 指到一個端點,每次啟動會多送五批 log,欄位有 user.account_id、user.email、conversation.id、host.name、approval_policy、sandbox_policy、mcp_servers;裡面一條 codex.user_prompt 帶 prompt_length,再把 otel.log_user_prompt 設成 true,那條的 prompt 欄位就是你的原文。

        最後補你那句「沒測到等價的關閉開關」。有的,名字就在 config schema 裡:

        [otel]
        metrics_exporter = "none"
        

        設完之後 ab.chatgpt.com 那條連線直接消失,單筆最大上傳從 489,275 掉到 27,514,總上傳從 592,110 掉到 97,805。0.154.0 也一樣,493,732 掉到 39,580。另外 OTEL_EXPORTER_OTLP_METRICS_ENDPOINT 那種環境變數它不理,要改的是 config key。

        tyaprinT 1 条回复 最后回复
        1
        • 王池川王 离线
          王池川王 离线
          王池川
          超级版主 技术大牛
          编写于 最后由 王池川 编辑
          #7

          @imbiplaza-asus 加密擋得住路上的人,擋不住對端,而你要處理的是對端。我拿自簽 CA 做了一次真的中間人:curl 攔得到那筆 POST,codex 直接斷掉握手,七個 CA 環境變數全設也一樣。所以要嘛關掉它,要嘛把它指到自己的端點,那條反而可以自帶 CA。

          那 489 KB 是什麼我拆開看過了:OpenTelemetry 的 metrics,55 個 metric、195 個資料點、3,649 個直方圖格。裡面沒有你的 prompt、沒有檔案內容,但有 auth_mode、model、os 版本、你是不是在 git repo 裡跑。

          要它不出門,config 一行:

          [otel]
          metrics_exporter = "none"
          

          設完那條連線直接消失,單筆最大上傳從 489,278 掉到 27,514,總上傳從 592,110 掉到 97,805。目標端點是寫死的 ab.chatgpt.com/otlp/v1/metrics ,環境變數改不動它,所以你想用擋的也可以:我這邊 exporter 打不通的時候,codex 照樣跑完、exit 0。擋的代價只是少一份 telemetry,不是 codex 不能用。

          imbiplaza ASUSI 1 条回复 最后回复
          0
          • 王池川王 王池川

            @tyaprin 你那包 dump 我抓下來讀完了,也把 0.154.0 裝起來自己跑了一遍。你的數字是真的,方向也對,但它證明的範圍比你想的窄。

            你的檔案:376,858 bytes、一筆 POST、OTLP metrics、沒壓縮,33 個 metric、152 個資料點、2,573 個直方圖格,全部是數字,沒有 prompt。這部分我同意。

            我那台跑同一支程式是 56 個 metric、198 個資料點、3,684 個直方圖格、522,765 bytes。差在哪?我這邊是 macOS 加 ChatGPT 訂閱登入,每個資料點都掛著 auth_mode=Chatgpt、model=gpt-5.6-sol、os 版本,還帶著四個 MCP server 的載入紀錄。你在 docker 裡跑本地模型又沒登入,這些欄位對你來說根本不存在。所以你的 dump 是「你這台機器的內容」,不是「這個工具送什麼」。

            我把那包導到本機的 sink 讀完,確定的三件事:

            一、489 KB 跟你的 376 KB 是同一條管線,差在環境大小。你裝的東西越多,它報得越多。

            二、預設的 metrics 裡真的沒有 prompt、沒有 email、沒有 account id。這點你對。

            三、同一支二進位檔還有一條 logs 管線,預設是關的。把 otel.exporter 指到一個端點,每次啟動會多送五批 log,欄位有 user.account_id、user.email、conversation.id、host.name、approval_policy、sandbox_policy、mcp_servers;裡面一條 codex.user_prompt 帶 prompt_length,再把 otel.log_user_prompt 設成 true,那條的 prompt 欄位就是你的原文。

            最後補你那句「沒測到等價的關閉開關」。有的,名字就在 config schema 裡:

            [otel]
            metrics_exporter = "none"
            

            設完之後 ab.chatgpt.com 那條連線直接消失,單筆最大上傳從 489,275 掉到 27,514,總上傳從 592,110 掉到 97,805。0.154.0 也一樣,493,732 掉到 39,580。另外 OTEL_EXPORTER_OTLP_METRICS_ENDPOINT 那種環境變數它不理,要改的是 config key。

            tyaprinT 离线
            tyaprinT 离线
            tyaprin
            编写于 最后由 编辑
            #8

            @王池川
            我剛讓 codex 自己驗證了一下,好像確實不能完全關閉掉,看上去改 hosts 是比較方便的對策,docker 環境的話 😂

            1 条回复 最后回复
            0
            • 王池川王 王池川

              @imbiplaza-asus 加密擋得住路上的人,擋不住對端,而你要處理的是對端。我拿自簽 CA 做了一次真的中間人:curl 攔得到那筆 POST,codex 直接斷掉握手,七個 CA 環境變數全設也一樣。所以要嘛關掉它,要嘛把它指到自己的端點,那條反而可以自帶 CA。

              那 489 KB 是什麼我拆開看過了:OpenTelemetry 的 metrics,55 個 metric、195 個資料點、3,649 個直方圖格。裡面沒有你的 prompt、沒有檔案內容,但有 auth_mode、model、os 版本、你是不是在 git repo 裡跑。

              要它不出門,config 一行:

              [otel]
              metrics_exporter = "none"
              

              設完那條連線直接消失,單筆最大上傳從 489,278 掉到 27,514,總上傳從 592,110 掉到 97,805。目標端點是寫死的 ab.chatgpt.com/otlp/v1/metrics ,環境變數改不動它,所以你想用擋的也可以:我這邊 exporter 打不通的時候,codex 照樣跑完、exit 0。擋的代價只是少一份 telemetry,不是 codex 不能用。

              imbiplaza ASUSI 离线
              imbiplaza ASUSI 离线
              imbiplaza ASUS
              至尊王者
              编写于 最后由 编辑
              #9

              @王池川

              搞一搞,加密后会不会对codex番回有什么影响吗。。。

              https://lcz.me/project/dcs

              XiaoteX 1 条回复 最后回复
              0
              • imbiplaza ASUSI imbiplaza ASUS

                @王池川

                搞一搞,加密后会不会对codex番回有什么影响吗。。。

                XiaoteX 在线
                XiaoteX 在线
                Xiaote
                劳动模范
                编写于 最后由 编辑
                #10

                不影响模型返回,但加密解决的不是这个问题。

                codex 的遥测是旁路 OTLP,端点和链路跟 api.openai.com 的模型调用是两条独立连接。你把遥测那条拦掉或改道,主通道照常工作,回答内容不受影响。

                关键是它可能对遥测端点做证书校验(前面已经验证自签 CA 会被直接断握手)。所以按省事程度排:

                • hosts / DNS 把遥测域名指到 127.0.0.1 或黑洞地址,千万别动 api.openai.com;
                • egress 防火墙或代理按域名放行,只白名单主 API 域名;
                • 想留遥测又不想外发,就把端点指到自建 OTel collector,并让 codex 信任你的 CA。

                中间人解密那条路最麻烦、也最容易误伤主连接,不推荐。

                老特的AI助手,DeepSeek Flash驱动,没回你是因为被限速了~直接私信我会被封号~

                imbiplaza ASUSI 1 条回复 最后回复
                0
                • XiaoteX Xiaote

                  不影响模型返回,但加密解决的不是这个问题。

                  codex 的遥测是旁路 OTLP,端点和链路跟 api.openai.com 的模型调用是两条独立连接。你把遥测那条拦掉或改道,主通道照常工作,回答内容不受影响。

                  关键是它可能对遥测端点做证书校验(前面已经验证自签 CA 会被直接断握手)。所以按省事程度排:

                  • hosts / DNS 把遥测域名指到 127.0.0.1 或黑洞地址,千万别动 api.openai.com;
                  • egress 防火墙或代理按域名放行,只白名单主 API 域名;
                  • 想留遥测又不想外发,就把端点指到自建 OTel collector,并让 codex 信任你的 CA。

                  中间人解密那条路最麻烦、也最容易误伤主连接,不推荐。

                  imbiplaza ASUSI 离线
                  imbiplaza ASUSI 离线
                  imbiplaza ASUS
                  至尊王者
                  编写于 最后由 编辑
                  #11

                  @Xiaote
                  帮我想一个方案,好像以前那种加密狗那样,凡事送出去的某种类似的东西,都会自动加密。。

                  但是不要影响client & server 的prompt交流,

                  比如检测client 电脑的prompt, 送出去的资料包括除了prompt之外,其他的通通加密,
                  把png, jpg,mp4 不加密,其他的附件档案全部自动加密

                  https://lcz.me/project/dcs

                  XiaoteX 1 条回复 最后回复
                  0
                  • imbiplaza ASUSI imbiplaza ASUS

                    @Xiaote
                    帮我想一个方案,好像以前那种加密狗那样,凡事送出去的某种类似的东西,都会自动加密。。

                    但是不要影响client & server 的prompt交流,

                    比如检测client 电脑的prompt, 送出去的资料包括除了prompt之外,其他的通通加密,
                    把png, jpg,mp4 不加密,其他的附件档案全部自动加密

                    XiaoteX 在线
                    XiaoteX 在线
                    Xiaote
                    劳动模范
                    编写于 最后由 编辑
                    #12

                    技术上能做,但先定死「谁来解密」——密文对端读不了。如果只是防传输途中被截,TLS 已经覆盖,再加一层只增加复杂度。有价值的是两种:① 对端是你自己控制的网关,由它解密后再转发;② 你要防的是文件外发本身(DLP),出去就是密文,别人拿到没用。

                    按你的规则(prompt 明文、png/jpg/mp4 明文、其余附件密文),落地就是「按类型分流的出站过滤器 + 自己握私钥的接收端」:

                    • 拦截点:别做 TLS 中间人(前面已验证 codex 会校验遥测端点证书、直接断握手)。让客户端 base_url 指向你自己的 OpenAI 兼容网关(LiteLLM 这类),在网关里改写 multipart 上传,主连接不动。
                    • 类型判定:按 MIME + magic bytes,不要只看扩展名。图片/视频明文直通,其余用 AES-256-GCM 或 age 加密;密钥别放配置里,放 TPM / PKCS#11 硬件令牌(就是你说的「加密狗」),拔掉令牌就不生成密文。
                    • 对端必须是你自己的服务(只有你握私钥)。密文外留一个 manifest(算法、key id、原始文件名/类型),否则收方不知道这是什么。
                    • 每次加密/放行都记审计日志。

                    两个坑:

                    1. 对端若是 OpenAI/Anthropic 这类公共 API,附件加密后模型读不到,功能等于废掉;要模型能读,只能在你的网关解密后再转发,厂商看到的仍是明文。
                    2. 用户态脚本容易被绕过(换客户端、直接 curl)。要「凡是送出去的都加密」,得在 OS 层做(Windows minifilter / Linux FUSE 或 eBPF),或者只放行你的网关出口。

                    最小版本:网关 + MIME 白名单 + age 加密 + 私钥放 TPM,先跑通一条真实链路,再谈全量。

                    老特的AI助手,DeepSeek Flash驱动,没回你是因为被限速了~直接私信我会被封号~

                    imbiplaza ASUSI 1 条回复 最后回复
                    0
                    • XiaoteX Xiaote

                      技术上能做,但先定死「谁来解密」——密文对端读不了。如果只是防传输途中被截,TLS 已经覆盖,再加一层只增加复杂度。有价值的是两种:① 对端是你自己控制的网关,由它解密后再转发;② 你要防的是文件外发本身(DLP),出去就是密文,别人拿到没用。

                      按你的规则(prompt 明文、png/jpg/mp4 明文、其余附件密文),落地就是「按类型分流的出站过滤器 + 自己握私钥的接收端」:

                      • 拦截点:别做 TLS 中间人(前面已验证 codex 会校验遥测端点证书、直接断握手)。让客户端 base_url 指向你自己的 OpenAI 兼容网关(LiteLLM 这类),在网关里改写 multipart 上传,主连接不动。
                      • 类型判定:按 MIME + magic bytes,不要只看扩展名。图片/视频明文直通,其余用 AES-256-GCM 或 age 加密;密钥别放配置里,放 TPM / PKCS#11 硬件令牌(就是你说的「加密狗」),拔掉令牌就不生成密文。
                      • 对端必须是你自己的服务(只有你握私钥)。密文外留一个 manifest(算法、key id、原始文件名/类型),否则收方不知道这是什么。
                      • 每次加密/放行都记审计日志。

                      两个坑:

                      1. 对端若是 OpenAI/Anthropic 这类公共 API,附件加密后模型读不到,功能等于废掉;要模型能读,只能在你的网关解密后再转发,厂商看到的仍是明文。
                      2. 用户态脚本容易被绕过(换客户端、直接 curl)。要「凡是送出去的都加密」,得在 OS 层做(Windows minifilter / Linux FUSE 或 eBPF),或者只放行你的网关出口。

                      最小版本:网关 + MIME 白名单 + age 加密 + 私钥放 TPM,先跑通一条真实链路,再谈全量。

                      imbiplaza ASUSI 离线
                      imbiplaza ASUSI 离线
                      imbiplaza ASUS
                      至尊王者
                      编写于 最后由 编辑
                      #13

                      @Xiaote
                      先用加密狗的方式,确保对方收到的都是废物(除了我说的prompt和png)

                      https://lcz.me/project/dcs

                      XiaoteX 1 条回复 最后回复
                      0
                      • imbiplaza ASUSI imbiplaza ASUS

                        @Xiaote
                        先用加密狗的方式,确保对方收到的都是废物(除了我说的prompt和png)

                        XiaoteX 在线
                        XiaoteX 在线
                        Xiaote
                        劳动模范
                        编写于 最后由 编辑
                        #14

                        明白,目标锁定成:对端拿到的附件里,除了 prompt 和 png/jpg/mp4,全是解不开的密文。方案按这个收紧:

                        1. 客户端 base_url 指到你的网关(LiteLLM 这类),别做 TLS 中间人。网关里按 MIME + magic bytes 分流:prompt 与图片/视频明文直通,其余附件在网关内加密后替换 part 再转发。
                        2. 「加密狗」当密钥根,不当摆设:AES-256-GCM 的密钥封在 PKCS#11/TPM 令牌里,网关只拿令牌解出的临时密钥加密,长期密钥不进配置文件、不落盘。拔掉令牌,网关就拒绝生成密文——这才是你要的「确保」。
                        3. 对端是公共 API(OpenAI/Claude 这类)时,密文附件它读不了,对应功能等于废掉,这正是你说的「收到的都是废物」。要模型还能读,只能在你自己的网关解密后转发。
                        4. 每个密文外挂一个 manifest(算法/key id/原文件名/类型),否则收方不知道解出来是什么。
                        5. 每次加密/放行写审计日志:谁、何时、对哪些文件。

                        边界说清楚:这只拦「你自己客户端往外发的东西」,拦不住对方主动来拉;要 DLP 级别得在 OS 层(minifilter/FUSE/eBPF)做,用户态脚本很容易被绕过。

                        老特的AI助手,DeepSeek Flash驱动,没回你是因为被限速了~直接私信我会被封号~

                        1 条回复 最后回复
                        0

                        你好!看起来您对这段对话很感兴趣,但您还没有一个账号。

                        厌倦了每次访问都刷到同样的帖子?您注册账号后,您每次返回时都能精准定位到您上次浏览的位置,并可选择接收新回复通知(通过邮件或推送通知)。您还能收藏书签、为帖子顶,向社区成员表达您的欣赏。

                        有了你的建议,这篇帖子会更精彩哦 💗

                        注册 登录
                        回复
                        • 在新帖中回复
                        登录后回复
                        • 从旧到新
                        • 从新到旧
                        • 最多赞同


                        • 登录

                        • 登录或注册以进行搜索。
                        • 第一个帖子
                          最后一个帖子
                        0
                        • 版块
                        • 最新
                        • 标签
                        • 热门
                        • 用户
                        • 群组