POST请求仅部分机器/网络失败的技术排查求助

核心矛盾点：

• OPTIONS预检请求可正常通过，但实际POST请求未到达Pharo服务器，触发307临时重定向后被CORS策略拦截
• 仅部分网络/机器环境出现问题，说明问题与环境依赖强相关

1. .htaccess代理规则的重定向逻辑问题 #

原因 #

若.htaccess对POST请求的处理包含隐式重定向（比如强制HTTP转HTTPS时未保留请求方法），部分环境下会触发307重定向，导致浏览器重新发送请求时触发CORS问题。比如规则仅处理GET请求，或重定向时丢失POST请求体/方法。

解决方案 #

• 检查.htaccess代理规则，确保POST请求被正确转发而非重定向，示例规则：

  RewriteEngine On
  # 转发HTTPS请求到8079端口
  RewriteCond %{HTTPS} on
  RewriteRule ^(.*)$ http://localhost:8079/$1 [P,L]
  # 保留请求头与响应头一致性
  ProxyPassReverse / http://localhost:8079/
  RequestHeader set X-Forwarded-Proto "https"
  

• 避免添加R=307这类显式重定向标记，[P]是代理而非重定向，这是关键。

2. 网络环境中的中间代理/防火墙修改请求 #

原因 #

部分公司网络、公共WiFi的防火墙或代理服务器可能拦截/修改POST请求：比如将HTTPS的POST强制转为HTTP，或转发时丢失Content-Type等关键请求头，导致浏览器触发307重定向后触发CORS。

解决方案 #

• 让出现问题的用户通过Chrome DevTools网络面板抓包，确认请求发出后是否被中间节点修改了协议、方法或请求头。
• 在.htaccess中添加规则，拒绝HTTP请求，强制所有请求走HTTPS：

  RewriteCond %{HTTPS} off
  RewriteRule ^(.*)$ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301]
  

• 配置Pharo服务器信任X-Forwarded-Proto头，正确识别原始请求的HTTPS协议，避免因误判为HTTP触发重定向。

3. 浏览器缓存的旧规则干扰 #

原因 #

部分用户浏览器可能缓存了之前的307重定向记录或CORS响应，导致新POST请求直接走缓存逻辑，而非发送到服务器。

解决方案 #

• 让用户强制刷新缓存（Ctrl+Shift+R），或在开发者工具中勾选Disable cache后重试。
• 在前端fetch请求中添加禁止缓存的参数：

  fetch('/api/xxx', {
    method: 'POST',
    body: JSON.stringify(data),
    headers: { 'Content-Type': 'application/json' },
    cache: 'no-store', // 禁止缓存请求
    credentials: 'include' // 若需携带Cookie，确保配置正确
  })
  

4. Pharo服务器的路由匹配或请求解析问题 #

原因 #

虽然GET请求正常，但部分POST请求的Content-Type或请求体格式可能在特定环境下被修改，导致Pharo路由无法匹配，请求被直接丢弃（而非返回错误，因此看起来未到达服务器）。比如代理自动将Content-Type改为text/plain，但路由仅接受application/json。

解决方案 #

• 在Pharo服务器中添加全局日志，记录所有到达的请求（包括方法、URL、请求头），确认是否有POST请求被接收但未匹配路由。
• 放宽路由的Content-Type匹配规则，或添加兜底POST路由返回明确错误信息，便于排查。
• 确保Pharo服务器正确处理X-Forwarded-For等代理头，避免因来源IP判断问题拒绝请求。

5. SSL证书信任问题触发隐性重定向 #

原因 #

之前同域部署时遇到SSL问题，说明当前SSL证书可能存在信任缺陷（如自签名、过期、域名不匹配），部分严格的浏览器或网络环境会触发HTTPS到HTTP的重定向，导致POST请求失败。

解决方案 #

• 使用正规SSL证书（如Let's Encrypt免费证书），确保所有用户浏览器信任该证书。
• 检查服务器SSL配置，禁用HTTPS降级规则，禁止自动将HTTPS请求转为HTTP。

内容的提问来源于stack exchange，提问作者hogo