I'm trying to setup Xdebug because I'm tired of using echoes and var_dumps.
I'm using Atom as my IDE with the php-debug plugin.
I'm using the laravel Homestead vm as a server. forwarded port 9000 to 9999
Atom has the plugin installed with the following settings:
I set a breakpoint in Atom, I browse to my page but the breakpoint doesn't trigger.
I have a hunch that it has something to do with the IDE key but I don't know how to proceed.
Does anyone know the IDE key for atom?
Or is there something else I'm missing?
edit: I've added the following to xdebug.ini:
xdebug.auto_trace = 0
xdebug.collect_includes = 1
xdebug.collect_params = 1
xdebug.collect_return = 0
xdebug.collect_vars = "Off"
xdebug.default_enable = "On"
xdebug.dump.COOKIE = ""
xdebug.dump.FILES = ""
xdebug.dump.GET = ""
xdebug.dump.POST = ""
xdebug.dump.REQUEST = ""
xdebug.dump.SERVER = ""
xdebug.dump.SESSION = ""
xdebug.dump_globals = 1
xdebug.dump_once = 1
xdebug.dump_undefined = 0
xdebug.extended_info = 1
xdebug.file_link_format = ""
xdebug.idekey = "VVVDEBUG"
xdebug.manual_url = "http://www.php.net"
xdebug.max_nesting_level = 100
xdebug.overload_var_dump = 1
xdebug.profiler_append = 0
xdebug.profiler_enable = 0
xdebug.profiler_enable_trigger = 1
xdebug.profiler_output_dir = "/tmp"
xdebug.profiler_output_name = "cachegrind.out.%t-%s"
xdebug.remote_autostart = 1
xdebug.remote_enable = 1
xdebug.remote_handler = "dbgp"
xdebug.remote_host = "192.168.50.1"
xdebug.remote_log = /srv/log/xdebug-remote.log
xdebug.remote_mode = "req"
xdebug.remote_port = 9000
xdebug.show_exception_trace = 0
xdebug.show_local_vars = 0
xdebug.show_mem_delta = 0
xdebug.trace_format = 0
xdebug.trace_options = 0
xdebug.trace_output_dir = "/tmp"
xdebug.trace_output_name = "trace.%c"
xdebug.var_display_max_children = -1
xdebug.var_display_max_data = -1
xdebug.var_display_max_depth = -1
Like #sparkos72 says, the atom ide key xdebug.atom works for me on Ubuntu 16.04 and Debian 7 :-). I try to extend their answer.
I used php-debug atom extension with this config in the xdebug.ini (path: /etc/php5/apache2/conf.d/xdebug.ini).
xdebug.remote_enable=1
xdebug.remote_handler=dbgp
xdebug.remote_mode=req
xdebug.remote_host=172.17.0.1
xdebug.remote_port=9000
xdebug.idekey=xdebug.atom
xdebug.remote_autostart=true
I have a docker container with debian 7 + apache + php 5, that's the reason because I use ip 172.17.0.1 instead of 127.0.0.1. My "real" machine is an Ubuntu.
Hope it helps.
IDE key is xdebug.atom for me (mac/apache). In the Atom php-debug config, set the server port to 9000
None of the answers worked for me, so I'm leaving one of my own.
Setup
Make sure xdebug is enabled; sudo phpenmod xdebug or equivalent
Make sure xdebug is correctly configured:
xdebug.remote_enable=1
xdebug.remote_handler=dbgp
xdebug.remote_mode=req
xdebug.remote_host=172.17.0.1 (as per your setup)
xdebug.remote_port=9000 (as per your setup)
Didn't do xdebug.remote_autostart because it starts the debug stuff even for normal requests. So, even if you are not in the debug mode for the Chrome / Firefox extension, an attempt to convey debugging data will be made, which might slow things down without any reason.
Install Xdebug chrome/firefox extension and setup IDE Key as xdebug-atom (I found xdebug.atom to also be working).
Debugging
When you actually want to debug something,
Add a breakpoint where you want in your code; Alt + F9 or equivalent.
Open the PHP Debug panel in Atom; Ctrl + Alt + D or equivalent. If you are on certain versions Ubuntu, you might want to change the shortcut Ctrl + Alt + D might act as Show Desktop. In which case, click on the PHP Debug button in the IDE to toggle the debugger.
The debugger should say something like Listening to port 9000 or the port you setup in the PHP Debug settings.
Open the page you want to debug in your browser (if not already open) and click on the debugging extension icon to enable Debug mode. This actually sets a cookie in your document like XDEBUG_SESSION=xdebug-atom, etc.
Once the debug extension is enabled, refresh the page and you should be able to use the debugger (if everything went right).
Hope this helps. Took a while to get it working. Now I don't have to buy PHP Storm!
I know it is late but again:
Your .ini file have this:
xdebug.idekey = "VVVDEBUG"
which means you need to set the value "VVVDEBUG"(without quotes) in "The Easiest Xdebug" extension settings where you use "Atom" currently
IDE key is xdebug-atom for me on PHP3.2+ ATOM+ XAMPP+ XDEBUG Helper, strongly recommending to use XDEBUG Helper, you could set IDE key there.
I was trying the same thing, but never I found a real solution and I saw that xdebug started debug when find a error exeption I started put error in my code when I need debug and works well, example put this code in the line that you want debug.
#xdebug_start:
and watch the magic.
I did a video installing the plugin.
https://www.youtube.com/watch?v=jD0TIzYMFzQ
Related
I try to setup Xdebug for shopware-docker without success.
VHOST_[FOLDER_NAME_UPPER_CASE]_IMAGE=ghcr.io/shyim/shopware-docker/6/nginx:php74-xdebug
After replacing your Folder Name and running swdc up Xdebug should be activated.
Which folder name should I place?
Using myname, the same name as in /var/www/html/myname, return error on swdc up myname:
swdc up myname
[+] Running 2/0
⠿ Network shopware-docker_default Created 0.0s
⠿ Container shopware-docker-mysql-1 Created 0.0s
[+] Running 1/1
⠿ Container shopware-docker-mysql-1 Started 0.3s
.database ready!
[+] Running 0/1
⠿ app_myname Error 1.7s
Error response from daemon: manifest unknown
EDIT #1
With this setup VHOST_MYNAME_IMAGE=ghcr.io/shyim/shopware-docker/6/nginx:php81-xdebug (versioned Xdebug) the app started:
// $HOME/.config/swdc/env
...
VHOST_MYNAME_IMAGE=ghcr.io/shyim/shopware-docker/6/nginx:php81-xdebug
But set a debug breakpoint (e.g. in index.php), nothing happens
EDIT #2
As #Alex recommend, i place xdebug_break() inside my code and it works.
Stopping on the breakpoint the debugger log aswers with hints/warnings like described in the manual:
...
Cannot find a local copy of the file on server /var/www/html/%my_path%
Local path is //var/www/html/%my_path%
...
click on Click to set up path mapping to open the modal
click inside modal select input Use path mapping (...)
input field File path in project response with undefined
But i have already set up the mapping like described in the manual, go to File | Settings | PHP | Servers:
Why does not work my mapping? Where failed my set up?
The path mapping needs to be between your local project path on your workstation and the path inside the docker containers. Without xDebug has a hard time mapping the breakpoints from PHPStorm to the actual code inside the container.
If mapping the path correctly does not work and if its a possibility for you, i can highly recommend switching to http://devenv.sh for your development enviroment. Shopware itself promotes this new enviroment in their documentation: https://developer.shopware.com/docs/guides/installation/devenv and provides an example on how to enable xdebug:
# devenv.local.nix File
{ pkgs, config, lib, ... }:
{
languages.php.package = pkgs.php.buildEnv {
extensions = { all, enabled }: with all; enabled ++ [ amqp redis blackfire grpc xdebug ];
extraConfig = ''
# Copy the config from devenv.nix and append the XDebug config
# [...]
xdebug.mode=debug
xdebug.discover_client_host=1
xdebug.client_host=127.0.0.1
'';
};
}
A correct path mapping should not be needed here, as your local file location is the same for XDebug and your PHPStorm.
I am using selenoid for remote browser testing in ruby.
In that I am using 'selenium-webdriver', 'capybara', 'rspec' for automation. And I am using attach_file method for uploading file to browser
I want to upload file on Firefox and Chrome browser but it raises error on both;
In chrome
Selenium::WebDriver::Error::UnknownCommandError: unknown command: unknown command: session/***8d32e045e3***/se/file
In firefox
unexpected token at 'HTTP method not allowed'
So After searching I found the solution for chrome which is to set w3c option false in caps['goog:chromeOptions'] > caps['goog:chromeOptions'] = {w3c: false}
So now chrome is using OSS bridge for handshaking but I don't know how to do it in Firefox. Similar solution is not available for Firefox.
My browser capabilities are following:
if ENV['BROWSER'] == 'firefox'
caps = Selenium::WebDriver::Remote::Capabilities.new
caps['browserName'] = 'firefox'
# caps['moz:firefoxOptions'] = {w3c: false} ## It is not working
else
caps = Selenium::WebDriver::Remote::Capabilities.new
caps["browserName"] = "chrome"
caps["version"] = "81.0"
caps['goog:chromeOptions'] = {w3c: false}
end
caps["enableVNC"] = true
caps["screenResolution"] = "1280x800"
caps['sessionTimeout'] = '15m'
Capybara.register_driver :selenium do |app|
Capybara::Selenium::Driver.new(app, browser: :remote,
:desired_capabilities => caps,
:url => ENV["REMOTE_URL"] || "http://*.*.*.*:4444/wd/hub"
)
end
Capybara.configure do |config|
config.default_driver = :selenium
end
I have found the problem. There is bug in selenium server which run on java so I have to change my selenium-webdriver gem version 3.142.7 and monkey-patch.
You can find more information here about the bug and resolution.
For now I have to change my gem and monkey patch the selenium-webdriver-3.142.7\lib\selenium\webdriver\remote\w3c\commands.rb file. check for below line which is on line no 150.
upload_file: [:post, 'session/:session_id/se/file']
and update it to
upload_file: [:post, 'session/:session_id/file']
i had a similar issue with rails 7. the issue is connected with the w3c standard. the core problem is that the webdriver for chrome uses a non-w3c standard url for handling file uploads. when uploading a file, the webdriver uses the /se/file url path to upload. this path is only supported by the selenium server. subsequently, the docker image provided by selenium works fine. yet, if we use chromedriver, the upload fails. more info.
we can solve this, by forcing the webdriver to use the standard-compliant url by overriding the :upload_file key in Selenium::WebDriver::Remote::Bridge::COMMANDS. since, the initialization of this the COMMANDS constant does not happen when the module is loaded, we can override the attach_file method to make sure the constant is set correctly. here the hacky code:
module Capybara::Node::Actions
alias_method :original_attach_file, :attach_file
def attach_file(*args, **kwargs)
implement_hacky_fix_for_file_uploads_with_chromedriver
original_attach_file(*args, **kwargs)
end
def implement_hacky_fix_for_file_uploads_with_chromedriver
return if #hacky_fix_implemented
original_verbose, $VERBOSE = $VERBOSE, nil # ignore warnings
cmds = Selenium::WebDriver::Remote::Bridge::COMMANDS.dup
cmds[:upload_file] = [:post, "session/:session_id/file"]
Selenium::WebDriver::Remote::Bridge.const_set(:COMMANDS, cmds)
$VERBOSE = original_verbose
#hacky_fix_implemented = true
end
end
In Firefox images we support /session/<id>/file API by adding Selenoid binary which emulates this API instead of Geckodriver (which does not implement it).
In an XAMPP/Linux environment, I'm using XDebug via Eclipse to assist set-up of a new application.
I start the application from the client laptop like so:
http://192.168.1.5/oc/index.php?XDEBUG_SESSION_START
(The idea being that I can step on the server while interact via the physically adjacent client.)
I can successfully monitor execution up to the point where I see the initial panel on the browser.
I now wish to pause execution immediately a button is clicked...
<form action="index.php" method="post">
<input type="submit" class="primary" value="Finish setup" data-finishing="Finishing …">
</form>
The submit no doubts triggers re-execution of 'index.php' but the debug hook is seemingly lost. (The break points are ignored.)
How can I retain (or re-establish) the hook?
NB:
Problem is only because I am debugging remotely. I see expected behaviour when I commence monitoring via Eclipse -> Debug As issued server-side.
Here's the full .ini:
[XDebug]
zend_extension = /opt/lampp/lib/php/extensions/no-debug-non-zts-20170718/xdebug.so
xdebug.remote_enable = on
xdebug.remote_port = 9000
xdebug.remote_log = /tmp/xdebug.log
xdebug.profiler_append = 0
xdebug.profiler_enable = 1
xdebug.profiler_enable_trigger = 0
xdebug.profiler_output_dir = "/tmp"
xdebug.profiler_output_name = "cachegrind.out.%t-%s
I'm trying to get trace logging information out of the gecko driver, in order to debug some issues we're having with moving to newer versions of Python, Robot Framework, Selenium, Firefox.
See in the DEBUG robot output below, I'm setting the capabilities to include log level arguments as part of moz:firefoxOptions.
When the capabilities are printed out for Open Browser, the moz:firefoxOptions value has been replaced with the profile info, so I never get tracing set.
20190219 13:07:22.461 - INFO - {'browserName': 'firefox', 'marionette': True, 'acceptInsecureCerts': True, 'moz:firefoxOptions': {'prefs': {'log': {'level': 'trace'}}, 'args': ['-headless', '-profile', '/tmp/tmpimda__f2']}, 'binary': '/usr/bin/firefox'}
20190219 13:07:22.461 - INFO - +--- END KW: BuiltIn.Log (1)
20190219 13:07:22.461 - INFO - +--- START KW: CustomLib.AdminClass.Open Browser [ ${LOGIN URL} | ${BROWSER} | desired_capabilities=${dc} | ff_profile_dir=${profile} ]
20190219 13:07:22.462 - INFO - Opening browser 'Firefox' to base url 'https://HOST:PORT/bmmadmin/login.jsp'.
20190219 13:07:22.480 - DEBUG - POST http://127.0.0.1:38132/session {"capabilities": {"firstMatch": [{}], "alwaysMatch": {"browserName": "firefox", "acceptInsecureCerts": true, "moz:firefoxOptions": {"profile": "UEsDBBQAAAAIAOtoU04+3NKsfgMAAM0MAAAHAAAAdXNlci5qc6VWTW/UMBC98ytQTyCx1rbABU6lFAkJUcSq4mg59mTjrmMbe7zp/nvGyaYsbb6AWz7e89hvZt44RQjcByhfnBXBNfTGlKtZo61yDVOp9gysKAyos1fPMSR4+f5ZesoxAiGEZE/ApTBxBG2hQVGwFAzhzkThEr4rjLC7sym8F1tYtn5EETB5lhmEXE+jKlfDEblgL49Z3O3p5FoBqyM6266it9YFGFmAPqkb+6MVOJ6vmbYY3O33L9Phc1Jqcc9lFSgwjzJoj5wU56jrHPT1epiwDBnAu4BcGMPvIod7CR61s3Ew6XdiL7plmetgLFau+Wyv6NEZGCRZwMaFHZOCKHtY5XjCrAiw13ImrxFkChoPTMa+HEeAj5PTgJFZr9lSm2IyoZTO5xQzizRQqECHC1zIrCBPlNsUERSXEHBYzRNSjClHfCBp+gBhhtXpwa3IsnLYgx0JJLxnySvqVCYSumEFT0CLWk3p6I04gLo+X2++OqRcEuHNCNg11jihqDAtaRzasvlRgd1k9bXdTse6vv1yyfp2m7SjFvmadVmYsy5td1THYKnsycS6JF/MYcmSOo8cB7uyJPxIpfagAEJlZQBB0k4/6RDxkrSQI230YEOihPaZVFtoiqeMWphGhKV2CiLI6lgWc1BTxuRzc/f2PuajEGO2DiSnJBXayi/J27gMIlYzUSowhskK5O4jlCIZ/ND9mabRDImMjm1v7JVxceYoJ+gbyvgwmBQRnXdmVSsQBqvunS1ytgl+8rlVrv+R3Ucvc0F9T3+/feO22/xRdp7+F/vwzmh5YPnjJhW1bvP8v/xv7cfL3w09tAzs0TkTGTmEC8eNT15f8ugjB2sNtG1rRXPGbnlWfjhG9gjbFm5roh878kYSO7vu+XoUXhgnd0ZHnK6IE0Zb4Feu9mTthTZ5AFq9rdAcZqlLLPwp3JJ/l4fb0UY6GfxTqvajvnP51dEHVzRiMcXhlXtKhUjXtkrH6rDKvz3NxJUBu8VsCRdv3/5J65emqUX5MMY1vDhw1XnC4N48WYzHmLub104Js/DmUWoD9MRc0NQWvKvRfJmawUcMWiJ/TBsKlW+NlqywhrqAsGlfR+TKZb7TyI6y9eP0WMqDB+8pCIYiYDiwTor25Bdz2EmRnsID3LXjbHAn916T7VO2WD4y1QS5PzF+Jh3GIvymNJWmMLmLBhi/AFBLAQIUAxQAAAAIAOtoU04+3NKsfgMAAM0MAAAHAAAAAAAAAAAAAACkgQAAAAB1c2VyLmpzUEsFBgAAAAABAAEANQAAAKMDAAAAAA=="}}}, "desiredCapabilities": {"browserName": "firefox", "acceptInsecureCerts": true, "moz:firefoxOptions": {"profile": "UEsDBBQAAAAIAOtoU04+3NKsfgMAAM0MAAAHAAAAdXNlci5qc6VWTW/UMBC98ytQTyCx1rbABU6lFAkJUcSq4mg59mTjrmMbe7zp/nvGyaYsbb6AWz7e89hvZt44RQjcByhfnBXBNfTGlKtZo61yDVOp9gysKAyos1fPMSR4+f5ZesoxAiGEZE/ApTBxBG2hQVGwFAzhzkThEr4rjLC7sym8F1tYtn5EETB5lhmEXE+jKlfDEblgL49Z3O3p5FoBqyM6266it9YFGFmAPqkb+6MVOJ6vmbYY3O33L9Phc1Jqcc9lFSgwjzJoj5wU56jrHPT1epiwDBnAu4BcGMPvIod7CR61s3Ew6XdiL7plmetgLFau+Wyv6NEZGCRZwMaFHZOCKHtY5XjCrAiw13ImrxFkChoPTMa+HEeAj5PTgJFZr9lSm2IyoZTO5xQzizRQqECHC1zIrCBPlNsUERSXEHBYzRNSjClHfCBp+gBhhtXpwa3IsnLYgx0JJLxnySvqVCYSumEFT0CLWk3p6I04gLo+X2++OqRcEuHNCNg11jihqDAtaRzasvlRgd1k9bXdTse6vv1yyfp2m7SjFvmadVmYsy5td1THYKnsycS6JF/MYcmSOo8cB7uyJPxIpfagAEJlZQBB0k4/6RDxkrSQI230YEOihPaZVFtoiqeMWphGhKV2CiLI6lgWc1BTxuRzc/f2PuajEGO2DiSnJBXayi/J27gMIlYzUSowhskK5O4jlCIZ/ND9mabRDImMjm1v7JVxceYoJ+gbyvgwmBQRnXdmVSsQBqvunS1ytgl+8rlVrv+R3Ucvc0F9T3+/feO22/xRdp7+F/vwzmh5YPnjJhW1bvP8v/xv7cfL3w09tAzs0TkTGTmEC8eNT15f8ugjB2sNtG1rRXPGbnlWfjhG9gjbFm5roh878kYSO7vu+XoUXhgnd0ZHnK6IE0Zb4Feu9mTthTZ5AFq9rdAcZqlLLPwp3JJ/l4fb0UY6GfxTqvajvnP51dEHVzRiMcXhlXtKhUjXtkrH6rDKvz3NxJUBu8VsCRdv3/5J65emqUX5MMY1vDhw1XnC4N48WYzHmLub104Js/DmUWoD9MRc0NQWvKvRfJmawUcMWiJ/TBsKlW+NlqywhrqAsGlfR+TKZb7TyI6y9eP0WMqDB+8pCIYiYDiwTor25Bdz2EmRnsID3LXjbHAn916T7VO2WD4y1QS5PzF+Jh3GIvymNJWmMLmLBhi/AFBLAQIUAxQAAAAIAOtoU04+3NKsfgMAAM0MAAAHAAAAAAAAAAAAAACkgQAAAAB1c2VyLmpzUEsFBgAAAAABAAEANQAAAKMDAAAAAA=="}, "binary": "/usr/bin/firefox", "marionette": true}}
Anyone have any ideas what I may be doing wrong here? And/OR some alternative methods of getting trace logging from geckodriver?
BTW: the moz:firefoxOptions I'm setting may not be correct, they're just the latest combination I have tried, but I can't tell what is going to work until the options I set are actually being sent to firefox.
Environment:
Python 3.6.3
geckodriver 0.24.0 ( 2019-01-28)
Mozilla Firefox 60.4.0
PIP:
requests (2.21.0)
robotframework (3.1.1)
robotframework-requests (0.5.0)
robotframework-selenium2library (3.0.0)
robotframework-seleniumlibrary (3.3.1)
selenium (3.141.0)
setuptools (40.8.0)
urllib3 (1.24.1)
ROBOT:
Open Browser To Login Page
${dc}= CustomLib.Get Desired Capabilities ${BROWSER}
Set To Dictionary ${dc}
... binary ${PATH TO MARIONETTE}
Log ${dc}
${profile}= CustomLib.Create FF Profile
Open Browser ${LOGIN URL} ${BROWSER} desired_capabilities=${dc} ff_profile_dir=${profile}
PYTHON:
#keyword
def get_desired_capabilities(browser):
_capabilities = {'ff' : DesiredCapabilities.FIREFOX,
'firefox' : DesiredCapabilities.FIREFOX
}
browserKey = str(browser).lower()
desired = _capabilities[browserKey]
BuiltIn().log("get_desired_capabilities B4 :" + str(desired))
#THIS IS ASSUMING FIREFOX
desired['marionette'] = True
desired['acceptSslCerts'] = True
desired['ignoreProtectedModeSettings'] = True
desired['headless'] = True
desired['moz:webdriverClick'] = True
desired['moz:firefoxOptions'] = {'log':{'level':'trace'}, 'args':['-headless']}
#desired['moz:firefoxOptions']['log'] = {'level':'trace'}
#desired['moz:firefoxOptions']['args'] = ['-headless']
BuiltIn().log("get_desired_capabilities returning :" + str(desired))
return desired
#keyword
def create_ff_download_profile(path):
from selenium import webdriver
BuiltIn().log('PATH: ' + path)
fp = webdriver.FirefoxProfile()
fp.set_preference("browser.download.folderList", 2)
fp.set_preference("browser.download.manager.showWhenStarting", False)
fp.set_preference("browser.helperApps.alwaysAsk.force", False);
fp.set_preference("browser.helperApps.neverAsk.saveToDisk", 'text/xml,text/plain,application/octet-stream')
fp.set_preference("browser.download.dir", path)
fp.update_preferences()
return fp.path
thanks,
Tom
This is how I set the log level to be trace in Firefox:
*** Settings ***
Library SeleniumLibrary
*** Keywords ***
${options}= Evaluate sys.modules['selenium.webdriver.firefox.options'].Options() sys
${options.log.level}= Set Variable trace
${driver}= Create Webdriver Firefox options=${options}
Go To https://www.google.com
It's basically following this python pattern from the firefox docs and translating it into Robotframework
Hope this helps!
Using phantomjs page.evaluate to extract "resultStats" (div id) from http://www.google.com/search/?q=site:%s works on my local server but not on production server.
NOTE: I'm using the latest phantomjs 1.9.7, however I experienced the same issue with the previous version 1.9.6
NOTE: Phantomjs page.render (on Google home page as well as any other domain name) is working on both servers and creates nice screenshots.
On my production server (Debian stable 7.3 #linode.com) the PHP code below for a top level domain name as the "$url" returns:
TypeError: 'null' is not an object (evaluating 'document.getElementById('resultStats').textContent') phantomjs://webpage.evaluate():2 phantomjs://webpage.evaluate():3 phantomjs://webpage.evaluate():3 null
On my local server (debian testing) the PHP code below for the same "$url" returns:
About 43 results
This happens with any domain name/url I use as the argument - I've tested it on dozens.
What might cause this to occur in my remote production server and not my local server?
gsiteindex.js
var page = require('webpage').create(), site;
var site = phantom.args[0];
page.open("https://www.google.com/search?q=site:" + site, function (status) {
var result = page.evaluate(function () {
return document.getElementById('resultStats').textContent;
});
console.info(result);
phantom.exit();
});
.php
$phantomjs = "phantomjs";
$script = "gsiteindex.js";
$site = $url;
$command = "$phantomjs $script $site";
$googlestring = shell_exec($command);
echo $googlestring;
die();
Well, nrabinowitz was right. I tested it more on my own server using proxies, most timed out, some returned the above error, and a couple returned correct results (well I assume they were correct based on the location the IP address of the proxy - because the figures were a little different than using my ISPs public IP address (calif., USA)).
So it's simply a matter of google blocking certain types of requests from certain IP addresses.
Thanks again for the comment.
Incleude header with user-agent e.g.
header = {'user-asgent': 'Mozilla/5.0 (Windows NT 10.0; Win64; x64;
rv:68.0) Gecko/20100101 Firefox/68.0'}
Withuot user agent you get googles gefault style page without resultStats a also had this issue and adding header helped
Default google search page looks like this
enter image description here