API Error: Claude Code is unable to respond to this request, which appears to violate our Usage Policy ( https://www.anthropic.com/legal/aup ). This request triggered restrictions on violative cyber content and was blocked under Anthropic’s Usage Policy. To request an adjustment pursuant to our Cyber Verification Program based on how you use Claude, fill out https://claude.com/form/cyber-use-case?token=pGYLMnOMNAll0qGatSemsGMPVwg44IccTgchmVGPeug9rBoG__W2Q2mEoSACBRJLuROgXsCiVNOABgiMSAL80i6He8YsoeSWPjxHceD3C-h_V3K7Talb30XqJaqcEv1fw2XsFTxGwD… Try rephrasing the request or attempting a different approach. If you are seeing this refusal repeatedly, try running /model claude-sonnet-4-20250514 to switch models.为啥会出现这个错误 4 个帖子 - 4 位参与者 阅读完整话题
Introducing Prism, one inbox for pull requests across both Github and Gitlab. AI makes it easy to generate a lot of code and PRs, so Prism makes it easy to track which PRs needs your attention. Eventually I'd like to make a great code review UI as part of this, too, but baby steps. Free while in beta. Give it a shot, and let me know what you think. Comments URL: https://news.ycombinator.com/item?id=47806464 Points: 1 # Comments: 0
改成报这个了，Request rejected (429) · Service Unavailable，难道是解封了吗。 1 个帖子 - 1 位参与者 阅读完整话题
Request failed with status code 400: {“error”:{“type”:“client”,“reason”:“ssrf_blocked”,“message”:“connection to private IP is blocked”,“retryable”:false}} 3 个帖子 - 2 位参与者 阅读完整话题
Meta An Update on Meta Quest Pricing Starting April 19, 2026, we’ll be increasing the prices for our Meta Quest 3 and Meta Quest 3S headsets. Est. reading time: 2 minutes 新价格 Meta Quest 3S (128 GB): $349.99 Meta Quest 3S (256 GB): $449.99 Meta Quest 3 (512 GB): $599.99 Meta blames RAM shortage for $100 Quest 3 price hike | The Verge 4 个帖子 - 4 位参与者 阅读完整话题
API Error: 400 {"type":"error","error":{"type":"invalid_request_error","message":"\"thinking.type.enabled\" is not supported for this model. Use \"thinking.type.adaptive\" and \"output_config.effort\" to control thinking behavior."},"request_id":""} claudecode中 api调用一直这样 1 个帖子 - 1 位参与者 阅读完整话题
IT之家 4 月 16 日消息，受全球内存短缺影响，Meta 成为又一家上调硬件产品售价的科技公司。 从 4 月 19 日起，Meta 的 128GB 版 Quest 3S VR 头显售价将调整为 349.99 美元（IT之家注：现汇率约合 2391 元人民币），256GB 版 Quest 3S 为 449.99 美元（现汇率约合 3075 元人民币），Quest 3 则为 599.99 美元（现汇率约合 4099 元人民币）。两款 Quest 3S 机型均涨价 50 美元（现汇率约合 341.6 元人民币），Quest 3 涨价 100 美元（现汇率约合 683.2 元人民币）。 翻新产品同样会涨价。翻新 128GB 和 256GB 版 Quest 3S 同样各涨价 50 美元，分别调整为 319.99 美元（现汇率约合 2186 元人民币）和 409.99 美元（现汇率约合 2801 元人民币）；翻新 Quest 3 售价 549.99 美元（现汇率约合 3758 元人民币），涨价 170 美元。配件价格将保持不变。 Meta 表示：“我们做出这一调整，是因为高性能 VR 硬件的制造成本大幅上涨。全球关键零部件 —— 尤其是内存芯片价格的飙升，正影响几乎所有消费电子产品品类，其中就包括 VR 设备。为了继续为用户提供 Quest 平台应有的硬件、软件与服务品质，我们需要对定价进行调整。” 此次调价后，Quest 头显成为又一款因内存危机涨价的科技产品，此前已有手机和平板、微软 Surface 、掌机、索尼 PlayStation 5 等产品纷纷涨价。 不过，Meta 的另一类硬件产品目前暂不受影响：Meta 发言人 Johanna Peace 向 The Verge 透露，Meta 短期内暂无因内存短缺上调智能眼镜售价的计划。
尝试登录 公益站 出现 The request is missing a required parameter, includes an invalid parameter value, includes a parameter more than once, or is otherwise malformed 昨天正常用不行，但是开 无痕浏览 还能正常上去，现在开不开无痕都报这个错了，本来想看看有没有佬友遇到相同问题，但搜到的都是说 “多试几下” ，实在没招了 求解 1 个帖子 - 1 位参与者 阅读完整话题
API Error: 500 {"type":"error","error":{"type":"api_error","message":"Internal server error"},"request_id":"xxxxxx"} · check status.claude.com 1 个帖子 - 1 位参与者 阅读完整话题
API Error: 500 {“type”:“error”,“error”:{“type”:“api_error”,“message”:“Internal server error”},“request_id”:“req_011Ca5jjamr8PgBFjeoi1Mrr”} · check status.claude.com 12 个帖子 - 7 位参与者 阅读完整话题
现在又报错 API Error: 500 {“type”:“error”,“error”:{“type”:“api_error”,“message”:“Internal server error”},“request_id”:“req_011Ca5dderFswn1BfKDvkhyKB”} · check status.claude.com 16 个帖子 - 15 位参与者 阅读完整话题
拿到验证码的url, 解析出request_code 通过request_code, 请求ext_api/page_data接口, 拿到验证码基础信息. 主要包含 session 和 sign 两个长字符串 2.1 sign 是一段加密过的 包含 环境检测 / 控制流 的/很 长 /很 大 的 一串js代码. 解密sign要用到session , 目前检测的环境不多 , sign解密成js代码并且执行成功后可以拿到一个关键的变量 _f 的值. 通过request_code, 请求ext_api/spiderindefence/info接口, 拿到验证码的两张图片信息, 以及一个很重要的 hint 值(乱码字符串, 解密九宫格图片的顺序时要用到) 识别第一张图片文本, 拿到要 连接哪个颜色 ; 识别第二张图片, 拿到 哪个坐标(位置)是哪个颜色 4.1 文本图片 可以考虑使用 ddddocr , 可以勉强识别, 成功率较低 4.2 九宫格图片 识别 4.2.1 服务器下发的九宫格 原图 , 顺序/大小都是混淆过的 . 页面最终显示的验证码 是在客户端 先用js解密出九宫格图片的排序顺序, 然后用canvas重新画出的一张图片. 4.2.2 需要扣一下 解密九宫格图片排序的js代码; canvas画图的代码用python的PIL库复现一下就行(一点儿也不难:curse:) 4.2.3 重组后的九宫格图片, 还要注意调整分辨率 (不然会导致下面4.2.4中坐标读取错误) 4.2.4 每个位置的球的颜色识别, 本质就是用PIL库读取固定点的RGB值就可以了, 判断RGB在哪个颜色范围, 就属于哪个颜色. (9个球的位置都是固定的) 4.2.5 参考 原图: 重新排序以及重置分辨率后: 5. 生成滑动轨迹. 手动收集, 每个位置的球都手动连一次, 要注意收集到的轨迹数组的长度, 太长不行, 太短也不行. (不然就得重新收集, 一点儿也不麻烦{:1_909:}) 6. 加密各个参数, 提交验证(这部分有很多要注意的点, 先写还记得的) 6.1 behavior和_token, 使用的同一个加密算法, 加密两轮, 但是传入的参数有区别 , 注意区分就好了. 加密结果要用到上面解出来的**_f** 值 6.2 _token主要包含 两个重要的时间戳 , 几段 不完整的 鼠标移动轨迹 数组和一个点击事件生成的小数组, 以及一些简单的基础环境信息 6.3 behavior主要包含 九宫格图片 与各个元素的相对位置坐标, 点击次数, 以及滑动轨迹(有长度限制) 6.3 时间戳部分, 在正确的位置生成正确的时间戳! 注意每个有关联的时间戳之间的差值. 多刷新几次浏览器, 拿到一个大概的差值, 在代码里随机生成一下 6.4 轨迹部分, 注意每个轨迹数组是怎么来的. 不同的轨迹数组, 但是可以相互印证, 对不上就鸡鸡! 有意思的: 通过判断是否存在 “v_” 开头的函数名, 检测v_jstools插件. 图片顺序的解密, js代码的解密, 轨迹的加密代码 都不难. 扣完代码, 再加上补环境的代码, 也就400+行! 更多的是 每个节点生成的时间戳 和 各个轨迹数组的验证! 1 个帖子 - 1 位参与者 阅读完整话题
Hi HN, I’m building Resonly to help teams prioritize feature requests with more context than just votes. The idea is simple: not every request is equal. A feature requested by multiple paying customers may matter more than one with 100 upvotes from free users. I’ve added a way to associate revenue with each customer, so when someone upvotes or submits a feature request, the admin can see three signals: MRR at risk — how much current MRR is tied to customers asking for it; MRR lost — how much MRR was lost from customers who churned before it was solved; Potential MRR — how much MRR could be converted from trial customers requesting it. I’d love your honest feedback on the idea and positioning. Comments URL: https://news.ycombinator.com/item?id=47766516 Points: 1 # Comments: 0
OAuth error: Request failed with status code 403 1 个帖子 - 1 位参与者 阅读完整话题
I got a surprise bill. Nothing catastrophic, but enough to make me dig into why — an agent had hit a retry loop and kept calling the API for hours. There's no way to set a hard cap on the Anthropic or OpenAI APIs. You can get an email after the fact, but nothing that actually stops requests mid-flight. So I built a proxy. You swap one environment variable, it routes through Costile instead of calling Anthropic directly, and when you hit your daily or monthly limit it blocks further requests immediately. No SDK changes, no code refactor. Took me about a weekend. Currently supports Anthropic, with OpenAI next. It's MIT licensed and self-hostable in about 5 minutes. Try the demo at costile.com if you want to poke at it. I've got anomaly detection on the roadmap, but I'm second-guessing the scope — is surfacing cost spikes enough, or do people actually need to know why the agent went off the rails? The former is straightforward to build, the latter is a much harder problem. Curious where others would draw that line. GitHub: https://github.com/Mkiza/ai-agent-cost Comments URL: https://news.ycombinator.com/item?id=47765314 Points: 1 # Comments: 2
Article URL: https://anna.software/main Comments URL: https://news.ycombinator.com/item?id=47765139 Points: 3 # Comments: 0
错误提示是 Error: Your request was blocked. openclaw 解决403的方式是加UA hermes agent的配置文件里面不能添加UA 直接让小龙虾把 User-Agent: curl/8.5.0 注入 .hermes/hermes-agent/run_agent.py 手工修改的方式是把 elif "xxxapi.cc.cd" in effective_base.lower(): client_kwargs["default_headers"] = { "User-Agent": "curl/8.5.0", } 加入到这附近 elif "api.kimi.com" in effective_base.lower(): client_kwargs["default_headers"] = { "User-Agent": "KimiCLI/1.30.0", } 其中 xxxapi.cc.cd 这里改成你自己的中转站的地址 1 个帖子 - 1 位参与者 阅读完整话题
[!question] generate链接有什么用途？ generate_204主要功能：检测网络状态。当你的设备（手机、电脑、路由器等）连接到一个新的网络（如公共 Wi-Fi）时，它需要确认是否真的能访问互联网。正常情况： 设备访问该链接，服务器返回一个 HTTP 状态码 204 No Content（表示请求成功，但没有返回任何内容, 也有个别厂商返回状态码200或静态文本）。由于响应体为空，加载速度极快且节省流量。在 HTTP 协议中，204 状态码表示“执行成功，但不返回任何实体内容”。 [!question] 谁在使用它？ 浏览器： 用来判断用户是否需要登录路由器界面。 代理软件（如 Clash/V2Ray）： 经常使用这些链接来测试不同节点的延迟和可用性。 操作系统： 用来显示网络连接图标上的感叹号（如果无法访问该链接，系统会认为当前网络无法上网）。 以下是国内外互联网科技公司提供的公共网络测试服务链接： [!todo] http://www.gstatic.com/generate_204 http://www.google-analytics.com/generate_204 http(s)://www.apple.com/library/test/success.html http://cp.cloudflare.com/generate_204 http://edge-http.microsoft.com/captiveportal/generate_204 http://connectivity-check.ubuntu.com http://www.v2ex.com/generate_204 http://connect.rom.miui.com/generate_204 http://wifi.vivo.com.cn/generate_204 http://connectivitycheck.platform.hicloud.com/generate_204 http://spectrum.s3.amazonaws.com/kindle-wifi/wifistub.html http://detectportal.firefox.com/success.txt http://connectivity.samsung.com.cn/generate_204 http://www.qualcomm.cn/generate_204 欢迎补充 1 个帖子 - 1 位参与者 阅读完整话题
首先说一下前提： 自己搭建的 sub2api 用 codex 上请求不上，但是站上其他人的公益站的 sub2api 的却可以，主要体现在/v1/responses 的请求不通，但是使用 curl 发请求却是可以的。 先是查了一下站上有人问没，有说不用代理的，有说没加 /v1的，翻了几个和我情况也不太相符，于是问 ai： 他先让我看我的 sub2api 是否真的支持 /v1/responses ，用 curl 请求非流式和流式，判断是不是这个的问题；我试了没问题都有返回。 然后让我看是不是 nginx 配置 的问题，发现多了静态网站配置的，让我删了排除干扰；顺便排除 cf 没开小黄云；改完以后测试发现还是有问题。于是再问它。 nginx 改好了，重启了，还是这样。先• Reconnecting... 2/5 (16s • esc to interrupt) └ Stream disconnected before completion: error sending request for url (https://xxx/v1/responses) 最后■ stream disconnected before completion: error sending request for url (https://xxx/v1/responses) 他判断是： 请求阶段/连接阶段就出问题了 。 也就是说，Codex 甚至可能还没稳定进入“正常接收流”的阶段。 让我检查全链路问题： 确认是否经过 Cloudflare； 把 HTTP/3 / QUIC 彻底关掉， 别让客户端有机会走 HTTP/3，只保留 listen 443 ssl; listen [::]:443 ssl; 强制测 HTTP/1.1 和 HTTP/2 直接看 Nginx access/error log 从服务器本机测，不走公网绕路 都测了发现都正常，又判断是不是域名证书有问题，因为返回有点不同。 openssl s_client -connect 域名:443 -servername 域名 ，测了发现证书没问题。 上面一通查证，发现都正常。它说最后该怎么办呢？ 现在最有效的排查方式，不是继续猜，而是抓“真实请求” : 给 nginx 增强 access log，重点看用 codex 发消息后nginx 日志的打印情况。 最终发现了问题了关键点： 2026/04/13 14:57:58 [info] 28#28: *70 SSL_do_handshake() failed (SSL: error:0A000102:SSL routines::unsupported protocol) while SSL handshaking, client: xxxx, server: 0.0.0.0:443 2026/04/13 14:57:59 [info] 28#28: *71 SSL_do_handshake() failed (SSL: error:0A000102:SSL routines::unsupported protocol) while SSL handshaking, client: xxx, server: 0.0.0.0:443 2026/04/13 14:58:00 [info] 28#28: *72 SSL_do_handshake() failed (SSL: error:0A000102:SSL routines::unsupported protocol) while SSL handshaking, client: xxxx, server: 0.0.0.0:443 它 优先怀疑 TLS/代理兼容问题。看 nginx 里是否有 ssl_protocols TLSv1.2 TLSv1.3 ; 看了一下我的还真没有！！ 最终给了我建议， 80 和 443 混在一个 server 里，虽然能跑，但不够干净 改造后的配置： upstream backend_GduktARz { server sub2api:8080; keepalive 64; } # 80 端口：纯跳转 server { listen 80; listen [::]:80; server_name 域名; location ^~ /.well-known/acme-challenge/ { default_type "text/plain"; root /var/www/letsencrypt; } location / { return 301 https://$host$request_uri; } } # 443 端口：正式 HTTPS server { listen 443 ssl http2; listen [::]:443 ssl http2; server_name 域名; ssl_certificate /etc/nginx/certs/xxxx.pem; ssl_certificate_key /etc/nginx/certs/xxxx.pem; # 关键：明确支持 TLS 1.2 / 1.3 ssl_protocols TLSv1.2 TLSv1.3; client_max_body_size 1000m; access_log /dev/stdout; error_log /dev/stderr info; # 专门给 Responses SSE location = /v1/responses { proxy_pass http://backend_GduktARz; proxy_http_version 1.1; proxy_set_header Host $host; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_set_header X-Forwarded-Proto $scheme; proxy_set_header Connection ""; proxy_buffering off; proxy_request_buffering off; proxy_cache off; gzip off; # SSE 一般别乱折腾 chunked，保持现在这样问题不大 chunked_transfer_encoding off; proxy_read_timeout 3600s; proxy_send_timeout 3600s; send_timeout 3600s; add_header Cache-Control "no-cache" always; add_header X-Accel-Buffering "no" always; } # 其他 API location /v1/ { proxy_pass http://backend_GduktARz; proxy_http_version 1.1; proxy_set_header Host $host; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_set_header X-Forwarded-Proto $scheme; proxy_set_header Connection ""; proxy_read_timeout 300s; proxy_send_timeout 300s; } # 兜底 location / { proxy_pass http://backend_GduktARz; proxy_http_version 1.1; proxy_set_header Host $host; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_set_header X-Forwarded-Proto $scheme; proxy_set_header Connection ""; } } 改了后发现正常了！！我的 codex 可以正常回复了！！ 花了一下午的时间，发现终于好了。 最后结论总结采用及更改： 显式开启 HTTP/2 显式声明 TLS 版本 在 /v1/responses 保持流式友好配置 拆分 80 / 443 server（不是主因） 最终结论： Nginx 在 HTTPS/TLS/HTTP2 连接层面的配置不够明确，导致部分客户端连接协商失败，进而表现为客户端请求发送失败和流式响应中断。 后语： 现在的 ai 时代还是太超前了，想几年前如果遇到这种问题，不熟悉这个领域的根本解决不了。还是感谢人类的伟大创造。后面有人如果遇到可以参考一下（大概率遇不到 ） 2 个帖子 - 2 位参与者 阅读完整话题
正在蹬的时候突然发现 500 了? API Error: 500 {"type":"error","error":{"type":"api_error","message":"Internal server error"},"request_id":"req_xxxx"} 没有收到封号邮件,网也是通的,有一样的佬友吗? 21 个帖子 - 19 位参与者 阅读完整话题