[{"content":" 面向:买美股 + 宽基 ETF(VOO / QQQ)的入门者。\n怎么用这份文档:不用一次读完。看到不懂的术语回来查即可。标 ⭐ 的是最该优先掌握的核心概念,其余可以慢慢补。每个词的格式大致是:是什么 → 怎么用 → 正常范围 / 常见坑。\n最基础:你能买的几类资产 股票(Stock / Equity)⭐ 一家公司的一小块所有权。你持有它,就拥有这家公司未来利润的一小份索取权。它长期值多少,根本上取决于公司能赚多少钱。\nETF / 指数基金(Index Fund)⭐ ETF 是\u0026quot;交易所交易基金\u0026quot;,可以像股票一样随时买卖。指数基金是其中最常见的一种:它不挑股票,只是机械地照着一份\u0026quot;名单\u0026quot;(指数)按比例持有一篮子资产。你买 VOO,就一次性持有了标普 500 那约 500 家公司各一小片;买 QQQ,就持有了纳斯达克 100 那约 100 家(偏科技)。好处是分散和低成本。\n债券(Bond) 本质是\u0026quot;你借钱给政府或公司,它定期付你利息、到期还本\u0026quot;。比股票稳,回报通常也低。利率上升时,已发行债券的价格会下跌(这点很多人不知道)。\n现金 / 货币基金(Cash / Money Market) 最安全、几乎不波动,但长期会被通胀慢慢侵蚀购买力。它的作用不是赚钱,而是\u0026quot;弹药\u0026quot;和\u0026quot;安全垫\u0026quot;。\n看懂一只股票的核心参数(估值) 市值(Market Cap)⭐ 公司的整体身价 = 股价 × 总股数。判断一家公司\u0026quot;大不大\u0026quot;看的是市值,不是股价。常见分档:大盘股(\u0026gt;100 亿美元)、中盘、小盘。\n股价 ≠ 贵贱(重要误区)⭐ 一只 500 美元的股票不一定比 50 美元的\u0026quot;贵\u0026quot;。股价只是\u0026quot;总身价 ÷ 股数\u0026quot;,跟公司被高估还是低估没有直接关系。要判断贵贱,得看下面的估值倍数(如市盈率),而不是看单价高低。\n每股收益(EPS, Earnings Per Share) 公司净利润 ÷ 总股数,即\u0026quot;每一股分到多少利润\u0026quot;。是市盈率的分母,财报季最受关注的数字之一。\n市盈率(P/E Ratio)⭐ = 股价 ÷ 每股收益。直观理解:按现在的盈利水平,多少年能\u0026quot;赚回\u0026quot;你买入的价格。P/E 高,通常意味着市场预期它未来增长快(也可能是被高估);P/E 低可能便宜,也可能是市场不看好。\nTTM P/E:用过去 12 个月的真实利润算(看过去)。 Forward P/E:用预测的未来利润算(看预期)。 参考:标普 500 历史长期平均大约在 15–20 倍区间。 PEG 比率 = 市盈率 ÷ 利润增长率。用来修正\u0026quot;高 P/E 到底是贵还是合理\u0026quot;。经验法则:约等于 1 算合理,远大于 1 可能偏贵。(彼得·林奇常用的粗略指标,别当精确公式。)\n市净率(P/B, Price-to-Book) = 股价 ÷ 每股净资产。对银行、地产这类\u0026quot;资产很重\u0026quot;的公司更有意义;对轻资产的科技公司参考价值低。\n市销率(P/S, Price-to-Sales) = 市值 ÷ 营收。常用于还没盈利的成长型公司(没有利润就算不出 P/E)。\n股息率(Dividend Yield) = 每年每股分红 ÷ 股价。比如股价 100、每年分 3 元,股息率就是 3%。注意:高得离谱的股息率有时是\u0026quot;股价暴跌\u0026quot;造成的假象,不一定是好事。\n营收 / 净利润(Revenue / Net Income) 营收是\u0026quot;卖了多少钱\u0026quot;(流水),净利润是\u0026quot;最后真正赚到多少\u0026quot;(去掉所有成本费用税)。营收增长快但一直不赚钱的公司要警惕。\n自由现金流(FCF, Free Cash Flow)⭐ = 经营产生的现金 − 维持/扩张所需的资本开支。简单说是\u0026quot;公司真正能自由支配的现金\u0026quot;。利润可以被会计手法修饰,但现金流更难造假,所以很多老手更看重它。\n净资产收益率(ROE, Return on Equity) = 净利润 ÷ 股东权益。衡量\u0026quot;股东每投入 1 块钱,公司一年能赚回多少\u0026quot;,是判断公司赚钱效率的关键指标。长期稳定在 15%+ 通常算优秀。\n利润率(Margins) 毛利率 =(营收 − 成本)÷ 营收;净利率 = 净利润 ÷ 营收。利润率高且稳定,往往说明公司有\u0026quot;护城河\u0026quot;(定价权强、竞争小)。\n看懂一只 ETF / 基金的参数 费用率(Expense Ratio)⭐ 基金每年从你持有的资产里收取的管理费,按百分比算。看着小,长期复利下影响巨大。\nVOO 约 0.03%／年,QQQ 约 0.20%／年。 直觉:1% 的年费,30 年下来可能侵蚀你最终收益的两成以上。这是选基金时最该先看的一个数字。 规模(AUM, Assets Under Management) 基金管理的总资产。太小的基金有清盘风险,主流宽基(VOO / QQQ)规模巨大,不用担心。\n持仓与权重(Holdings \u0026amp; Weights) 基金里到底装了哪些公司、各占多少。买之前最好扫一眼前十大持仓——你会发现很多\u0026quot;不同\u0026quot;的科技 ETF,前十大持仓高度重叠(都是那几家大厂),买多个可能并没有真正分散。\n跟踪误差(Tracking Error) 指数基金的实际表现和它要追踪的指数之间的偏差。越小越好,说明基金\u0026quot;复制\u0026quot;得越精准。\n溢价 / 折价(Premium / Discount) ETF 的市场成交价 vs 它实际净值(NAV)之间的差。主流大 ETF 几乎贴合净值;冷门、小众或交易时段不对的 ETF 可能出现明显溢价/折价,相当于多付/少付了钱。\n流动性 / 成交量(Liquidity / Volume) 每天成交得多不多。流动性好 = 买卖价差小、容易成交;流动性差的小众 ETF,光买卖价差就能吃掉你不少收益。\n分红(Distribution) ETF 会把持仓公司派的股息定期转给你。VOO 这类有一定股息,QQQ 较少(成长股普遍少分红)。\n收益与风险参数(决定你睡不睡得着) 年化收益率(CAGR, 复合年增长率)⭐ 把一段时间的总增长,换算成\u0026quot;平均每年复合增长多少\u0026quot;。它是几何平均,不是简单的\u0026quot;总收益 ÷ 年数\u0026quot;——后者会高估。比如三年涨了 60%,CAGR 约是 17%,而不是 20%。(为什么偏高?因为复利:若真按每年 20% 滚,三年会涨到 +73%,远超 60%;要正好涨 60%,每年只需约 17%。)意义在于:它把波动的多年表现压成一个可比的年化数字,是横向比较不同基金/策略长期表现的通用标尺。\n总回报 vs 价格回报(Total Return vs Price Return)⭐ 价格回报只算股价/净值涨了多少;总回报还把收到的股息(并假设再投资)算进去。长期看两者差距很大——标普 500 相当一部分的长期回报来自股息再投资。看基金或指数的历史业绩时,认准 \u0026ldquo;总回报(Total Return)\u0026rdquo; 口径,别被只显示价格涨幅的数字误导。\n波动率(Volatility)⭐ 价格上下波动的剧烈程度,常用标准差衡量。波动率高 ≠ 一定亏,但意味着\u0026quot;颠簸\u0026quot;更厉害、更考验心态。QQQ 的波动率明显高于 VOO。\nBeta(β)⭐ 衡量一个资产相对整个市场的波动放大倍数。市场本身 = 1.0。\nβ \u0026gt; 1:比市场波动更大(如很多科技股、QQQ)。 β \u0026lt; 1:比市场更\u0026quot;稳\u0026quot;(如公用事业股)。 β ≈ 1:和市场同步(VOO 接近 1)。 最大回撤(Max Drawdown)⭐ 历史上从最高点跌到最低点的最大幅度。是衡量\u0026quot;最坏情况下你要承受多大痛苦\u0026quot;的关键指标。比如某资产最大回撤 50%,意味着你可能要眼睁睁看着账户腰斩。买之前先看它历史最大回撤,问自己扛不扛得住。\n夏普比率(Sharpe Ratio) =(收益 − 无风险利率)÷ 波动率。衡量\u0026quot;你每承担一单位风险,换来了多少超额回报\u0026quot;。越高越好,是比较不同策略\u0026quot;性价比\u0026quot;的常用指标。\n相关性(Correlation)⭐ 两个资产是否同涨同跌,范围 −1 到 +1。\n接近 +1:高度同步(比如 VOO 和 QQQ,都是美股,一起涨一起跌)。 接近 0 或负:走势独立甚至相反。 真正的分散,靠的是持有相关性低的资产。你同时买 VOO + QQQ,相关性很高,分散效果有限。 交易与成本(每天都在悄悄吃钱) 买卖价差(Bid-Ask Spread)⭐ 买价(bid)和卖价(ask)之间的差。你\u0026quot;买入即亏\u0026quot;的那一小块就是它。主流大盘股/ETF 价差极小,冷门标的价差可能很大。\n市价单 vs 限价单(Market / Limit Order)⭐\n市价单:以当前最优价立刻成交,快但价格不可控(流动性差时可能成交在很糟的价位)。 限价单:你指定一个价格,到价才成交,价格可控但可能成交不了。 新手习惯:除非急着成交,多用限价单。 滑点(Slippage) 你预期的成交价和实际成交价之间的差,常出现在大单、波动剧烈或流动性差时。\n税(Tax)⭐ 常被忽略的一层成本。卖出实现盈利时通常要交资本利得税,收到的股息也可能被预扣税。一般规律是持有越久税率越友好(很多市场对长期持有有优惠),所以频繁交易除了多付价差和滑点,还会多交税。具体税率随你所在地和账户类型而定——下手前先搞清楚自己的税务情况,这对最终到手收益的影响往往比你想的大。\n组合与策略概念(影响最大的一层)⭐ 资产配置(Asset Allocation)⭐ 你的钱在股票/债券/现金之间怎么分配。研究反复证明:决定你长期回报和波动的,主要是配置,而不是你选了哪只股票。 这是新手最该重视、却最容易忽略的一层。\n分散化(Diversification)⭐ \u0026ldquo;不把鸡蛋放一个篮子\u0026rdquo;。通过持有多种、且相关性低的资产,降低单一资产暴雷对你的伤害。注意:买一堆高度相关的东西(如多只科技 ETF)不算真正分散。\n复利(Compounding)⭐ 收益再产生收益,像滚雪球。它的威力来自时间——同样的年化收益,30 年和 10 年的最终结果天差地别。\n快捷算法:72 法则。 用 72 除以年化收益率,约等于本金翻倍所需的年数。年化 8%,约 9 年翻倍;年化 4%,要 18 年。一个心算复利威力的好工具。\n定投 / 平均成本法(DCA, Dollar-Cost Averaging)⭐ 固定时间投入固定金额(比如每月买一笔 VOO),不去预测高低点。好处是摊平成本、避免\u0026quot;一把梭在最高点\u0026quot;,也避免被情绪左右择时。\n再平衡(Rebalancing) 一段时间后,涨得多的资产占比会变大,组合偏离你原定的配置。再平衡就是定期卖一点涨多的、补一点涨少的,把比例调回目标。本质是\u0026quot;被动地高抛低吸\u0026quot;。\n仓位 / 头寸(Position Sizing) 单个资产在你组合里占多大比例。再看好一个东西,也要给单一标的设上限,防止它出意外时拖垮整体。\n宏观参数(影响整个市场的潮水) 利率 / 美联储(Interest Rate / Fed)⭐ 美联储调整的基准利率是影响股市的最大变量之一。粗略规律:加息(钱变贵)通常利空股市,尤其重创成长股/科技股(QQQ);降息通常利好。 因为利率影响\u0026quot;未来的钱折算到现在值多少\u0026quot;。\n通胀 / CPI(Inflation)⭐ 物价上涨的速度,常用 CPI 衡量。通胀过高会逼迫美联储加息,从而压制股市。市场对每月 CPI 数据非常敏感。\n别忘了算实际收益。 名义收益是账面数字,实际收益 ≈ 名义收益 − 通胀。如果一年赚了 5% 但通胀 4%,你的购买力其实只增长了约 1%。衡量投资有没有真的让你变富,要看实际收益,而不是账面数字。\n收益率曲线(Yield Curve) 不同期限国债的利率连成的曲线。当短期利率高于长期(\u0026ldquo;倒挂\u0026rdquo;)时,常被视为经济衰退的预警信号。\n美元指数(DXY) 美元相对一篮子货币的强弱。美元走强往往对新兴市场和大宗商品形成压力。\n杠杆与衍生品(高风险,先懂再碰) 保证金(Margin)⭐ 向券商借钱来放大买入。它同时放大盈利和亏损;当亏损过大时会触发\u0026quot;追加保证金/强制平仓(margin call)\u0026quot;,可能在最低点被强制卖出。新手谨慎使用。\n杠杆 / 反向 ETF + 损耗(Leveraged / Inverse ETF Decay)⭐ 像 TQQQ(做多纳指 3 倍)、SQQQ(做空 3 倍)这类,追求的是每日收益的固定倍数。由于每天都要重新调整杠杆,在来回震荡的行情里会产生\u0026quot;波动损耗\u0026quot;——长期持有往往跑输你以为的目标,即使方向看对了也可能亏。它们设计用于短期对冲/交易,不适合长期持有。\n期权(Options) 赋予你\u0026quot;在某价格买入/卖出某资产\u0026quot;权利的合约(认购 call / 认沽 put)。可以用于对冲或投机,杠杆高、机制复杂,强烈建议把前面的基础都打牢之后再碰。\n给入门者的一句话总纲 先彻底搞懂 「组合与策略」那一节,以及 费用率、最大回撤、相关性、年化收益率 这几个参数。它们对你长期结果的影响,远大于你研究任何一只具体个股。把这些当成\u0026quot;地基\u0026quot;,其余术语作为工具,用到时再回来查。\n风险提示:本文为概念科普,不构成任何投资建议。\n","permalink":"https://blog.lddi.net/posts/investing-concepts/","summary":"面向买美股和宽基 ETF 的入门者:一份梳理资产类别、估值参数、风险指标与组合策略的概念地图,标注了最该优先掌握的核心。","title":"投资入门:看懂资产、估值、风险与组合的核心概念"},{"content":" 本文为在自有服务器上进行合法网络实验的操作记录，仅供学习参考，请遵守所在地的法律法规。\n上一篇 VLESS、REALITY 与 CDN 讲清了原理，这篇就动手：同一台 VPS，分别把 REALITY（直连、无需域名） 和 WS + CDN（藏源站、需要域名） 跑起来。两套都基于 Xray，核心差别只在 streamSettings。\n准备工作 一台境外 VPS（Debian / Ubuntu 为例），有 root 权限； 安全组 / 防火墙放行 443 端口； WS + CDN 方案还需要一个域名 + 一个 Cloudflare 账号。 先用官方脚本装好 Xray：\nbash -c \u0026#34;$(curl -L https://github.com/XTLS/Xray-install/raw/main/install-release.sh)\u0026#34; @ install 配置文件在 /usr/local/etc/xray/config.json，改完用 systemctl restart xray 重启。\n方案一：VLESS + REALITY（直连，无需域名） REALITY 不需要域名和证书，最省事，适合 IP 还没被封的新机器。\n第 1 步：生成所需的密钥和 ID\nxray uuid # 生成 UUID（客户端身份） xray x25519 # 生成一对密钥：Private key / Public key openssl rand -hex 8 # 生成 shortId 记下：UUID、Private key（服务端用）、Public key（客户端用）、shortId。\n第 2 步：服务端配置\n{ \u0026#34;inbounds\u0026#34;: [ { \u0026#34;listen\u0026#34;: \u0026#34;0.0.0.0\u0026#34;, \u0026#34;port\u0026#34;: 443, \u0026#34;protocol\u0026#34;: \u0026#34;vless\u0026#34;, \u0026#34;settings\u0026#34;: { \u0026#34;clients\u0026#34;: [ { \u0026#34;id\u0026#34;: \u0026#34;\u0026lt;UUID\u0026gt;\u0026#34;, \u0026#34;flow\u0026#34;: \u0026#34;xtls-rprx-vision\u0026#34; } ], \u0026#34;decryption\u0026#34;: \u0026#34;none\u0026#34; }, \u0026#34;streamSettings\u0026#34;: { \u0026#34;network\u0026#34;: \u0026#34;tcp\u0026#34;, \u0026#34;security\u0026#34;: \u0026#34;reality\u0026#34;, \u0026#34;realitySettings\u0026#34;: { \u0026#34;dest\u0026#34;: \u0026#34;www.microsoft.com:443\u0026#34;, \u0026#34;serverNames\u0026#34;: [\u0026#34;www.microsoft.com\u0026#34;], \u0026#34;privateKey\u0026#34;: \u0026#34;\u0026lt;Private key\u0026gt;\u0026#34;, \u0026#34;shortIds\u0026#34;: [\u0026#34;\u0026lt;shortId\u0026gt;\u0026#34;] } } } ], \u0026#34;outbounds\u0026#34;: [{ \u0026#34;protocol\u0026#34;: \u0026#34;freedom\u0026#34; }] } 几个关键参数的含义：\ndecryption: none：VLESS 自身不加密，这里固定写 none（加密交给 REALITY/TLS）； flow: xtls-rprx-vision：XTLS Vision 流控，避免「TLS 套 TLS」的双重加密开销，REALITY/直连 TLS 专用； dest / serverNames：要「借用」的真实网站，两者必须一致。选一个真实存在、支持 TLS 1.3、且本地不被墙的大站当「门面」； privateKey：REALITY 密钥对里的私钥，留在服务端；对应的公钥（Public key）给客户端； shortIds：客户端识别码，可留空 \u0026quot;\u0026quot; 或填上面生成的值，服务端可配置多个区分不同客户端。 第 3 步：客户端关键参数\n参数 值 作用 Address / Port VPS 的 IP / 443 直连服务器，不经过域名 UUID 上面生成的 客户端身份，须与服务端一致 flow xtls-rprx-vision 与服务端对应的 Vision 流控 security reality 启用 REALITY SNI www.microsoft.com 握手时伪装成的「门面」网站，须等于服务端 serverNames publicKey (pbk) 上面生成的 Public key 与服务端私钥配对，完成认证 shortId (sid) 上面生成的 须是服务端 shortIds 里的一个 fingerprint (fp) chrome 模拟的 TLS 指纹，让握手看起来像 Chrome 浏览器 用分享链接一键导入\n除了手填，更常见的是直接导入一条 vless:// 链接（v2rayN、v2rayNG、NekoBox 等都支持「从剪贴板导入」）。REALITY 节点的链接格式：\nvless://\u0026lt;UUID\u0026gt;@\u0026lt;VPS-IP\u0026gt;:443?encryption=none\u0026amp;flow=xtls-rprx-vision\u0026amp;security=reality\u0026amp;sni=www.microsoft.com\u0026amp;fp=chrome\u0026amp;pbk=\u0026lt;Public key\u0026gt;\u0026amp;sid=\u0026lt;shortId\u0026gt;\u0026amp;type=tcp#REALITY节点 ? 后面的每个参数就对应上表里的一项，# 后面是节点备注名。重启 systemctl restart xray，导入后连上就能用。\n方案二：VLESS + WS + CDN（藏源站，需要域名） 当机器 IP 容易被封时，用 Cloudflare 把源站藏起来。\n这套方案比 REALITY 多了一个组件 Nginx。它是最常用的 Web 服务器 / 反向代理，在这里干两件事：\n在 443 端口提供带证书的 HTTPS（CDN 回源要求源站是合法 HTTPS，而 Xray 的 WS 只是裸 WebSocket）； 只把约定好的密钥路径（如 /mypath）反代给本地 Xray，其余路径返回一个普通网页，伪装成正常网站。 Nginx 需要你自己准备证书。不过我们本来就在 Cloudflare 后面，直接用 Cloudflare 免费的**源站证书（Origin Certificate）**最省事——它由 Cloudflare 签发、有效期长达 15 年，只需被 CDN 信任即可。\n第 1 步：Cloudflare 解析 + 源站证书\n把域名的 A 记录指向 VPS IP，开启橙色云（代理）； SSL/TLS 模式选 Full (strict)； 在面板 SSL/TLS → Origin Server → Create Certificate 生成证书，把证书和私钥分别存到 /etc/ssl/cf-origin.pem 和 /etc/ssl/cf-origin.key。 不想用源站证书，也可以用 acme.sh 配合 Cloudflare DNS API 申请 Let\u0026rsquo;s Encrypt 证书，后面 Nginx 配置同理。\n第 2 步：Xray 监听本地 WS\n{ \u0026#34;inbounds\u0026#34;: [ { \u0026#34;listen\u0026#34;: \u0026#34;127.0.0.1\u0026#34;, \u0026#34;port\u0026#34;: 10000, \u0026#34;protocol\u0026#34;: \u0026#34;vless\u0026#34;, \u0026#34;settings\u0026#34;: { \u0026#34;clients\u0026#34;: [{ \u0026#34;id\u0026#34;: \u0026#34;\u0026lt;UUID\u0026gt;\u0026#34; }], \u0026#34;decryption\u0026#34;: \u0026#34;none\u0026#34; }, \u0026#34;streamSettings\u0026#34;: { \u0026#34;network\u0026#34;: \u0026#34;ws\u0026#34;, \u0026#34;wsSettings\u0026#34;: { \u0026#34;path\u0026#34;: \u0026#34;/mypath\u0026#34; } } } ], \u0026#34;outbounds\u0026#34;: [{ \u0026#34;protocol\u0026#34;: \u0026#34;freedom\u0026#34; }] } 注意 WS 方案不需要 flow（Vision 只用于 REALITY/直连 TLS）。\n第 3 步：Nginx HTTPS + 反代\n/etc/nginx/conf.d/proxy.conf：\nserver { listen 443 ssl; http2 on; server_name your.domain.com; ssl_certificate /etc/ssl/cf-origin.pem; ssl_certificate_key /etc/ssl/cf-origin.key; # 密钥路径反代给本地 Xray location /mypath { proxy_pass http://127.0.0.1:10000; proxy_http_version 1.1; proxy_set_header Upgrade $http_upgrade; # WebSocket 升级 proxy_set_header Connection \u0026#34;upgrade\u0026#34;; # WebSocket 升级 proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; } # 其余路径返回普通页面做伪装 location / { return 200 \u0026#34;hello\u0026#34;; } } 这里最容易漏的是 Upgrade / Connection \u0026quot;upgrade\u0026quot; 两个头——没有它们 WebSocket 握不上手，Nginx 反代 WebSocket 必须手动加上。改完 nginx -t 测试语法，再 systemctl restart nginx。\n第 4 步：客户端关键参数\n参数 值 作用 Address 域名（也可填 Cloudflare 优选 IP） 连的是 Cloudflare 节点，不是源站 Port 443 CDN 对外的 HTTPS 端口 UUID 与服务端一致 客户端身份 security tls，SNI = 域名 与 CDN 之间走标准 HTTPS network ws，path = /mypath WebSocket 传输；path 须和服务端、Nginx 完全一致 host 域名 WS 的 Host 头；填优选 IP 时必须写域名，CDN 靠它判断回源到哪个站 用分享链接一键导入\nWS + CDN 节点的 vless:// 链接格式：\nvless://\u0026lt;UUID\u0026gt;@\u0026lt;域名或优选IP\u0026gt;:443?encryption=none\u0026amp;security=tls\u0026amp;sni=\u0026lt;域名\u0026gt;\u0026amp;type=ws\u0026amp;host=\u0026lt;域名\u0026gt;\u0026amp;path=%2Fmypath#WS-CDN节点 注意 path 在链接里要做 URL 编码：/mypath 写成 %2Fmypath。WS 方案不带 flow（Vision 只用于 REALITY/直连 TLS）。\n验证与排错 systemctl status xray nginx # 两个服务是否都在跑 journalctl -u xray -e # 看 Xray 报错日志 nginx -t # 检查 Nginx 配置语法 ss -tlnp | grep -E \u0026#39;443|10000\u0026#39; # 端口是否监听 常见坑：\nREALITY 连不上：多半是客户端 publicKey / shortId / SNI 和服务端对不上。 WS + CDN 502 / 握手失败：检查 Nginx 是否写了 Upgrade / Connection 头、path 是否和 Xray 完全一致、Cloudflare 是否橙云且 SSL 模式为 Full (strict)。 能连但不通：确认 VPS 防火墙和云厂商安全组都放行了 443。 小结 两套方案 Xray 配置的差异，几乎只在 streamSettings：REALITY 走 tcp + reality，CDN 走 ws，外面套一层 Nginx/CDN 的 TLS； 新机器、要速度 → 先上 REALITY； IP 被盯上、要藏源站 → 换 WS + CDN； 建议两套都配好，按网络情况随时切换——这也正好对应上一篇的选型结论。 ","permalink":"https://blog.lddi.net/posts/vps-vless-setup/","summary":"接上一篇原理，这次动手在一台 VPS 上分别把 REALITY 和 WS + CDN 两套方案跑起来，只讲关键步骤和容易踩的坑。","title":"搭建 VLESS + REALITY 与 VLESS + WS + CDN"},{"content":" 本文从技术角度讲解开源代理协议的设计思路，仅供学习与合法的网络研究使用，请遵守所在地的法律法规。\n一个被忽略的前提：对抗的不是「加密」，而是「识别」 很多人以为代理的关键是「把流量加密」。可 HTTPS 早就把内容加密了，真正的难点在于：审查系统（DPI，深度包检测）根本不需要解密你的内容，只要能识别出「这是一条代理连接」，就能直接封锁。\n所以代理协议这些年的演进，主线只有一条：让自己的流量看起来和正常 HTTPS 没有区别，甚至让主动探测也分辨不出来。抓住这条主线，VLESS、REALITY、CDN 就都串起来了。\nVLESS：做减法的传输协议 VLESS 是 Xray（Project X）项目的核心传输协议，可以理解为前代 VMess 的「轻量化继任者」。\n它最反直觉的一点是：VLESS 本身不加密。\nVMess 自带一套加密和基于时间的认证（alterID），不仅有性能开销，加密后的流量还带有可被统计识别的「指纹」。 VLESS 把加密这件事彻底交给传输层的 TLS，自己只用一个 UUID 做身份校验。于是更轻、更快、特征更少。 代价是：VLESS 几乎总要和 TLS 搭配（VLESS + TLS）；再配合 XTLS Vision 流控，还能避免「TLS 套 TLS」的双重加密开销。\n一句话：VLESS 负责「传」，TLS 负责「伪装成 HTTPS」。\nREALITY：借用一张「别人家的门面」 VLESS + TLS 听起来很完美，但 TLS 这一层有个老大难——证书和域名：\n你需要一个自己的域名加证书； TLS 握手时的 SNI、证书信息都会暴露「这台服务器在自建服务」； 审查方可以主动探测：主动连上你的端口，发现证书可疑、或者背后没有真实网站，就判定为代理并封锁。 REALITY 的思路非常巧妙：不再用你自己的证书，而是「借用」一个真实大网站的握手。\n工作方式大致是：\n客户端发起握手时，SNI 填一个真实存在的大站（比如 www.microsoft.com）； 持有正确密钥的客户端，服务器认出来，走代理； 对没有密钥的主动探测者，服务器把它透明转发到那个真实网站——探测方拿到的是微软真实的证书和真实页面，看不出任何破绽。 这样一来：不需要自己的域名和证书；TLS 指纹就是真实大站的指纹；主动探测也打不穿，因为打过去看到的是真网站。\n服务端配置的关键部分长这样（Xray）：\n{ \u0026#34;protocol\u0026#34;: \u0026#34;vless\u0026#34;, \u0026#34;settings\u0026#34;: { \u0026#34;clients\u0026#34;: [{ \u0026#34;id\u0026#34;: \u0026#34;你的-UUID\u0026#34;, \u0026#34;flow\u0026#34;: \u0026#34;xtls-rprx-vision\u0026#34; }], \u0026#34;decryption\u0026#34;: \u0026#34;none\u0026#34; }, \u0026#34;streamSettings\u0026#34;: { \u0026#34;network\u0026#34;: \u0026#34;tcp\u0026#34;, \u0026#34;security\u0026#34;: \u0026#34;reality\u0026#34;, \u0026#34;realitySettings\u0026#34;: { \u0026#34;dest\u0026#34;: \u0026#34;www.microsoft.com:443\u0026#34;, \u0026#34;serverNames\u0026#34;: [\u0026#34;www.microsoft.com\u0026#34;], \u0026#34;privateKey\u0026#34;: \u0026#34;服务端私钥\u0026#34;, \u0026#34;shortIds\u0026#34;: [\u0026#34;\u0026#34;] } } } dest / serverNames 就是「借用」的目标网站，privateKey 与客户端的公钥配对完成认证。\nCDN：把源站 IP 藏起来 REALITY 解决了「流量特征」和「主动探测」，但还留着一个软肋：你的服务器 IP 是直连暴露的。这个 IP 一旦被盯上，可以直接按 IP 封。\nCDN（如 Cloudflare）提供了另一条路：\n客户端连接的是 CDN 的 IP，CDN 再把流量回源到你的服务器； 审查方看到的只是 CDN 那一大片共享 IP，没法整片封（否则会误伤大量正常网站）； 你的真实源站 IP 被藏在 CDN 背后。 CDN 方案通常长这样：VLESS + WebSocket + TLS，因为 CDN 主要代理 HTTP / WebSocket 流量。\n这里有个关键认知：REALITY 和 CDN 基本是互斥的。CDN 会在它那一端终结（解密）TLS，而 REALITY 要求真实的 TLS 握手原样到达你自己的服务器。所以它们是「两条不同的路线」，不是叠加关系。\n怎么选：REALITY vs CDN 维度 VLESS + REALITY VLESS + WS + CDN 域名 / 证书 不需要 需要域名（证书可由 CDN 提供） 抗主动探测 强（探测看到的是真网站） 一般 源站 IP 直连暴露，可能被封 IP 藏在 CDN 后，较难封 延迟 / 速度 直连，低延迟 多一跳，延迟更高 隐私 流量不经过第三方 CDN 能看到（它终结了 TLS） 简单记：\n想要低延迟、强抗探测，且不怕换 IP → 选 REALITY； 源站 IP 容易被封、希望藏住服务器 → 选 CDN（WS + TLS）； 进阶玩家也会两套并存，按网络环境随时切换。 小结 代理的核心矛盾是「不被识别」，而不是「加密」； VLESS 做减法，把加密交给 TLS，自己只管轻量传输； REALITY 用「冒用真实网站握手」解决了证书 / 域名和主动探测的难题； CDN 换个思路，用共享 IP 藏住源站，代价是延迟和隐私。 三者不是谁取代谁，而是针对「识别」与「封锁」的不同侧面，各自补上一块拼图。\n","permalink":"https://blog.lddi.net/posts/net-proxy/","summary":"从「对抗识别」这条主线出发，讲清 VLESS、VLESS + REALITY 和 CDN 各自解决了什么问题，以及该怎么选。","title":"VLESS、REALITY 与 CDN：现代网络代理的三块拼图"},{"content":"关于我 我是 Di Li，一名游戏开发工程师。平时喜欢钻研各种技术，也关注金融与投资。比起把知识囤在脑子里，我更习惯把它们写下来——把一件事讲清楚的过程，往往才是真正想明白它的过程。\n这里写些什么 技术：游戏开发、网络、后端，以及日常折腾各种工具时的踩坑记录； 金融：投资理财方面的思考与笔记； 教程：把某件事从头到尾跑通的完整步骤，方便自己回看，也方便你照着做。 内容不追求多，但尽量把重点讲清楚。\n为什么写 一部分是为了自己：写下来的东西，日后翻起来比记忆可靠得多。另一部分是为了你——如果某篇文章恰好帮你省下了几个小时，那就是它最大的价值。\n","permalink":"https://blog.lddi.net/about/","summary":"关于我与这个博客","title":"关于"},{"content":"新装一台机器——开发机也好、服务器也好——想 clone、pull、push 你的 GitHub 仓库时，常会卡在认证。先理清什么时候需要认证：\n只读 clone 公开仓库 → 不用认证，直接拉； 访问私有仓库（clone / pull / push） → 要认证； 向任何仓库 push（哪怕是公开仓库） → 也要认证。 也就是说，除了「拉公开仓库」，机器要对仓库做任何带权限的操作都得先有「身份」。配一次，之后这台机器就能正常 clone / pull / push 了。\n主线：身份有两条路——SSH 密钥 或 Token（PAT），区别在于「这把钥匙能开多少扇门、能干什么」。\n原理：公钥私钥怎么验证身份 下面两种 SSH 方式都基于一对密钥，先把它怎么验证身份说清楚：\n私钥：留在你机器上（~/.ssh/ 里），绝不外传； 公钥：可以公开，交给 GitHub 登记。 它们是「非对称」的——用私钥算出的签名，只有配对的公钥能验证；而从公钥推不出私钥。验证流程大致是：\n你事先把公钥登记到 GitHub（账号的 SSH keys，或仓库的 Deploy keys）； 连接时你的机器发起 SSH，表示「我持有某公钥对应的私钥」； GitHub 用登记的公钥出一道随机「考题」（challenge）； 你的机器用私钥对考题签名，把结果发回； GitHub 用公钥验证这个签名——验得过，就证明你确实握有配对的私钥，身份成立，放行。 你的机器 GitHub │ ① 我持有某公钥对应的私钥 │ │ ───────────────────────────────▶ │ │ ② 随机考题 challenge │ │ ◀─────────────────────────────── │ │ ③ 用「私钥」签名考题，发回 │ │ ───────────────────────────────▶ │ │ ④ 用登记的「公钥」验签 → 放行 │ 关键点：私钥从头到尾没离开过你的机器，网络上传的只是「用私钥算出的证明」。所以即使全程被监听，也偷不到私钥——这就是为什么公钥能随便公开、私钥必须保密。\n方式一：SSH 密钥（账号级，最通用） 一把绑在你 GitHub 账号上的密钥，你名下所有仓库、clone / pull / push 全都能用，适合你自己常用的开发机。\n① 生成密钥（一路回车即可）：\nssh-keygen -t ed25519 -C \u0026#34;my-laptop\u0026#34; 它会问你保存路径（回车用默认 ~/.ssh/id_ed25519）和密码（回车 = 不设）。生成两个文件：id_ed25519（私钥，保密）和 id_ed25519.pub（公钥）。\n-t ed25519：密钥类型，比老的 RSA 更短更安全，现在的推荐； -C \u0026quot;my-laptop\u0026quot;：一段注释/标签，纯粹方便日后辨认，不影响功能。 ② 把公钥加到账号：\ncat ~/.ssh/id_ed25519.pub # 复制这串 GitHub → Settings → SSH and GPG keys → New SSH key → 粘贴。\n③ 用 SSH 地址操作（默认名字的密钥 SSH 会自动使用，无需额外配置）：\ngit clone git@github.com:ldddi/your-repo.git ssh -T git@github.com # 验证：看到 \u0026#34;Hi ldddi!\u0026#34; 就通了 优点：配一次，覆盖你所有仓库和所有操作； 缺点：权限大——机器一旦失守，你所有仓库都暴露。所以服务器上更适合下面的只读 Deploy Key。 方式二：Deploy Key（只绑单个仓库，服务器/CI 首选） 一把只对一个仓库生效、还能设成只读的 SSH 密钥。适合 VPS 拉某个项目来部署——权限最小，机器被攻破也只影响这一个仓库的读取。\n① 在那台机器上生成（同样一路回车）：\nssh-keygen -t ed25519 -C \u0026#34;deploy-my-blog\u0026#34; ② 公钥加到「仓库」（不是账号）：GitHub → 进入该仓库 → Settings → Deploy keys → Add deploy key → 粘贴 ~/.ssh/id_ed25519.pub。只是拉代码就别勾 \u0026ldquo;Allow write access\u0026rdquo;（保持只读最安全）。\n③ 用 SSH 地址 clone / 切换远程：\ngit clone git@github.com:ldddi/my-blog.git # 之前用 https clone 过的，改成 SSH： git remote set-url origin git@github.com:ldddi/my-blog.git 进阶：一台机器要拉多个私有仓库 一把 Deploy Key 只能绑一个仓库，而默认名字 id_ed25519 一台机器只有一份。所以多个仓库时，要给每个仓库单独生成一把、用 -f 指定不同文件名：\nssh-keygen -t ed25519 -C \u0026#34;deploy-blog\u0026#34; -f ~/.ssh/key-blog -N \u0026#34;\u0026#34; ssh-keygen -t ed25519 -C \u0026#34;deploy-repoA\u0026#34; -f ~/.ssh/key-repoA -N \u0026#34;\u0026#34; （这里 -f 指定文件名、-N \u0026quot;\u0026quot; 设空密码，正是为了区分多把 key、且免交互。）\n但自定义名字的 key，SSH 默认不会主动去用（它只认 id_ed25519 这类默认名）。所以要在这台机器上（不是 GitHub）编辑 ~/.ssh/config，告诉它「连哪个仓库用哪把 key」：\n# 文件在拉代码的机器上：~/.ssh/config Host github-blog # 自定义别名，随便起 HostName github.com User git IdentityFile ~/.ssh/key-blog # 这个别名用这把私钥 IdentitiesOnly yes Host github-repoA HostName github.com User git IdentityFile ~/.ssh/key-repoA IdentitiesOnly yes Host github-blog：一个别名——因为两个仓库都在 github.com，靠别名区分该用哪把 key； HostName / User git：实际连的还是 github.com、用户名固定 git； IdentityFile：这个别名用哪把私钥； IdentitiesOnly yes：只用这把，别去试机器上其它 key（避免连错/被拒）。 clone 时把地址里的 github.com 换成你的别名：\ngit clone git@github-blog:ldddi/my-blog.git # 注意是 github-blog 不是 github.com 单仓库时用默认名字 id_ed25519 即可，SSH 自动会用，不用折腾这个 config。\n方式三：Personal Access Token（PAT，走 HTTPS） 不想用 SSH、或在 CI 里跑，就用 Token 走 HTTPS：\nGitHub → Settings → Developer settings → Fine-grained token，限定到指定仓库 + 给所需权限（只拉给 Contents: Read，要推送给 Read and write）； clone： git clone https://\u0026lt;TOKEN\u0026gt;@github.com/ldddi/your-repo.git 优点：权限可细到「某仓库只读」；适合 CI、纯 HTTPS 环境； 缺点：Token 会过期，要妥善保存、定期轮换。 怎么选 方式 能访问 能干什么 适合 账号 SSH 密钥 你所有仓库 clone / pull / push 自己的开发机 Deploy Key 单个仓库 默认只读（可开写） 服务器 / CI 拉单个仓库 PAT（HTTPS） 可细粒度限定 按授予的权限 CI、HTTPS 环境 小结 只读拉公开仓库不用认证；私有仓库、以及任何 push 都要； 自己的开发机 → 账号 SSH 密钥，一次配好、全仓库全操作通吃； 服务器拉单个仓库部署 → 只读 Deploy Key，权限最小、最安全； CI / HTTPS 环境 → PAT。 ","permalink":"https://blog.lddi.net/posts/github-machine-access/","summary":"新机器想 clone / pull / push 你的仓库，常卡在认证上。讲清什么时候要认证、SSH 密钥和 Token 怎么配、服务器该用哪种。","title":"怎么让一台机器访问你的 GitHub 仓库"},{"content":"很多人第一次在 Cloudflare 后台看到 Edge Certificates、Client Certificates、Origin Server 三栏证书会犯懵。其实只要先搞清楚 Cloudflare 在你和访客之间到底做了什么，三种证书就各归其位了。\n先搞清楚：Cloudflare 在中间做了什么 Cloudflare 本质是一个 CDN + 反向代理。当你把域名接入 Cloudflare、打开「橙色云」之后，发生了一件关键的事：域名的 DNS 不再直接解析到你的服务器，而是指向 Cloudflare 的 IP。\n于是访客的请求路径从「直连」变成了「中转」：\n访客 ──→ Cloudflare 边缘节点(离访客最近的机房) ──→ 你的源站服务器 这一层带来了 CDN 的种种好处：\n就近接入 + 缓存：访客连的是离自己最近的边缘节点，静态内容直接从缓存返回，更快； 隐藏并保护源站：访客只看到 Cloudflare 的 IP，你真实服务器 IP 被藏起来，挡 DDoS、防端口扫描； 边缘防护：WAF、限流、Bot 拦截都在边缘就做掉。 代价是——Cloudflare 必须夹在中间，先把访客的 HTTPS 解开、再转发给你。正因为多了这一跳，HTTPS 不再是「浏览器到服务器」端到端的一条，而是被切成了两段，每段单独建立 TLS、各自需要证书：\n访客浏览器 ──TLS①── Cloudflare 边缘节点 ──TLS②── 你的源站(Nginx) Edge 证书 Origin 证书 TLS①：访客只和 Cloudflare 握手，看到的是 Edge 证书； TLS②：Cloudflare 再单独和你的源站握手，用的是 Origin 证书； 而后台那个 SSL/TLS 模式（Flexible / Full / Full strict）定义的，正是「第二段怎么加密、要不要校验源站证书」。 抓住「一条 HTTPS 被切成两段」这条主线，下面三种证书就全通了。\nEdge Certificates（边缘证书） 管的是 TLS①：访客浏览器 ⇄ Cloudflare 这一段。\n它装在 Cloudflare 的边缘节点上，访客在地址栏看到的那把小锁、那张证书，就是它； 默认由 Cloudflare 免费自动签发、自动续期（Universal SSL），你什么都不用管； 它是公共受信任的证书（浏览器认的 CA 签的），因为它要直接面对访客。 你站点 blog.lddi.net 访客看到的 HTTPS，就是 Edge 证书在起作用。\nOrigin Server Certificates（源站证书） 管的是 TLS②：Cloudflare ⇄ 你的源站服务器 这一段。\n由 Cloudflare 签发，但装在你自己的服务器上（Nginx）； 特点：只需被 Cloudflare 信任就行（不被公共浏览器信任也没关系，因为访客从不直连源站）；有效期可长达 15 年，免费； 配合 SSL/TLS 模式 Full (strict) 使用——这个模式会校验源站证书是否有效，所以源站必须装它。 这就是你 VPS 上 Nginx 配置里的 /etc/ssl/cloudflare/lddi.net.pem——它正是 Origin 证书。\nClient Certificates（客户端证书） 这张是另一个维度的东西，别和上面两张混。它用于 mTLS（双向 TLS），验证的是「谁在访问」。\n普通 HTTPS 只验证服务器身份（证明「你连的确实是这个网站」）； mTLS 反过来还要求客户端也出示证书，证明「你是被授权的访客」； Cloudflare 可以充当私有 CA 签发客户端证书，发给授权的设备/用户；开启 mTLS 后，没带有效客户端证书的请求会被直接拒绝； 典型场景：内部 API、后台系统、移动 App 后端——只放行特定设备，挡掉其他所有人。 所以 Client 证书不是用来「加密通道」的，而是用来「认人」的。\n一张表看懂区别 证书 装在哪 管哪一段 / 作用 证明谁的身份 谁签发 Edge Cloudflare 边缘 访客 ⇄ Cloudflare（加密） 服务器（给访客看） Cloudflare（Universal）/ 自带 Origin Server 你的源站 Nginx Cloudflare ⇄ 源站（加密） 源站（给 Cloudflare 看） Cloudflare Origin CA Client 客户端设备 双向认证（认人） 客户端 / 访客 Cloudflare Client CA 小结 Edge 和 Origin 是同一条 HTTPS 被 Cloudflare 拆成两段后、两段各自的「服务器证书」——一段对访客，一段对源站； Client 是另一回事——它在握手时反过来验证客户端身份，用于 mTLS 准入控制； 日常自建站最常打交道的是前两个：访客那段（Edge）Cloudflare 自动搞定，源站那段（Origin）你需要在服务器上装一张并把模式设成 Full (strict)。 ","permalink":"https://blog.lddi.net/posts/cloudflare-certificates/","summary":"用「一条 HTTPS 被 Cloudflare 拆成两段」这条主线，讲清 Edge、Origin Server、Client 三种证书各自管什么。","title":"Cloudflare 的三种证书：Edge、Client、Origin Server"}]