WP_insert_post自动化异常：FTP视频上传入库脚本调用丢失源配置行

遇到过一模一样的坑！这种浏览器能跑但脚本请求不行的问题，大概率是请求头、会话差异或者服务器端安全限制导致的，给你几个排查方向和具体解决办法：

1. 先对比浏览器和脚本的请求头差异 #

浏览器按F12打开开发者工具，在Network标签页找到那个GET请求，复制所有请求头；然后用脚本打印出发送的请求头，核心看这两个关键点：

• User-Agent：浏览器的UA是标准的浏览器标识（比如Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/118.0.0.0 Safari/537.36），而脚本默认UA是python-requests/2.31.0或Perl的LUA标识，WP的部分配置加载逻辑可能会因为UA非浏览器而跳过代码。
• Cookie：浏览器访问WP时会自动带上会话Cookie（比如wordpress_logged_in_xxx或wp-settings-1），这些Cookie可能关联了权限或配置加载状态，脚本默认没有。

解决示例（Python）：

import requests
headers = {
    'User-Agent': 'Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/118.0.0.0 Safari/537.36',
    'Cookie': 'wordpress_logged_in_xxx=xxx; wp-settings-1=xxx;'  # 从浏览器复制完整Cookie
}
# 用params自动处理参数编码，避免手动拼接出错
params = {'title': 'jeff', 'key': 'key'}
response = requests.get('urltofile', params=params, headers=headers)

2. 检查WP安全插件或服务器防火墙拦截 #

比如Wordfence这类WP安全插件，或者服务器的mod_security防火墙，会拦截非浏览器的请求，导致部分代码逻辑不执行。

• 临时测试：关闭安全插件后再用脚本请求，如果恢复正常，就给你的脚本请求添加白名单；或者查看服务器mod_security日志，确认是否有拦截记录。

3. 给WP脚本加调试日志定位问题 #

在你的WP脚本开头添加日志，记录每次请求的所有上下文信息，对比浏览器和脚本请求的差异：

// 日志写到服务器可读写的路径，比如tmp目录
file_put_contents(
    '/tmp/wp_script_debug.log',
    "请求时间：" . date('Y-m-d H:i:s') . "\n" .
    "请求头：" . print_r($_SERVER, true) . "\n" .
    "参数：" . print_r($_GET, true) . "\n" .
    "当前加载的配置：" . print_r($你的配置变量, true) . "\n" .
    "=====\n",
    FILE_APPEND
);

发起两次请求（浏览器+脚本）后，查看日志就能明确那两行配置是没初始化，还是条件判断没满足。

4. 排除参数编码问题 #

手动拼接URL时可能出现编码错误（比如特殊字符转义），导致服务器只收到部分参数，进而影响配置加载。建议用脚本内置的参数拼接方法自动处理编码，比如Python的params参数、Perl的HTTP::Request->new带参数列表。

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